Does this kind of trick question work well in practice? If they explicitly ask for syntax errors it would be a waste of time to also check the code for other errors. I can’t imagine many people opting to do that unless they know it’s a trick question.
It shouldn't be a trick question, but an open one. “What can you see wrong in this code?, there are a few things, we don't expect you to see them all”. For non-junior starters it is effectively a simulated code review — can this candidate spot problems before they get committed further into the pipeline (and hopefully avoid them in their own code).
I don’t see what information people can glean from those trick questions.
Any time I’ve interviewed people I’ve made it a point to emphasize that none of my questions are trick questions and if anything is unclear, they should ask clarifying questions. The result? Interviewees are more comfortable and are far more honest about what they know, what they don’t know, and you get to see a glimpse of what they’re really like.
"Basically, I will ask you questions, and hopefully you will give me answers.
It is fine to say 'I do not know'. It is fine to guess, but if you do, I would prefer that you tell me it is a guess.
If you want any clarification, I will try to provide it. If you don't recall the exact signature of a library function, ask me. I will note down what I said and not hold incorrect nformation I give against you.
