I’ve conducted many interviews that starts off with asking questions about projects. Many candidates sound like rockstars. They even nail all sorts of technical follow-up questions.
Then when I start asking coding questions, and I’m not talking leetcode here, more similar to fizzbuzz, they can barely write an if-statement. My conclusion is that some people are great at talking, but you really need to test the technical abilities too.
Perhaps your technical questions are not adequate enough if someone can sound like a "rockstar" while not being able to program an if statement?
I've interviewed hundreds of people over my career and I've never had an interview where I couldn't figure out their technical abilities through a conversation.
I'll tell you what leetcode interviews do find you though, they find you people that have no idea how TCP/HTTP work, they have no idea how you would debug a distributed system. They've never deployed anything to a server. They probably have no idea how to even measure the amount of work being performed by a server. They've never thought about CI/CD/Deployment/Scalability. They've never used any cloud resources. They have potentially never been through a code review.
etc, etc, etc, etc.
Someone crushing a leetcode test tells me about 1% of the stuff I'd like to know about their knowledge and abilities.
The best interview strategy for me is to give a short take-home assignment (coworkers go through it in under an hour max.) which is somewhat related to the domain space we are hiring for.
Some solutions are rejected on the spot (bad practices, does not solve the task correctly), other candidates are invited for a technical interview. Some generic questions, then we go through the solution - with emphasis on less than perfect areas. It is quite easy to see when someone is bluffing, and you also see how the person deals with feedback.
