INTERVIEW PREP
STAR method interview examples: the right and wrong way, by role
See a typical STAR answer next to a stronger one for your role, and what the stronger answer does differently.
Almost every candidate has heard of STAR: Situation, Task, Action, Result. Because everyone uses it, interviewers hear a lot of answers that follow all four steps and still say very little.
A product-management interviewer discussion on Reddit describes exactly this: answers that sound polished and alike, then fall apart once the interviewer asks for specifics. STAR gives a story an order. Whether the story is any good depends on what goes into each step, and that changes with the question and the role.
What each step is for
Most weak STAR answers follow the four steps but spend their time in the wrong place. This table shows what each step needs to do, and roughly how much of a two-minute answer it deserves, so you can check where your own time goes.
| Step | What it should do | Roughly how long |
|---|---|---|
| Situation | Give just enough context for a stranger to follow: where, when and what was at stake | 10–15 seconds |
| Task | Say what you were responsible for or trying to achieve. It is not the situation again | 5–10 seconds |
| Action | What you decided, did or said, and why. This is where you are evaluated | About a minute |
| Result | What changed for users, the team or the business, and what you learned or would do differently | 15–20 seconds |
For a two-minute answer, the action should take more than half the time. If your first decision appears after a minute, the situation is too long. The behavioral interview mistakes guide explains why that happens.
Where STAR answers usually go wrong
Even answers that follow all four steps tend to slip in the same places. Listen for these when you practice:
- Too much background. Two minutes on the situation leaves thirty seconds for what you did. A data-science interviewer on Reddit names long, wandering answers as one of the most common errors they see.
- The task just repeats the situation. “The task was to fix the problem” tells the interviewer nothing new. Say what you were responsible for.
- The action describes the team, not you. “We aligned and moved forward” hides what you decided. In a thread about BCG fit interviews, candidates report interviewers probing for their personal contribution rather than the team's.
- No reasons. If you say what you did but not why, the interviewer can't tell how you think.
- The result is vague or invented. “It went really well,” or a percentage you can't support.
- Saying the labels out loud. “The situation was... my task was...” sounds rehearsed. Follow the order, but don't announce each step.
Examples by role
In each made-up pair, both answers follow STAR. Compare how much of each one is spent on the action, and whether you can tell why the candidate made each decision.
Software engineer
Question: “Tell me about a trade-off you made. What did you give up, and why?”
STAR used the wrong way
“We were building a new checkout service for our e-commerce platform, which had grown a lot over the previous two years and was running on a monolith that a lot of teams contributed to, so deploys were slow and there were a lot of merge conflicts... [another minute of background].
My task was to help with the checkout migration. I worked on the payment integration and wrote a lot of the tests. We had to move fast, so we balanced speed and quality. In the end we launched on time and the checkout was much faster.”
Why it falls short: Most of the time goes on background. The trade-off is never stated: what was given up? “Balanced speed and quality” is the phrase the interviewer was hoping you'd unpack.
STAR used well
“We were moving checkout out of our monolith before the holiday sales freeze, about six weeks away. I owned the payment integration. The trade-off was retries: building proper idempotent retries for the payment provider would take three weeks we didn't have. I chose to ship without automatic retries and route failed payments to a manual review queue instead, because a failed payment the support team could see was safer than a retry that might charge someone twice.
I agreed with the support lead how many failures a day the support team could absorb and added an alert at that level. We launched before the freeze. The queue averaged a handful of cases a day, and in January I built the proper retries and removed it. I'd make the same call again, but I'd have written the retry design down before launch so January started faster.”
What makes it work: The constraint (the freeze), what was given up (automatic retries), why (no double charges), how the risk was contained and what happened to the deferred work.
Follow-ups to expect: How did you decide the queue was safe? What would have made you delay the launch? More engineering questions are in the software engineer behavioral interview guide.
Product manager
Question: “Tell me about a time stakeholders wanted different things from your work. What did you do?”
STAR used the wrong way
“Sales wanted us to build custom reporting for a big prospect, and the support team wanted us to fix onboarding. My task was to align the stakeholders. We set up a meeting, discussed priorities and aligned on a plan that worked for everyone. We ended up doing a bit of both, and everyone was happy with the outcome.”
Why it falls short: The answer says “we” at every important moment, so the interviewer can't tell what the PM did. “A bit of both” avoids the decision the question is about.
STAR used well
“Sales wanted custom reporting to close a large prospect this quarter. Support wanted us to fix onboarding, which generated the most tickets. We had capacity for one. I met each lead separately and asked what they were trying to protect. For sales, it was one deal. For support, it was the time new customers took to get started.
I pulled ticket data and found that most onboarding tickets came from a single import step, which was smaller than either team assumed. I proposed fixing the import step first, about two weeks of work, and offering the prospect a manual monthly report while we did it. The head of sales agreed after the prospect accepted the workaround.
Import tickets dropped sharply, the deal closed, and we scoped custom reporting properly the next quarter. Looking back, I'd have pulled the ticket data before the first meeting rather than after.”
What makes it work: Each side's goal is stated fairly, the PM's own steps are clear, data changed the size of the problem and the final decision names who agreed and why.
Follow-ups to expect: What if sales had refused? How did you check the ticket numbers?
Product designer
Question: “Tell me about a time what you learned from users or data changed what you built.”
STAR used the wrong way
“The situation was that our onboarding flow wasn't performing well. The task was to improve onboarding. For the action, I did user research and created new designs following best practices. The result was that conversion increased by 300 percent and users loved it.”
Why it falls short: The labels are read aloud, the task repeats the situation, the research is never described and the result sounds invented. Nothing shows what the research changed.
STAR used well
“I was designing a shared calendar for small clinics, and I'd planned it around a weekly view because that's what our competitors used. Before building it, I ran short sessions with six front-desk staff using a clickable prototype. Four of them ignored the weekly view and kept asking who was free in the next hour, because most of their bookings came from patients calling in on the day.
That changed the design. I made a ‘next available’ list the default screen and moved the weekly view behind a tab. The engineering lead was worried about the extra work, so I cut a drag-to-reschedule feature to keep the scope the same. After launch, support requests about finding open slots, which had been our most common question in the pilot, mostly stopped.
I'd now test the default view before designing anything else.”
What makes it work: The original assumption, what users actually did, the design change it caused, the trade-off made with engineering and an honest result.
Follow-ups to expect: Why six participants? What did you lose by hiding the weekly view?
Data analyst
Question: “Tell me about a time you disagreed with a colleague or manager about an analysis or a decision.”
STAR used the wrong way
“My manager wanted to report that our new pricing page increased conversions. I knew the analysis was wrong because she hadn't accounted for seasonality. My task was to show her the correct numbers. I redid the analysis properly and showed it was flat. She eventually admitted I was right, and we didn't send the report.”
Why it falls short: It is a story about being right. The manager's reasoning is missing, the method is waved through and the result is a win over a colleague rather than a better decision.
STAR used well
“My manager wanted to tell leadership that the new pricing page lifted conversion by about ten percent, based on comparing the month before and after launch. I owned the weekly conversion report, and the launch had landed in our busiest season, so I wasn't sure the comparison was fair. Her point was reasonable: leadership wanted an answer that week, and the lift looked real.
Instead of arguing, I compared the same weeks in the previous year and checked conversion for traffic that never saw the new page. Both rose by about the same amount. I showed her the two charts side by side and suggested we report the result as ‘no clear effect yet’ and run a proper split test.
She agreed and presented it that way. The test ran for three weeks and showed a small lift, much smaller than ten percent. I now add a seasonal comparison to every before-and-after analysis by default.”
What makes it work: The manager's reasoning is treated as reasonable, the analyst's checks are specific, the recommendation is constructive and the lesson changed future work.
Follow-ups to expect: What would you have done if she had sent the report anyway? How did you choose the comparison weeks?
Program manager
Question: “Tell me about a time the requirements changed after you had started. What did you do?”
STAR used the wrong way
“Halfway through our data-center migration, leadership added a new compliance requirement. My task was to manage the change. I updated the project plan, held a re-planning session, updated the RAID log and sent a status update to all stakeholders. I made sure everyone was informed. We adapted and delivered the program.”
Why it falls short: It lists process steps but no decisions. What did the new requirement cost, what was traded off and who agreed to it? “Delivered the program” hides whether the date moved.
STAR used well
“Six weeks into a twelve-week data-center migration, legal told us customer data from two regions had to stay in-region, which our plan didn't allow. I owned the delivery date across four engineering teams. I first asked the team leads to estimate the impact, which was about four extra weeks if we kept the original order.
Rather than accept the delay, I proposed resequencing. We would move the eleven services with no regional data first, on the original date, and give the two affected regions their own later phase. I took that option, along with the risk of running two environments for a month, to the program sponsor, who approved it.
The first phase landed on time and the regional phase finished three weeks later. The cost was about a month of running two environments at once. I now ask legal to review data-location constraints at the start of every migration.”
What makes it work: The change and its cost are concrete, the program manager made a real choice, the trade-off and approval are named and the lesson is a process change.
Follow-ups to expect: How did you get the team leads to re-plan quickly? What would you have done if the sponsor had refused?
Consultant
Question: “Tell me about a time you worked with a difficult client, customer or stakeholder.”
STAR used the wrong way
“We had a really difficult client on a cost-reduction project who kept rejecting our analysis and changing what they wanted. My task was to manage the relationship. I stayed professional, kept communicating and made sure we met all their requests. In the end the client was happy and extended the project.”
Why it falls short: “Difficult” is a label, not a description. The client's concern is missing, the actions are generic and “the client was happy” doesn't show what changed.
STAR used well
“On a procurement cost project, the client's head of operations rejected our first savings estimate in front of her team. I was the analyst responsible for that model. I asked to meet her afterwards and found the real concern. Two of the suppliers we'd marked for consolidation handled emergency orders, and she'd been burned by a consolidation before.
She was right that our model didn't account for that. I rebuilt the estimate with emergency orders excluded, which reduced the savings by about a fifth. I also asked her to review the supplier list before we presented again. She presented the revised plan to her CFO herself.
The lesson I took was to test a model with the person who will live with it before it reaches a meeting.”
What makes it work: The stakeholder's concern is explained fairly, the candidate admits the model's gap, the action is specific and the outcome shows trust being rebuilt.
Follow-ups to expect: How did you raise the lower savings with your manager? The consulting behavioral and fit questions guide covers more.
When not to use STAR
STAR is for questions about a specific past experience. It is the wrong shape for:
- Opening questions such as tell me about yourself (use now, proof, next).
- Fit questions such as why do you want this job? or why should we hire you?
- Self-assessment such as what are your strengths? and what are your weaknesses?, where a short example supports the point, but the point comes first.
- Hypotheticals (“What would you do if...?”). Answer the scenario, then offer a real example if you have one.
Check your own STAR answer
Say your answer aloud, record it and listen back for these:
- Could someone who wasn't there follow the situation within about 15 seconds?
- Is there at least one sentence where you decided or chose something, with a reason?
- Did you say what it cost, what you gave up, or what the other person wanted?
- Is the result honest, including anything that didn't work?
- If someone asked “Why?” about your main action, do you have an answer ready?
If any answer is no, fix that part and tell the story again in fresh words. Don't memorize the improved version. Keep the decision points as cues so you can adapt when the question is worded differently.
New to the format? Start with what a behavioral interview is.