The STAR method is a way of answering interview questions about something you've done before. You tell the story in four parts: the Situation, your Task, the Action you took and the Result.
It's simple enough to explain in a sentence, and most people have heard of it. The harder part is using it well when you're nervous, and that mostly comes down to two things: spending your time on the Action, and having the right stories ready before you walk in.
What is the STAR method?
Most interviews include behavioural questions, sometimes called competency questions. They usually start with something like:
- Tell me about a time you dealt with a difficult customer.
- Give me an example of when you improved a process.
- Describe a situation where you disagreed with a colleague.
The idea behind them is fairly straightforward. How you handled something in the past is treated as evidence of how you'd handle it again, so the interviewer wants a real example rather than a description of how you like to work.
The STAR method gives that example a shape. Without one, it's easy to spend most of your answer on background, mention what you did in passing and never quite get to how it turned out. With one, the interviewer hears the context, your part in it and the outcome, in that order, which is also roughly the order they need it in to score you.
It's widely used in the UK. The Civil Service, for example, assesses candidates against a set of behaviours, and its guidance for candidates suggests the STAR method for structuring examples. It also says not to assume the recruiting manager will know or understand the situation you were facing, which is good advice for any interview.
What each part of STAR should cover
| Part | What it answers | Rough share of your answer |
|---|---|---|
| Situation | Where were you, and what was going on? | About 15% |
| Task | What were you responsible for? | About 10% |
| Action | What did you do, step by step, and why? | About 55% |
| Result | What happened, and how do you know? | About 20% |
These aren't fixed rules. They're a starting point, and the one worth watching is the Action. If it's less than half your answer, something else is taking too long.
Situation
Set the scene in two or three sentences: where you were working, roughly when, and what the problem was. Give enough for the interviewer to follow the story and no more.
The natural instinct is to explain everything, the team structure, the history, why the system was built the way it was. It feels necessary because you know all of it. But the interviewer doesn't need most of it, and every sentence spent here is one less spent on what you did.
Task
Say what you specifically were responsible for, or what you set out to achieve. This is the part people most often skip or blur into the Situation, and it's worth keeping separate because it gives the interviewer something to judge your actions against.
One sentence is often enough. "I needed to get a finished deck ready five days earlier than planned" tells the interviewer exactly what success looked like.
Action
This is the answer. Talk through what you did, roughly in the order you did it, and say why wherever it isn't obvious.
Two things make the biggest difference here.
Say "I", not "we". If you were part of a team, that's fine, say so once while you set the scene. But the interviewer is assessing you, not the team, and "we redesigned the process" leaves them guessing which part was yours. It can feel a little uncomfortable, particularly if you're used to sharing credit, but it's what the question is asking for.
Include the reasoning. "I spoke to finance first" is an action. "I spoke to finance first, because they'd be the ones signing off the numbers" shows judgement, and judgement is usually what's being scored.
Result
Finish with what happened. If you have a number, use it: time saved, errors reduced, a deadline met. If you don't, describe what changed in plain terms, such as the complaint being closed, the new process still being used, or the feedback you got.
Don't invent a figure to make it sound better. Interviewers often ask a follow-up, and "how did you measure that?" is a difficult question to answer about a number you made up.
It's also worth adding a sentence on what you learned or would do differently, particularly if the result wasn't entirely positive. Some people call this STARR, with the extra R for reflection. You don't need it on every answer, but it works well for questions about mistakes or setbacks.
How long should a STAR answer be?
There isn't one right length, because it depends on the question and on how the interviewer runs the conversation. As a starting point, I'd aim for around two minutes and treat three as the upper limit.
Under a minute usually means the Action is too thin. Over three, and you've probably lost the interviewer somewhere in the Situation.
It's much easier for an interviewer to ask a follow-up question than it is to sit through a long answer and pick out the part they wanted. If you stop at two minutes and they want more, they'll ask, and you'll still have something to give them.
The only reliable way to know how long your answers are is to say them out loud with a timer running. It's easy to underestimate how long you've been talking.
A weak and a strong STAR answer, side by side
Here's the same story told two ways, in answer to "Tell me about a time you had to meet a tight deadline."
Weak answer · illustrative
"We had a big client pitch coming up and it got moved forward by a week, which was really stressful because the team was already stretched and there were a lot of moving parts. Our manager was off as well. We all pulled together, worked late a few nights and managed to get it done. The client was happy in the end and it went well. I think it shows I work well under pressure."
What's wrong with it:
- It's almost all Situation. The interviewer knows it was stressful, but not what you did about it.
- It says "we" throughout, so there's no way to tell your part from anyone else's.
- The Result is vague ("it went well"), and the last line tells the interviewer what to conclude instead of showing them.
Strong answer · illustrative
Situation I was a marketing assistant, and a client moved their pitch meeting forward by a week while our manager was on annual leave.
Task I was responsible for the slide deck and the supporting figures, so I needed a finished version five working days earlier than planned.
Action I listed everything left to do and split it into what the pitch couldn't go ahead without and what would be nice to have. I dropped two of the nice-to-have sections and asked a colleague to take over the case study slides, since they'd written the original case study. I emailed our manager a short note on what I was cutting and why, so there'd be no surprises when they got back, and I booked a run-through with the account lead two days before the meeting so there was time to fix anything we found.
Result The deck was ready a day early, the run-through caught two figures that needed correcting, and the client signed off the project in that meeting. Looking back, I'd have told the client up front about the two sections we dropped, because they asked about one of them.
Why the second one works:
- The Situation and Task take three sentences between them.
- Every action is something the speaker did, and most have a reason attached.
- The result is specific, and the reflection at the end shows they're not just telling the tidy version.
STAR method examples for common interview questions
Below are six worked examples. They're illustrative rather than real answers, so use them for the shape and not the wording. Three come from Jordan Ellis, the analytics engineer on our example canvas. Jordan and every project are fictional, and the company names are for illustration only.
1. "Tell me about a time you dealt with a difficult customer"
Good for customer-facing roles, and for anyone early in their career.
Situation I was working weekends at a phone shop, and a customer came in angry because a repair we'd promised for Friday still wasn't back on Saturday.
Task I was the most senior person on shift, so it was mine to sort out.
Action I let them finish before saying anything, then apologised for the delay without making excuses. I checked the repair system with them at the counter, which showed the part had arrived late at the repair centre. I phoned the centre while they waited, got a firm date of Tuesday, and offered a loan phone until then, which we were allowed to do for repairs that ran over. I also added a note to the job so whoever picked it up on Tuesday wouldn't have to start from scratch.
Result They took the loan phone and left a lot calmer than they came in, and collected the repair on Tuesday without any further complaint. My manager then asked me to show the rest of the weekend team how to set up loan phones, as most of them didn't know we could.
2. "Tell me about a time you managed stakeholders who disagreed"
From Jordan's canvas · fictional
Situation At Spotify, different teams were calculating the same metrics in different ways, so the numbers in leadership reviews rarely matched.
Task I wanted to give every team one trusted definition of each core metric.
Action The product and finance leads each had their own version, and both had reasons for it. So rather than pick a winner, I wrote a metrics glossary with them and made them joint owners of it. I then built the core metrics once in dbt, with tests on every model, and moved the 40 most-used dashboards onto that shared layer so nobody was choosing between versions any more.
Result Disputes about metrics in quarterly reviews all but disappeared, and new dashboards now ship in days rather than weeks.
What makes it work is that the disagreement is resolved by giving both sides ownership, not by the candidate winning the argument.
3. "Tell me about a time you made a mistake"
Situation In my first year as an administrator at a housing association, I sent the monthly arrears report to the senior team with two columns showing the previous month's figures.
Task I needed to correct it before anyone acted on it, and make sure it didn't happen again.
Action I noticed the next morning when the totals didn't match the finance system. Within the hour I emailed everyone who'd received it, said plainly which figures were wrong, and sent a corrected version. I told my manager what had happened before they heard it from someone else. The cause was that I built the report by copying from two spreadsheets, so I suggested adding a check row that compared the totals against the finance system, with the report not going out until they matched.
Result Nobody had acted on the wrong figures, and the check row has stayed in the report since. It caught a mismatch of its own two months later. What I took from it is that the fix for a manual mistake is usually a check, not trying harder to be careful.
It owns the mistake in the first sentence, spends most of its time on the fix, and the reflection is specific rather than "I learned to be more careful".
4. "Give me an example of when you improved a process"
From Jordan's canvas · fictional
Situation At Spotify, the month-end revenue reconciliation took the finance team three days of spreadsheet work.
Task I set out to automate the reconciliation and flag only the real exceptions.
Action I rebuilt the reconciliation in SQL, working directly against the source systems. Rather than hand finance a new tool to learn, I sent them an exceptions list each morning of close, with the source rows attached, so they only looked at what genuinely needed a person. I worked alongside them through two closes before we switched the old process off.
Result Close reconciliation went from three days to half a day.
A clear before and after, and the two closes worked side by side show some care for the people relying on the process.
5. "Tell me about a time you had to make a difficult decision"
From Jordan's canvas · fictional
Situation At Microsoft, sales reporting ran on an ageing on-premises warehouse whose nightly loads often overran, and I was leading the move to a cloud warehouse.
Task The one thing I couldn't do was disrupt monthly reporting. Finance needed every month-end report on time.
Action The faster option was a single cutover on a set date, and I decided against it. Instead I ran the old and new warehouses side by side for two months, reconciling the totals every day, and only switched over once they'd matched for 30 days running. That meant maintaining two systems for longer, so I kept the regional finance teams informed at every cutover milestone. Before moving anything I'd mapped every source table and report, which turned up 60 legacy reports nobody used, and we retired those rather than migrate them.
Result We migrated on schedule with no missed month-end reports, and the nightly load time fell from six hours to 40 minutes.
It names the option that wasn't taken and what the chosen one cost. That's what makes a decision sound difficult rather than obvious.
6. "Tell me about a time you showed leadership"
This one comes from outside work, which is fine. The Civil Service guidance linked above says examples can come from volunteering or hobbies, and most interviewers take the same view.
Situation At university I was treasurer of the hiking society, and halfway through the year we realised we'd booked a minibus for a trip we couldn't fill, with a deposit we couldn't get back.
Task I needed to cover the cost without cancelling the trip or putting up everyone's membership fee.
Action I contacted the walking clubs at two nearby universities to ask if they'd like to share the trip, and one of them filled the remaining seats at the same price per person. I set up a single sign-up sheet for both groups and collected payment before the date, so we weren't chasing money afterwards. I then proposed to the committee that future bookings needed a minimum number of paid sign-ups first, and they agreed.
Result The trip ran full, the deposit wasn't lost, and we ran another joint trip with the same club later that year.
Common STAR method mistakes
Too much Situation. Covered above, but it's the easiest one to fall into. If you're running long, cut here first.
"We" instead of "I". Say once that it was a team effort, then talk about your part.
No result, or a made-up one. A vague result weakens the answer. An invented one is worse, because it tends to fall apart under a follow-up question.
Learning answers word for word. A script sounds like a script, and if the interviewer interrupts with a question, it's easy to lose your place. Learn the points of each story, not the sentences.
Picking the most impressive project rather than the best fit. A big project where your part was small usually makes a weaker answer than a small one you led. Choose the example where your actions answer the question.
Using the same story for everything. One good project can cover several competencies, but if every answer comes back to it, the interviewer starts to wonder what else you've done.
How to prepare your STAR stories
Answering in STAR on the spot is quite hard if you're also trying to remember what you did three years ago, so most of the work happens before the interview.
Four short lines are much easier to hold on to under pressure than a polished story, and you can add the detail around them as you talk.
- Start from the job description. Pick out the skills and behaviours it asks for. They're usually close to the questions you'll be asked.
- List your projects, not your job titles. Go through each role and write down everything you worked on that had a beginning and an end: a launch, a fix, a migration, a difficult quarter.
- Write each one as STAR notes. A line or two per part, bullet points rather than paragraphs. Add the numbers now, while you can still find them.
- Match stories to competencies. Most projects show more than one. Jordan's metrics project, for example, works for stakeholder management, problem solving, attention to detail and ownership. A simple grid of stories against competencies shows you quickly where you're thin.
- Aim for eight to ten stories. That's usually enough to cover an interview without repeating yourself, with a spare for "Can you give me another example?"
- Say them out loud. Time them, and if they're running long, trim the Situation before anything else.
- Prepare for the follow-ups. What would you do differently? What did other people think? What was the hardest part?
The detail of a project fades surprisingly quickly once you've moved on. It's much easier to write it down while it's fresh than to try to reconstruct it the night before an interview.
When not to use the STAR method
STAR is for questions about something you did. It doesn't really fit:
- "Tell me about yourself" or "Why do you want this job?" These want a short summary and your motivation, not a story.
- Hypothetical questions, such as "What would you do if…?". Talk through how you'd approach it, and mention a time you did something similar if you have one, but forcing a full STAR onto a hypothetical tends to feel awkward.
- Strengths questions. The Civil Service, among others, asks about your interests and what you enjoy doing, alongside behaviour questions. Those are about you, not about a particular time.
- Technical questions, where the interviewer wants to see you work through the problem in front of you.
STAR, STARR, CAR and other variations
You'll come across a few versions of the same idea:
- STARR adds a second R for Reflection: what you learned.
- CAR (Context, Action, Result) folds the Situation and Task into one.
- SOAR (Situation, Obstacle, Action, Result) puts the difficulty front and centre.
They all do the same job. Use whichever one helps you keep the context short and the actions specific. Nobody is checking which acronym you followed.
Questions people ask about the STAR method
What does STAR stand for?
Situation, Task, Action, Result. Some versions add a second R for Reflection.
Can I use an example from outside work?
Yes. Volunteering, education, a hobby or something you organised can all work, particularly early in your career. The Civil Service's guidance for candidates says the same.
How many STAR examples should I prepare?
Eight to ten, covering different competencies, is a sensible starting point. That gives you enough to answer a full interview without repeating yourself.
What if my example didn't have a good result?
It can still be a good answer, especially for questions about mistakes or setbacks. Say honestly what happened, then what you learned and what you'd do differently.
Can I use the same example twice in one interview?
Best avoided if you can. If you do need to, say so ("I'll come back to the migration project, but a different part of it") and focus on a different set of actions.
Do I need to say "Situation", "Task" and so on out loud?
No. The structure should be there without being announced. Phrases like "what I did was" and "in the end" are enough to signpost it.
Keeping your STAR stories in one place
This is the part CareerCanvas is built for. Send us your CV and we turn every project into a STAR story, laid out on one screen. Pick a competency, such as stakeholder management, and the projects that fit light up, each with a one-line reason why, so you're not re-reading your CV the night before.
We don't invent anything. A result only appears where you can back it up, and you approve every word before it goes live.