I’ve gotten compliments on the technical challenges I’ve set up for applicants interviewing to join my team… from the applicants themselves.

People don’t always perform well with an audience, and rarely do we code in front of others during our day-to-day. Pair Programing is an over-looked powerful practice, it helps a ton with these anxieties, but that’s the topic of another day.

I believe in take-home challenges — they’re the closest you can get to simulating what it’ll be like working on the job. If you’re looking to see if someone should join your team, it makes sense that you should evaluate the skills they’ll be using on the job.

I work at a security company — my team interfaces with a lot of APIs. I found a public API for superheroes that wasn’t designed very well, so we’re already simulating some of the challenges the candidate would face daily — figuring out how to use poorly designed tools. Then I made up a playful story having to do with impossible travel, which happens to be something we look out for. The fact that it’s a superhero database makes the “impossible travel” amusing.

I won’t go into more detail about the challenge — some mystery should remain — but you get the idea. And by the time you read this we’ll have moved on to some other challenge.

I also don’t believe in burdensome challenges. A take-home should be doable within a couple hours, even if the candidate is given a week to complete the task. This way they can fit it into their own schedule. Often looking for a job can be a full-time job, and doing so while holding down a job can be quite difficult. 

Once the candidate has the time to solve the problem and submit the best work they can in the time given, I find it important to do a code review, to understand how they approached the problem, and to dig into their solution.

The Case for Algorithms, Regardless

There is, however, good reason to test algorithms. An adequate engineer gets the work done; an excellent engineer gets it done well. I always tell my team when they’re stuck: “Make it work, then make it work well.”

Computer science algorithms, like binary tree traversal, or using a stack to manipulate multiple embedded levels of objects, can be difficult problems to solve. There also tends to be several ways to solve a problem: some will take exponentially longer, or take that much more memory to solve. 

It may feel like these are problems that bear no relevance to your day-to-day as an engineer. But it’s important for a hiring manager to see how you solve problems, and to see that you’re considering the right things when you do.

Either way you approach hiring, it’s a two-way street. It’s important to signal in the process how it will be like to work with you, just as you’re trying to decide if you want to work with them. 

And if you’re in the market looking, be understanding of algorithmic technical coding challenges. The more you practice for them, the less they’ll annoy you, and the more you’ll see their relevance for your day-to-day work. You may even learn something and level up.