Many, perhaps most, technical IT jobs these days require some form of the take-home coding assignment as part of the interview process. These vary from algorithm exercises, such as “write a bubble sort function”, to a more complex “write a web application to sell flowers via a REST API” types.

A few years ago, I worked with a company that did one of these more complex types, and it was the first stage of the interview process.

That is to say, as soon as HR received an application, they asked them to do the assignment. Only once the assignment was complete, was the candidate’s résumé, along with the completed assignment, shown to any technical hiring manager (usually me) and asked for a pass/fail to move on to the first human face-to-face interview.

This policy had been put in place by the founding CTO, and remained in tact long after his departure. His reasoning was that it saved a lot of time for the hiring manager, since they wouldn’t be forced to interview candidates who didn’t have the coding “chops” we desired.

Today I want to discourage you from doing the same. I think this is a harmful hiring practice for both the candidate, and the hiring manager. Here’s why:

• This is incredibly time-consuming for the candidate. As such, many candidates (those in highest demand) simply won’t complete the process, and will thus be inappropriately filtered.
• It’s actually quite time-consuming for the hiring manager, too. This company (to their credit) had a policy of providing detailed feedback to every job applicant. This meant that reviewing these coding assignments took at least half an hour, and often longer.
• Coding assignments probably aren’t very realistic tests of a developer’s ability, anyway. I’ll talk more about this another day.
• Personally, I find the ethics questionable of requiring an unpaid, multi-hour take-home assignment for job applications. In my view, even throw-away work like this ought to be paid if it’s required.

What alternative should you consider?

Well, the obvious thing to change is to do the take-home coding assignment as a second stage. This allows you to do an initial screening first, and only ask candidates you’re serious about to invest their time on a take-home coding exercise. While this is an improvement to be sure, consider these other alternatives as well:

• Ask the candidate to provide some code they’ve already written.

  It could be from a hobby project, a previous employer (assuming no NDA), or even a take-home assignment for another job application. I’ve written more about this from the applicant’s perspective in the past.

• Do a much shorter technical screening as the first step.

  This could be as simple as one or two questions that a non-technical HR person can be trained to ask. Some examples, which can be adjusted to match your tech stack and target seniority level, if you desire:

  “What’s the difference between a hash and an array in JavaScript?”

  “Can you give an example of a time you would use a closure?”

  “What are the steps you take to compile a program in Rust?”

  The ideal questions at this stage require a bit of technical knowledge, but can’t be faked by random memorization of minutiae. Also, the answer matters much less than how they answer, which makes it easier for a non-technical recruiter to grade them. If they answer quickly and confidently, they probably pass. If they stumble around, they don’t.

• Use a shorter take-home assignment.

  The most often cited reason companies I talk to give for doing take-home assignments is “so we can discuss the implementation with the candidate.” You don’t need a full-fledged, 8-hour REST application for this. Use an assignment that takes only 30 minutes to complete. You can still ask about trade-offs and design decisions with 30 lines of code. Any “realism” offered by a longer project is mostly imagined anyway.