I think the problem is more with the arbitrary nature of interviewing and reviewing than the review itself (whiteboard and live code pairing exercises on random problems present additional problems).
We use the take-home code project approach - and use a standardized scoring sheet and review process. If the code project passes, we then use a standardized process for interviewing them, centered on the code project itself: can you defend your code, can you add a small feature to it, can you refactor part of it. We allow the candidate to use Google/StackOverflow/whatever during these code pairings, or to 'think out loud' on a whiteboard or notepad or whatever.
We follow this exact process every time. We also provide mentoring and training to staff on what we look for in both the code reviews and the interview. It isn't perfect, but most candidates who've given us reviews on Glassdoor have liked the process, and most of the candidates that we've hired have been great additions to our team.
Kim Arnett [she/her] leads the mobile team at Deque Systems, bringing expertise in iOS development and a strong focus on accessibility, user experience, and team dynamics.
I like that you allow the candidate to use external resources to find a solution - that's definitely a real-world example.
I would advise caution around take-home coding. You maybe excluding people and not even know it
As a mom, and for a while single mom, this was not an option for me. I couldn't set aside an extra 4 hours in my day to sit down and fully concentrate on a coding project outside of my regular (baby-sitter-available) hours. Just a friendly heads up.
Hmmmm seems like a situation where it might be possible to offer two different styles of interview, both expecting to evaluate the same basic skills and offer choice to the candidate.
We have a light take-home portion to our interview. It's a questionnaire that can be finished pretty quickly (30 mins). I wonder where the line is drawn where this can become a burden for some candidates.
I'll have to see if we have metrics on candidates who refuse outright to do the code project (for whatever reason). I know that a fair number agree to do it, and then never submit it, which can be interpreted any number of ways.
Guilty as charged on occasionally never submitting on some rare occasions. In my case, it was always one of the following:
1) An offer from the HR/dev interviewing you to answer questions isn't honored
2) Time conflict with other take-home assessments. This is on both parties to keep in mind that a candidate may have several on his/her plate and one may have to be cut.
3) Related to #1: Incomplete or conflicting requirements and questions regarding it are either answered vaguely or not at all.
4) Sometimes things come up in life and you can't just dedicate the time when you otherwise thought you could.
In all cases where I have to stop, I strive to send an email. I'm only human and sometimes that doesn't happen and I apologize profusely when I realize that's happened because, well, good manners. :)
I think there's a definite blindspot here, and I'm on board with giving people options with how to proceed on demonstrating their skills. Take-home or live-coding? Code samples?
I realize there's, well, let's call it "sensitivity" to making sure a candidate isn't misrepresenting themselves, and code samples are a terrific way for people like that to cheat. But a good way to filter those people out is to have them simply explain their code. In detail. Ask how they'd improve it? Ask them to potentially re-factor it in ES6 if it's written a little more classically.
There are options, and I think it's only fair to present a few so a candidate can pick the one that really lets them show off. :)
"[H]ave them simply explain their code. In detail. Ask how they'd improve it? Ask them to [...] re-factor[.]"
You've just described our interview process. :-)
We've definitely had candidates ask if they could submit an existing code sample instead of taking the test. In the handful of instances where we've agreed, those candidates have all crashed and burned. Hard. It's always a pet project that they've been working on for a while, it's never as good as the candidate thinks it is (even when it's good!), and they have a hard time looking critically at their baby.
Very similar to us. Key to our process behind the scenes is that everyone fills out evaluation forms independently and we're not allowed to talk to one another about anything until everyone has submitted. We then discuss things based on the various feedback surveys (which are done at each possible stage, so a few times per candidate).
This, we think, provides maximum unadulterated wisdom of the crowds, less group-think, and more containerization of possible biases.
Not being able to look critically at your own work is a huge red flag, just because that's a person who's going to get super defensive in even the most casual code review.
I used to be that person, but I learned to accept that every baby, even from the most seasoned programmers on the team, has warts. And it's even OK to admit that one or two projects in any given gig is Rosemary's Baby from head to toe. It happens. The test is simply to see if someone can admit it to a peer.
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.
I think the problem is more with the arbitrary nature of interviewing and reviewing than the review itself (whiteboard and live code pairing exercises on random problems present additional problems).
We use the take-home code project approach - and use a standardized scoring sheet and review process. If the code project passes, we then use a standardized process for interviewing them, centered on the code project itself: can you defend your code, can you add a small feature to it, can you refactor part of it. We allow the candidate to use Google/StackOverflow/whatever during these code pairings, or to 'think out loud' on a whiteboard or notepad or whatever.
We follow this exact process every time. We also provide mentoring and training to staff on what we look for in both the code reviews and the interview. It isn't perfect, but most candidates who've given us reviews on Glassdoor have liked the process, and most of the candidates that we've hired have been great additions to our team.
I like that you allow the candidate to use external resources to find a solution - that's definitely a real-world example.
I would advise caution around take-home coding. You maybe excluding people and not even know it
As a mom, and for a while single mom, this was not an option for me. I couldn't set aside an extra 4 hours in my day to sit down and fully concentrate on a coding project outside of my regular (baby-sitter-available) hours. Just a friendly heads up.
Yeah, it's definitely a weakness that we're aware of.
Hmmmm seems like a situation where it might be possible to offer two different styles of interview, both expecting to evaluate the same basic skills and offer choice to the candidate.
We have a light take-home portion to our interview. It's a questionnaire that can be finished pretty quickly (30 mins). I wonder where the line is drawn where this can become a burden for some candidates.
I'll have to see if we have metrics on candidates who refuse outright to do the code project (for whatever reason). I know that a fair number agree to do it, and then never submit it, which can be interpreted any number of ways.
Guilty as charged on occasionally never submitting on some rare occasions. In my case, it was always one of the following:
1) An offer from the HR/dev interviewing you to answer questions isn't honored
2) Time conflict with other take-home assessments. This is on both parties to keep in mind that a candidate may have several on his/her plate and one may have to be cut.
3) Related to #1: Incomplete or conflicting requirements and questions regarding it are either answered vaguely or not at all.
4) Sometimes things come up in life and you can't just dedicate the time when you otherwise thought you could.
In all cases where I have to stop, I strive to send an email. I'm only human and sometimes that doesn't happen and I apologize profusely when I realize that's happened because, well, good manners. :)
I think there's a definite blindspot here, and I'm on board with giving people options with how to proceed on demonstrating their skills. Take-home or live-coding? Code samples?
I realize there's, well, let's call it "sensitivity" to making sure a candidate isn't misrepresenting themselves, and code samples are a terrific way for people like that to cheat. But a good way to filter those people out is to have them simply explain their code. In detail. Ask how they'd improve it? Ask them to potentially re-factor it in ES6 if it's written a little more classically.
There are options, and I think it's only fair to present a few so a candidate can pick the one that really lets them show off. :)
"[H]ave them simply explain their code. In detail. Ask how they'd improve it? Ask them to [...] re-factor[.]"
You've just described our interview process. :-)
We've definitely had candidates ask if they could submit an existing code sample instead of taking the test. In the handful of instances where we've agreed, those candidates have all crashed and burned. Hard. It's always a pet project that they've been working on for a while, it's never as good as the candidate thinks it is (even when it's good!), and they have a hard time looking critically at their baby.
Very similar to us. Key to our process behind the scenes is that everyone fills out evaluation forms independently and we're not allowed to talk to one another about anything until everyone has submitted. We then discuss things based on the various feedback surveys (which are done at each possible stage, so a few times per candidate).
This, we think, provides maximum unadulterated wisdom of the crowds, less group-think, and more containerization of possible biases.
Not being able to look critically at your own work is a huge red flag, just because that's a person who's going to get super defensive in even the most casual code review.
I used to be that person, but I learned to accept that every baby, even from the most seasoned programmers on the team, has warts. And it's even OK to admit that one or two projects in any given gig is Rosemary's Baby from head to toe. It happens. The test is simply to see if someone can admit it to a peer.