Understand. Try. Explain.
What you will learn
Turn a real experience into an answer someone can follow. Use the structure to organise evidence, then rehearse naturally rather than memorising a script.
- Separate the situation, your responsibility, your actions and the result.
- Describe your individual contribution while crediting other people.
- Prepare honest follow-up details, including uncertainty and lessons from setbacks.
How to use this lesson: read one section, predict what the example will do, then compare your reasoning with the explanation. Try the self-check questions before opening their answers.
1. Choose an experience with a clear decision
Start with the question you want to answer: solving a difficult problem, handling feedback, managing a disagreement or learning something quickly. Choose one specific event with a decision you can describe. A small, well-explained contribution is more useful than an impressive project name with no detail about your work.
Work experience is not the only source. A course assignment, volunteer activity or personal project can show the same habits. Name the context honestly so the listener can judge its scale. If it was a solo project, do not invent a team; if it was a team project, distinguish your role from the shared outcome.
Before drafting, write down the facts you could explain in a follow-up: what was difficult, what you tried, why you chose that approach, who helped and what evidence you saw afterwards. Replace confidential names and details with a safe description while keeping the decision understandable.
2. Give each STAR section a different job
Situation sets the scene: what was happening, and why did it matter? One or two clear sentences usually provide enough background for an initial answer. Avoid a long history of the company or technology unless it changes the decision you made.
Task describes your responsibility and the constraint. “Our group had a failing demonstration” is context; “I owned the failing import step and had one afternoon to investigate it” explains your part. Do not claim ownership of a decision that someone else made.
Action explains what you personally did and why. Describe the sequence, the evidence you used and any trade-off. “I worked hard and communicated” is vague. “I reproduced the import failure with two rows, checked the date conversion and asked a teammate to verify the expected format” gives the listener something concrete to evaluate.
Result reports what happened, followed by what you learned. Use measured figures only when you actually have them. A qualitative result such as a repeatable test or an agreed handover checklist can be useful evidence. If the outcome was disappointing, say so and explain what changed in your later behaviour.
Spend more of your answer on Action than on background. The optional 90-second timer is a rehearsal aid, not a rule that every interview answer must follow.
3. Revise for clarity and prepare follow-ups
Read your first draft aloud. Underline sentences that describe your actions and circle claims that need evidence. If most of the answer is context, shorten it. If you cannot support an exact improvement percentage, replace it with an observation you can explain accurately.
Replace vague phrases with a concrete sequence. Instead of “we fixed the issue,” explain which part you investigated, what you changed, and how the team checked it. Use “we” for a shared result and “I” for your own contribution without taking credit for other people’s work.
Prepare for questions such as “Why that approach?”, “What else did you try?”, “How did you know it improved?” and “What would you do differently?”. Keep a few factual notes rather than adding every detail to your opening answer.
Use the builder to draft your own version, then copy or download it before leaving. The current tab holds the text in memory; reloading or closing it clears the draft. The tool does not send the story to an AI service, assess your competence or predict an interview outcome.
Follow the reasoning
A worked example
Fictional teaching example: a student investigates an intermittent test failure. Use the structure, then replace every detail with an experience that actually happened to you.
| Part | Example answer |
|---|---|
| Situation | Our course project had an intermittent failing test that made it difficult to trust the final demonstration. |
| Task | I was responsible for investigating the failing test and explaining a fix to the group. |
| Action | I reproduced the failure with a smaller input, checked the shared state and changed the setup so each test started independently. I asked a teammate to review the change and reran the affected cases. |
| Result | The test became repeatable in our checks. I documented the cause and learned to check test isolation earlier. |
Why this matters: The action names an investigation, a correction and a check. The result is deliberately limited to the checks performed; it does not invent a production reliability percentage. A useful follow-up would be which state was shared and how the smaller input exposed it.
Example 2: disagreement without blaming a teammate
Fictional teaching example: a volunteer team disagrees about how much information a registration form should request. The goal is to show a decision process rather than to prove that someone else was wrong.
| Part | Example answer |
|---|---|
| Situation | Our volunteer group was revising an event registration form. Some members wanted more questions, while others worried the form would take too long. |
| Task | I agreed to propose a version the group could review before registration opened. |
| Action | I listed which details organisers actually needed, separated optional questions and walked through a draft with two volunteers. I recorded their concerns and presented the shorter draft with the reasons for each required field. |
| Result | The group agreed on the required questions and opened registration with that version. I learned to make a disagreement concrete with a draft rather than debating preferences in the abstract. |
Why this matters: This story does not claim the form increased registrations because no measurement is provided. The supported result is a shared decision and a completed form. If asked about other people’s views, explain them fairly and describe how they influenced the draft.
Example 3: a setback with an honest result
Fictional teaching example: a learner misses a personal project deadline. A reflective answer can describe a disappointing outcome without pretending the mistake never mattered.
| Part | Example answer |
|---|---|
| Situation | I planned to finish a personal dashboard over a weekend, but I underestimated the time needed to connect the data source. |
| Task | I needed to decide what I could finish and how to make a more realistic plan. |
| Action | I listed the unfinished work, built the smallest working data view first and postponed decorative charts. For my next project, I tested the riskiest integration before estimating the rest of the work. |
| Result | I missed the original weekend goal, but completed a smaller working version later. I learned to separate assumptions from verified tasks when planning. |
Why this matters: The answer admits the missed goal, identifies a planning mistake and describes a specific later habit. To strengthen your own version, give accurate details about what happened in the next project. Do not invent a successful later outcome if you have not yet tested the new habit.
Common mistakes and how to avoid them
Borrowing a model answer as your own experience
Examples teach structure. Copying the event as a personal claim leaves you unable to answer factual follow-ups and misrepresents your experience. Draft from your own notes instead.
Using “we” for every action
Credit the team, then name the part you personally owned. An interviewer should be able to distinguish shared context from your decisions.
Inventing metrics to make a result sound stronger
Use numbers only when you know how they were obtained. A clear observation with a stated limitation is better evidence than an unsupported percentage.
Forcing every question into STAR
STAR suits examples of past behaviour. A direct factual question or a coding explanation may need a shorter, different structure. Answer the question being asked.
Explain it in your own words
10 self-check questions
Pause before revealing each answer. These questions are unscored, so you can revisit them as often as you need.
01What does STAR stand for?
Situation, Task, Action and Result. Each part has a different job: context, responsibility, what you did and what happened.
02How is Task different from Situation?
Situation describes the context. Task states your particular responsibility, goal or constraint within that context.
03Which section usually needs the most detail?
Action, because it explains your decisions and behaviour. Keep enough context to make those decisions understandable.
04Can a course project be a valid example?
Yes, if it is relevant and described honestly as a course project. Explain the scale, your contribution and what you learned.
05Do I need a numerical result?
No. Use a number when you have evidence for it. Otherwise give a specific observable outcome and acknowledge what you did not measure.
06Can I discuss a failure?
Yes. State the outcome honestly, take responsibility for your part and explain a concrete change in your later approach. Avoid pretending a lesson automatically erased the impact.
07When should I use “I” and “we”?
Use “I” for your individual actions and “we” for shared work or outcomes. Credit help accurately.
08What should I do if I cannot remember an exact figure?
Do not invent one. State the observation you do remember, or explain that you do not have the exact measurement.
09Does a completed builder checklist mean the answer is strong?
No. It indicates that fields contain text. It does not verify accuracy, relevance, evidence or interview quality.
10How should I use the 90-second timer?
As an optional rehearsal constraint to spot unnecessary background. Adapt the length to the question and conversation; it is not a scoring rule.
Try it yourself
Use these exercises after the examples. Make a prediction or write your own answer before checking the suggested approach.
Practice 1
Replace a vague action
Improve “I helped my team solve a difficult problem” using a real event. Include one decision, one reason and one way you checked the result.
Show a hint
Complete: “I noticed…, so I chose… because…. I checked it by…”.
Check the explanation
There is no single correct story. A clear answer names something you actually observed, the change you personally made and evidence you can discuss. Remove any part of the template that does not match your experience.
Practice 2
Check every result claim
Circle every outcome and number in your draft. For each, write where the evidence came from. Replace claims you cannot support.
Show a hint
Ask “Did I measure this, observe it directly, or hear it from someone else?”
Check the explanation
A supported result might be “the three reproduction cases passed after the fix.” It does not automatically justify “all failures were eliminated.” Keep the result within the scope of what you checked.
Practice 3
Practise a follow-up conversation
Rehearse your story, then answer “What would you do differently?” and “What did another person contribute?”. Save a copy before reloading.
Show a hint
Name one specific alternative and give other people accurate credit.
Check the explanation
A useful reflection connects a lesson to a future action, such as testing a risky integration earlier. A fair contribution statement identifies help received while keeping your own responsibility clear.