Assigning potential employees a software task to complete before their interview has become normal. Is this a bad practice?
It assumes that the candidate has or can quickly get all the equipment and programs necessary. It assumes that the candidate, who is often already working full-time and may be going through multiple job application processes, can take the time for it. Not paying for work that candidates do is mildly exploitative (and wildly exploitative if sample work is used without hiring the candidate, though that’s more likely to happen in fields like design). It assumes that the candidate will do the work themselves and be honest about how much time they took and how difficult they found it.
So yes, I think this practice has problems.
Why am I still using at-home programming challenges? Because it gives me a realistic look at the candidate’s current abilities. Many candidates don’t have an up-to-date self-written code sample just hanging around, and their work for other companies can’t be passed around as easily as a designer shows a portfolio. Asking for a small programmatic task that can be completed in a few hours levels that playing field and allows me to compare candidates’ ability on the exact same task.
How could I achieve the same result without the unfairness?
If we keep the premise that there’s a good reason for the take-home challenge and it must stay, there are some changes we could make. Offer to let the candidate come into the office and use company equipment, or create a set-up that allows them to upload their code to a test environment and run it there if their own computer isn’t equipped for local development. Pay for their time. Offer feedback on their work if the candidate is not selected for moving forward in the process.
Aside: My experience giving feedback to rejected candidates has so far been 100% positive. Aside from qualitative feedback on their actual code, see my follow-up post on Friday for some advice you can give them.
If we throw away the take-home challenge, the best alternative I have is live pair programming. Having the candidate as the navigator and an experienced programmer from our side as the driver means that the candidate doesn’t have to worry about having adequate hardware, accidentally sharing the wrong screen, the exact syntax of the code, or making stupid typos in an interview situation. We also have a third person present who mostly observes but occasionally jumps in with questions.
The biggest advantage to pair programming is that you already get a good feeling for how it would be to have this person on your team. A disadvantage is that a candidate may be more nervous and not perform as well as they would if they were working alone with more time. And it’s important that the driver lets the candidate navigate without taking over the session.
Relying solely on resumes, references and more traditional interviews is tough to do in a field like software development, where differing branches and standards mean that code quality is at times highly subjective. It’s important to have a look at candidates’ code – the question is how to do it in a way that shows the hiring manager what they’re looking for without creating unreasonable impositions on the candidate.