> Interview situations are very, very different than the others.
How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, since it's understandable for them to be a bit more nervous than a coworker would be.
The primary way in which interviews are different from after-the-hire social interactions is that interviews are high-stakes events, and the candidates know it. For some people, that knowledge is enough to put them into a self-reinforcing mental death spiral. Their fight-or-flight response takes over and they literally stop thinking as their bodies switch into survival mode.
That's why, when you're interviewing candidates, your first job is to get them to relax. Start out with small talk and softball questions until you sense them unwind. Then move slowly into the real questions.
When you get to the coding problems, again, start with dead-simple questions so that the candidates have the time to gain some confidence before the harder problems arrive.
The first programming problem I give – and this is after some small talk – is usually something like, "Print the odd integers between 1 and 100, in increasing order." This problem is so simple that it doesn't tell me anything about the candidate's ability, but that's okay. It helps to calm the candidates so that when I get to the problems I care about, I'll get better measurements.
That's the goal: To measure how the candidates actually perform, not to see whether they'll choke under interview stress.
I'm embarrassed to admit that in one of my first interviews I was asked to code bubble sort and choked for the first 30 seconds (it felt like a lot longer) until I reminded myself "I can do this" and sort of got back into things. I'd be tempted to disagree that this is such a big factor but it happened to me on bubble sort.
Don't be embarrassed, it's more of the same point. Exactly zero percent of my 15 years of development experience include writing a bubble sort. Your post represents perfectly what the author is saying about the disconnected, displacing, time wasting effects caused by conventional wisdom about performing tech interviews. If the developer is not themselves you're not hiring who you think you're hiring. I know you don't choke when you're doing good work. There must be a better way.
Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job.
Not really. A job interview is your one single chance to make a good enough impression to get the job. You could freeze up in a meeting and it would be fine, if the rest of your performance is on par.
One meeting in a job is a very tiny part of your overall employment. An interview is the one and only impression you get to make.
(For further reading, please consult the lyrics to Eminem's "Lose Yourself". Mom's spaghetti.)
How exactly? Freezing up in a meeting can get you fired just like freezing up in an interview can get you turned down for the job. Sure, you'll get comfortable with your coworkers, and they'll get more forgiving of temporarily lapses, but I think most interviewers (for non-terrible jobs especially) purposefully give some extra leeway to interviewees, since it's understandable for them to be a bit more nervous than a coworker would be.