editione1.0.8
Updated August 24, 2022You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.
danger There are some interview questions that are designed to see how the candidate reacts to the parameters of the question, like asking an impossible question, never giving enough guidance on what the question is really about for the candidate to succeed, or being incredibly silent or non-interactive during the interview. Anything that feels like it could even possibly be considered a mind game is bad territory to be in.
Not only is this a poor way to treat a candidate (and strong candidates with other options will rightly drop out if treated like this), but an interview must assess candidate-company fit for both sides. Candidates want and need to know how you work and communicate, and it’s your job to demonstrate that to them.
If you go into an interview with the intention of lording your knowledge over a candidate, showing them how smart you are, they can tell. And if you ask questions but don’t really listen to the answers, it’s all too obvious.Eric Ries, author of The Lean Startup*
danger It’s critical not to fall into the trap of trying to compete with the interviewee or to impress them for the sake of the interviewer’s ego.
A shibboleth question is an interview question that seeks to quickly assess a candidate’s general capabilities in an area by asking a question that the interviewer believes anyone in that area ought to know the answer to.
dangerThese questions are dangerous because not everyone will agree on what the common knowledge base in an area is, and asking for very specific knowledge will filter out qualified candidates. For example, not all software engineers will necessarily know dynamic programming.
These kinds of questions can be used by technical screeners and even recruiters if you have a high enough volume of candidates that you need some way to filter and also can’t find another way to distinguish otherwise equally qualified candidates. But it’s risky and does not create a good candidate experience, because it suggests you care more about factual knowledge than general ability, which rubs people the wrong way. It’s also problematic for candidates from nontraditional backgrounds. Anything keyword-based, especially when assessed by a non-coder, is going to be biased against them.
cautionTwo other specific kinds of questions to watch out for are brainteasers and Fermi problems. These kinds of questions used to be popular, but neither have been shown to correlate with job performance and may annoy many candidates or distract from more practical and relevant signals.