Post-interview recommendations: a case against ‘maybe’
If you’re ever an interviewer on a role I’m hiring for, there’s this one thing I’m going to ask you to do that might feel weird. After you conduct that interview, I’m going to ask you to send me a recommendation, and I’m going to insist that the recommendation begins with a very clear “hire” or “no hire”. I won’t accept any form of “maybe”.
Many people find this uncomfortable; they want to avoid being this direct. That’s understandable. It’s uncomfortable feeling like you’re passing judgment; I get why folks want to avoid that. But if you send me a recommendation that leaves out this bottom line, or if you give me a “maybe” or something similarly non-committal, I’m going to push back. This post explains why.
Examples
Before diving in, let’s look at a few examples of what I’m talking about. Here are three example recommendations I wrote, based on some real interviews. They’ve been heavily edited and redacted: names have been changed, identifying information has been omitted, and I’ve changed most of the technical terms to something similar (e.g. I’ll have changed “Python” to “Ruby”, “AWS” to “GCP”, etc.). I’m also only including the first paragraph – the real things are longer and have more details (but that’s another post).
The context here is an interview for a Staff-plus security engineer – a quite senior but non-manager security leader. My interview focused on technical topics: threat modeling, vulnerability remediation, and secure development workflow. I was looking for a detailed understanding of these areas, and also an understanding of the organizational issues of fitting these activities into a larger engineering organization.
First up, here’s a strong “yes” recommendation:
Hire. Tina’s technical skills are extremely strong, a really good match to what we’re looking for. Tina demonstrated deep experience in security engineering, particularly around threat modeling, static analysis tooling, memory-safe languages (particularly Rust), and similar topics. I have some minor reservations about her ability to think organizationally/strategically, but I think those weaknesses are minor and more than outweighed by her strengths.
Here’s a candidate where I’m recommending that we don’t extend them an offer, but it’s more complicated than a simple “no”:
No hire. For a less senior role, particularly one that’s appsec-focused, he’d be a fantastic fit, but for this senior/leadership role, it’s a “no”. The bottom line is that Abdul demonstrated really solid instincts, especially for secure design, and also showed strong experience in application security (pentesting, mostly). But he showed serious gaps around infrastructure security, to the point that I wouldn’t trust him to work well with engineers without some very firm leadership and guidance. I don’t see him being effective in leading mixed-discipline teams, and that sort of cross-over engineering/security is pretty critical. I think he could get there with the right management/mentorship/leadership, but he’s not there yet.
Sometimes, an interview goes so badly that you can’t imagine ever working with this person. Here’s what a “no” recommendation looks like:
No hire. This interview was, bluntly, a disaster. Boris was not able to answer any of my questions with any degree of success and did not demonstrate any of the skills necessary for the job. The conversation was almost entirely devoid of any level of technical depth, despite repeated probing. Every time I pushed for specifics — tools, protocols, APIs, etc — he changed the subject and spoke in generalities. There were a couple of other red flags: a few mildly inappropriate jokes; some overly personal questions. This isn’t someone we should have on our team.
The most important part of your recommendation is a clear “yes” or “no”
As you can see, the format I recommend starts with the phrase “hire” or “no hire”. Forcing people to give a clear “yes” or “no” is important to me; this is a hill I’ll die on.
The cold truth is that at the end of the hiring process, you have a binary decision to make: offer, or no offer. You can’t “maybe hire” someone; you need to make a decision. Sometimes that decision is really easy, but often it isn’t: people are complex, and it’s rare for someone to be a perfect match or an obvious “hell no”. While the final decision rests with the hiring manager (perhaps in conjunction with their manager, HR, etc.), I want everyone on the hiring panel to be on the same page that a clear “yes” or “no” is the outcome we’re headed towards.
This “yes” or “no” is also the most important piece of feedback that a hiring manager can get from the hiring team. You might work with this person; are you excited about that prospect? If you don’t come out of an interview feeling like you could trust this person to be your colleague, you need to tell me you think they won’t be able to do the job.
Finally, forcing up-or-down recommendations helps prepare people to ultimately be in the decision-making role. Not everyone involved in hiring has the ambition to become a hiring manager, but many do. Making hiring decisions is one of the harder things that a hiring manager does, so when you’re making a hire/no-hire recommendation you’re getting to practice this skill in a lower-stakes way.
Expanding on the recommendation: “yes, but …” or “no, unless…” is fine
The next part of a written recommendation is to briefly summarize why you’re making this hire/no-hire recommendation. This summary is the most important couple of notes about the candidate: why you’re recommending “yes” or “no.”
This is where you can caveat your “hire” or “no-hire” recommendation. Again, I think it’s vital to give a clear “yes” or “no” recommendation, but it’s common for that recommendation to be “rounded up” or “rounded down” from a more nuanced take. So while your recommendation should start with a “yes” or a “no”, it’s fine for that to be of the form “yes, but …” or “no, unless…” Frequently, this takes the form of a statement like:
- “Hire, but the candidate was weak in Area X. I don’t think that’s a dealbreaker, but if it is, then we shouldn’t make an offer”
- “No hire for this position, because of Reason Y, but they’d be great for Role Z”
- “No hire, because of weaknesses in Area X, but with enough coaching/mentorship I think it’d be fine”
- “No hire because of X, but I’d change my mind if other interviewers said …”
These are important pieces of information. Sometimes things that you thought were a dealbreaker turn out to be something that the hiring manager thinks can be managed around. Or something you thought wasn’t a big deal turns out to have been echoed in other interviews and is revealed as a trend.
Usually, one paragraph is enough
This kind of single-paragraph recommendation is the core of a post-interview written recommendation. Usually, this is enough; if there are additional details the hiring manager can follow up. So for most hiring practices, I don’t advise asking interviewers to write recommendations much longer than the examples above.
In some cases, you will need more. For example, right now a bunch of my hiring is done on behalf of a client. In those cases, I’ll follow a paragraph like the above with an in-depth debrief on the interview (5-10 paragraphs, usually). That level of detail feels important in a consulting relationship because I’m not as intimately familiar with the details of my client’s organization. There may have been something that seemed minor to me but was a red flag, so I need to try to share as much detail about my recommendation as possible.
I also haven’t touched on how grading rubrics fit into post-interview recommendations.
If you’re interested in seeing what these longer recommendations look like, or want to know about grading rubrics, stay tuned. I plan to write about them both in the future.