It depends how it is done. I used to think the same way, and I would never hire someone without having seen them program live.
But having experienced leetcode-style interviews on the candidate side, it's clear to me that they are no longer about figuring out and coding a solution on the spot. Interviewers expected a solution FAST, and to match that you need to have studied and learned the answer beforehand.
There's a difference between asking someone to invert a binary tree, and asking someone to sum up a list of numbers. The latter finds the people who can't code much more quickly!
This is so true. You see it when you are on the hiring end. There are all kinds of people out there. I fully expect every hireable programmer to be able to set up a class, instantiate it, and use types. A lot of people are not even at that level. They know just enough to be dangerous.
No. The unfortunate reality is that if you don't do something - if you don't find a way to test whether they can actually program - then you will hire people who can't program. You need something.
But that "something" doesn't have to be leetcode. There are much better (and less abusive) ways of doing the same thing. All it takes is a programming problem that they've not seen before. That's it.
Nonsense. Ask a candidate to add a feature to an open source product similar to your own, and share the PR.
Ask them to do it with a time box.
Guaranteed better results.
...Instead you end up hiring people who can memorize every test from leetcode.com without having the slightest idea on how or when to use those data structures and algorithms in the real world.
