3 ms·
Possible failure modes with this approach: quite a few candidates who are not strong at actually doing the work will be able to somewhat convincingly "talk the
by shoo 6y ago
Possible failure modes with this approach: quite a few candidates who are not strong at actually doing the work will be able to somewhat convincingly "talk the talk" well enough to pass stage 2. If stage 3 is done async then there's a minority of candidates who will cheat and get someone else to solve the challenge for them. If the org has set up a hiring pipeline rather that first tries to identify strong hires before figuring out exactly which team they would join rather hiring to fill a specific role then step 2 might not make sense either, as there's no specific team to interview.
I agree that the in person time pressured performative problem solving & coding engineering interview process is often a poor approximation of the work.
- crehn 6y agoSome companies (e.g. Amazon) have a separate verification interview to ensure the candidate is the author of the deliverable.
- heavenlyblue 6y agoI think I failed one of the interviews this way actually: after having done the async part of it I did about 10 other test interviews and literally forgot about what I did for this one. I had quite a few “aha” moments where I was “ah wait, I totally didn’t do that, have I?”. Didn’t get the job, however neither did I like them.
- lampe3 6y agoThats why you let people present the code and talk through it. We had one case were you could clearly see that the person had no clue what he is talking about it. Its quit easy to see. Just ask them to change something small.
- grumple 6y agoThe problem you mention is why we have references, which you’re asked for when you apply to any job or use a recruiter (at least, a good one). Those references should be coworkers who can testify to their productivity, ability, and team fit. If at least two people who worked closely with someone like them enough to give a referral, they are probably worth hiring.