[gracenotes]

I am not sure I agree with this focus. As someone who does not exactly do single-question technical interviews but more like two- or three-question ones, my goal is somewhere in the vicinity of measuring the software engineering version of IQ. Granted, free form technical interviews are well known to be bad at this, but all the other ways seem worse.

Bloom's taxonomy[1] is useful here I think. Assessment ideally shouldn't stall at 'understand' or 'remember'. I do agree it is important to know about a large variety of things. The more specialized the job is, the more important it is for a candidate to do a decent subset of it on day 1. But sometimes you can explore a candidate's knowledge through 'apply' (use X to do Y) or 'analyze' and 'evaluate' (do Y), such as in a system design question, to see the structure of their thought process rather than something more scattershot.

Finally, regarding skipping a question, sometimes you can sense that a candidate's knowledge is limited in some area, which is a good time to just move on and try to go deep on something else. Not everyone has been afforded the same opportunities and has the same amount of experience. Software is a job where the potential to grow can do you better than a fixed skill set, especially if you see hiring as similar to making an investment.

[1] https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/