Good tests, I find, are to give them a simple piece of code with minimal comments. For example, some non-standard special purpose container implementation. Then ask them to explain what the purpose of the code could be as simply and short as possible.
Either - They'll start literally explaining each line of code without understanding the whole. - They completely miss the point. - They at least figure out it's a container of some sorts. - They'll explain technically what it literally does. - They'll give you the academic term for the concept it implements. - They'll actually explain the purpose briefly in simple words.
Those last three are good, in different ways. The better ones will also spot the bugs or performance issues in the code.
I mentioned to a colleague that what I value most is someone who is creative. There are many candidates out there who know all the buzzwords or can discuss features of a programming language purely from memory, etc.
This can make for some impressive interviewing, but it tells nothing of their ability to use that knowledge to solve real problems, or their creativity in how they use their skill and expertise when faced with new dilemmas.
Sure, you could contest that the creative side isn’t necessary for certain levels of engineering, or that only tech leads require this as a mandatory trait, but I would argue that it is far more important than what most interviews test - rote memorization.
I've always tried to do that... until recently.
With a new recruit, this is the fastest way to nightmare discussions. He always emphasizes the cons of my proposals, and never admit that his proposals also have cons. To be honest, I really think he believes what he says, he seems to not see ahead of time where the blocking points will be.
I am now forced to only submit the pros, and prepare an argument for the cons, which is rarely needed. This is not a way to have good technical decisions.
This is not how it works! There are over 1000 problems on leetcode. Sure, many of them are solved using the same techniques but there is usually a twist and you often need to combine multiple approaches or come up with something new (to you). And then there is usually a very problem-specific way in which the problem can be solved 10 or 50 times faster. Often these insights are very difficult to come up with. The people who created these questions are actually very smart and excepting some of the questions at the easiest level it's usually a far cry from simply implementing Dijkstra from memory!
The problem with leetcoding in interviews is that it is easily measurable but not an important metric. Focusing on someone's aptitude at skills they never use at their job means good developers get tossed aside or are forced to waste energy jumping through hoops needlessly.
I think a general chat about a broad problem and the interviewee's thought process of how they would approach it can tell you much more than whiteboarding some memorized algorithm.