INTERVIEW PREP
What is a behavioral interview? What interviewers listen for, and how to prepare
What interviewers are listening for when they ask about your past, and how to prepare without memorizing a script.
“Tell me about a time you disagreed with a teammate.” When you hear this, the interviewer isn't waiting for a happy ending. They want to know a few specific things: whether you describe the other person fairly, what you actually said or did, and whether anything changed. Often they write those details down as you speak.
If you know what they're listening for, it's much easier to choose the right story and the right details to include.
What a behavioral interview is
A behavioral interview asks about things you have actually done: “Tell me about a time...” or “Give me an example of...” The idea is that how you handled real situations says more than how you think you would handle an imaginary one.
Many companies run these interviews in a structured way. Every candidate for the role gets similar questions, and answers are judged against criteria agreed in advance. A 2022 review of decades of hiring research found structured interviews among the best predictors of how well someone will do in the job. In the UK, they're often called competency-based interviews.
These questions can come up at almost any stage of hiring, not only in a round labeled behavioral. Some companies give them a round of their own, such as a “leadership principles” interview, a consulting fit interview or a conversation with the hiring manager. They also appear in recruiter screens and are often mixed into technical rounds.
What the interviewer is doing while you answer
The interviewer isn't comparing your answer to a perfect one. They have a short list of qualities to judge, such as ownership or how you handle disagreement, and they're looking for evidence of each one in what you say.
That's why specific details matter. If you say “I aligned the team,” the interviewer has nothing to write down. If you say “I met each team lead separately and asked what they were worried about,” they can see exactly what you did.
They'll also ask follow-up questions, such as “What did you do next?”, “Why that option?” or “What would you do differently?” These check that the story holds up and that the work was really yours. A data-engineering interviewer on Reddit explains that asking for detail about real work is how they spot candidates who overstate their part.
What each common question is checking
Each common question is a way of asking about one quality. If you know which one, you know which details to bring. This table covers the questions you're most likely to hear.
| The question | What it usually checks | The details that answer it |
|---|---|---|
| A disagreement or conflict | Can you disagree without damaging the work or the relationship? | The other person's view, what you said, how it was resolved |
| A failure or mistake | Do you own your mistakes and learn from them? | Your part, how you fixed it, what you do differently now |
| A project you owned | How much you took on, and how you made decisions | What you decided and why, what changed for users |
| A decision without full information | How you decide when you're unsure | What you didn't know, how you limited the risk |
| Feedback that changed how you work | Do you act on feedback? | The feedback, what you changed, and how you know it stuck |
| Persuading someone you didn't manage | Can you bring people round without authority? | Their objection, and how you dealt with it |
Sometimes a question is very specific and you don't have an exact match. Think about the quality it's checking and use the closest real example. A software-careers discussion recommends doing exactly that and saying how it connects, rather than inventing a story.
How the questions change by role
The format is the same for every role, but the experiences interviewers ask about are not. Knowing what your role tends to cover tells you which stories to prepare first.
- Software engineers are asked about trade-offs, production incidents, technical disagreements and work they owned from start to finish. See software engineer behavioral interview questions.
- Product managers are asked about stakeholders who wanted different things, decisions made with data, and products that didn't work as expected.
- Data analysts are asked about findings that challenged what people believed, disagreements about an analysis, and explaining results to people without their background.
- Product designers are asked about research that changed a design, feedback on their work, and disagreements with product or engineering.
- Program managers are asked about scope that changed partway through, persuading teams they don't manage, and keeping several teams on track.
- Consultants are asked about difficult clients, leading a team through a hard moment and persuading people. Some firms spend a long time on a single story with many follow-up questions. See consulting behavioral and fit questions.
If you'd like to see what a good answer looks like in your role, STAR method interview examples answers one common question for each of these roles, first poorly and then well.
Pick stories that fit the level of the job
Interviewers don't only listen to what your story shows. They also notice how much you were responsible for. The same question has a different expected answer for a junior role than for a senior one, so a story that works well for one can sound too small for the other.
Take engineering as an example. For a junior role, a good story might be fixing a hard bug in a feature someone else designed. For a senior role, the interviewer expects more: an unclear problem where you decided the approach, explained the trade-offs and brought other people along.
When you choose a story, ask yourself: does this show the kind of responsibility the new job would give me? If not, pick a bigger example. If the work was shared, be clear about which part you led.
Questions about you, before the experience questions
Most interviews start with a few questions about you, such as “Tell me about yourself” or “Why do you want this job?” They aren't asking for a story about one event, so the advice above works a little differently. Each has its own guide:
- Tell me about yourself
- Why should we hire you?
- Why do you want this job?
- What are your strengths?
- What are your weaknesses?
- Why did you leave your last job?
- Where do you see yourself in five years?
How to prepare your stories
You don't need a script for every possible question. A small set of real stories you know well will cover most of them.
- Read the job description for themes. Note five or six qualities it keeps coming back to, such as ownership, working across teams or handling uncertainty.
- Choose six to eight real stories. A good starting set covers work you owned, a disagreement, a mistake, a decision made without full information, feedback that changed you, and a time you persuaded someone you didn't manage.
- Match stories to themes. Make sure each theme has at least two stories you could use. Don't rely on one big project for every question, because it makes your experience look narrow.
- Write short notes, not full answers. For each story, note the decision you made, why, what happened and what you'd change. Notes let you tell the story in your own words when a question is phrased differently.
- Keep the mixed results. A story where things partly went wrong, told honestly with your part in it, is often more convincing than a perfect one.
Give each answer a simple order
The STAR method (Situation, Task, Action, Result) is a common way to order a story. Keep the background short, say what you were responsible for, spend most of the time on what you did and why, and finish with what changed. You don't need to say the four words out loud.
Following the four steps doesn't guarantee a good answer. Many answers follow STAR and still leave out what the interviewer needed. The STAR examples guide shows the most common ways this happens. The behavioral interview mistakes that hide your best work explains why good work gets lost under pressure.
Practice out loud, with interruptions
Reading your notes feels very different from answering a person. Say each story out loud, and ask someone to interrupt with “Why?” or “What else did you consider?”
Afterwards, ask them: “What did you hear me do?” If they can't say, add the decision that was missing and try again. A friend, a career adviser or a recording of yourself all work for this.
The day before
Re-read the job description, pick the four or five stories that fit it best, and say each one out loud once. Keep your notes nearby. In the interview, listen to the actual question before you choose a story, and answer what was asked, not what you prepared for.
Further reading
For another explanation of the STAR method from a career-services point of view, these university guides are clear and short: