> What happens to every candidate who gets flustered by the questioning and seems to bow out earlier than their technical depth?

I'm not sure I get this question - I'm not talking about a white-boarding exercise. I'm just talking to the candidate about a technical project they have worked on in the past, the pain points, how they resolved them, etc. If that results in the candidate being flustered it's not a good sign on numerous axes.

> How do you hire people who are more technical in a subject area than your current staff, if your test bottoms out at the depth of the current interviewer in the room?

That is a _very_ different hiring situation. If you have no one in the company that is equipped to properly technically interview the candidate they obviously you can not properly technically interview the candidate. You'd likely have to leverage the connections of the management team to find the right person to lead up unknown territory.

One of the very best people we ever hired was so flustered in his final interview with us (a formality, after work-sample challenges) that he was visibly shaking during it. If we had taken the "numerous axes" on which the was "not a good sign" seriously, we'd have missed that hire --- and, I think, an entire business unit in our firm wouldn't have been started.

I generally think software developers (I count myself among them) know far, far less about psychological assessment than they think they do.

Of course that happens, but you're taking a real risk in hiring someone who can't get through the interview. I'd rather miss out on a good hire than make a bad one. You only have so many ways to determine whether or not someone is competent.

I don't know what to tell you. We switched to pure work-sample hiring and hired several dozen people that way. We retained all of them. I can't say that about our interview process prior to that: not only were we not picking up the "moneyball" candidates I'm talking about here, but we were also hiring people we (painfully) ended up having to let go.

The only time people face the specific pressure of an interview is in an interview. I promise you, whatever generalization you're making doesn't hold.

My point is that you can't easily discern why they are performing poorly. All things being equal I'll take the person who could answer the questions.

I have an anxiety disorder, so in depth conversation with a stranger is going to cause me to be flustered. If you asked me to give the answer in writing I could. If you asked me to code on a whiteboard I could. If you asked me to do a takehome I could. But a verbal conversation with a stranger judging me in an interview setting is the worst out of all possible options for me.

100x this. Whiteboarding is so outside the typical engineering process that it just feels cruel, especially to people with any kind of anxiety. It's like if you were hiring construction workers and you asked them to perform an interpretive dance about concrete in the interview. It's just not at all the job and very difficult for many of the people who go into programming in the first place. It's hard for me to think of it as anything other than hazing.

> If that results in the candidate being flustered it's not a good sign on numerous axes.

Are you hiring sales reps or engineers? Why are you asking for an engineer to sell you on their past project(s)?

Interviews by their nature are about judgment, and knowing you're being judged by a complete stranger who holds the power over this potential path of your future is enough to get anybody flustered, especially a brainiac that just wants to work in relative peace behind their desk.

> Are you hiring sales reps or engineers? Why are you asking for an engineer to sell you on their past project(s)?

I don't ask them to sell me, I ask them to dive into the technical issues they faced and how they solved them. It tells me a lot more about how they will handle similar issues in the future than scribbling DFS on a white-board would.

Just to clarify, when you say "how they would handle similar issues" do you mean talking to a hiring manager about a past project during an interview setting?

I don't understand what you're calibrating for...

I'm a bit unclear on your question. I'm assuming a technical person with relevant knowledge performs the technical interview, if that is what you mean.

The interview setting, with someone who might or might not be technically capable, with your job / career / earnings at stake is a very different situation than explaining past projects to a colleague at work.

Programmers in a company work with other programmers. If they cannot explain some work they've done then they are useless. Or would you hire a programmer who does not speak English?