Preparing for behavioural interviews without memorising answers

A taxonomy of about a hundred behavioural questions, and a method for covering them with four or five stories instead of a hundred rehearsed answers.

I went through general software and research-engineering interviews towards the end of my PhD. The behavioural rounds were the part I found hardest to prepare for. Technical rounds at least have a shape you can practise against; the behavioural ones are abstract — the questions are open-ended, it is not obvious what a good answer even looks like, and most of the advice out there tells you to prepare a story for every question you might be asked.

That advice is wrong, or at least unusable. There are too many questions, you cannot memorise that many answers, and an answer that sounds memorised is worse than one that rambles a little. What worked instead was to spend the preparation time on structure rather than volume: work out what the questions actually are, group them, and then build a small set of real stories that cover every category between them.

This post is the result. The question bank below was assembled mostly from Google and Meta interview reports; the method that follows is what I would tell someone starting from scratch.

1. What the round is actually measuring

The single most useful reframing: the interviewer is not collecting anecdotes. They are looking for evidence of a small number of traits, and every question is a different doorway into the same house. "Tell me about your hardest project" is not a request for a hard project. It is a request for evidence that you can recognise difficulty, break it down, and keep making decisions inside it.

Roughly, the traits being probed are:

• Ownership — do you treat problems as yours once you see them
• Judgment under constraint — how you decide when you cannot do everything
• Conflict handling — whether disagreement makes you defensive or curious
• Communication — whether you can make a complicated thing legible to someone who was not there
• Growth — whether experience actually changes your behaviour

Every category in the bank below maps onto one or more of these. Once you see the mapping, the hundred questions collapse into something manageable.

2. The question bank — twelve categories

Main questions are the top-level bullets; the indented items are follow-ups that came up often enough that you should expect them. Assume you will get at least two follow-ups on anything you say.

1 · Projects and challenges

• Describe a challenging or complex project you worked on.
  • What made it challenging?
  • What problems did you encounter?
  • How did you resolve them?
  • What was the impact — metrics, results?
• Tell me about your most interesting recent project.
• Describe a time when a project did not go the way you expected.
  • How did you react?
  • What did you do afterwards — documentation, process change?
• Tell me about a time you introduced something new to your team.
• Tell me about a time you did something beyond expectations.
• Describe a time you stepped up and supported the team.

2 · Conflict and disagreement

• Tell me about a time you disagreed with someone.
  • How did you handle the conflict?
  • What was the outcome?
• How do you generally deal with conflict?
• Tell me about a conflict with a teammate. With a manager.
• What would you do if someone on the team is hard to work with? Is not collaborating? Is not meeting expectations?
• Tell me about a time different perspectives led to different design decisions.
  • How were they merged into a better solution?
• Tell me about a time you listened to someone and changed your mind.
• Tell me about a time you advocated for someone else on a team.

3 · Teamwork, leadership and collaboration

• Describe working in a team with very different personalities or backgrounds.
• How do you help others integrate into a team?
• Tell me about your onboarding experience.
  • How did others help you?
  • How have you helped new members onboard?
  • What did you take away?
• What would you do if a team member misses deadlines? If you were the leader assigning roles? If the team faced a problem nobody was familiar with?
• Tell me about a time you supported inclusiveness at work.
• What is your understanding of inclusiveness?
• What makes a good leader or mentor?
  • An example from a past manager.

4 · Ownership and responsibility

• Tell me about a time you showed strong ownership.
• Tell me about a time you took initiative beyond your responsibilities.
• A bug is found right before release and there is no time to fix it. What do you do?
• Compare: a bug in a project you own, a bug in a project you do not own, and a bug with no dependency on your current work.
  • How do you prioritise and act in each case?
• Tell me about a time your integrity was tested.

5 · Prioritisation, deadlines and workload

• Tell me about a time you had too much work.
  • What caused it?
  • How did you handle it?
• How do you prioritise tasks?
• What do you do with multiple deadlines? With very tight ones?
• Tell me about a time you had to multitask.
  • Did you complete everything?
  • Did you consider dropping anything?
• How do you respond when someone asks you to prioritise their request over others? When you receive an unreasonable requirement?

6 · Learning, growth and adaptability

• Tell me about a time you learned something new and changed your approach.
• Tell me about a time you learned from someone else and applied it.
• What have you done in the past year to improve yourself?
• Tell me about a recent achievement you are proud of.
• Tell me about a time you realised your method was wrong and corrected it.

7 · Feedback and communication

• Tell me about a time you gave someone feedback.
  • How did they respond?
• What is good feedback versus bad feedback? Give examples.
• Tell me about a time you had to manage expectations — with stakeholders, with management.

8 · Team dynamics and difficult situations

• What would you do if someone took all the credit for the team's work? If someone is not a team player? If team morale is poor?
• How do you make an unstructured team more structured?
• How do you handle an environment with poor work-life balance?

9 · Product and user thinking

• If you were building a product for diverse user groups, how would you design for different needs and balance the trade-offs?
• Tell me about a time you improved a product or a solution.

10 · Career, motivation and personal

• Self-introduction.
• Why this company?
• Short-term and long-term career goals.
• Strengths and weaknesses.
• What do you expect from your next manager?
• What are your plans for the year?
• Have you changed any habits or hobbies recently?

11 · Hypothetical and scenario-based

• As a team leader: how do you handle missed deadlines? How do you assign roles?
• You find a bug in another team's project before starting your own work. Same bug, but in your own project. What changes?
• A product needs to serve users globally. What would you do?

12 · Reflection — the universal follow-ups

These attach to almost any answer. If you have not thought about them, the follow-up is where the answer falls apart:

• Why did you choose that action?
• What alternatives did you consider?
• What would you do differently next time?
• What did you learn?

