Behavioural Interviews
Technically strong candidates lose offers here more often than they expect, usually for one reason: they answer in generalities instead of telling a specific story.
The STAR structure
| Time | ||
|---|---|---|
| Situation | The context. Where, when, what was at stake. | ~15% |
| Task | Your specific responsibility. | ~15% |
| Action | What you did, and why you chose it. | ~55% |
| Result | The outcome, quantified where possible, and what you learned. | ~15% |
Two rules that fix most weak answers:
- Say "I", not "we". The interviewer is assessing you, not your team. "We migrated the database" tells them nothing about what you did. Credit the team once, then describe your own contribution.
- Spend the time in Action. Candidates over-explain the setup and then summarise the interesting part in one sentence. The reasoning behind your decisions is the entire signal.
Preparing properly
Do not prepare an answer per question — there are too many. Prepare five to seven stories and map them onto question types. Most behavioural questions are one of these:
| Theme | What they are checking |
|---|---|
| Conflict with a colleague | Can you disagree without damaging a relationship |
| A project that failed | Do you take ownership, and did you learn |
| Leadership / influence | Can you move things without authority |
| A difficult technical decision | How you reason under uncertainty and trade-offs |
| Handling pressure or ambiguity | Do you prioritise, or freeze |
| Feedback you received | Are you coachable |
| Something you are proud of | What you actually value |
A good story is specific, recent, yours, and has a measurable outcome. Write each one out once, in full. You will not memorise it — but writing it makes the details available under pressure.
The questions that recur, and what a good answer looks like
"Tell me about yourself."
Not your life story. Three parts, about 90 seconds: where you are now and what you own, one or two accomplishments relevant to this role, and why this role is the next logical step. Finish with a clear handover rather than trailing off.
"Tell me about a time you disagreed with a colleague."
They are testing whether you can hold a position without making it personal. A strong answer shows you sought to understand the other view first, brought data rather than opinion, and — crucially — either changed your mind or committed fully to the decision that was made. "I was right and they eventually agreed" is a weaker answer than it feels.
Avoid: stories where the other person is simply incompetent. It reads as a red flag about you, not them.
"Tell me about a project that failed."
The trap is choosing something trivial, or something that was not your fault. Pick a real failure with genuine consequences, take clear ownership of your part, and spend most of the answer on what you changed afterwards — and ideally, on evidence that the change stuck.
Avoid: "my weakness is that I work too hard." It signals that you either lack self-awareness or are unwilling to be honest.
"Tell me about a difficult technical decision."
This is really a system-design question in narrative form. Name the options you considered, the constraints (deadline, team skills, existing systems, cost), why you chose as you did, and what you would do differently knowing what you know now. Acknowledging a trade-off you accepted is a strength, not an admission.
"Why do you want to work here?"
Do the research. Reference something specific — the product, a technical blog post, the problem domain — and connect it to what you want to do next. Generic praise is transparently generic.
"Do you have any questions for us?"
Always yes. This is assessed. Useful ones:
- What does success look like for this role in the first six months?
- How does the team decide what to work on?
- What is the on-call and code review culture like?
- What is the biggest technical challenge the team faces right now?
- Why is this role open?
Common mistakes
- Rambling. Aim for two to three minutes. Practise out loud and time yourself — it is always longer than it feels.
- Hypotheticals. "I would usually…" is not a story. Give a specific instance.
- No result. Every story needs an ending, with a number if one exists ("cut deploy time from 40 to 6 minutes").
- Blaming. Even when someone else genuinely caused the problem, focus on your response to it.
- No preparation. It shows immediately, and interviewers read it as not caring much about the outcome.
A note on honesty
Do not invent stories. Interviewers ask follow-up questions — "what would you do differently?", "how did the other person react?", "what was the number before?" — and fabricated stories collapse under two or three of them. A modest true story, told well and with real reflection, beats an impressive invented one every time.
If you genuinely lack experience with something, say so and describe the nearest thing you have done. "I have not led a team, but I did own the migration end-to-end and coordinated three people across two teams" is a good answer. A fabricated one is a failed reference check waiting to happen.
Found a mistake? Edit this page on GitHub.