Behavioural Interviews and the STAR Method
Definition
A behavioural question asks what you did in a past situation. The STAR method structures the answer as Situation, Task, Action and Result, spending most of the time on what you did and what came out of it.
Why it exists
Technical skill alone does not show how you work with others. Past behaviour is how interviewers judge ownership and judgement, and a structure keeps your answer focused.
How it works
STAR, with senior-level emphasis
| Part | What to say | Proportion |
|---|---|---|
| Situation | Context in 1-2 sentences: system, scale, team, stakes | ~10% |
| Task | Your responsibility or the problem to solve, and the constraint | ~10% |
| Action | What you did, step by step, and why, including options you rejected | ~60% |
| Result | Measurable outcome, what you learned, and what you changed afterwards | ~20% |
Tips:
- Say "I", not "we", for your actions, and "we" for team outcomes. Credit others genuinely.
- Quantify: latency from 900 ms to 120 ms, incidents down 70%, deploys from weekly to daily, cost saved, users affected.
- Keep each answer to 2-3 minutes; stop and let them ask for depth.
- Include the trade-off or mistake: it signals judgement and honesty.
- End with the learning and a later application (a pattern you now use).
- Add a STAR + L (learned) tail for failure questions.
Build your story bank
Prepare 6-8 stories that can answer many questions. For each, write bullets: situation, your actions, metrics, lesson. Tag each with themes:
| Story | Themes it can serve |
|---|---|
| A production incident you led | Ownership, pressure, communication, post-mortem, technical depth |
| A performance/scalability win | Impact, data-driven decisions, technical depth |
| A conflict or disagreement | Collaboration, influencing without authority, empathy |
| A project that failed or slipped | Failure, accountability, learning, risk management |
| A time you led a design/migration | Leadership, trade-offs, stakeholder management, ambiguity |
| Mentoring someone / raising the bar | Leadership, coaching, culture |
| Ambiguous or changing requirements | Ambiguity, prioritisation, pushing back |
| A tough technical decision | Judgement, trade-offs, risk |
Common questions and what interviewers listen for
| Question | Listening for |
|---|---|
| Tell me about a production incident you handled | Calm triage, communication, root cause, prevention |
| Describe a disagreement with a teammate or manager | Respect, data over ego, resolution, relationship afterwards |
| Tell me about a failure | Accountability without blame-shifting, concrete learning |
| How do you handle ambiguity? | Clarifying questions, small experiments, decisions with incomplete data |
| Tell me about a time you improved a process or system | Initiative, measurement, adoption |
| How do you prioritise? | Impact vs effort, stakeholders, saying no |
| Tell me about mentoring | Investment in others, specific techniques, outcomes |
| Describe a time you influenced without authority | Persuasion by evidence, empathy, building coalitions |
| Why are you leaving / why us? | Positive, forward-looking, researched |
| What is your biggest weakness? | Self-awareness plus an active improvement plan (real, not a disguised strength) |
Answering specific tricky questions
- "Tell me about a time you disagreed with your manager." Show respectful candour: you presented data, listened, and either aligned or committed to the decision ("disagree and commit"). Never badmouth.
- "What would your last manager say about you?" Name a strength and a growth area, each with an example.
- "Why did you leave / are you leaving?" Be positive: what you seek (scope, domain, scale), not complaints.
- "Tell me about a time you made a mistake in production." Prefer a genuine one; focus on detection speed, communication, and prevention.
- "How do you handle pressure and deadlines?" Prioritise ruthlessly, communicate early, negotiate scope, protect quality in critical paths.
- "Where do you see yourself in 3-5 years?" Deepening technical leadership, owning bigger systems, growing others; align honestly with the role.
Leadership signals for senior and staff roles
- You raise the bar for the team (design docs, standards, tooling), not just for your own code.
- You make others effective: unblock, delegate, coach, document.
- You influence across teams with evidence and empathy.
- You manage risk and ambiguity, use data, and are comfortable saying "I don't know yet, here is how I'll find out".
- You communicate to different audiences: engineers, product, executives.
- You own outcomes, not just tasks, and follow through after launch.
Example code
Worked examples
:::note Illustrative, not scripts These are fictional examples written to show structure, depth and level of detail. Do not memorise or reuse them: interviewers probe follow-up questions, and only a story you actually lived survives that. Replace the content with your own real experiences and numbers. :::
1. A production incident (technical ownership)
Situation: Our order service (about 400 req/s at peak) started timing out during a flash sale; checkout success dropped from 98% to 70% within ten minutes. Task: I was on call and the incident commander; I needed to restore checkout and find the cause. Action: I declared an incident and kept a timeline in the channel. The dashboards showed database connection-pool waits climbing, and thread dumps showed all request threads blocked waiting for a payment-provider call that had slowed to ~8 seconds. Retries were multiplying the load. I (1) enabled the existing feature flag to switch to the secondary provider, (2) reduced the client timeout from 30 s to 3 s and capped retries, which stopped thread exhaustion, and (3) scaled out the service to absorb the backlog. Checkout recovered in 25 minutes. Afterwards I ran a blameless post-mortem. Result: Root cause was missing timeouts and a retry storm against a degraded dependency. We added circuit breakers and bulkheads with Resilience4j, per-provider timeouts, and a load test simulating a slow provider in CI. The next flash sale had zero checkout degradation, and p99 latency during dependency slowness stayed under 800 ms. I shared the runbook with the other teams.
Why it works: specific numbers, a clear individual role, technical diagnosis, mitigation before root cause, and a systemic fix.
2. A disagreement (collaboration)
Situation: A senior colleague wanted to adopt event sourcing for our new inventory service; I believed a standard relational model with an outbox was enough. Task: Reach the right decision for the team without damaging the relationship or delaying the project. Action: I asked for their requirements first (auditability and replay) and wrote down evaluation criteria with the team: delivery time, operational complexity, team experience, and the real audit needs. I proposed a one-day spike of both options against two representative scenarios and shared the results. The spike showed that event sourcing would triple the effort for a requirement the outbox plus an append-only audit table already met. Result: We chose the simpler design and agreed to revisit if replay became a hard need. We shipped three weeks earlier, and my colleague later led an ADR template for such decisions. I learned to turn opinion debates into small experiments with agreed criteria.
3. A failure (accountability)
Situation: I led a migration of a reporting table with 400 million rows to a new schema. Task: Complete it without downtime. Action: I wrote the migration and tested it on a staging copy a tenth of the size. In production, an
ALTER TABLEtook a lock for 11 minutes, blocking writes, and caused a partial outage. I rolled back, communicated to stakeholders, and led the review. Result: The mistake was testing on unrepresentative data and not using online schema change tooling. We now rehearse migrations on production-sized copies, use expand/contract andlock_timeout, and I wrote the team's migration checklist. The next large migration ran with no impact. I owned the incident openly, which also made it easier for others to report problems early.
4. Ambiguity and pushing back
Situation: Product asked for "real-time" dashboards with no definition. Task: Deliver value without overbuilding a streaming platform. Action: I interviewed the three main user groups and discovered "real-time" meant "fresher than yesterday, under five minutes" for 90% of cases. I proposed a staged plan: five-minute micro-batches first, streaming only for the fraud team who needed seconds. Result: We delivered the first version in two weeks instead of a quarter, cut infrastructure cost by roughly 60% versus the streaming-first design, and added streaming later only where justified.
5. Mentoring
Situation: A junior engineer was producing large, slow pull requests and struggling with concurrency bugs. Task: Help them become independent without taking over their work. Action: We agreed on goals, paired weekly on design before coding, introduced small PRs with checklists, and I reviewed with questions instead of fixes. I also gave them a contained ownership area (the notification retries) with me as backup. Result: Review turnaround dropped from days to hours, they fixed their first production concurrency issue independently within three months, and they now mentor interns.
System design considerations
- Prepare six to eight stories that map to many questions
- Quantify results: latency, cost, incidents, delivery time
- Rehearse aloud and time yourself
When to use it, and when not
Use it when
- You prepare stories for leadership, conflict, failure and impact questions
- You need concise answers under three minutes
- You want to show senior-level ownership
Think twice when
- You describe what the team did without your own actions
- You choose stories with no measurable outcome
- You blame others when discussing failures
Preparation checklist
- Write 6-8 stories using the table above; rehearse each aloud in under three minutes.
- Collect numbers (latency, throughput, cost, incident counts, delivery times) from your resume projects.
- Prepare two failure stories and one conflict story honestly.
- Research the company's values and engineering blog; map stories to them.
- Prepare questions about team practices, on-call, decision making and growth.
- Practise with a friend; ask for feedback on clarity, length and your individual contribution.
Common mistakes
Mistakes to avoid
- Rambling without structure; spending 80% on Situation.
- All "we", no "I".
- No metrics or outcome.
- Blaming others or the company.
- Stories that are all technical heroics with no collaboration, or all politics with no substance.
- Memorised scripts that ignore the question asked: adapt a story to the question.
- Claiming perfection ("my weakness is working too hard").
Interview questions
1. How long should a STAR answer be?
Two to three minutes; offer to go deeper on any part.
2. What if I have no major incident or failure story?
Use a smaller real example (a bad deploy, a missed estimate, a flaky test suite), because the learning and ownership matter more than the scale.
3. Can I reuse one story for several questions?
Yes, with a different emphasis each time, but have at least five distinct stories ready.
4. How honest should I be about failures?
Fully; interviewers look for ownership and learning, and inconsistencies are noticed.
Check yourself
1What should most of a STAR answer focus on?
2What makes a result convincing?
3How should you talk about a failure?
Key takeaways
- Structure with STAR; spend most time on your actions and reasoning.
- Quantify results; include trade-offs, mistakes and lessons.
- Maintain a reusable story bank mapped to common themes.
- Show leadership through impact on people, process and outcomes.
Finished this page? Track your progress (saved only in your browser).