Ask HN: What is your process for code challenges during recruitment?
This question is directed at people who use coding challenges to help assess candidates for developer roles. What is your process? What tools do you use? What sort of challenges do you have? Do you have different challenges for different experience levels? How about different roles e.g. front env vs. back end. Are you proscriptive in tech choices? Do you have time limits/expectations? What level of feedback for you provide?
Basically I would love to hear all the details (including minutiae) from when you start the process, to the end.
5 comments
[ 2.6 ms ] story [ 26.0 ms ] threadThey take as many days as they need, then come back and conduct a code review of their code with our team. This shows us how they approach coding, how they think through problems, how well they communicate their thinking, how much curiosity they have about the their own solution, how they respond to criticism.
We like this approach because it is much more reflective of how developers actually work than white board or academic type testing. It tells us where their intellectual focus is, their level of humility about learning from others. Surprisingly, what they can teach us. We've had young applicants stump 30-year veterans, which was awesome.
So far, we've had nothing but very strong hires with this approach, and the applicants have all said they very much appreciated how we roll.
> we send them home with a set of 5 coding tasks.
How do you provide these tasks? Via email? Links to GitHub repos?
> come back and conduct a code review of their code with our team
How does that usually work? Does it happen in their editor of choice? On a company machine or theirs? Do they submit a PR? Do you take a look at their submission before inviting them back in?
> They take as many days as they need
Is there an expectation that they would spend days or effort? Or just a few hours? Do you try and adjust expectations of code quality for the time they dedicated to the problem?
> So far, we've had nothing but very strong hires with this approach, and the applicants have all said they very much appreciated how we roll.
That's great to hear it's working so well. Thanks again for the thoughtful response.
Code reviews are casual. Usually, they plug a projector into their notebook and show us their code in whatever editor they wrote it in. We have 3-5 engineers in the room, they ask questions about the code structure and approach. It's been respectful and positive.
We give them days because most are full-time employees and in many cases have long work days. Giving them flexibility allows them to fit the work into their schedule. Note that most wind up spending much more than the 2 hours and in many cases, take the task much further than is required. We've had 2 hours as the least and in one case, 12. We keep the ask small to respect their time, but love to see them get engaged with it.