But isn't this a work sample test?
So debugging or implementing some small stuff against a real application would perform better than leetcode.
TBH, I think the original point of algorithms was to act as disguised intelligence test, which are tricky to use in US hiring.
The more general point is that the algorithmic approaches from leetcode problems have not a lot of relation to what most programmers do all day, and as such, are less useful as a work-sample test.
Doing a take-home where you fix some bugs would probably work better (i.e. more correlated with outcomes) than leetcode interviews.
I'd say asking someone to regurgitate some solution for a random leetcode problem is far worse an approximation than asking someone to write, say, a little toy API that does nothing more than retrieve a value out of a set.
See how well they're able to develop in a language of their choosing. Can they get started immediately or do they stumble putting together the first little building blocks?
Treat it like a "real-world example" and make that clear up front. Do they think about logging and metrics? (for the purposes of a toy interview problem, just writing to stdout for both would be sufficient). Do they think about dependency injection? What about unit tests?
Then follow it up by asking them to modify a bit of their logic. ("okay, we've got it returning a matching value from the set if it exists - what if we wanted to add in wildcard support at the end of the incoming string?").
Tons of very real things to consider, even in the constraints of a simple toy problem.
As someone who works in Big Tech, I would much rather have people on my team who think about maintainability, debuggability, monitoring, what can go wrong, etc. etc. (and have shown during an interview they're capable of writing some trivial business logic around that) than someone who absolutely nailed mirroring a binary tree and solving the longest common sub-sequence problem.