[Godelization]

If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team? Stressful situations can occur in software engineering, including for example a moment where you realize production services are broken because of code you just deployed.

[brimble]

Interview pressure is nothing like an emergency. I'm cool as a cucumber in an emergency. Hell, I kind of love them. Interviews are another thing entirely.

[EDIT] What I'd liken an interview to isn't an emergency, but a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one. That's closer to what it is, than an emergency. That also makes it very unlike nearly all activity anyone engages in at work, emergency or routine, social or solo, except for certain high-pressure sales or top executive jobs, maybe.

[porknubbins]

I’m normally cool under pressure and able to solve technical problems quickly. But in a situation where what matters isn’t actually solving the problem but evaluating my performance and my brain goes into overdrive with perfectionism/meta thinking about what they are thinking about me to the point where I sometimes can’t even do basic math.

[xkgt]

Exactly, I have been in such high pressure situations several times with directors and CIOs breathing down my neck, but surprisingly I am quite composed in such scenarios. Severity of the problem at hand is in fact liberating as it is easier to focus. But that is not the case with interviews, when there is a strong "me" factor in the thought process.

[jjav]

> a date, a visit to the bank for a mortgage application when you're very much not sure whether you'll get it, participating in a talent show, and shopping for a car, all rolled in to one

Great quote. Those feeling pretty much summarize to perfection the current fad of interviewing pressure.

[mLuby]

Okay Password Swordfish. :P

As for those who code without guns to our heads, I'd take the candidate who ships well-tested code over the candidate who ships emergency code. Prefer few large fires over frequent small ones and just roll back.

[sanderjd]

If I were that hiring manager I would have the wisdom to know that this provides no signal whatsoever of how successful those people would be on my team.

Edit to add: The kinds of pressure experienced on the job are not at all the same as those experiences during an interview. "Doing well under pressure" is not a generic skill. Someone who freezes up during an interview may be the coolest head in the company while restoring a database backup during an outage, and vice versa.

[jjav]

> If you as a hiring manager have the choice to pick between two candidates, one of whom stays cool and productive under pressure, and the other who goes blank in emergencies, which would you prefer to have on your team?

It's completely different, not even remotely comparable.

The pressure during a real-world outage is not a big deal. It's collaborative, we're all trying to solve this. And the work that needs to be done is actual real work. I'm extremely good at that, so I basically feel no pressure at all no matter how high the stakes are.

Interview pressure though? Whole different monster. It's confrontational and I'm expected to basically do improv acting on topics that have nothing to do with the actual job while someone nitpicks and eyerolls every irrelevant nonsense.

[educaysean]

Your comment is not factually incorrect, but it takes a lot of logical leaps. Let's say: if all other things were equal, would you want to hire a candidate who has worked with just 1 programming language throughout her career or someone with experience on 5 different programming languages?

It's probably correct to answer "the person with 5", but does it automatically prove that "# of languages under the belt" is a great metric for evaluating engineering prospects?

We can come up with all kinds of justification for the current state of engineering interviews, but most everyone conducting the intervews know that our methods are extremely primitive and are thirsty for a better path forward.

[ggff67]

I think I'd want the smarter candidate regardless in a job like software development that is overwhelmingly based on quiet focus time. It's easier to help them work through the rare emergency, than to help a less-skilled employee work through literally everything else.

But just blanking when suddenly put on the spot happens to everyone. Human memory retrieval is a complicated process, nothing like a computer. You can have vast expertise in there but not be able to retrieve it instantly, unless of course you've practiced interviewing that very subject a lot recently.

[grimjack00]

In the production issues I've been involved with, I was not forbidden use of Google, API docs, consultation with others, etc., and I did not have to work out anything on a whiteboard.