Should you use coding tests during a web development interview?

It’s a hot potato. A question that plunges both recruitment and development forums into flurries of impassioned debate. Should you set coding challenges when interviewing for IT or web development positions? Here’s some guidance.

You are hiring for a web development or programming role. Naturally you want to find the best possible fit for the job. After all, you are committing lots of time and effort to the recruitment campaign, not to mention the financial outlay of a long-term salary for your new recruit. With that in mind, you could set coding tests for your candidates which is what a lot of hirers and recruiters do. But while it’s common, it’s not necessarily a good idea. In fact you could end up offending a candidate who would have been a fine fit for your firm. So then: to test or not to test? Here’s some direction. 

Can you interpret the results?

First things first. You should only test your candidates’ programming skills if you - or someone on the interview panel - can actually make sense of the results. If all that code looks like paroxysms of brow-furrowing gobbledygook, then you have to question the point of this exercise. Why test someone in a specialism that you’re not a specialist in? 

Who should you test?

It’s obvious why recruiters set coding challenges. To see whether candidates can actually manipulate the languages they claim to know. Your new hire’s first day would be a bad time to find out that their skills are rather more limited than their CV claimed.

But be careful. It’s fine to test juniors who have little or no on-the-job experience. But mid-weight and senior professionals can sometimes take offence when they’re asked to prove themselves. They likely have an expansive portfolio of work behind them and advanced knowledge of their chosen languages.

Should you test your candidates during the interview or send them home with a test?

Your choice. There are pros and cons both ways. If you are testing your candidates mid-interview, keep the challenge short and sweet. Your applicants shouldn’t have to write more than five lines of code. But beware that the interview is a high-pressure environment and you may not see your candidates’ best work.

The alternative is to send your candidates home with a test to complete. These can be more in-depth and give you an opportunity to get a more robust, rounded impression of each candidate’s abilities. But, again, proceed with caution.

Chances are your candidates are applying for other roles. They have more than one coding challenge to conquer. Most likely unpaid. You are asking your candidates to commit a significant amount of time, for potentially zero reward which could possibly sour the relationship before it’s even started.  You might want to consider paying them for the exercise.

Ask for a rationale on the choices they have made

Whichever type of challenge you choose to set, ask candidates to explain their decision-making process. It’s a great way to test their problem-solving and communication skills. And you will get a decent feel for how comfortable they are with their specialism(s).

There are other ways of testing technical skills

A coding challenge isn’t the only way to test your applicants’ abilities. Ask them about challenges they have solved in the past. Get them to define technical terms related to their discipline. And, for more experienced candidates, you can ask for samples of code they have produced for previous projects.

Do not underestimate the power of discussion. If a candidate can’t talk about a language, it’s unlikely they will be able to code it.

It’s not all about raw ability

Brawny coding ability is all well and good but that’s only part of the picture. Your candidates need to have the communication skills to discuss technical problems in lay terms that non-IT people can relate to. They need to be astute problem solvers. They need to be adaptable, positive and unflappable under pressure. Do not make the mistake of overlooking soft skills.

Over to you...!

Ultimately this boils down to making sure you hire the right candidate. After all, taking on the wrong employee can be an expensive mistake - both in terms of time and money. If you have any doubts about a candidate, why shouldn’t you set a test?

Yet while testing junior applicants is par for the course, be careful with senior candidates. Asking for sample code from previous projects and discussing their experience at interview is often a better way to extract the information you need to make informed decisions - without offending skilled developers who have already proved their worth on live projects.

You may also be interested in:

>> 8 things millennials want in a workplace

>> How to create a competitive benefits package - on a budget

>> How to choose between two great candidates - in 8 steps