[shaftway]

I see the whiteboard tests as similar to the skills test necessary to get a motorcycle license in California. To get your license you need to weave between a set of cones, go around a circle, and then come back through the set of cones, all without exceeding 5 mph or putting your foot down.

None of this tests real-world skills. You never have to weave as tight as the test requires, going that slow makes it painfully difficult, and if you have any balance issues at that speed you should put your foot down, even if it's just for a quick touch. But they keep the test as-is. The thinking is that if you're capable of doing the hard stuff in the test it demonstrates that you've had enough time on the bike to figure the rest of it out.

The leet-code interview questions are the same. I don't expect you to have read the problem before, or to give me a perfect answer, because the interview isn't the job. But how you handle a question like that gives me insights into roughly how much experience you have and how comfortable you are with code. If you can handle that question, even if you wobble a bit, you'll probably be fine on the job.

[shaftway]

FWIW, the question I asked when I interviewed was whether a group of stones on a Go board had any liberties. I don't play Go, and I don't explain it that way; instead I describe stones as trapped or not, and define what trapped means. Then I make sure that the candidate can identify whether a few stones are trapped to ensure they understand the question. The methods they used to solve it were very illuminating.

Beginner candidates tended to try to optimize for following paths. They'd move as far as they could in a single direction then turn and repeat. They'd miss branches and backtracking was very hard. They wouldn't realize they had to keep track of visited spaces and had to be spoon-fed that scenario. These candidates would not know how to write unit tests, or would say they'd test "edge cases" and literally only test the edges of the board.

Intermediate candidates tended to use BFS or DFS, sometimes using a stack or queue, sometimes with recursion. At first they wouldn't realize they needed to keep track of visited spaces, but they'd notice it themselves and have a solution for it. When asked for unit tests, these candidates would always start with a bunch of input validation, and end with few actual unit tests.

Advanced candidates would reason about the board as a whole. Often using BFS or DFS to build an answer key and then looking up the answer for that. Or maybe they'd use BFS or DFS to find the solution, but it was a nice clean implementation. These people had a good sense of what kind of unit tests the code needed and knew that input validation and unit tests were different.

I had candidates who didn't finish but still got a hire recommendation, and I had candidates who did finish, but it was such a dumpster fire that they didn't get a hire recommendation.