I used to agree with the anti-Leetcode sentiment like the OP, but changed my tune fairly quickly once I started doing actual production-grade software engineering that goes beyond just simple CRUD and realized the things that Leetcode tests are applicable everywhere. It just kinda clicked one day for me and I started passing Leetcode assessments.
Sure, some interviews are pretty hard and some algorithms/data structures are not as common on the job. But given a complex enough system, you'll run into lots of situations where having this foundation will pay off. I mean, it's just computer science.
That's the thing about software engineering. You can get a lot done without knowing the foundational stuff. But then you're just a blunt instrument. Everything looks like a nail to a hammer.
I am the OP. Please understand that I am not against coding problems in interviews. Anyone who has done any interviewing will tell you that a surprising number of supposedly qualified applicants cannot code at all (usually because they have been doing project management for too long.)
And if you have a specific industry need to invert a binary tree or fill 8 containers with 32 differently sized boxes or whatever then go nuts. But I have found working through a 30 minute exercise with the candidate, asking them to explain their thought processes, and listening to what questions they ask is much better than just giving them 30 minutes to bash their head against a problem.
It is more effort for the interviewer though because it cannot be automated. But it does allow you to scale the interview by asking things like "What would it take to make your code thread safe? Imagine 4 threads. Now imagine 1000, what would you change?", etc.
So I agree with both things you said here - besides filtering those that can't code at all, you learn a lot by working through the problem with the candidate. And vice-versa. "30 minutes to bash their head against a problem" is not a good interview process.
I'm pro make them code and test their big o.
Honestly it's 30-45 minutes where you can establish whether the person can code, and whether they have the basic foundational knowledge to crack efficiency problems is pretty hard to beat.
Whilst there's probably diminishing returns on making the actual challenge more and more difficult, the general concept is a lot fairer than the majority of other interview types I've had thrown at me. ( Usually something they've solved internally, where they expect you to regurgitate the same answers without the same context )
The problem is leetcode interviews for CRUD jobs, and there is no accountability to really stop that.
This is in part due to job titles being meaningless. Senior Software Engineer has a very large dynamic range of technical ability needed when looking industry-wide. For example, if "Developer" was the non-leetcode title, and "Engineer" was the leetcode title (with harder interviews and higher pay), it'd make things a lot more understandable for everyone.