This approach simply doesn't always work. Some people are amazing-sounding but terrible in practice. The reverse is also true - some people are terrible at talking about their work, but produce amazing code. (Their lack of communication skills might or might not hamper their actual job performance, depending on multiple factors.)
On the other hand, leet code questions definitely don't show that the candidate can actually write maintainable, well-documented code with test suites and easy-to-use APIs.
Though I will say that having some kind of fizz-buzz style phone screen is still, in my mind, a good idea. It saves a lot of time if it turns out that your candidate can't even write a simple for loop (and so many can't, to my great dismay).
The interview that's always worked for me in hiring is where we talk about the issue and we see if the person understands the problem. There's an infinite number of things we can get into, and if the person is experienced they'll never run out of things to say. I've never hired someone who turned out not to know the basic things like some particular algorithm.
I suppose if we're talking the leetcode style interview loops, they normally have a system design part. That might be the closest to what I do.
* implementation choices with pros and cons
* details about how the underlying system works
* domain knowledge, where applicable
* sample code where the candidate writes to mimic something from the system
My interview style has always been: "Tell me what you know, and we'll see if that's true or not." Surprisingly, most candidates fail even that since they don't seem to understand their own projects. But I find this approach the fairest of all since it allows the candidate to lead the interview and it doesn't assume anything about the candidate's knowledge or prior experience.