Introducing take-home exercises to my hiring process.

Problem

I was on the fence about hiring someone and making them an offer. Passing on good candidates is always tough, as you invest so much time during an interview process. His interview went fine, the team liked him and his code quality was acceptable. However, I wasn't sure that his code was great. One of Netflix's core promise for employees is that you'll be working with awesome colleagues and as a manager, and I try to carry that around. So I had to decide, should I take him or should I not?

Actions taken

I decided to do something I wasn't used to - ask the candidate to do a take-home exercise. I built up an exercise for the candidate to do in 24 hours, which was more than sufficient. When he came back with the exercise, some of the concerns I had about his code quality were concerned. His implementation was okay, but if I had used his solution I would continually be reconciling bugs, as his edge cases were not thought through. We, therefore, ultimately decided to pass on that candidate.

Lessons learned

This event made me rethink my position on take-home exercises, as I believe it helped to prevent me from hiring someone that would not have been a good fit. However, at the time, I was not a big fan of those exercises because I thought it caused a lot of friction with the candidate, that they were hard to organize and that they were not respectful of the candidates' time. I realized that using coding whiteboard exercises does not yield accurate results. It creates an artificial environment, in which candidates may suffer pressure and the fear of a blank canvas. I think it's not the approach we should have regarding software development in this era, given the teamwork, powerful IDEs, and Google searches all used in day-to-day software development nowadays. While I do use some whiteboard exercises to validate some fundamental understandings, when I need to test the quality of a candidate's code I tend to lean towards a take-home exercises.