Q: "No job has any similarity with leetcode-style interviews or that type of constraints and time pressure. Why do we have to do them?"

Say you are a big tech company. The biggest one, even--you are Google. You need a scalable and impartial way of hiring a lot of SWEs. So, the first thing you--in true engineering fashion--is decoupling the dependency between hiring and team matching. But that means you cannot hire for specific tech or domain experience: You don't know in what team candidates will end up, and your teams use a bunch of different languages and tech stacks (a lot of it is internal anyway, so you definitely can't hire for that).

What you actually want is candidates who can take any complex software system (that's not part of the candidate's previous expertise) and answer hard questions about it, like what's the best way to add a feature, how to optimize it, or how it should be refactored. In other words, you want to hire for general problem-solving skills. (Sidenote: do you notice how most of this doesn't apply to small companies? It's almost like they should interview differently!)

Or to put it more bluntly, you want to hire for (a type of) intelligence. Sure, there's a lot more to being a SWE than problem-solving skills--that's why Google also does system design and behavioral interviews. But you still want to hire for this trait.

I'm genuinely curious: what do people who oppose leetcode-style interviews think is better for this than algorithmic interviews?

Oh and one more thing: you receive an overwhelming amount of applications from qualified candidates, so you are more OK with rejecting good candidates than accepting bad ones.