Basically there are two approaches: LeetCode vs project/test based.
The LC approach is fair if you only consider the fact that everybody will get these exercises. They are somewhat standard, and you know what to expect. However, you need to spend quite a lot of time to be able to solve difficult problems under a given time. And yet, emotions might get the best of you and you lose it, despite having solved the problem a bunch of times.
LC problems are not really useful as they don't resemble anything you'd do at work. However, if you do solve them, this shows to the company hiring you that you have been persistently training on LC problems, which shows you are consistent. A good quality, despite the uselessness of the problems.
The alternative, take home tests, are a better indicator of experience and engineering capability, although some might say one could "cheat". That's no different than outsourcing your job to somebody, which means this is fundamentally a trust issue -- so the problem lies elsewhere.
I've also seen variants of having candidates do some kind of trial where you get to experience what a typical day of work looks like at a company. This makes sense at a surface level, until you realise that the "typical day of work" is usually pretty atypical. They day of work trial generally can go two ways: the candidate works on an actual thing that needs to be done, or the candidate works on a fake thing users are supposedly asking for.
The latter is problematic, because you can do everything right, but since it's a) a fake problem, and b) you have no actual user feedback or requests to work on, this gets pretty subjective. Unless you read your interviewer's mind, you're left to wonder why you were rejected.
I'd take a LeetCode problem over a fake work day any time, as much as I dislike LC interviews. I guess all of this is to say, it's complicated :)