Recruitment

Stop making candidates do massive tech tests

Not so many years ago applying for a front-end development job used to involve writing a CV, linking to some sites you’ve built, and answering some questions in interviews. In recent years though it feels like much of that has disappeared in favour of an endless grinding procession of tech tests.

Now before I go further I should disclaim that I’m not writing this article with any particular company in my crosshairs. Rather it’s based on my experiences (good and bad) both as a candidate and as someone who’s participated in and helped design recruitment processes for several organisations.

The other thing I’d say right off the bat, is that technical recruitment is hard. It takes a lot of care and consideration to do it well and in a way that is effective and fair to both the hiring company and the candidates.

So with all of that out of the way…

Your tech test should not be step 1 in your recruitment process

I’d hope this would go without saying, but when someone applies with their CV please read it.

For any role except the most entry level someone’s prior experience is going to be highly relevant for whether you chose to progress a candidate or not, and that should be clear from their CV alone. You’ll be doing both them and yourself a favour if you can exclude a clearly inappropriate candidate without moving them on to the more time-intensive parts of the hiring process.

Personally, I also favour a short technical phone interview as a way to quickly and easily whittle down candidates.

Okay, so you’ve read their CV, maybe had a quick chat with them on the phone, but you’ve still got your heart set on them doing a tech test for you. Here’s how to do it right;

Your test shouldn’t take more than an hour or two to finish

Yes really - 2 hours max. And that’s for two very good reasons;

It’s going to immediately exclude some applicants

“But if you care enough about the job you’ll find the time” I hear you say. And you’re right that a large tech test will tend to weed out any but the most enthusiastic candidates.

But it will also exclude a lot of the people you WANT applying. People who already have a busy job for example, who may well be some of the stronger candidates. Perhaps more importantly, it will also exclude anyone with caregiving responsibilities, chronic illness, or other significant asks on their time.

It’s important to remember that the amount of ‘free time’ people have varies massively based on someone’s life circumstances. There’s a reason so many posh people work in industries that regularly require unpaid internships as entry positions - they’re the only ones who can afford to clear that hurdle and wait it out for one of the paid jobs.

If your tech test requires someone to do a day of unpaid work (or more), you’re giving a leg up to people with more money and less responsibilities, and a raised middle finger to everyone else.

In short: large tech tests increase barriers to hiring diversity.

A larger test is harder to evaluate

How can you tell the difference between someone who mostly avoids CSS because they’re not confident with it, and someone who’s CSS skills are absolutely fine but they work a full time job and they’re also spending time interviewing with one of your competitors?

How can you tell the difference between someone who is routinely lax with their test writing, and someone who already spent 6 hours doing free work for you and has thrown in the towel?

You can’t. And so your ability to evaluate a large test fairly is always hampered by not knowing if candidate A is a less strong applicant, or if they just didn’t have a whole weekend to spend on it like candidate B did. You’re making things harder for yourself by creating an uneven playing field, and the larger your test is the more skewed it gets.

So how do we fix it?

Cutting your bloated test down to size

By far the easiest way to take your too-large tech test and cut it down to something more manageable is to just provide a partially completed example to the candidates. That’s right; you’re just going to do some of it for them!

Let’s say your test involves building a search results page for some public API. Rather than making someone start from scratch, provide them with a basic app shell ready for them to build the new page into.

Or if you’re asking them to code up a given design in HTML and CSS, why not start them off with the textual content already provided in an unstructured document. Or with some basic partial styling that needs to be fleshed out and finished off.

No matter what your test is, there’s going to be a way for you to provide the candidate with a bit of a head start that takes out some of the grunt work.

Not only will that cut down the amount of time it takes to complete the task, but it’ll also provide a couple of additional benefits;

1. See how well the candidate is able to adapt to an existing style

Let’s face it, when’s the last time you got to start a totally new greenfield web project from scratch? Almost never. It’s probably about 1% of your job as a developer.

So wouldn’t it be better to test the 99% of the job - extending or improving an existing piece of technology?

Not only is that a much more realistic test case, it’ll also allow you to see how the candidate deals with working in a style or architecture that may not be their chosen one. (NB: ideally the coding styles and technologies in your tech test should closely match what you expect them to use in your organisation).

If they can recognise the patterns that you’ve used and comfortably apply them to new work to finish the test then that’s a big tick for someone who’s going to fit in easily as a team member. If they totally ignore it or worse still pointlessly refactor it to suit their personal tastes, then buddy you just might have yourself a diva.

2. You can deliberately leave areas to be improved

Just because you’re providing a partially completed test to your candidates doesn’t mean it needs to be perfect.

I wouldn’t recommend giving them a piece of code that’s going to totally bamboozle them with hidden fatal flaws, but there’s nothing to say you can’t make some judiciously chosen mistakes here and there and give them an opportunity to fix them.

This could be;

Get creative! Anything you’re interested in testing I’m sure you’ll be able to find a way to build into your partial test, and often in a way that would have been impossible when asking someone to build it all from scratch.

Got something to add? Join the conversation