3. Building the story set

Do not try to prepare a story per question. There are around a hundred questions above; you cannot hold a hundred rehearsed answers in your head, and if you could, they would sound rehearsed. My honest view is that most people over-prepare for these rounds.

The structure that works is one core story plus a few satellites:

• The core story is the most substantial project you have actually done. It should be the thing your CV is built around, it should involve other people, and it should be complicated enough that you can come at it from several angles. A good core story answers categories 1, 4, 5 and 6 as it stands, and often 2 and 3 as well.
• Satellites are three or four smaller stories chosen specifically to cover what the core story cannot. Usually that means conflict (category 2), giving feedback (7), and something about team dynamics (3 or 8).

Choose for coverage, not for how impressive the story is. A small story about disagreeing with a collaborator over an analysis choice is more useful than a second big project, because the second big project answers the same questions the first one already did.

Before you write anything, build the coverage table — twelve rows, one per category, and mark which story you would reach for. The empty rows tell you what to go looking for in your own experience.

Category	Typically covered by
1 Projects and challenges	Core story
2 Conflict	Satellite — needs a real disagreement
3 Teamwork and leadership	Core story or a mentoring satellite
4 Ownership	Core story
5 Prioritisation	Core story
6 Learning and growth	Core story, from a different angle
7 Feedback	Satellite — usually the hardest gap to fill
8 Team dynamics	Satellite
9 Product and users	Any story, reframed around who it was for
10 Career and motivation	Prepared separately; not a story
11 Hypotheticals	No story needed — reasoning, not recall
12 Reflection follow-ups	Every story must carry these

4. Working with an LLM without letting it write for you

An LLM is genuinely useful here, but only in one role: as an interviewer who extracts detail from you. The moment you let it draft, it invents — plausible metrics, plausible colleagues, plausible conflicts. You will not notice, and then you will be asked a follow-up about a detail you never lived and cannot defend.

So the rule is: it asks, you answer, it assembles only what you said. Four prompts, in order.

Step 1 — Scope the story set

Give it your CV and the question bank, and ask for a map rather than prose. What you want out of this step is the list of gaps.

Here is my CV, and a list of behavioural interview questions.

[paste CV]
[paste the question bank]

Do not write any stories yet.

1. Identify 4-6 experiences from my CV that could plausibly support answers.
2. For each, list which of the twelve categories it could cover.
3. Show me which categories are NOT covered by any of them.

Output a coverage table and the list of gaps. Nothing else.

Step 2 — Let it interrogate you

This is the step that does the work, and the one people skip. One story at a time. The line about not suggesting details is the one that matters. Without it the model starts offering you a version to agree with, and agreeing is much easier than remembering.

We are going to develop one story: [one-line label].

Your job is to interview me, not to write for me. Ask one question at a
time about what actually happened. Focus on:

- the constraint I was under, and who else was involved
- what I actually did, decision by decision
- what alternatives existed and why I rejected them
- what the measurable outcome was
- what I would do differently now

Do not suggest details. Do not fill in gaps. Do not offer me a version to
confirm. If I say "I don't remember" or "that didn't happen", drop that
thread and move on.

Ask up to 10 questions, then stop and show me what you have.

Step 3 — Assemble, with provenance

Three lengths, because you will be asked for a summary as often as the full version. The [UNVERIFIED] marker is what makes this safe to use — anything tagged is either something you should verify or something to delete.

Using only facts I gave you in this conversation, draft this story in
three lengths:

- 30 seconds: the version for "give me a quick example"
- 90 seconds: the default answer
- follow-up material: alternatives considered, what I would do
  differently, what I learned

Mark with [UNVERIFIED] anything you inferred rather than heard from me.
Do not smooth over gaps - leave them visible.

Step 4 — Audit the coverage

Once everything is written, check the map again. It catches the common case where four stories all turn out to answer category 1.

Here are my finished stories:
[paste]

Here is the full question list:
[paste]

For each of the twelve categories, tell me which story I would use and
how strong the fit is: strong / workable / none.

List the gaps. Do not invent new stories to fill them.

5. Answering: lift, don't narrate

The most common mistake is answering the question literally — as though being asked for the hardest situation you have faced were a request for an accurate account of that situation. It is not. Every question is an opportunity to demonstrate a strength, and an answer that describes events accurately but demonstrates nothing is a failed answer.

So every answer needs a lift at the end: the point where the story stops being an event and becomes evidence.

• A setback becomes how you operate under pressure.
• A conflict with a colleague becomes how you communicate.
• Being overloaded becomes how you decide what not to do.
• An error you made becomes how you changed your process afterwards.

If the interviewer could not write down a trait after your answer, the answer did not land — however true it was.

The lift should be one or two sentences and it should be earned by the story, not bolted on. "And that taught me the importance of communication" is bolted on. "I now write the disagreement down and send it to the other person before we meet, because most of what looked like disagreement turned out to be two people using the same word differently" is earned.

6. Failure modes

• Preparing volume instead of coverage. Twenty stories that all answer category 1, and nothing for feedback or conflict.
• Letting the model write the story. It reads well and collapses on the first follow-up.
• No numbers. "It got much faster" invites a follow-up you cannot answer. Know the actual figure, or say plainly that you did not measure it and what you would measure now.
• Conflict stories where you were right. A conflict story in which you were correct all along and the other person came round demonstrates nothing. The good version is one where you changed your mind, or where you were right and still had to make it work with someone who disagreed.
• Answers with no "I". Long descriptions of what the team did. The interviewer is assessing you, not the project.
• Sounding rehearsed. Prepare the material and the lift, not the sentences.

An earlier and shorter version of this appeared in Chinese on 1point3acres. This version is expanded, and the Chinese version here is expanded to match.