How to stop failing behavioral interviews
What I'm actually listening for when you answer.
👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
I can tell you someone’s level before they finish their first answer.
Not because I’ve read their resume closely, and not because I’ve quizzed them on architecture. I can tell from the first ninety seconds of a behavioral answer, before they’ve even gotten to the result, whether I’m talking to a mid-level engineer or a Staff one.
This is how interviews work, and once you see it, you can’t unsee it.
Your level gets decided very early
Two engineers can describe the exact same project, with the exact same outcome, and walk out of an interview leveled two grades apart.
One says: “We had a service that kept falling over, so we spent a sprint fixing the flakiest parts. It went well, things are more stable now.”
The other says: “I noticed our checkout service was failing intermittently, tracked it to a shared connection pool three teams were touching without realizing it, and decided we needed a two-week freeze on that service to get a fix in. Two teams pushed back. I walked them through the incident data and we agreed on a smaller, scoped fix instead.”
Same project. But an interviewer hears two completely different candidates. The first sounds like someone who was part of the team. The second sounds like someone who ran the effort.
Sometimes I stop taking notes on outcomes by the time the candidate gets to them, because the outcome rarely tells me anything I didn’t already decide two sentences earlier.
I’m listening for:
Scope of ambiguity. Did you get handed a ticket, or did you have to figure out what the actual problem even was?
Who you influenced. One teammate is a data point. Three teams with conflicting priorities is a different job entirely.
Whether your influence stopped at your team. The signal is what happened with people who didn’t have to listen to you.
Whether you name the trade-off. “We decided to do X” tells me nothing. “We chose X over Y because Y would’ve meant a slower rollback if it broke” tells me you understood the bet you were making.
Whether you noticed the problem or were told about it. Passive discovery is fine for a junior engineer. Active discovery, before anyone assigned it to you is what’s expected of senior+.
None of this requires more experience than you have probably. Most candidates that are under-levelled have plenty of the right experience. They just never learned to say it that way.
I wrote more about what this looks like from the hiring side in Your interview process for senior engineers is wrong.
The frameworks aren’t the problem
Everyone tells you to use STAR. Fewer people tell you what it’s actually for.
STAR, or CARL, or whichever four-letter acronym you’ve bookmarked, is not something you build in real time while a stranger watches you think. It’s a filter you apply beforehand, to decide which three or four stories from your career are worth having ready.
Most candidates skip that step. They get in their interviews with a general sense of “things I’ve done” and try to shape a structured answer while someone is taking notes on how long they’re taking to get to the point. That’s where the rambling comes from.. you’re doing outline and delivery at the same time, out loud, for the first time, in the interview of the company you really want to join.
If you ramble for six minutes on a question you actually know the answer to, we can agree that it’s a rehearsal problem, not a knowledge gap.
A written answer isn’t a spoken one
So some candidates do the sensible thing. They sit down, they write out their STAR stories in a doc, they polish the language, they read it back a few times.
And then they get into the interview and it falls apart anyway, because writing and speaking are two different skills that happen to use the same words.
A written story doesn’t interrupt you, doesn’t ask “wait, why did you choose that over the alternative?” halfway through, and doesn’t force you to improvise an answer to a follow-up you didn’t prep for while keeping your tone steady.
This is also why Stop interviewing like a mid-level engineer keeps coming up in conversations I have with my mentees who are technically strong and still get rejected. Their gap usually is that their judgment has never been pressure-tested out loud before their interviews.
You can’t hear your own blind spot
You cannot self-assess your own narration.
You already know what you meant and that’s exactly the problem. When you read your own STAR doc back to yourself, your brain fills in all the context you didn’t say out loud, because you were there. You’ll never catch yourself saying “we decided” when you meant “I decided”, because in your head, you already know it was you.
An interviewer doesn’t have that context. They only have your words. Which means the only way to find out what your story actually sounds like from the outside is to say it out loud, to someone who wasn’t there, who’s willing to interrupt you and push back the way a real interviewer will.
Most people don’t do this until their actual interview. The first time they hear their own story land is also the only time it counts.
You need to rehearse with friction built in. Say the story out loud. Get interrupted the way a Bar Raiser or a Staff-level panel actually will. Then find out, in a language more specific than “that felt fine”, exactly where the story read as scope you own versus scope you were near.
That’s the entire premise behind the mock interview coach I built into em-tools.io/interview-prep. It’s not a chatbot that tells you “good answer, nice use of leadership”. You have an actual voice conversation, it follows up the way a real interviewer follows up, and it scores you across the exact signals above, including scope and complexity, specificity, and how much of the story was you versus “the team”. You get a model answer next to your own, so you can see precisely where the same accomplishment could have read one level higher.
It’s free to run your first few questions through it. If a story you thought was strong comes back scored as vague on scope or thin on trade-offs, that’s the version of that feedback you actually want before your interview.
Try a free mock interview with one story you’re planning to use in your next loop.
What’s next for you probably isn’t more prep. It’s finding out, before it costs you a level, what your best story actually sounds like from an interviewer’s perspective.
See you in the next one,
~ Stephane
P.S. If you’re looking for Engineering Manager roles, this is the exact system I have used to get multiple EM offers after only 2.5 years into being an engineer.