How Behavioral Interviews Are Scored

A behavioral interview asks what you've done rather than what you would do, on the idea that how you handled real situations is the best guide to how you'll handle the next ones. At many companies it's a round of its own, run by the hiring manager, an engineer or manager from a nearby team, or someone whose job in the loop is to assess behavior and values for every team. Other companies fold a few behavioral questions into their technical rounds. Either way your answers are scored, and a weak behavioral round can cost you an offer the coding rounds earned.

A dedicated round often runs 45 to 60 minutes. It usually opens with introductions and tell me about yourself, covers three or four questions, each with several follow-up questions, and saves a few minutes at the end for your questions. That's 10 minutes or more per story, so the interviewer plans to dig into each one, not to hear it and move on. While you talk, the scoring has already started.

1. Notes. Many interviewers type or write down close to what you say, especially your actions, decisions and numbers, because their write-up has to quote evidence rather than impressions.
2. Competencies. Each company has its own list of what it hires for, such as ownership, handling conflict or dealing with ambiguity, and some publish it as values or leadership principles. Interviewers are usually assigned a few to cover, and each story counts as evidence for or against them.
3. The write-up. Afterward, the interviewer scores each competency, often on a short scale, adds an overall hire or no-hire recommendation, and backs both with evidence from their notes.
4. Calibration. Your interviewers compare write-ups in a debrief or a hiring committee, next to your technical feedback. A specific example they can quote persuades the room. "Seemed like a strong communicator" doesn't.

Every score is calibrated to the level you're interviewing for. The interviewer isn't only asking whether this is a good story, but whether it's the story of someone at this level. What changes most from level to level is scope: how far the effects of your work reached, and how much of the problem you owned.

Entry, mid   [own work]
Senior       [own work][team]
Staff        [own work][team][cross-team]
Principal    [own work][team][cross-team][org]

That's why the same story can score differently. Say you found a slow database query, rewrote it, and halved a page's load time. For a mid-level engineer that's a clear, strong answer. For a staff engineer it's thin. The interviewer wants to hear how you noticed several teams kept shipping the same kind of slow query, got them to agree on a fix, and what changed across all of them. Prepare stories that match the level you want, and when you tell a smaller one, say what it led to.

Across all of this, a strong answer is made of evidence. It's one specific situation, not "what I usually do". It says what you did and why you chose it, apart from what the team did. It ends with a result someone could check, and it holds up when the interviewer digs. A weak answer is general, hypothetical, all "we", or a good story that answers a different question. The STAR method puts the evidence where the interviewer is looking for it.