Don't Pay Candidates for Interviews

If you ask applicants to write a small application as part of your interview process, it's become de rigueur to pay them a small amount for their time. After all, it's only fair if you're asking them to spend their valuable, expert time in developing bespoke, sample software for you, that they be paid for their time.

We routinely hire new developers (disclaimer: we're not hiring now), but we won't pay you for your time. And there's a solid reason for that. We will compensate you for your time, but not in the way you might expect.

First, let's get the obvious out of the way. Most companies who pay applicants set a fixed rate. This rate is usually very small, but the reason is simple: we've had past jobs offered with hundreds of applicants from all over the world. Even paying a small rate to all of them would have been expensive due to both direct costs and labor costs (we have gotten hundreds of applicants for some positions). And if you're in the US, a $25 Amazon gift card is almost an insult when you've spent hours or days crafting something perfect. But what if we can compensate applicants in a way that's fair for everyone?

What we do is simple: if you get past the résumé/CV screen, we might have a brief phone screen or we might go straight to the technical test. Either way, you get to the technical test that other companies are paying people to take. Ours works a bit differently.

One of our developers first takes the test. They typically take about two hours to complete. Then they spend time making the code "production ready", which, along with technical competence, is what we're looking for in applicants. That takes a couple of extra hours. Let's be generous and say that if you really spend time working on the problem, you'll take about a day to really produce something worth returning to us.

Source: https://unsplash.com/photos/oXV3bzR7jxI

We give applicants a week to do a day's worth of work. And we make it clear that if they take that full week, we won't penalize them for that. We value quality over speed. Further, we don't send the test until the candidate says they have the time to start it. In other words, we give candidates far more time than they need, and the luxury to take it when they want to (given the constraints of how soon we need to hire someone).

And we don't pay them for this. Instead, we offer them something that is not only far more valuable, but offers the same value to everyone, regardless of whether they live in Nepal or New York: a full code review.

We have an established set of criteria we look for—which varies depending on our client needs—and we create custom tests for those clients. We then review every test against that predetermined set of criteria. (Side note: for our software tests, we always check if the candidate has included tests, documentation, and can write clean code). Regardless of whether or not the applicant passed the test, they get the full code review, including numerous links to further resources for those areas that we felt the applicant needed more experience in.

The results have been wonderful. I can't tell you how many times applicants who have failed the test have written to us, thanking us for taking the time to review their code and give feedback. For many of them, it's the first code review they've ever had! For some, we even encourage them to apply to us for future positions when we're hiring again.

When was the last time you had a candidate thank you after not hiring them? Probably never.

To be honest, this approach to evaluating candidates takes a lot more work. We have to hand-craft tests, we have to take them internally to make sure they're fair, and because we have a clear checklist for every applicant's test, we have to be very thorough for everyone. However, it's the right thing to do. We know that even if you don't succeed, we've given you something more than an Amazon gift card or a small amount of money: we've given you concrete feedback on what you need to excel and that will last far longer.

Stop paying people to take your test. Take the time to be fair to them and give them an honest, in-depth level of feedback they've never had before, along with guidance on where to look for more information to improve. Even if you don't hire them, you know that you've done the right thing in helping them even if they don't currently have the skills to help you.

Update: due to comments elsewhere, I'd like to be clear that our tests absolutely do not cover work we're actually doing and we do not use candidate code in our production code. We strive to be ethical.