,
20 tweets,
3 min read
Read on Twitter
Thread: [In which a programmer opines about how to interview other programmers]. I interviewed well over 400 people in the SF Bay Area over the last 8 years, and along the way got to see a lot of other interviewers work.
The most common mistake I saw interviewers make was treating the interview as a search for everything the candidate *didn't* know, instead of everything they *did* know. It's an unfortunate mistake, often leading to false negatives, a poor candidate experience, and a monoculture.
These were interviewers working with the best intentions. They tried to be rigorous, fair, precise, accurate, exhaustive etc. They wanted to make sure they fulfilled their mission of selecting the best people for the team.
But their focus on identifying the best people was problematic for two reasons: one is that it lead them to neglect the candidate experience. Evaluating the candidate is only half of the interview.
The other half is ensuring the candidate feels they were judged fairly, treated with empathy and with respect, and that they walk away with positive feelings about the experience even if they failed. You want them to leave the interview wanting to work at the company.
The other problem is that people misconstrue how to identify competent candidates. They come up with a whitelist of desired responses and ask directed questions seeking to reveal whether the candidate can produce the required reply.
Questions and expected answers become narrow, closed instead of broad, open. The narrower the question, the less likely it becomes that even a skilled candidate will surpass "the bar". In my experience, this led to a higher than necessary false-negative rate.
As an aside, of course you want your process to be as fair and reproducible as possible (ie. the same candidate should ideally see the same outcome regardless of the day they come in, or who happens to be assigned to interview them).
Interviewing is an inherently subjective and intuitive affair, no matter how much you try to make it objective and systematic (and you *should* still try, of course, unless you want conscious and unconscious biases to totally undermine the whole affair).
But while you might want to make the "correct" choice as often as possible, the question of whether you should worry more about false positives or false negatives is very context-dependent, so I'm not going to get into that here.
But I will say that overall, I saw more evidence of false negatives due to the "overfitting" problem that I'm discussing here, than false positives (usually due to unconscious biases IMO, where we assumed that something missing would be there, or something present wasn't really).
So, yeah. Instead of treating the interview as a mistake-cataloguing exercise, you should be viewing it as a search to expose as much of the candidate's knowledge and skill as possible. It's not hunting for errors, it's searching for expertise.
The ideal outcome for you is that the candidate is great and the company gets a great new team member. The ideal outcome for them is that they get an offer and are thrilled to work with you.
You both want the same thing, and the best way to make it happen is to search for strengths instead of weaknesses. That's what we all are after all, even the best of us: assemblies of skills and shortcomings, nuggets of knowledge and misconceptions, good parts and bad parts.
The job of the interviewer is to find the good parts (just as the job of the candidate is to do their best to make those parts manifest). By all means, when you're writing your interview feedback you should of course note down the places where the candidate misstepped.
But even the weakest performance should have some countervailing positive signal and if it's there, it's on you to extract it, otherwise you have failed just as much as the candidate.
I don't want to read feedback that consists of the interviewer gleefully pouncing on every tiniest departure from the expected golden path. "A-hah! You didn't know that Array.prototype.push returns the new length of the array as well mutating it!"
"GOTCHA! You got the order of the callback arguments to reduce wrong!" etc. Sure, if the candidate's performance is dominated by many of these small slip-ups, the consistent weak negative signal starts to add up.
But there is almost always positive signal to be picked up along the way, and if you don't do your darndest to find it, then you are letting the candidate down. Do your job well and at the end you can weigh up all the good and all the bad together and make a decision.
End of rant for now. Just remember: your job is not to catch mistakes (or rather, not *only* to catch mistakes), but to find out the most you can about what the candidate knows and can do. Now, go forth, and make the poor suffering fools scrawl on whiteboards!
