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 5 day unpaid technical challenge as part of an interview process that’s probably not a positive signal.

A good length is around 30 minutes and never longer than 90. Challenges should be short enough to complete in a single sitting.

Open Ended

You can’t judge a candidate solely based on their response to a technical challenge. A response is something to talk about in the next interview. When you sit down and have that next discussion, it’s great to be able to ask questions like

“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! Takehome challenges are great for increasing diversity in your hiring process. Stay tuned for a whole post on this soon.

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.

More commonly, the challenge is so difficult that 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 means of telling your candidates apart from one another.

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. Let a bit of 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 get better responses that you’ll enjoy reviewing and discussing much more.

Check these out

Takehome’s sample challenges fit these criteria. Sign up today and have a look.

— David Banham, Takehome