The idea of an audition project comes up frequently in recommendations about hiring and interviewing, most recently in HackerEarth’s Technical Interviews: What’s beyond the Fizzbuzz challenge. I find points 1-4 solid and insightful advice, but point 5 – the audition project – irks me.

After clearing the hurdles of the interview itself, the candidate is to be given a small real project to be completed in about a week or so. On the face of it, the idea has a lot going for it: Nobody disagrees that there are no better ways of evaluation a person’s skill than their actual performance on solving a real, relevant problem with the team. But I am rather bearish on the idea:

First, I plainly don’t think it’s fair to request of a candidate to invest a whole week into a single application. If they are out of a job, it’s easier to achieve, but if the person you are hiring already has a job or is finishing up university, it gets tricky. Most people in good jobs can probably take a week of vacation on short notice, what if the offer doesn’t come through? Then another, and another? You’re putting yourself in an increasingly exposed position, and keeping your interviewing secret from your current employer gets all but impossible. Also, I don’t think it’s unreasonable to interview to the final stage at two or more potential jobs before making a call. This practise will make that all but impossible to achieve.

Second, few teams have a cache of such problems.

The problem must be well defined and documented and as good as free of proprietary dependencies - if we are to get good signal from just a week’s effort, it can’t be spent on getting to know the intricacies of your existing codebase or understanding the problem to begin with.

I mean ‘proprietary’ very broadly, not just that very-closed-source homebaked collection of libraries and middleware that has grown organically for the past five years that you know you should get rid off anyway. I mean basically anything that assumes business or product knowledge beyond what a candidate can reasonably be expected to learn from your website. Unless your team is working on a quite popular open source project, that means pretty much all your code.

One of the reasons outsourcing is so difficult is that shared context is key to effective communication and understanding. The exact same constraint applies here.

Maybe I’m not thinking hard enough, but I struggle to think of even a few tasks that fit this bill from my last three jobs.

Finally, the real killer is the simple fact that the team needs to work with this person to evaluate them, and so the team needs to invest time, effort and emotion into getting to know this person, and suffer the morale impact of making the no-hire decision – to fire the person. After all, as a part of your hiring process, you’d want signal from it: A substantial portion of the candidates should fail at this stage.

We need to make the interview process better, but the audition project is not it.

Discussion welcome at Hacker News