How to prepare interview examples using the STAR method

Start with the skills the interview will assess

A behavioural question asks about something you have done, such as handling a disagreement or recovering from a mistake. Competency questions may ask for similar evidence of a skill. Begin with the job description and the interview brief so you prepare examples relevant to this role.

Microsoft’s interview advice recommends identifying relevant skills from the job description and preparing specific examples of the situation, actions, outcome and learning. It also notes that candidates may face role-related scenarios. An account of past work and an answer to a hypothetical problem require different preparation.

Ask the recruiter which formats to expect. Our guide to recruitment stages helps clarify that brief. STAR can organise past examples, but it does not replace practising the coding, design or other tasks a technical assessment actually requires. When a question asks what you would do, make clear that you are proposing an approach rather than reporting an outcome you achieved.

Build a small bank of different experiences

Choose enough examples to cover the role’s main demands without forcing every answer into the same story. A useful starting set includes a difficult problem, a disagreement, a delivery constraint, a mistake and a learning experience. This is a preparation exercise, not a required number of stories.

For each example, note the setting, your responsibility, the important decision, the outcome and what you learned. Map it to the skills it demonstrates. A production incident might show diagnosis and communication, but use the part that answers the question you are asked.

The National Careers Service’s STAR guide says examples can come from work, home or volunteering. Projects and study can also provide material when you describe their setting accurately. If you are early in your career, a small, well-understood example is easier to defend than an inflated claim.

• Problem-solving: what evidence helped you choose between possible causes?
• Collaboration: how did you handle a real difference in priorities or opinions?
• Delivery: what did you change when time, scope or resources became constrained?
• Mistake: what did you own, repair and change afterwards?
• Learning: how did new knowledge change something you could do?

Use STAR to organise an example

STAR stands for situation, task, action and result. The National Careers Service describes it as a way to structure examples and recommends concise, conversational delivery. Use the parts as prompts in your notes, not labels you must announce during the interview.

Give enough context for the interviewer to understand the stakes. Then focus on what you did, why you chose that approach and what happened. Microsoft adds reflection in its STAR(R) model. A brief explanation of what you learned can help the interviewer understand your judgement.

Worked STAR example: diagnosing a software defect

The following is a hypothetical developer example for ‘Tell me about a difficult problem you solved’. It illustrates structure and ownership; replace it with an event you experienced.

Situation and task: ‘Our customer import sometimes created duplicate records when an upload was retried. I was responsible for investigating the API behaviour and proposing a fix. The support team needed a clear explanation for affected customers.’

Action: ‘I compared the failed requests with the import logs and reproduced a retry after a connection timeout. I found that the first request could finish even though the client had received no confirmation. I discussed the failure case with a senior engineer and proposed an idempotency key so repeating the same import request would not create another batch. I implemented the change and added integration tests for repeated requests. QA ran the wider regression checks, and I documented the behaviour for support.’

Result and reflection: ‘The repeated-request test then returned the existing result without adding duplicate records. We released the fix after review. I cannot attribute every later support outcome to that change, but I can explain the behaviour we verified. I also added retry scenarios to our API review checklist because our earlier tests had covered invalid input but missed an interrupted connection.’

The answer names a specific diagnosis, decision and contribution. It distinguishes the developer’s tests from QA’s work and keeps the result within the evidence. That makes it possible to answer a follow-up without inventing a business impact.

Make your contribution and result precise

Use ‘we’ for shared context and ‘I’ for your own actions. If someone else chose the architecture, say so and explain what you contributed. Leading a workstream, implementing a change and assisting a colleague are different responsibilities; each can supply useful evidence.

For a numerical result, know the baseline, measurement period and source. If you cannot verify a figure, use a supported qualitative result instead. Do not turn a correlation into a claim that your change caused every improvement that followed.

Check that your account agrees with the CV you submitted. The CV evidence-mapping guide can help you connect written claims to examples. Remove client identifiers and confidential details from preparation notes; explain the problem without disclosing protected material.

Prepare for the questions after your story

The National Careers Service explicitly recommends being ready for follow-up questions. Test each example by moving beyond the sequence of events. You should understand the choices well enough to explain them in a different order.

For the hypothetical API example, useful follow-ups include why an idempotency key was chosen, what would happen with concurrent requests and which failure cases remained. If you did not own part of the solution, state the boundary and explain what you do know.

• What evidence changed your initial view of the problem?
• Which alternatives did you consider, and what trade-offs mattered?
• What was your contribution compared with other people’s work?
• How did you verify the result, and what could you not measure?
• What went less well than planned?
• What would you change if you faced the same situation again?

Practise the answer, not a script

Tell the story aloud from a few bullet points. Ask someone to stop you when the context is unclear or your contribution disappears into ‘we’. Practise a concise opening version, then expand the decision or result when they ask. There is no single ideal answer length for every question.

Listen for jargon, unnecessary names and background that do not help explain the decision. Keep enough technical detail for the audience. The National Careers Service’s interview tips suggest practising with someone you trust and asking for clarification when a question is unclear.

Prepare a setback honestly, too. Identify what you got wrong, what you did once you noticed and what changed afterwards. If the result remained disappointing, say that; learning does not require rewriting an unsuccessful outcome as a win.

Check the meeting details and your own questions

Review your example notes alongside the job description, then prepare questions that help you assess the team. For example, ask how a recent technical decision was reviewed or what support a new hire receives when taking ownership of a system.

If you use CVer, the interview-calendar guide explains how to verify entries created from confirmed recruiter emails. Compare the time and instructions with the latest message, particularly after a reschedule. An automatically added calendar entry does not send your confirmation to the recruiter.

• Confirm the date, time zone, meeting link, participants and expected format.
• Check any setup instructions and which tools or resources you may use.
• Test your microphone and connection, and keep a contact for technical problems.
• Keep brief example prompts available if notes are permitted; do not read a prepared answer word for word.
• Afterwards, record useful feedback, questions you found difficult and the agreed next step.