"Tell me about a time when you had to deal with a difficult colleague."
You've heard this question. You know STAR: Situation, Task, Action, Result. You launch in: "Situation: I was working at Company X. Task: I needed to work with a colleague who had a different communication style..."
And the interviewer's eyes start to glaze.
STAR is an excellent framework — it forces structure into what would otherwise be a rambling story. The problem is how people apply it. When you label each section out loud, you stop telling a story and start reciting a template. Nobody talks like that. Nobody wants to listen to it either.
What STAR Is Actually For
STAR is a planning tool, not a script. Use it to structure your thoughts before the interview, not as a format you read out during it. The structure is internal — the delivery should sound natural.
Here's the real question the interviewer is asking with every "tell me about a time when..." question: "Does this person's actual experience demonstrate the competency I need?" Your job is to give them evidence. STAR is just a way of organising the evidence so it's easy to follow.
The Elements (Without the Labels)
- Situation: Set the scene in 1–2 sentences. Enough context that someone outside your company can understand what was happening.
- Task: What specifically were you responsible for? (Important: "we" answers are a yellow flag — interviewers want to know what YOU did, not the team.)
- Action: This is 60–70% of your answer. What specific steps did YOU take? What was your reasoning? What did you do that another person in your position might not have?
- Result: What happened? Numbers if possible. What did you learn? Would you do anything differently?
⚠️Watch out
The most common STAR mistake: spending 80% of the time on Situation and Task, then rushing the Result. Interviewers care most about what you DID and what the OUTCOME was.
The 8 Stories That Cover 80% of Behavioral Questions
You don't need a different story for every question. Most behavioral questions test one of these competencies, so prepare one strong story per competency and adapt as needed:
- 1Handling a conflict with a colleague or stakeholder
- 2Dealing with a setback, failure, or mistake
- 3Working under pressure or to a tight deadline
- 4Showing initiative or going beyond what was asked
- 5Leading or influencing others without formal authority
- 6Adapting to a significant change or unexpected challenge
- 7Managing multiple priorities simultaneously
- 8Delivering a successful project or outcome you're proud of
Write these stories out. Time them (aim for 90–120 seconds). Practise them until they're natural, not memorised.
5 Complete Worked Examples
Q: "Tell me about a time you dealt with a difficult colleague."
Strong STAR answer (notice: no labels)
"Last year I was working on a product launch alongside a senior engineer who had a very different view of timelines — he thought we needed another two months, I thought we could ship with what we had and iterate. Rather than escalating it or just going around him, I asked if we could spend 30 minutes mapping out his specific concerns. It turned out his main worry was one feature that had historically caused support tickets. We agreed to hold back that one feature and ship everything else. The launch went ahead on schedule, the product team hit their Q3 target, and we added the delayed feature three weeks later with minimal drama. Looking back, what I'd do differently is have that conversation two weeks earlier — we wasted time being in a standoff when we had compatible views underneath."
Q: "Tell me about a time you failed."
Strong STAR answer
"About two years ago I was managing a client account and I missed a key deadline because I underestimated how long the data validation stage would take. The client was understandably frustrated — this was a quarterly report they'd been waiting on. I called them immediately rather than emailing, explained what had happened without making excuses, and gave them a specific new date I was confident I could hit. I then built a buffer into every subsequent project timeline and started flagging risks earlier rather than trying to solve them quietly. The client relationship recovered — they actually gave us a larger contract six months later. But the miss itself was on me and I don't gloss over it."
Q: "Tell me about a time you worked under pressure."
Strong STAR answer
"In my last role, our CTO left suddenly three weeks before a major platform migration. I was the most senior engineer available and the timeline was fixed because of contractual obligations. I immediately broke the project into daily milestones so we could see exactly where we were each morning, brought in two contractors for the most time-consuming elements, and ran daily standups to catch blockers fast. We hit the deadline by two days, which sounds like barely surviving — but given where we started with a third of the technical leadership gone, I was genuinely proud of what the team did. I also learned that I perform better under pressure when I can make the ambiguity visible — a daily milestone board is now something I use on every significant project."
Q: "Tell me about a time you showed initiative."
Strong STAR answer
"I was doing customer support at my previous company and I kept getting the same three questions in different forms every week. None of them were in the FAQ — they were about edge cases in our billing system. Rather than just answering them one by one forever, I wrote up a short internal doc explaining the logic behind the billing rules, shared it with the team, and proposed we add a condensed version to the help centre. My manager approved it in a day. Support tickets for those three categories dropped by around 60% over the next month. It took me maybe two hours of effort. I mention it not because it was a huge project but because it's the kind of thing I find myself doing regularly — I'm uncomfortable with persistent friction that has an easy fix."
Q: "Tell me about a time you influenced without authority."
Strong STAR answer
"I wanted our engineering team to adopt a code review standard that the team had resisted before. Rather than lobbying my manager, I ran a small experiment: I spent two sprints doing thorough code reviews on my own PRs with detailed comments, and then at the next retrospective I showed the data — the features reviewed that way had a 70% lower bug rate in the following month. People respond to evidence more than to proposals, and once the pattern was visible, the team voted to formalise the practice. I wasn't the most senior person in that room by any stretch. But the data did the convincing."
One More Thing: The Follow-Through
The Result section is where most people get vague. "It went well" is not a result. "The project landed" is not a result. Push yourself to answer: What measurably changed? What did you learn that you've applied since? What would you do differently?
Interviewers ask behavioral questions because they believe past behaviour predicts future behaviour. The follow-through — what you learned and how you changed — is the part that signals growth and self-awareness. Don't skip it.