Hinting and Helping Candidates Shine

You’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.

A key part of extracting signal is making sure the candidate is able to put their best foot forward. An interviewer’s job entails setting up the candidate to shine—but it’s up to the candidate to actually shine. While the interviewer/interviewee relationship has an inherent adversarial component, if it’s clear that the interviewer is trying to set the candidate up for success, it can de-stress the process. Strategies might include outlining the flow of the interview before it begins, making it clear what the interviewer is looking for, and clarifying how the candidate can best provide answers. Giving appropriate guidance and hints can help get the candidate unstuck.

Much like the process of scaling the question, good hints are metered out carefully, starting with more general hints and gradually getting more specific. An interviewer who solves the problem for the candidate definitely doesn’t intend to hire them, so hints that answer for the candidate aren’t appropriate unless it’s clear they are not a fit. It’s also important to time hints properly—not too early, before the candidate has time to think; and not too late, when the interview runs overtime. This timing will vary by question (some questions take longer to answer than others), but if a candidate is clearly stuck for more than a few minutes, it’s usually time to get them unstuck. Also note that letting a candidate flounder for too long restricts what information you can gather as an interviewer. A candidate stuck for 45 minutes on a single aspect of a question might have performed brilliantly on the rest of the question, but for you to discover that, you’d have to give an appropriate hint so that they can move along.

Hints can take multiple forms:

• Nudging a candidate toward or away from a particular approach that they mentioned. This is especially important early in the question, so that the candidate doesn’t work on a mis-scoped problem. In this scenario, you might say something like, “Don’t worry about how this would work when stored on disk; you can focus on solving this in memory.”

• Giving the candidate general hints toward a solution. You might say, for example, “You mentioned binary trees; you might want to explore that direction further.” When they’re running out of time, these kinds of hints help a candidate get unstuck from a bad path that you believe they would eventually discard anyway.

• Giving the candidate general feedback on the solution. This might sound like the following: “I think you may have a bug” or “It seems like there are cases this solution doesn’t handle.” These hints give the candidate a chance to discover the gaps independently and also allow the interviewer to assess the candidate’s ability to reason about their solution.

• Giving the candidate specific feedback or direction. You might say, “What happens if you pass the argument 8 to this function?” These kind of hints are certainly strong, and might indicate some concern that the candidate isn’t able to track down the problem in question, but they give the interviewer a chance to validate that if a bug does turn up in a work setting, the candidate will be able to find it. These hints usually won’t invalidate a coding interview because this mimics the way most people run their code to find issues in real-life situations.

• Telling the candidate exactly why something is wrong and asking them to address it. “If your solution were to handle multiple connections simultaneously, it would have race conditions. How could you fix this?” This kind of hint can either be part of making a question harder, like if the initial problem statement didn’t include these constraints, or can be a sign that the candidate missed something critical to the problem. This kind of hint is a last attempt to see how the candidate handles the problem. Is their response, “Oh, of course, that was silly of me,” followed by an immediate explanation of how to fix it, or do they seem confused by why that is an issue in the first place? If they follow up with the former, you’re back on track.

For the sake of candidate experience, if at all possible, you’d like the candidate to get to a satisfying stopping point by the end of the interview. Being half-finished with a problem will carry over and negatively impact the rest of their day. Given that coding questions are particularly noisy, it’s most helpful to make the signal you get from each one be as independent as possible. If the interview has gone south, and it’s clear the candidate cannot recover, the next goal will be to lead them to that satisfying conclusion using whatever hints are needed, or even by explaining the problem directly.