In defence of technical tests

Development May 20, 2020

I've just undergone a round of recruitment to expand my team at work.  We're a small, steadily growing team.  But when we hire someone, I want to understand their thought process.  That's why we ask them to code as part of the interview process.  Having seen some posts on LinkedIn against tech tests, I'm here to defend them.

My normal recruitment process involves a small section of the interview where someone works through a series of problems.  I break these down into 3 sections:

  1. Look at the problem, and explain how you'd solve it
  2. Solve the problem in the manner you described in 1.
  3. Refactor part of the existing code

This is great when you're side-by-side with someone, but doesn't work great via video conference.  So we changed it this time round to a take-home test.  Unfortunately this makes the test longer; which is the main gripe of people who take tech tests.

I understand why you hate them

The main issue people have is the time a take-home test takes.  Usually in the order of a small number of hours.  That's a big commitment to give a company when you might not even pass their standards to progress through the interview.  I don't know if it's worse to spend that time up front and get rejected for an interview, or go through the interview process, and get rejected for code.

Personally, I think it's better to fail early, so I issue the tech test first.  This seems to be quite common.  For those who would argue "but I come across well in an interview"; that's kind of the point.  Very few people are really themselves in an interview.  They put on a facade, however small, to improve their chances.  I'd rather waste 30 minutes checking over a tech test than spend a couple of hours interviewing someone only to find they can't code.

Yes, I've seen some of your GitHub code

And I've also seen that it's not all your code.  It's forked from another project, or has several contributors (that bit is good, though), or is so old and unmaintained to be irrelevant.  GitHub, GitLab, Bitbucket, or wherever you decide to host your public projects will generally only have code you are absolutely happy for the world to see.  Things you've spent hours and hours on, mostly to show off.

Yes, I've also looked at your StackOverflow profile. I can see you understand some of the concepts you're answering questions to.  But those are clearly in your comfort zone.  They are also going to be answered at a time when you are less likely to be under pressure, without a job riding on it.

So yes, tech tests are great

They give whoever is recruiting a chance to see how you tackle a problem which might not be in your comfort zone, and to do it in a time-limited manner, rather than having days, weeks, or months to refine it ahead of it going public.  They give an insight into the way you think of solutions, and then execute them.  Let's not forget it helps to ensure you can, hopefully, accomplish something basic in the specified language.

Like most people, I hate doing tech tests.  But I understand the reasons behind them, and the benefits they bring to the recruiter.  I'll do them as and when I need to, but don't make it take days to complete.  That's only going to leave a bad impression of your business.

Tags