I understand the idea behind it, I just don't think "not choking when asked to code in a stressful situation" correlates well to "being able to design and write functional and maintainable software that maps well to customer and company needs".

If the devs at your company need to put out fires constantly, then maybe it's a good test of whether they'll be able to do that.

I think a good tell is that when I want to practice for interviews, what I do looks very little like what I do to actually get better at my job. The hands-down most effective ways to practice for it don't much resemble legitimate continuing professional education (i.e. drilling leetcode on physical whiteboards) and, if they help me get better at my job, it's only marginally so and essentially by accident.

People who say "oh, I just want to see how you approach the super-hard problem" are often the first to comment on threads like this, but the experiences of OP and others seem to indicate that most interviewers expect you to actually finish or GTFO.

It's a bit of both

1) The companies that do this interview a TON, so there are bound to be bad experiences, and those are the ones that people blog about

2) The questions are supposed to be hard, but achievable. So you get two scenarios:

A/ candidates who are not good enough and are not aware of it. "How am I supposed to know if the hashmap/dicationary data structure in the language I say I'm best at maintains insertion order? I just google that every time - everyone does!". Sorry, bucko. That's the kind of in-depth understanding of your tools that we DO expect you to give a shit about

B/ Immature interviewers with a bar that's too high that are using overly complex questions and don't get noticed right away by the more experienced interviewers.

So ultimately, YEAH, the questions I ask, for me to want to move forward with a candidate, I expect you to solve the problem. But I'm not expecting you to solve it in the most efficient way or GTFO