Are Coding Tests a Load of Rubbish?

Coding tests are sometimes placed at the first step of the interview process. But, is there any real value to these tests, or have they just become a standard procedure, packaged as something useful when, in reality, they’re an unnecessary hurdle for candidates, and possibly doing more harm than good to your hiring process?

Put it bluntly, are they a load of rubbish or not?

Why are coding tests useful?

Most things that grow in popularity have redeeming qualities, yes even drum and bass. So, here are some reasons why you might want to consider introducing a coding test to your hiring process:

• Unknown companies: If you come across an ex-Googler or an Amazon whizz, you can probably argue that their experience speaks for itself. But what if a candidate has gained expertise in more humble settings, let's say at a smaller, lesser-known company? In that case, don’t coding tests level the playing field, so that candidates are evaluated on their skills rather than the notoriety of their previous employers?
• Logistical nightmares: Applications, especially for generic job titles like ‘senior backend engineer,' are skyrocketing. When the sheer number of CVs makes it impossible for your team to give each the attention they deserve, then adding a step to help manage the volume could be a sensible thing to do.
• Skills > everything: A cultural fit is important. But, if you’re hiring for a contract role, or a project sprint, then raw skills take priority. You’re going to want to hire 10/10 developers who can roll up their sleeves and get to work, and the most straightforward way to assess their suitability is through a test.
• Can they walk the walk? Last year, we all experienced the ‘great flattening,' aka the largest tech companies laying off staff left, right, and centre, with product managers receiving the most heat. In Elon's own words, companies are looking for managers who can ‘write a meaningful amount of code themselves.' But, it’s not always easy to tell if someone is hands-on because to put it politely, some candidates ‘exaggerate’ their abilities, placing a programming language at the top of their CV, despite not touching it for years.

What’s wrong with coding tests?

Whoah, it got a little too pro-coding tests there. There are definitely a few flaws that could be impacting your hiring process, to name a few:

• Alienating talent: I've seen seasoned developers with over a decade of coding experience bail out of interview processes, and you know why? Because they're offended. They've climbed the career ladder, bagged promotions, and manoeuvred through multiple roles, and now they're expected to prove their skills through your test.
• Wanting something for nothing: Let's discuss take-home tests that require a significant portion of a candidate's life, including their evenings and weekends. Did someone say #unpaidlabour? You're asking candidates to pour their time and effort into your hiring process, but here's the kicker – they haven't even had a chance to meet a single soul from your team or fully grasp what the role is all about.
• Missing passive talent: Ever wonder who's more likely to do something for nothing? Someone who doesn’t currently have a job. This means your coding test could be filtering out a pool of passive talent who might have spotted the role and showed interest, but bounced the moment they saw the lengthy selection process.
• Don't underestimate a culture fit: We've all had that toxic co-worker who drains the life out of a company. Particularly for startups, culture fit and personality bring heaps of value. Sometimes, having a 7/10 developer on board can be a smarter move than a 10/10, especially if they're strategic thinkers. It's about building a team that clicks, not just a bunch of individual skill sets.

• Understand the limitations: I'm sure you walked out of a school exam wondering, “what on earth was that?" despite it being your best subject. Coding tests are a bit like that – just a snapshot. They can't fully capture what someone brings to the table. It's like trying to judge a movie based on a single frame – you're only seeing a fraction of the full picture.

• Learning curves are steep: Just because someone doesn’t have all the skills today doesn’t mean they won’t have them tomorrow. For example, if a candidate is well-versed in AWS and is put into an Azure environment, they’re going to pick it up extremely quickly. Remember, candidates aren’t going to know every single language or framework, but they’re often interchangeable. So, within two weeks, it’s completely possible for them to be up to speed.

So, are coding tests a load of rubbish?

You’re not going to get a straight answer from me. While I hate to come across wishy-washy, I think there’s a middle ground.

For high-volume junior positions or mid-level roles, I completely understand using coding tests. There's just not enough time in the day to fairly review each applicant individually. Plus, when they're junior, experience isn't a great differentiator, making it tough to benchmark candidates against each other.

But when it comes to senior positions, coding tests can start to do more harm than good. Senior candidates have a wealth of experience, have proven themselves over the years, and, most crucially, are short on time. You risk losing top talent because, at their level, they know the value of their time.

Coding tests shouldn't be slapped on with a one-size-fits-all approach; you need to consider the seniority, the type of position, and how you want to use them. I wouldn’t recommend placing a coding test at the first stage of your interview process, and if you do, it should be short, as you don’t want to ask them for too much without providing them with anything in return.

You should also consider the alternatives where possible. Why not ditch the test and opt for a good old technical interview instead? That will not only allow you to evaluate a candidate's skills but also provide them with face time and a deeper understanding of the position.

It can be a win-win.