Coding challenges in interviews

I'm interested in hearing people's thoughts about coding challenges in the interview process. After years of iteration as a hiring manager, I have had the most success with take-home challenges. Here's an abbreviated example prompt:

Using the frontend technology of your choice, build an application that lets users search through an image API (such as Unsplash or Pixabay) and save the images they like locally.

Please send us your code when you are satisfied with your work. Note that we value clear, readable, and maintainable code. We expect this exercise to take a maximum of 4 hours. Please email us if you need any clarification.

The point of not having a deadline for submission is to be cognizant of people's busy lives and schedules - looking for a job is a time-consuming process. The open-ended requirements allow people to use the technology they're the most comfortable with because I want to see people's best work.

However, I've received feedback saying that some candidates prefer alternatives to take-home challenges:

• whiteboarding solutions with someone in real life
• live-coding a small app or algorithm (remotely or on-site)

But to me, the most surprising piece of feedback was that some people don't want to be tested: they expect their title and experience to speak for itself. My opinion is that code challenges aren't about proving or disproving one's experience: they're about understanding how one thinks, collaborates, and problem-solves, and there's no way to glean that from a resume.

Discuss 🔉

So, in order to improve the lives and chances of everyone involved, I turn to you, friendly dev.to folks:

• what do you think about coding challenges and take-home tests?
• if you could pick, how would you demonstrate your coding and problem-solving skills to an interviewer?
• are there some biases or problems you'd like to call out with any of the methods you've experienced?

Comments

[drew.tech]

We did take-home tests for awhile at my last company. We found that when the market is strong, experienced developers don't want to spend time on take-home tests.

Instead of doing a take-home test, we did a paired programming challenge on a similar sample. This way we tested their communication skills and dev ability at the same time.

The people who don't want to be tested at all though are crazy. It's still a job interview at the end of the day.

[Maxime]

Thanks for your insight, Drew! There's a lot of value in testing communication skills with a pairing exercise.

I'm curious about why candidates would prefer pair-programming over a take-home test if lack of time is their main issue. It sounds easier to spend a couple hours working on some code over the weekend instead going in for an on-site interview.

[drew.tech]

Our entire process (minus commute) was less than four hours.

Personally, I feel like taking something home is a chore, whereas collaborating during an interview feels engaging and gives me a glance at the company’s culture. As they say, an interview is a two way street.

If you can optimize your entire interview process to be respectful of a candidate’s time, you will get more great candidates to say yes.

We solved this with:

• one remote tech screen (30 mins)
• on-site culture convo (30 mins)
• on-site pair-programming (45 mins)
• on-site whiteboard session (45 mins)
• on-site debrief with hiring manager (30 mins)

All of the on-sites happened on the same day. Through the process, you met two random employees, four developers, and the hiring manager.

This helped us get to the offer stage ASAP and let the candidates interview the company throughout the process.

[Maxime]

That sounds very efficient, thanks for sharing!