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.
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?