2 ms·

I partially disagree. "Can you think, can you write, can you build" are important, but difficult and time consuming to test, especially if there are a lot of (i

I partially disagree. "Can you think, can you write, can you build" are important, but difficult and time consuming to test, especially if there are a lot of (initial) candidates to choose from. Theoretical/trivia questions do give quick overview of field knowledge, especially connecting them thematically. For coding, 4-6 line "refactor this" tasks do the same. Candidate shouldn't even write, discussing solutions in pseudocode is enough. After jumping this bar, one can make more freeform discussions or do pair programming.

zbentley 9y ago
I think selecting a first-line interviewing strategy depends on how many candidates you have for the job. Do you have a large number of candidates for a small number of positions? Then tune your process to very quickly eliminate anyone who might not make the cut, at the cost of many false negatives (qualified people who are removed from the process due to e.g. not knowing trivia). This is the Google approach. Do you have a small number of candidates? Then interview for comprehension/ability to think and work with others, at the cost of more time spent interviewing and potentially more time spent mentoring qualified hires in specific trivia/skills needed to execute. This is the smaller company/less-well-known company approach. Most of the truly egregious failures in interviewing (not just in software!) come about due to companies picking the wrong strategy given their situation.