In the technical rounds you fail on what you don’t know. In the behavioural round you fail on how you tell the story — and the failures are depressingly predictable. Interviewers rarely tell you when you’ve tripped one; they just quietly lower a score on their rubric and move on. This lesson walks through the nine red flags that sink the most candidates, and the fix for each. None of them require better experience. They require telling what you already did in the right way.
Mistake 1: Hiding behind “we”
What it sounds like:
“So we decided to re-architect the service, we moved it onto a queue, and we cut the latency in half.”
It sounds like teamwork. It scores like a blank. The interviewer is trying to figure out what you did, and “we” tells them nothing. When every sentence is “we”, the natural read is that you were in the room while other people did the work.
Why it hurts: The single biggest signal in a behavioural interview is ownership. “We” erases it.
The fix: Use “we” to set the scene, then switch to “I” for your actions. “The team was blocked on the migration, so I proposed the queue design, I wrote the proof of concept, and I drove the review that got us aligned.” It can feel boastful at first. It isn’t — it’s answering the question. You can still credit the team in the result.
Mistake 2: No result, no metrics
What it sounds like: A detailed story about what you did that just… stops. The interviewer waits for the payoff and it never comes.
Why it hurts: Impact is the second-biggest signal, and impact lives in the Result. Without it, the interviewer can’t tell whether your clever action actually mattered.
The fix: Always close with the outcome, and reach for a number. “Latency dropped from 800 ms to 120 ms at p99, which unblocked the launch and cut our on-call pages for that service by about 70%.” If you genuinely have no metric, use a concrete qualitative result: “The feature shipped on time, and the customer renewed the contract the next quarter.” A fuzzy result still beats no result.
Mistake 3: Blaming others or the company
What it sounds like:
“The project failed because the product manager kept changing the requirements and the other team never delivered their API.”
Why it hurts: It’s the fastest way to fail a failure question. The interviewer isn’t checking whether the failure was your fault; they’re checking whether you can own your part and learn from it. Blame signals the opposite — that in a real post-mortem you’d point fingers.
The fix: Own your contribution, even when you weren’t the main cause. “In hindsight, I should have flagged the dependency risk much earlier and built a fallback. I now start every project by listing the external dependencies and a plan B for each.” You can mention external factors in one neutral sentence, but the weight of the story must be on what you learned.
Mistake 4: Rambling with no structure
What it sounds like: Four minutes of backstory, a tangent about the tech stack, a detour into office politics, and the interviewer has lost the thread before you reach the point.
Why it hurts: Communication is itself a scored signal, and a senior role is partly about explaining things clearly under pressure. A shapeless answer reads as “can’t structure a thought.”
The fix: Use STAR (Lesson 2). One sentence of Situation, one of Task, the bulk on your Actions, and a crisp Result. If you feel yourself wandering, say “to get to the point…” and jump to the action. Aim for two to three minutes per answer.
Mistake 5: Over-rehearsed and robotic
What it sounds like: A word-perfect monologue delivered at a wall, with no eye contact and no room for a follow-up. It’s clearly memorised, and the moment the interviewer asks “why did you choose that?”, the script breaks.
Why it hurts: It kills the sense that you’re a real person they’d want to work with, and memorised answers are brittle — they can’t flex to the actual question.
The fix: Memorise the beats of each story (the STAR skeleton and the key numbers), not the words. Then tell it fresh each time. This also lets you re-aim the same story at different questions, which is the whole point of a story bank.
Mistake 6: Choosing a weak or trivial story
What it sounds like: “A time you showed leadership” answered with “I organised the team lunch rota.” The structure is fine; the stakes are nothing.
Why it hurts: The interviewer can only score the signal your story actually demonstrates. A low-stakes story caps your score no matter how well you tell it.
The fix: Pick stories with real stakes — a launch at risk, a production incident, a genuine disagreement, an ambiguous project you had to scope. When in doubt, choose the story where something could have gone badly wrong and you influenced the outcome. Your story bank should be built from these.
Mistake 7: A “failure” that is secretly a brag
What it sounds like: “My biggest weakness is that I care too much and work too hard.” Or a “failure” story where the only mistake was being too thorough.
Why it hurts: It reads as evasive. The interviewer asked for a real failure because they want to see self-awareness and growth; a humblebrag gives them neither, and it signals that you can’t be honest about your own gaps.
The fix: Tell a genuine mistake with real consequences — then spend most of the story on what you learned and what you now do differently. A real failure, well-owned, is a strong answer. Showing you can grow from a mistake is exactly the signal they’re after.
Mistake 8: Not answering the question asked
What it sounds like: The interviewer asks about a conflict with a peer, and you tell your prepared “hardest project” story because it’s the one you know best. It’s a good story — about the wrong thing.
Why it hurts: It shows you weren’t listening, and it fails to produce the specific signal they were probing for. Interviewers often have a checklist; a mismatched answer leaves a box unticked.
The fix: Listen to the exact ask, then take two seconds to pick the matching story from your bank. It’s completely fine to pause: “Let me think of a good example of that.” A ten-second silence that produces the right story beats an instant answer to a different question. If you must adapt a story, say which part you’re emphasising.
Mistake 9: Negativity about past teams or managers
What it sounds like: Eye-rolling about a “toxic” manager, a “clueless” product team, or a “dumpster fire” codebase.
Why it hurts: However justified, it signals how you’ll talk about this team in a year. It reads as low earn-trust and poor judgement.
The fix: Stay neutral and factual about people and context, and keep the focus on your own actions and decisions. You can describe a difficult situation honestly without passing a verdict on the humans in it.
Before and after
Here’s a weak answer to “Tell me about a time you disagreed with a teammate,” rewritten.
Weak:
“We had this situation where the other engineer wanted to use MongoDB and I thought it was a bad idea. We argued about it for a while. Eventually we went with Postgres and it worked out fine.”
Everything is “we”, there’s no action, no stakes, no result, and a vague ending. It proves nothing.
Strong:
”(Situation) On the payments service, a senior engineer wanted to store transactions in MongoDB; I was concerned we’d lose the ACID guarantees we needed. (Task) As the person owning correctness for that service, I had to resolve it without just pulling rank or stonewalling. (Action) Rather than argue abstractly, I wrote a two-page doc comparing the two for our actual access patterns, and I built a small spike showing a double-write bug that was easy to hit without transactions. I walked them through it one-on-one first so it wasn’t a public showdown. (Result) They agreed Postgres was the right call for the money path, and we kept Mongo for the analytics store where it fit. We shipped with zero consistency incidents in the first year, and that ‘write a short doc and a spike’ habit became how our team settled design disagreements.”
Same raw experience. One proves nothing; the other proves ownership, judgement, the ability to disagree without damaging the relationship, and a measurable result.
The meta-pattern
Every mistake on this list reduces to one of three things:
- Make your part visible. “I”, not “we”; actions, not context.
- Close the loop. Always land a concrete, ideally measured, result.
- Be real. Genuine stakes, genuine failures, no scripts, no blame.
Fix those three and you’ve dodged almost everything that sinks candidates on this round.