> What I need is a way that tells whether the person I'm interviewing can actually do the work that I'm hiring them to do. Maybe I should ask them about that. Maybe I should give them some problems similar to the actual work.
Would you mind sharing with us how to draw the rest of the owl?
Look, I don't even want to defend leetcode here, but it is a struggle to find questions that are:
1) Correlated with the actual work performance
2) Neat enough to be explained and solved in the course of an interview
3) Have objective enough answers so that it's possible to overcome likability bias in interviewers
4) Have objective enough answers to be able to meaningfully compare different candidates
5) Demonstrate that candidates can actually go from hearing a description of the problem to producing code that solves the problem
The best I've ever seen is the way my current boss does it. We do a two-hour interview (they've already passed a phone interview before we bring them in). We spend the first half hour just talking to them personally.
Then we give them a piece of code on paper. It's fairly simple - half a page. The function name is foo(). It's written in C#, but we don't expect them to actually know any C# details. The function takes an array of Strings as input, and returns an int. The questions are, what values does it expect for the Strings, what value does it return, what would they name the function, and what can go wrong (what exceptions can it throw - but we don't expect them to know the details of C# exceptions, so what might cause exception-like circumstances). This shouldn't take more than half an hour.
Also, it's the same code for every candidate, and we've seen a few dozen over the years, so we are fairly calibrated on how a quality candidate should do.
Then we ask them to write some code on the whiteboard. We give them a simple problem (again, same problem for every candidate). They can use any language they want. We don't expect them to be a compiler - we don't care if they get the parameters a bit wrong on a function call, as long as the code would be sound if the system accepted the syntax they expect. Again, this should take half an hour.
Then we give them a simple design problem. How would you design software to do this? It's a problem that is not rigidly specified, so they can have to flesh out the requirements (hey, welcome to the real world). It's got enough corner cases that we can ask them about one that they skipped, and watch them try to modify the design to handle it. We don't expect perfection - there is no perfect answer for this question. But we want to see them have some kind of reasonable taste or sanity in their design, and some ability to iterate the design as more requirements emerge. Once again, this takes half an hour. They're not done with the problem at the end of half an hour, but we've seen enough to know how they did.
Other than allowing them to ask any questions they want, that's it.
> Then we ask them to write some code on the whiteboard. We give them a simple problem
Can you share what kind of problem?
This actually sounds pretty close to what we did at my previous company, except that candidates were given a computer (nothing had to compile, it's just that we don't expect anyone to be able to write code on whiteboard) and two coding problems.
First one was pretty simple, such as printing a folder structure with nice indentation (given some predefined input data structure). The second one was harder, although we hired plenty who did not manage to completely solve that one, but if they did it was a plus.
Also had some design questions after that. Some people still complained that the interview was abstract algorithmic nonsense without relevance to real life.
Would you mind sharing with us how to draw the rest of the owl?
Look, I don't even want to defend leetcode here, but it is a struggle to find questions that are:
1) Correlated with the actual work performance
2) Neat enough to be explained and solved in the course of an interview
3) Have objective enough answers so that it's possible to overcome likability bias in interviewers
4) Have objective enough answers to be able to meaningfully compare different candidates
5) Demonstrate that candidates can actually go from hearing a description of the problem to producing code that solves the problem