4 ms·

Pop quiz style is much better than asking a single question and then diving deep into it. The most important part is that the candidate can say "pass" and that

Pop quiz style is much better than asking a single question and then diving deep into it. The most important part is that the candidate can say "pass" and that you don't force them to squeeze out a shitty answer. There is simply no better way to find out the breadth of someone's knowledge than to quiz them over a broad range of things. Think about it: this is exactly what engineers do with each other naturally and in a fun way over time. "Hey, do you know about X?" Compare this with Google's idiotic idea of asking a single question and judging the candidate on that randomly selected question. No one who knows their stuff will fail to answer a long list of pop quiz questions well...but anyone of any skill level might not know the answer to any particular question.

SamReidHughes 10y ago
I'm pretty sure Google has multiple interviews with multiple questions.
gracenotes 10y ago
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/ https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/

SamReidHughes 10y ago

I'm pretty sure Google has multiple interviews with multiple questions.

gracenotes 10y ago

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/ https://cft.vanderbilt.edu/guides-sub-pages/blooms-taxonomy/