Not to defend that interviewer, but sometimes it's inevitable that you do have to code under pressure. I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second, and I have to push a patch to production as quickly possible. Not that I would interview for such a situation.

You should probably roll back the commit that broke production though, instead of hastily pushing something out hoping you'll fix it.

And ideally you should've been doing a gradual rollout, deploying on a few machines first then slowly ramping it up.

And if you are in that position, it is because you have the most (or enough) context to be able to solve the problem.

In an interview situation, it is like being asked to fix a problem with skyscraper having never seen the interior before. Interviewing is low-context. You cannot test whether someone will fail under high-context pressure in an interview.

"I've been in situations where the whole system is collapsing, thousands of dollars are being lost every second"

That's the situation you get into when you code under pressure.

No jobs are performed best under pressure. Or at least past the body's ability for a brief surge (adreneline etc.). But it happens in every occupation because overall more will be produced by pushing people than letting them pace themselves...

> programming under pressure is the leading cause of programming disasters

I don't want to straw man you, but it seems like hiring someone who is demonstrably better at programming under pressure would mitigate the inevitable situations that force employees to program under pressure.

> mitigate the inevitable situations

Conversely - the person who feels like he's good at programming under pressure might consider it no big deal and not bother to mitigate any potential "programming under pressure later" possibilities.