Masterclass notes · 19 September 2026
Behavioural interviews, taken apart.
Everything from the hour, written out. Print it, or save it as a PDF from your browser.
The one idea
A behavioural interview is not a storytelling contest. It is an evidence-collection exercise, and the interviewer is filling in a form while you talk.
The debrief decides, not the interview
What happens after you leave the room is where the decision actually gets made:
- Each interviewer writes up notes independently, usually within the hour, before hearing anyone else’s view.
- Everyone submits a recommendation before the discussion, so nobody anchors on the loudest voice.
- The panel meets, and each person defends their read using only what you said.
- Disagreements get settled by going back to the evidence in the notes.
You are not in that room. Your words are. Whoever wants to hire you can only argue with what you gave them to write down.
Two notes from the same hour
“Came across well. Strong communicator. Talked about a migration and a disagreement with security. Seemed senior. Hard to tell what he personally did.”
Loses the debrief
“Rejected a full launch against product pressure. Designed a 5% canary with agreed error thresholds. Walked security through the rollback personally. Shipped on the original date; full rollout nine days later.”
Wins it
The same candidate could have produced either. The difference is what he gave the interviewer to write.
Three answers, marked up
These weak answers are not strawmen — they are what capable people genuinely say, which is precisely the problem. They sound fine.
1. “Tell me about a time you received critical feedback.”
Testing: Can you take feedback without getting defensive?
“Yeah, so in one of my performance reviews my manager told me I needed to work on my communication — that I wasn’t always keeping stakeholders in the loop. I took that on board. I made a real effort to be more proactive with updates and to communicate earlier in the process. By the next review cycle she said she’d definitely seen an improvement, so I think it worked out well.”
| “work on my communication” | Which communication? To whom? About what? |
| “wasn’t keeping stakeholders in the loop” | Whose words — his or hers? No example. |
| “I took that on board” | Not an action. A posture. |
| “made a real effort to be more proactive” | Effort is not a change. What did he do? |
| “she said she’d seen an improvement” | The proof is an opinion, not an outcome. |
2. “Tell me about a time you disagreed with your manager.”
Testing: Can you disagree without becoming difficult?
“My manager wanted to go with a particular approach on a migration, and I had concerns about whether it would scale. I raised it in our one-to-one and explained my thinking. He heard me out, and in the end we went with his approach — and honestly, it worked out fine. I’m a big believer in disagree and commit, so once the decision was made I got fully behind it.”
| “concerns about whether it would scale” | Scale to what? No number, no threshold. |
| “explained my thinking” | Thinking based on what — data, or a hunch? |
| “he heard me out” | Describes his manager, not himself. |
| “it worked out fine” | So he was wrong? Left unexamined. |
| “I’m a big believer in disagree and commit” | Quoting the principle isn’t demonstrating it. |
3. “Tell me about a time you failed.”
Testing: Accountability and learning.
“We had a project last year that slipped by about a quarter. There were a lot of dependencies on other teams that didn’t land when they said they would, and the requirements changed partway through, which didn’t help either. Looking back, we probably should have communicated the risk earlier. I definitely learned the importance of setting expectations with stakeholders up front.”
| “we had a project that slipped” | Whose project? Who was accountable? |
| “dependencies that didn’t land” | Other teams’ fault. |
| “the requirements changed” | Product’s fault. |
| “we probably should have…” | Hedged, collective, hypothetical. |
| “I learned the importance of…” | A lesson with no behaviour change attached. |
The same three, told properly
These are worked examples, not my CV. They are constructed to show the shape of a strong answer. Use them as a template for your own material — the value is in the structure, not the stories.
1. “Tell me about a time you received critical feedback.”
Situation
Two years into leading the payments platform team, my skip-level told me in a review that I was making architecture decisions too fast — that two of my tech leads were finding out after the call had already been made. She’d heard it from them directly.
Task
I needed to change how decisions got made on my team, not just promise to be more careful.
Action
I asked her for specifics instead of defending myself — which decisions, and who felt cut out. Then I went to both leads and asked them directly. They named the same thing: I was deciding in design reviews without circulating context first. So I changed the mechanism rather than my intentions. Any decision touching more than one service now got a one-page doc circulated 48 hours ahead, and I stopped deciding in the room. I also started a fortnightly forum where the leads brought their own decisions for input.
Result
Design docs went from about two a quarter to eleven. More importantly, two architecture decisions in the following six months were reversed before implementation because someone caught a problem in the doc — which was the entire point of the change.
Takeaway — Don’t prove the feedback was wrong. Prove you changed a mechanism — and show what the mechanism caught.
2. “Tell me about a time you disagreed with your manager.”
Situation
My director wanted a new notification service live in six weeks to hit a partner launch. I’d run the load numbers: the proposed design topped out around 400 messages a second, and the partner’s own forecast was 3,000 at peak.
Task
I needed either the design changed or the date changed — and I owned neither of those decisions.
Action
I didn’t argue about the date, because that would have been my opinion against his. I built a load test against the prototype and showed him the curve instead: degradation at 600/s, failure at 900. Then I brought two costed options rather than an objection — ship on the original date to a single pilot customer capped under 500/s, or take three more weeks and re-architect the queue. I wrote up the risk of each, including the risk of the one I preferred.
Result
He chose the pilot, which was not my recommendation. We shipped on the original date, it held, and the re-architecture landed the following quarter before general availability. Given what I put in front of him, I think he made the right call — my job was to get the 900/s number onto the table before the decision, not to win the argument.
Takeaway — Bring costed options, not objections. A disagreement you lost, told honestly, scores higher than one you won.
3. “Tell me about a time you failed.”
Situation
I led the migration of a document-processing service onto a new control plane. I estimated eight weeks. It took twenty-two, and it blocked two other teams’ roadmaps for a quarter.
Task
The estimate was mine, and so was the method that produced it.
Action
The mistake was specific: I scoped the work by reading the service’s code, and I never spoke to the teams calling it. Two of them depended on an undocumented endpoint I’d planned to delete. I found out in week nine, when their integration tests broke in staging. I stopped the migration, wrote down every caller, went and talked to all three teams, and re-planned from what they told me rather than from what the code implied.
Result
Twenty-two weeks instead of eight — there’s no way to dress that up. What changed is the method: I now build a caller inventory before I estimate anything. On the next two migrations I did that first, and both landed within ten percent of estimate.
Takeaway — A strong failure answer is not only about what failed. It shows ownership, recovery, and what changed afterwards.
The five things every strong answer does
If you keep one thing from the hour, keep this.
- A number early. 400 against 3,000. Eight weeks became twenty-two. Two docs became eleven.
- A named alternative that was rejected — and why. That is where judgment lives.
- An artefact. A one-page doc. A load test. A caller inventory. Something that existed, that you made.
- “I” on the decision, “we” on the outcome. The pronoun was never the problem — hiding your contribution was.
- Proof the change held. Two reversals caught in review. The next two migrations on time.
Note what is not on that list: being impressive, being likeable, or having a happy ending.
The ground a loop covers
A five-interview loop samples six or seven of these nine areas. Most candidates have genuinely prepared for two — usually Ownership and Problem Solving, because those are the comfortable ones.
- Scope and impact
- Ownership and execution
- Judgment and decision-making
- Ambiguity and adaptability
- Conflict and influence
- Communication and collaboration
- Learning, failure and recovery
- Leadership and developing others
- Customer and product thinking
What to do this week
- Take your best story and check it against the five above.
- Find one number you have been approximating. It is in an old dashboard or doc.
- Write your answer to “what was the other option, and why didn’t you take it?”
You need five or six experiences you know deeply enough to survive follow-ups — covering conflict, failure, ownership, ambiguity, influence and customer impact. Most people arrive with three and stretch them across questions they don’t fit.
Questions from the session
These came up live. They're paraphrased and attributed to nobody — several of you were candid about things you would not want quoted with your name on them, and that candour is what made the hour useful.
Can I say I used AI — Claude, Gemini, ChatGPT — when I talk about writing a design doc or building a roadmap?
Yes, and it's encouraged. I use Claude and Codex myself and write almost no code by hand. But you have to define the problem statement and the goal yourself before you hand anything to a model. If you don't, it will hallucinate or take you somewhere unproductive — and an interviewer probing the detail finds that very fast. Own the thinking, delegate the production.
How many stories do I actually need?
Five or six solid ones you can adapt. Not one per principle — a good story stretches across several, provided the evidence for each is genuinely in it.
What if I realise halfway through that I've misunderstood the question?
The fix is earlier than that: don't rush into the answer. State your assumption first — “I'm taking this as a technical disagreement rather than a people one, is that right?” — and you rarely end up there. Clarifying costs ten seconds. Recovering mid-answer costs the answer.
How do I handle a question about conflicting stakeholder priorities?
It depends on your role — an engineering manager and a product manager are being tested for different things. Either way it needs a concrete example: why the conflict existed (competing roadmaps, or no data to settle it), what you specifically did (brought a customer signal, brought numbers), and what changed as a result.
What if I get a question I haven't prepared for?
Don't build a story on the spot. An experienced interviewer probes for fine detail, and an invented story collapses in about two follow-ups. The defence is preparation plus familiarity — know everything on your own CV well enough to adapt it under pressure.
The interviewer wants hands-on experience with something I only know theoretically.
Say so. Modern loops weight adaptability and general problem-solving more heavily than rigid hands-on experience with every specific tool. An admitted gap is recoverable. A bluff that unravels is not.
My experience doesn't match the roles I'm targeting, and my answers fall apart under scrutiny.
That's the honest version of a problem a lot of people have, and the answer isn't better wording — it's material. Two routes: projects outside work, or finding something inside your current job that builds the experience you need. There is almost always something relevant you can build where you already are.
Separately, tailor your CV to at least a 50% match with the job description. Below that, a hiring manager never gets as far as your interview.
“Why are you leaving your current job?”
Good reasons: growth has stalled, you've stopped learning, the team was dissolved, you're relocating. Avoid anything interpersonal — disliking your manager or your team reads as a risk you would bring with you.
Where to go from here
You now know what a strong answer contains. The work left is doing it to your own material — five or six times over. These are the four ways I can help, in order of how much of it you want to do alone.
Start here · free
Story Builder
The interrogation from this handout, run on your own CV. It reads your experience, picks the one that fits the question you're preparing for, and asks up to five focused questions — including the two nobody asks themselves: which part was yours, and what was the option you didn't take. Then it writes the answer back in STAR, built only from what you confirmed.
It will not invent an achievement or a metric to make your answer sound better. If the evidence is missing it tells you what to go and find.
First two stories free · mystorybuilder.netlify.app
The questions we didn't reach · $9.99
Mastering the Interview
We marked up three answers in an hour. The book does 112 — every one written out in full STAR, across the nine areas on the previous page and four role tracks: program management, product management, product marketing and software development. Use it the way you'd use worked solutions: read the shape, then write your own.
$9.99 · askgurpreet.com/ebooks
If you have a loop coming · $299
Interview Preparation
Mock interviews run the way they are actually run inside Amazon and Microsoft — including the follow-ups, which is where prepared answers come apart. You get the feedback an interviewer writes but never shows you: which of the five your answer was missing, and what a debrief would have said about it.
If you're not sure it's the right thing, a 15-minute discovery call is $9.99 and exists precisely to work that out.
$299 · askgurpreet.com/coaching
A different problem
The AI Internship
Everything above assumes you have the experience and need to describe it better. For some people the honest problem is the other one — the stories aren't there yet. This is one real project, built end to end, reviewed by a Big Tech engineer, so that in six months you have something to answer these questions with.
Questions, or a story you want pressure-tested — reply to the email, or write to info@askgurpreet.com.