7 Dos and Don'ts for coding challenge interviews

A coding challenge is an important part of hiring in engineering, and I've seen both sides of them over the last ten years.

Here's 7 do’s and dont’s for coding challenges that I weave into interviewing processes I’ve made and will make your hiring easier and higher quality.

Do: make it clear what the expectations are

Open-ended tasks are good but try to make sure there are at least two key “finishing points” in the problem, for faster or slower candidates. Read through the task and make sure it actually tells them to do something specific!

Don't: make it an algorithmic problem

Algorithm challenges heavily favour university education and computer scientists which will introduce bias into your hiring. They’re rarely a test of real coding problems either. Instead make your coding problem as close to a real-life as you can.

Do: give the option to do it on their own time or yours

One thing I always push for is the option to do a live coding interview or take home test. Some people may find carving 1 hour for a live coding out of a day easier (perhaps they have kids in nursery). Conversely, some people may be nervous and underperform in live coding so may shine better in a take-home test.

Don’t: be ambiguous about how much time to spend on it

Give candidates a clear idea of how many hours they should spend on the task - and make it short. If a candidate can’t show they’re a good developer in under 3 hours, you probably need to make the coding challenge simpler. A take home test can be longer than a live coding interview.

Do: give candidates flexibility on what they focus on

Some developers build great UI, and some are better at building great business logic. Give them a problem that allows them to show their strengths - you likely need multiple strengths in your team. Towards the end of the interview, push them into the area they didn’t focus on to ensure they’re a T-shaped individual.

Don’t: see taking extra time and care necessarily as a good thing

If you’ve set the expectation of 3 hours for a take-home test, and someone has clearly spent 9 hours on it, ask them why. Prioritisation is an important part of being an engineer and taking a large amount more time could imply they were trying too hard to be perfect instead of pragmatic.

Do: continuously improve your hiring process

Your coding challenge shouldn’t be static and should reflect the team you want to build. Need more UI specialism? Focus the question on UI. Want someone who can do TDD? Make it clear in the challenge. Gathering feedback from candidates (both successful and unsuccessful) may help you improve the next interview and get you the right individual.

---

Any other thoughts or things you take to your hiring processes?