Hiring at Speed: the '+-=?:' framework

20th June 2025 · Matteo Merola

Hiring is one of the most critical things we do as engineering leaders. It’s also one of the hardest to get right. Over the years, I’ve hired over a hundred engineers, and I’ve iterated constantly on my process. My goal is simple: make it fast enough to not lose great candidates, and robust enough to yield good results.

We’ve all been in those endless hiring loops. Multiple rounds, panels, and long debrief meetings where the loudest voice often wins. I found that a lengthy process doesn’t correlate with a higher quality of hire. It just correlates with a higher chance of your top candidate accepting another offer.

Engineers want to have a say in who joins their team, but they are rightfully focused on their work. Being mindful of their time is paramount. This led me to develop a lightweight yet powerful feedback collection method that has become the cornerstone of my hiring strategy. I call it the +-=?: format.

The Process in a Nutshell

My interview process is trimmed down to the essentials:

  1. Hiring Manager Interview: I conduct this first. It’s my chance to assess alignment on values, ambition, and high-level experience. It’s a chance for the candidate to understand what the hell we are working on and learn about the company’s business.
  2. Technical Assessment: A pair of engineers (sometimes a trio) from the team takes the candidate through a technical discussion. This is their domain.
  3. Feedback Collection: After the technical assessment, each interviewer sends me their feedback in a structured format.
  4. Decision Making: I review the feedback, look for patterns, and make a decision. If there are conflicting opinions, I follow up with the interviewers to understand their perspectives better.

The magic happens right after the technical assessment. Instead of a group debrief, which can be swayed by groupthink, I ask each interviewer to send me their feedback as a direct message. This forces individual assessment and prevents bias.

The +-=?: Feedback Framework

The feedback comes in a simple, structured text format. It’s easy to write and, more importantly, easy to parse. Here’s the breakdown:

  • + Positives: What were the candidate’s clear strengths? What did you like?
  • - Negatives: What were the red flags or clear areas of weakness?
  • = On-the-fence: Points that could be good or bad depending on context, or things that simply felt “off” to the interviewer.
  • ? Doubts: What questions are still unanswered? What do you wish you had more time to explore?
  • : Recommendation: The final call, with a one-line justification. The scale is: dont-hire | hire-but | hire | hire-now.

Here’s a real-world example of what I might receive from an interviewer:

+ experience with both frontend and backend
+ experience with the same industry
- little experience with react (mostly angular)
= very much into "agile" and "scrum"
? although has exp with frontend and backend I could not grasp the depth of exp in distributed microservice setups

: hire-now : I would love working with this person, they seem nice and can bring plenty of exp to our team

Why This Framework Works

After I receive a couple of these from the interviewers, I almost always have a clear picture. The benefits have proven to be significant:

  1. It Minimizes Unconscious Bias: By having interviewers provide feedback independently, I eliminate the risk of one person’s opinion influencing the entire group before the discussion even starts.

  2. It Maximizes Signal, Minimizes Time: Engineers don’t need to write an essay. They just need to fill the template. This structure gives them clear buckets to think about during the interview itself. The whole process is incredibly respectful of their time.

  3. It Gives Interviewers Freedom: I don’t dictate how the engineers should run their technical sessions. So long as they come away with enough signal to fill out the +-=?: feedback, they can drive the conversation in the way that feels most authentic to them.

  4. It Surfaces Misalignment for Calibration: What happens when I get one :hire-now and one :dont-hire? This is a gift. It’s a clear signal that the interviewers are not calibrated. It gives me a perfect, data-driven reason to bring them together and discuss their conflicting viewpoints. These calibration sessions are far more valuable than a generic debrief.

  5. It Allows for Feedback Weighing: Sometimes I’ll have a less experienced engineer shadow an interview for training. Their feedback is valuable, but I can weigh it differently against the feedback from a tenured senior engineer. The raw text format makes this implicit weighting easy.

It’s a Framework, Not a Cage

A common question I get is whether this simple format loses valuable nuance. Like any tool, its effectiveness depends on how you use it. Here’s how we address potential pitfalls:

  • On Losing Context: The +-=?: message is the start of the feedback process, not the end. Its purpose is to get a clean, unbiased initial read. If I see an intriguing comment in the = or ? sections, I’ll follow up with that interviewer 1-on-1 to get the richer story behind the summary.

  • On Candidate Experience: The “freedom” for interviewers isn’t a free-for-all. It exists within firm guardrails. As a hiring manager, I set clear expectations for the tone, goals, and rules of engagement for all interviews. We aim for a process that is respectful and consistent for the candidate, even if the exact technical topics vary. The speed of this process is, in itself, a huge plus for the candidate experience.

  • On Hidden Biases: Individual biases can still exist. The framework helps by making them more visible. If an interviewer lists something like "= very much into 'agile'" as a neutral point, it’s a flag for me to ask why. This allows me to challenge assumptions and ensure we’re judging skills, not personal preferences. It turns a potential hidden bias into a coachable moment.

  • On Training Junior Interviewers: The framework is an excellent training tool. When joining the interviews, I always pair a junior interviewer with a senior one. After the interview, they can discuss what they observed before sending me their individual feedback. I can then compare their reports to see how the junior interviewer is progressing in their ability to spot key signals.

Final Thoughts

Hiring will always be an imperfect science. The context matters—hiring a full-time employee is different from bringing on a fixed-term consultant. But the principles of respecting time, structuring feedback, and mitigating bias are universal.

YOLO hiring doesn’t work, and outsourced recruitment doesn’t always have the team’s best interests at heart. Building a great team requires a thoughtful process. This framework is my way of making it quick, robust, and engineer-friendly.