STAR Framework

Since behavioural answers can be long (usually 2–4 minutes) and detailed, it’s best to use the STAR framework to structure your response.

STAR stands for Situation, Task, Action and Result.

Using this structure keeps your story clear, concise, and easy to follow, especially in complex or technical examples.

Answer Structure

Situation — 10%
What was going on? Set the context.

Task — 10%
What was your role or responsibility?

Action — 60%
What did you do? Be specific.

Result — 20%
What was the outcome? End positively and give metrics if possible.

The percentages show how to split your answer by time. For example, the 'action' part of your answer should be the most detailed, whereas 'situation' and 'task' should be short and concise.

Next, we’ll break down each part of the STAR structure in more detail.

Situation

What was going on? Set the context.

Keep it short and specific. Don’t go deep into the backstory or technical detail.

Give the interviewer enough context to understand where you were, what the team or project was, and what was going on.

Length: 1-2 sentences (or 10% of your answer)

I was working as a backend engineer at a mid-sized fintech company. We were preparing for a product release when we discovered a bug two days before the launch.

Task

What was your role or responsibility?

Explain what you were responsible for. What was the goal, challenge, or outcome you needed to achieve?

• Define what success looked like

• Make the task sound meaningful, not just "I had to do my job."

• Focus on your specific responsibility (unless teamwork is the focus)

Length: 1–2 sentences (10% of the answer)

I was one of the engineers responsible for deployment, so it was my job to help identify the issue and ensure the release could go ahead safely.

In the above example, the candidate defines success as the release going ahead safely.

Action

What did you do? Be specific.

This part should have the most detail.

• Describe what you did, not what the team did

• Break your action down into a few clear steps

• Use strong verbs to show ownership and decision-making

Length: 4–8 sentences (60% of the answer)

Example:

I started by taking a closer look at the bug, just trying to understand exactly what was going wrong. I teamed up with one of the QA engineers, and we spent some time trying to reproduce it.

Once we managed to do that, it became pretty clear that the issue was linked to a recent change in our transaction logic. I went through the commit history to narrow it down and eventually found the specific part of the code that was causing the problem. I rolled that section back, and to prevent it from happening again, I wrote a test that would catch similar issues in the future.

After that, I coordinated with QA to rerun the full test suite and make sure everything was stable before we pushed the fix and moved forward with the release

In the example above, we have 3 clear steps:

1. Investigated and reproduced issue

2. Identified and fixed root cause

3. Validated and deployed fix

Result

What was the outcome? End positively and give metrics if possible.

Share the clear result and ensure it links back to your original task. Did performance improve? Did customers complain less? Did the team save time or money?

If possible or relevant, share a measurable impact using numbers or metrics.

Length: 2–4 sentences (20% of the answer)

The fix held up in production and we were able to launch on time. On top of that, the test I added actually caught a similar bug in the next sprint, so it helped us avoid another last-minute scramble. Over the following couple of months, we saw around a 30% drop in final stage issues, so it ended up having a bigger impact than expected.

Adaptations

Depending on your level of seniority, there are certain adaptations you can make to the STAR framework. We'll explore these on the next page.