Very true points. Of all the "hiring is broken" articles I've read, this is certainly one of the most grounded. THANK you.
My company does indeed use a coding challenge for technical screening, which candidates have a week to do, between the first and final interviews. It is designed to be simple, but strictly analogous to the sort of work we actually do, instead of trying to be clever. Rarely does it actually take more than an hour or two to do, but the week-long window in which to submit it gives plenty of breathing room in which to do be able to do it to one's own satisfaction.
When it comes to reviewing it, we don't look for a particular solution. There are, in fact, countless viable ways of accomplishing the goal in the challenge spec. Instead, it shows us the developer's general working proficiency in the language, as well as their coding patterns, styles, and habits. There's a world of difference between someone who uses an "unguarded" while loop and, say, a properly iterative approach. Of course, whether either is even called for depends entirely on their solution.
(Also, during the final interview, the interviewee is given time to freely explain their solution and their logic for it.)
I have a challenge review form for myself and the other interviewers that keeps our review of the coding challenge submissions focused on the right things, instead of arbitrary "I wouldn't do it that way", and we compare notes before the final interview to resolve any discrepancies between our scoring, thus keeping it objective. Since we've been using the same coding challenge for several years, we can even compare an interviewee's scores to those of previous hires; by this point, we've actually found some fairly reliable patterns.
Developers shouldn't be allowed near a candidate, ever. Unless they have some basic people skills and empathy, they should stay away from recruitment processes completely. (...) Maybe developers who lead teams are an exception. They made it there because they're good both with code and with people.
Another exception is if they are specifically trained to add value to the recruitment processes. I've allowed a number of my developers over the years to be involved both in reviewing the submitted coding challenge and in the final interview. Any developer involved in the interview meets with me well in advance to discuss the candidate, the questions we'll cover, and the proper way to handle the interview. I am very careful to train them to show empathy, recognize and bypass their own biases, and communicate appropriately.
As a result, our hiring process provides a very positive experience, both for the interviewers and the interviewees.
Thank you @jason
for your kind words. It's kind of sad that not all companies take recruitment more seriously. I admire the few I find which, like yours, really offer not only a fair chance to candidates, but also hope to the industry. I think it should be common sense, and all recruiters should be competing to be better than others at what they do, sharing best practices, mentoring the less experienced HR people... Just like we do as developers, right? :)
Anyway thank you for your words and congrats for that process you follow in your company, I'd love to find that when I do interviews :D
Cheers,
L.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Very true points. Of all the "hiring is broken" articles I've read, this is certainly one of the most grounded. THANK you.
My company does indeed use a coding challenge for technical screening, which candidates have a week to do, between the first and final interviews. It is designed to be simple, but strictly analogous to the sort of work we actually do, instead of trying to be clever. Rarely does it actually take more than an hour or two to do, but the week-long window in which to submit it gives plenty of breathing room in which to do be able to do it to one's own satisfaction.
When it comes to reviewing it, we don't look for a particular solution. There are, in fact, countless viable ways of accomplishing the goal in the challenge spec. Instead, it shows us the developer's general working proficiency in the language, as well as their coding patterns, styles, and habits. There's a world of difference between someone who uses an "unguarded" while loop and, say, a properly iterative approach. Of course, whether either is even called for depends entirely on their solution.
(Also, during the final interview, the interviewee is given time to freely explain their solution and their logic for it.)
I have a challenge review form for myself and the other interviewers that keeps our review of the coding challenge submissions focused on the right things, instead of arbitrary "I wouldn't do it that way", and we compare notes before the final interview to resolve any discrepancies between our scoring, thus keeping it objective. Since we've been using the same coding challenge for several years, we can even compare an interviewee's scores to those of previous hires; by this point, we've actually found some fairly reliable patterns.
Another exception is if they are specifically trained to add value to the recruitment processes. I've allowed a number of my developers over the years to be involved both in reviewing the submitted coding challenge and in the final interview. Any developer involved in the interview meets with me well in advance to discuss the candidate, the questions we'll cover, and the proper way to handle the interview. I am very careful to train them to show empathy, recognize and bypass their own biases, and communicate appropriately.
As a result, our hiring process provides a very positive experience, both for the interviewers and the interviewees.
Thank you @jason for your kind words. It's kind of sad that not all companies take recruitment more seriously. I admire the few I find which, like yours, really offer not only a fair chance to candidates, but also hope to the industry. I think it should be common sense, and all recruiters should be competing to be better than others at what they do, sharing best practices, mentoring the less experienced HR people... Just like we do as developers, right? :)
Anyway thank you for your words and congrats for that process you follow in your company, I'd love to find that when I do interviews :D
Cheers,
L.