This format is popular because it's the best time/effort trade-off for both the company and the candidate. It's massively flawed, but everything else attempted so far turned out to be even worse.
Is programming weird because you can just ask someone to prove they know how to use a hammer? And so other industries just have to hire based on work history and/or bias "culture fit" during the interview? And they suffer terribly from people who can talk the talk but not walk the walk?
Or is programming weird because there's so much propensity for people to be able to talk but not walk? We rely on nerdspeak and jargon so much that just being able to prattle on in a dilbert-esque way would otherwise convince someone to hire you?
This is very simple problem to solve, and I think anyone who can't do that is not suitable for SDE3 (or 2 or 1, in my opinion)
One could argue about very difficult problems - can a candidate really be expected to invent the solution on the spot, or is it just because they saw it on LeetCode? Is it luck or ability?
But for simple problems, they are a strong negative signal and a very weak positive signal: just because you can merge sorted arrays, doesn't mean you're qualified, but if you can't even do that, you're most likely not qualified.
There's lots of other ways, but some of them suck.
Some fields attach a lot of weight to your alma mater, maybe they only hire people who studied law at Yale or Harvard.
Some fields require not just a degree, but also years of study under an industry veteran. Sometimes that also involves hazing like working 70-hour weeks, for some reason.
Some fields require work-sample tests where you show up at a given location and demonstrate your abilities on demand.
Some fields require not only a degree, but also years of working for free in order to break into paid work. And the paid work is far from guaranteed, that free work only pays off for 10% of people.
Some fields don't offer permanent employment, instead hiring people for much shorter periods - so bad hires can just not be rehired for the next project.
Given surgeons don't have to do live pancreatectomies as part of the interview process, I'm not convinced that's such a bad thing.
The candidate gets some code and a ticket description of what the code should do.
If he spots an issue, he can fix it right in the code or simply explain it.
I'd that testing the ability to read and understand code is both less stressful for the interviewee (no "judging every key stroke" stress) and more helpful for the interviewer.
Works great.