Learn the Situation-Task-Action-Result framework to structure compelling answers to behavioural interview questions.
STAR stands for Situation, Task, Action, Result. It is a structured framework for answering behavioural interview questions — those questions that begin with phrases like "Tell me about a time when..." or "Give me an example of..."
Behavioural questions are one of the most common interview formats used by UK employers, from graduate schemes at large corporates to mid-level roles at growing startups. The logic behind them is simple: past behaviour is the best predictor of future behaviour. Rather than asking you to speculate about what you might do in a hypothetical scenario, the interviewer wants concrete evidence drawn from your actual experience.
Without a clear structure, most candidates fall into one of two traps. They either give a vague, rambling answer that never quite lands, or they jump straight to the outcome without explaining what they actually did. The STAR method solves both problems by giving you a reliable skeleton for every answer. Once you internalise it, you can walk into any behavioural interview with confidence, knowing you have a repeatable way to communicate your experience clearly and persuasively.
Start by setting the scene. Give the interviewer just enough context to understand where you were and what was happening. Mention the company, your role, the project or the circumstances that created the challenge. Keep this to one or two sentences at most. The situation is the backdrop, not the main event. A common mistake is spending a full minute on context before you ever get to what you did.
Example: "In my previous role as a software developer at a fintech startup, we received a request from our largest client to move the launch date of a payments feature forward by a week."
Next, clarify your specific responsibility. What was expected of you? What problem needed solving, and why did it fall to you? This is where you distinguish your role from the wider team effort. The task should make it clear what success looked like and what was at stake if you did not deliver.
Example: "As the lead developer on the payments integration, it was my responsibility to determine whether we could realistically meet the new deadline and to present a revised plan to both the engineering team and the client."
This is the most important part of your answer, and it should take up roughly half of your total response time. Describe what you did, step by step. Be specific. Use "I" rather than "we" wherever possible. The interviewer is assessing your individual contribution, not your team's. Talk about the decisions you made, the skills you applied, and the obstacles you navigated. If you delegated, explain why and how. If you changed approach midway through, explain what prompted the shift.
Example: "I reviewed the backlog and identified three lower-priority tasks that could be deferred to the next sprint without affecting the core functionality. I restructured the remaining work into a minimum viable scope, focusing on the payment processing flow and error handling. I set up pair programming sessions with a colleague to accelerate development on the most complex integration point, and I scheduled a call with the client to walk them through the revised scope so they understood exactly what would ship on the new date and what would follow in the subsequent sprint."
Finish with the outcome. What happened as a direct consequence of your actions? Quantify the result wherever possible — percentages, revenue figures, time saved, customer satisfaction scores, or any measurable indicator. If the outcome was not entirely positive, be honest about it. Interviewers respect candidates who can reflect on partial successes and explain what they learnt. Always tie the result back to the business impact.
Example: "We delivered the core payments feature on time. The client signed off on the release without any issues, and the remaining features shipped the following sprint as planned. The project came in under budget and the client went on to increase their contract value by 20% the following quarter."
Here is a complete STAR answer to the question: "Tell me about a time you had to meet a tight deadline."
Situation: In my previous role at a fintech startup, our largest client requested that we move the delivery date for a payment integration feature forward by an entire week. The sprint was already underway and the team had planned around the original timeline.
Task: As the lead developer responsible for the payments module, I needed to find a way to deliver the critical functionality within the compressed timeframe while maintaining quality and keeping stakeholders informed.
Action: I immediately reviewed the remaining backlog and identified three tasks that were important but not essential for the initial release. I restructured the sprint to focus exclusively on the minimum viable payment flow: transaction processing, error handling, and the confirmation endpoint. I organised pair programming sessions with a colleague to tackle the most complex integration point, which cut our development time on that component roughly in half. I also proactively contacted the client to walk them through the revised scope, making it clear what they would receive on the new date and what would follow in the next sprint. This transparency meant there were no surprises at delivery.
Result: We delivered the core feature on time and it passed QA with no critical defects. The client signed off on the release and the remaining features shipped the following sprint, only five days later than originally planned. The client was impressed with how we handled the change, and their contract value increased by 20% the next quarter. Internally, we adopted the MVP scoping approach as a standard practice for future deadline shifts.
Notice how the answer is specific, uses "I" to clarify the candidate's own contribution, and ends with a quantifiable result. The entire answer, when spoken aloud, takes roughly 90 seconds — well within the two-minute window you should aim for.
Even candidates who know the STAR framework often undermine their answers with these avoidable errors:
The best way to prepare for behavioural interviews is not to memorise scripted answers. Instead, build a bank of five or six strong stories from your career that you can adapt to different questions on the fly.
Step 1: Identify your stories. Think back over the past two to three years. Look for moments where you solved a problem, overcame a challenge, led a team, handled conflict, or delivered something you were proud of. Write each one down in bullet-point STAR format.
Step 2: Map stories to competencies. Most behavioural questions test a handful of recurring themes: leadership, teamwork, conflict resolution, handling failure, taking initiative, working under pressure, and adapting to change. Ensure your bank of stories covers at least four or five of these themes. A single story can often be adapted to cover more than one competency depending on which aspects you emphasise.
Step 3: Practise out loud. Reading your notes silently is not the same as delivering an answer in conversation. Set a timer for 90 seconds and practise telling each story aloud. Record yourself if possible. Listen for filler words, unnecessary context, and moments where you slip into "we" when you mean "I." Each run-through will tighten the answer.
Step 4: Prepare for follow-up questions. Interviewers will often dig deeper: "What would you do differently?" or "How did your manager respond?" Think through the second layer of each story so you are not caught off guard.
Step 5: Keep it current. Where possible, draw from recent experience. A story from six months ago carries more weight than one from five years ago, unless the older example is significantly more relevant to the role you are applying for.
The STAR method is not about performing a rehearsed script. It is about giving yourself a reliable structure so that under the pressure of an interview, your natural experience comes through clearly and convincingly. Prepare your stories, practise the format, and trust that your real experience is enough.
Put the STAR method into practice with real interview questions: