Regarding Technical Code Tests

Quick post with some personal thoughts regarding the last Code on the rocks podcast, which was about recruiting and human resources, but it mentioned the topic of technical code tests for candidates.

First, a confession: I am quite terrible at doing code tests, due to two main reasons:

• I tend to get nervous, so I try to complete them in one sit even if given more time (like "the weekend")
• I always time-box them if they aren't limited in time

When I start a code test, I get into a state I can only think about it, so my normal life gets disrupted until I'm done. I'm unable to take long breaks, or sleep and then continue. I also know it can be harmful for me to time-box when I could instead take advantage, because I could for example do multiple iterations using the extra time to improve something, but my reasoning here is:

• This is a test, so for me the rule "is take it as such, a test": not strive for perfection but "what you'd do in a few hours most"
• My time is precious. I'm not going to spend a whole weekend with an unpaid code test, I'm sorry

I've only done 4 code tests in my life (out of 10 companies I've worked/work at):

• one I nailed it
• other I did well enough to get hired
• one I failed (there were external factors but I still had mistakes)
• the 4th wasn't evaluated as I got hired elsewere and they stopped the process. I'd like to think was going to be ok

Asking for a code test it's a standard practice, and in some scenarios it is one of the few alternatives (e.g. remote work), but I dislike them as it is hard to be trully fair/objective evaluating them. It is also quite hard to come up with unbiased coding challenges, too easy to fall into either algorithmic ones, or too specific/narrow problems that while you might actually be working at if hired, you might as well not have faced before (so is not fair to ask about them). And most times there's a subjectivity factor upon the reviewers: They might not like your style of code, they might have their biases and/or preferences, and sometimes happens that they might be reviewing the code for the first time and think there is only one "correct approach".

I instead prefer other alternatives:

• do an actual job task (or bugfix): getting paid for it as will take some time, but is a nice way to get the feeling. The main problem of this approach is it's really hard to do while working
• "work with us for a week": Similar to previous one, but becoming a member for a certain time. Best way to see (both sides) if there's a match, you're part of meetings, etc. and not just of a specific task
• doing a real task while pairing with an actual engineer from the company, so you don't get overwhelmed by doing something without knowledge of the scenario/context
• if not the previous one, at least doing a code test but live with a peer from the company, in a constructive way. Probably will make you nervous but at least you're able to explain your reasonings and the other side can also ask you why you take some decisions

Also, one thing I think it is critical is to give feedback to the candidate. I'm not saying you should reply with the failure points, but at least give some general feedback so they can improve. After all, they gave you time and effort by doing it.

And finally, coding tests are a cheap way to filter candidates for the recruiting deparment, but they do take effort both from candidates and from the technical side of the company (preparing and reviewing them). Effort that sometimes the recruiters could also spend filtering their targets instead of blind-shooting everywhere. This is a complaint because I've seen and still see so many bad examples.

For me code tests just work as a filter but act like a double-edged sword. I know of a few good engineers who have failed code tests, and I've met other people who probably were good "coding" but were not somebody I'd be happy to work with. As usual, there is no silver bullet.