A lot of the time I find “spot the bug” questions to be more informative, especially for junior roles. We stopped asking fizz-buzz - just about everyone has heard of it by now and it’s pretty easy to just rote learn a solution. Instead we give them the spec for fizz-buzz and a deliberately broken implementation and ask them to fix it. If they get flustered, just asking “what does this program output” usually give a pretty clear indication if they can reason about code in a systematic way.
That’s fine if there are no weird pedantic ropes to fall over. I am not a compiler or linker, that’s what I have compilers and linkers for. Same with an IDE. I don’t know many details of the stdlib or other common libs, because why should I waste space in my brain for stuff code completion can show me…
The kind of bugs I’m talking about are things like “the logical flow of the code is broken because the order of the if/else if/else branches is wrong”, “this program never finishes because you don’t increment that counter” and “you specified print the numbers 1 to 100, but that counter starts at 0”.
I’m testing your ability to think logically, not your knowledge of stdlib trivia
No, that approach is completely fine even if pedantic because you get the candidate to reason about their choices and their approach which tells you so much more about them than rote memorization. Being pedantic is the whole point of it.
That’s likely not what I mean by pedantic. If your code example has syntactic errors or calls functions with not enough or too many parameters and you expect them to notice, you want them to do, what a compiler does or to know technical documentation by heart. Which is completely academic and pointless.
Concentrating on “algorithmic” solution at hand is fine, though. Unless you again expect them to recognize stuff like “hey this is almost Dijkstra’s algorithm but wrong”, because the interview should not be a university computer science test.
A lot of the time I find “spot the bug” questions to be more informative, especially for junior roles. We stopped asking fizz-buzz - just about everyone has heard of it by now and it’s pretty easy to just rote learn a solution. Instead we give them the spec for fizz-buzz and a deliberately broken implementation and ask them to fix it. If they get flustered, just asking “what does this program output” usually give a pretty clear indication if they can reason about code in a systematic way.
That’s fine if there are no weird pedantic ropes to fall over. I am not a compiler or linker, that’s what I have compilers and linkers for. Same with an IDE. I don’t know many details of the stdlib or other common libs, because why should I waste space in my brain for stuff code completion can show me…
The kind of bugs I’m talking about are things like “the logical flow of the code is broken because the order of the if/else if/else branches is wrong”, “this program never finishes because you don’t increment that counter” and “you specified print the numbers 1 to 100, but that counter starts at 0”.
I’m testing your ability to think logically, not your knowledge of stdlib trivia
No, that approach is completely fine even if pedantic because you get the candidate to reason about their choices and their approach which tells you so much more about them than rote memorization. Being pedantic is the whole point of it.
That’s likely not what I mean by pedantic. If your code example has syntactic errors or calls functions with not enough or too many parameters and you expect them to notice, you want them to do, what a compiler does or to know technical documentation by heart. Which is completely academic and pointless.
Concentrating on “algorithmic” solution at hand is fine, though. Unless you again expect them to recognize stuff like “hey this is almost Dijkstra’s algorithm but wrong”, because the interview should not be a university computer science test.