[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.