Last time we established why code challenges are important. Now it’s time to talk about what separates a good challenge from a bad challenge. Stick to the following principles and you’ll get something great.

Concise.

You want great people. Everyone wants great people. Therefore, it’s pretty unlikely that your candidates are only going to be interviewing with you. If someone has time to do a five-day unpaid technical challenge as part of an interview process that’s probably not a positive signal. The best candidates are spending that time in other interviews.

Challenges should be short enough to complete in a single sitting. A good length is around 30 minutes. Never produce a challenge that will take longer than 90 minutes.

Open Ended

You can’t judge a candidate based solely on their response to a technical challenge. A response is a jumping off point, something to talk about in the next interview. When you sit down and have that next discussion, you’ll be able to ask relevant, useful questions such as:

“What if this requirement changed in this way? How would that impact your solution?”

or

“This code now needs to serve 10K concurrent users. Which parts would be the bottleneck? How would you start to deal with them?”

or

If you had more time, what would you do next?

Discriminatory

Discriminatory? Not like that!* In this context, we mean the challenge needs to be able to discriminate between skill levels. If the challenge is so simple that everybody gives a “perfect” answer, you haven’t learned anything about how your candidates compare to one another.

A more common pitfall is that the challenge is too difficult. If it’s just too complicated nobody can get anything meaningful done. This has the same effect as if all the responses were clustered at the other end of the bell curve. It doesn’t give you any way of telling your candidates apart from one another.

Protip: have some of your existing employees complete the challenge before you give it to candidates. That will help you to establish a baseline against which to judge responses.

Relevant

If you’re hiring an engineer to build a new database engine, don’t ask them to style a webpage. If you’re hiring a designer, don’t ask them to evaluate big O complexity of algorithms. Make the challenge relevant to the role you’re hiring for. Make it look and feel like what this candidate will need to do on an average day on the job.

Fun

Life’s too short for work to be boring. Let your team’s culture and spirit show in your challenges. The more fun and interesting the challenge, the more engaged your candidates will be in the process. You’ll send positive signals about your workplace, receive more enjoyable responses, and make the rest of your hiring process easier.

Check these out

This may sound like a lot of variables to keep in mind. If you want to start with something premade, or you just want an example to work with, Takehome’s sample challenges fit these criteria. Sign up today and have a look.

— David Banham, Takehome

  • Takehome challenges are actually great for increasing diversity in your hiring process.