Situation: Two senior engineers on my team disagreed strongly about whether to build a custom ML pipeline or adopt a managed service. The debate was blocking our quarterly roadmap.

Task: I needed to resolve the disagreement, keep both engineers engaged, and deliver a decision the team could rally behind.

Action: I facilitated a structured decision meeting using a weighted scoring matrix. Each engineer presented their case against criteria we agreed on: cost, time-to-market, maintainability, and team skill gaps. I then ran a two-day spike on the managed service to gather real data.

Result: The data showed the managed service saved eight weeks of development time. Both engineers accepted the outcome because the process was transparent. We shipped the feature a month ahead of schedule.

Example 3: Leadership

Situation: Our company acquired a startup, and I inherited a team of six engineers with a completely different tech stack and engineering culture.

Task: I needed to integrate the team, align on shared practices, and deliver a unified product within one quarter.

Action: I ran one-to-one meetings with every team member in the first week to understand their strengths and concerns. I created a shared engineering playbook collaboratively rather than imposing our existing standards. I paired engineers from both teams on integration tasks to build relationships through shared work.

Result: We delivered the unified product on time. Retention was 100% through the integration period. The collaborative playbook approach was adopted company-wide for future acquisitions.

Common Mistakes

Too much Situation, too little Action. Candidates spend 60% of their answer setting the scene. Aim for 10% Situation, 10% Task, 60% Action, 20% Result.

Using "we" instead of "I". Interviewers want to know what you did. Collaboration is good, but be specific about your individual contribution.

Vague results. "It went well" is not a result. Quantify: revenue gained, time saved, users impacted, incidents prevented, percentage improvements.

Quantifying Impact: Numbers That Prove Your Value

Weak results sound like opinions. Strong results sound like facts.

| Weak | Strong | |------|--------| | "Improved performance" | "Reduced API latency by 74%, from 1.2s to 310ms" | | "Saved money" | "Cut infrastructure costs by £45,000 per year" | | "Helped the team" | "Mentored 3 junior engineers, 2 promoted within 12 months" | | "Fixed bugs faster" | "Reduced mean time to resolution from 4 hours to 35 minutes" |

Your Practice Template

For each role you are preparing for, write out five STAR stories covering these themes:

1. Technical challenge - a hard problem you solved
2. Conflict or disagreement - how you navigated people dynamics
3. Leadership or influence - a time you led without authority
4. Failure and learning - what went wrong and what you took from it
5. Impact at scale - something that affected the business meaningfully

Key Takeaways

• Structure beats brilliance. A well-structured average story outperforms a brilliant but rambling one.
• Action is the star of STAR. Spend most of your time here.
• Numbers are non-negotiable. Every result should have at least one quantified metric.
• Prepare five stories, cover any question. Most behavioural questions map to the five themes above.

Practice out loud. Record yourself. Time yourself. The difference between a good candidate and a great one is preparation.