Tech tests are a red flag

I’ve had this conversation at least 5 times in the last 2 months, so I’m writing it down as a reference.

First, some background. You’re hiring a new developer. You have a team of people that are under the kosh, and you want to get them some help to make things better. Another developer (or 2 or 5 or a whole team) should solve the problem. But how to ensure that the people you interview are at least competent developers, before spending any time on them? Enter the technical test.

People often think technical tests are a good way to identify whether somebody can write the code necessary to do the job. Tech tests are frequently used as an initial screening tool. It usually goes something like, job ad -> CV screen -> phone screen -> tech test -> tech interview -> fit interview -> offer. Sometimes the tech test comes even before the phone screen, and I’ve seen it done as part of the CV submission. There are many things wrong with any variation of this process.

Technical tests are based on a misunderstanding of the interview process. Interviews are a time commitment from both parties to talk and see if they’re a good fit for each other. It’s not a one way process. A technical test, on the other hand, is one way. It requires no time commitment from the company until submission, and sometimes not until the resulting interview. Imbalanced interview processes are a red flag.

Technical tests are usually sent out before the candidate is invested in the company. So, before you have got candidates excited about joining you, you’re asking them to work for free. The people who are willing to invest their free time in your company is a subset of the people who would be a good fit for your company. You are going to lose people who have other things to do, don’t work for free, are exhausted after working at their current stressful job, and a bunch of other things. Unless your company frequently forces people to work overtime, a technical test is sending a message that filters people out in a way that’s arbitrary from the company’s viewpoint.

Technical tests focus on the wrong things. Lots of other people have talked about this, but let me just say that I have never worked in a company where developers were completely isolated, couldn’t ask questions, had artificially short deadlines, and didn’t have somebody they could bounce ideas off of.

Candidates that I want to talk to are those that are curious, communicate well, can find simplicity in seeming complexity, can write simple code that clearly communicates complicated subjects, and are eager to teach and learn.

Technical tests are based on a misunderstanding of the development process. After 20+ years in IT, one of the things I’ve learned about development is that the vast majority of a developer’s time should not be spent cutting code. In fact, writing code often accounts for 20% or less of their time. The skew gets more extreme the better a developer someone is, and the more mastery they have over the language they’re using.

In the end, whether or not to use technical tests is about what you value. If you value your employees’ time over potential employees, isolation over collaboration, deadlines over healthy staff, your convenience over candidate considerations, cutting code over solving problems, then maybe technical tests are the right thing for you. But if that doesn’t sound like you, maybe it’s time to rethink it.

If you want to know whether someone can do the job, make the interview process a reflection, as much as possible, of the work that’ll be expected of them. If you want to know if they can code, pair with them. Solve problems together. Hire them for a day to work on what your team is working on. Ask them to talk through what they’ve done. Get them to bring code they’ve done previously. There are many, many ways, to filter candidates while respecting them. Use them.