Depends on the job.
I'm currently hiring and the live coding exercise is a must for the position because I want to see how the person problem solves while under stress.
Because stuff happens. My team works on mission critical systems that can have issues that we sometimes must resolve quickly which is very stressful.
If you can't handle the stress of me watching over your shoulder while you code then you can't handle the stress of getting a critical bug fixed immediately. Maybe that's not true for everyone but I haven't heard of a better filter.
Not every position is like this. But that's the big thing I think people miss. Different software positions require different skillets beyond just tech stacks. And the interview process should measure for the particular software engineer skills needed for that position.
I've also hired people who if you just reviewed their code after the exercise you'd think they were terrible. But I'm not testing whether they are good at coding exercises, the test is a tool to see their ability to problem solve under pressure and to see their level of experience with the particularly tech stack.
Those are two very different kinds of stress.
In one situation you're stressed because you feel like your every action and step is being judged. Every moment you spend floundering you feel is being docked against you, you can't help but worry about how the person breathing down your neck is expecting you to approach the problem.
In the other situation you are a part of a team, you have each others backs and trust each other to make sound judgement calls. You're working together for a common goal rather than judging each others every movement.
Your hiring method sounds like hazing, you're putting interviewees though unnecessary stress to see if they crack. Stress that isn't the same as they would feel on the job, at least I hope you don't also treat your employees the same way.
To echo your point, fixing a bug with someone you just met standing over your shoulder clock ticking, is nothing like fixing a bug at your regular place of work.
In an interview, if you don't perform the task well, you can fuck off back to the street where you came from. In your job, you get to ask colleagues, consult previous project code, refer to in-house or external documentation, and calmly analyse to figure it out under your own "in the zone" steam.
Remember, interviews go both ways.
This doesn't sound like something a new hire should be responsible for and more someone who would eventually, after proven themselves able to, participate in.
Interviews are already stressful; you don't need to add to that by putting candidates into even more stressful situations just for kicks.
To flip it around, would you be willing to let the candidate review the details on all technical employees exit interviews and then ask you about them? Maybe review some completed financial audits from previous years? so they can see how the company reacts under pressure?
It doesn't.
> I'm currently hiring and the live coding exercise is a must for the position
It's not.
> because I want to see how the person problem solves while under stress
Why, it's a totally bullshit proposition. The stress of not having memorized some algorithm is not the same kind of stress as a live system going down.
You do it this way because you aren't able to come up with anything better.
Otherwuse these exercises would just paint a broad stroke that handling stress is common & generalized, when in fact it's unique and case by case in most situations.
Sounds like a great place to work...
tl;dr: If you're a stress factory there's no way on earth I'd be willing to work for you in the first place.