How long should a STAR answer be?

Sixty to ninety seconds, and treat ninety as the ceiling. That is roughly 200 spoken words, split Situation 10 seconds, Task 10, Action 50, Result 20. If your answers run past two minutes without the interviewer asking a single follow-up, the story is rarely the problem. You spent 40 seconds on setup that needed 10.

The 90-second budget, beat by beat

Write your answer out, then hold it against this. Every number here is countable, which is the point, because "be concise" is advice nobody can act on at 9am with a recruiter on the line.

Two things fall out of that table. Action takes 55% of the clock and more than half the words, because it is the only beat an interviewer can really score. Most answers invert the ratio: a minute of context, twenty seconds of what you did, and a Result that lands while the interviewer is already typing. The other point is the total. Two hundred words is small enough to count on your phone before the call.

The arithmetic assumes 140 words per minute, a normal measured speaking pace. The real range is roughly 120 to 160, and nerves push most people to the top of it. Calibrate once: read a 210-word answer out loud into your phone's voice recorder. Under 80 seconds means you are rattling through it, and the fix is to slow down rather than to add words. For any other draft, divide the word count by 2.3 to get the spoken length in seconds.

The seven lines that always get cut

Before you rewrite anything, delete these. They turn up in almost every over-long answer and not one of them earns a point.

• The warm-up. "That's a good question, let me think of a good one." Four seconds spent saying nothing.
• The cast list. Team size, reporting lines, who sat in which building. Nobody is drawing your org chart.
• How you found out. Thursday afternoon, an email, your first reaction. Texture, not evidence.
• The glossary. Explaining what a sprint, a queue or an override is to someone who works with them daily.
• The second example. "Something similar happened at my last place." One story, told properly.
• The consultation. Every side conversation before the decision. Keep the decision, drop the corridor.
• The apology. "That's probably more than you needed." Stop on the Result and let the silence sit.

Strip those out of a typical answer and you usually lose about 40% of the words without losing a single fact an interviewer could have scored.

Three answers, before and after the cut

Each answer below appears twice. First the version people actually give when nobody is holding a stopwatch, with the dead weight struck through like this. Then the surviving words, printed clean with the clock in them. Each long version runs roughly two to three times its budget, which is a very ordinary amount of overrun.

1. "Tell me about a time you dealt with a difficult stakeholder"

The three-minute version. 453 words, 3 minutes 17 seconds:

Yeah, that's a good question, let me think of a good one, I've got a few actually. So I joined the payments team about two and a half years ago, and back then we were six engineers, a PM, a designer shared with another team, and a director who had just moved across from the data org. Three weeks before a payouts launch at a fintech, compliance told us they would not sign off. I found out on a Thursday afternoon, by email, which is not how I would have chosen to hear it. The client already had the date. And to be fair to compliance, they sat in a different building, so everything went through email, which probably did not help. I owned the flow, so getting sign-off without slipping the launch was mine to fix. I did check with my manager first about whether to escalate to his director, and he said try to sort it out directly, which in hindsight was right. Escalating would have cost us a week. Honestly, my first reaction was frustration, because from where I sat they had held the spec for six weeks and raised nothing. I asked for thirty minutes with the head of compliance and went in without defending the design. I asked her to walk me through the risk in her own words. Which is not what I would normally do, I would usually turn up with slides. The objection was not the flow at all, it was that manual overrides left no audit trail, which was fair. An override is where an operator pushes a held payment through by hand, so you can see why that is sensitive. I scoped an append-only override log with the two fields she cared about, actor and reason, and had it estimated the same day. I brought her the design before I built it rather than after, so the review was a nod instead of a negotiation. Then I changed how we engaged compliance for good: a one-page risk summary at kickoff instead of a forty-page spec three weeks out. That spec was something we had inherited, nobody read it, and I think that was the real root cause of the whole thing. We shipped eight days late instead of six weeks late, which the client was fine with once we explained it, and the override log is now the default on every payout product. She asked for me by name on the next project, which was nice. What I took from it: when someone blocks you late, they usually raised it early in a document nobody read. Anyway, that is probably more than you needed, but that is the one that comes to mind.

The 90-second version. 204 words, 89 seconds:

Situation, 0:00. Three weeks before a payouts launch at a fintech, compliance told us they would not sign off. The client already had the date. Task, 0:10. I owned the flow, so getting sign-off without slipping the launch was mine to fix, and escalating would have cost us a week. Action, 0:20. I asked for thirty minutes with the head of compliance and went in without defending the design. I asked her to walk me through the risk in her own words. The objection was not the flow, it was that manual overrides left no audit trail, which was fair. I scoped an append-only override log with the two fields she cared about, actor and reason, and had it estimated the same day. I brought her the design before I built it rather than after, so the review was a nod instead of a negotiation. Then I changed how we engaged compliance for good: a one-page risk summary at kickoff instead of a forty-page spec three weeks out. Result, 1:10. We shipped eight days late instead of six weeks late, and the override log is now the default on every payout product. What I took from it: when someone blocks you late, they usually raised it early in a document nobody read.

2. "Tell me about a project that did not go to plan"

The long version. 340 words, 2 minutes 28 seconds:

Oh, plenty of those. Where do I start. We migrated a reporting service onto a new message queue over a weekend, and by Monday morning finance was seeing Friday's numbers as Monday's. The queue was a vendor product we had picked mostly because another team was already on it, which is a whole separate story. I had signed off the cutover plan, so the fix and the explanation were both mine. Two other engineers were on it with me, and to be clear we all made the call together. Month-end close was nine days out. I will be honest, I spent the first twenty minutes feeling sick about it. I stopped the rollout instead of rolling forward, because we could not yet tell how many records were affected. Rolling forward is where you push a fix rather than reverting, which is usually the tempting option. I had the old consumer back in ninety minutes. Then I wrote a query comparing row counts by ingest timestamp across both paths, which showed 1,400 duplicated rows inside a two-hour window rather than across the whole weekend. I reconciled those by hand with the finance lead watching, so she could see the before and the after herself. That took most of a day and a lot of coffee. Then I found the actual cause: the new consumer acknowledged messages before the write committed, so any retry reprocessed them. I added an idempotency key on the write, and a replay test in CI that fires a duplicate at every consumer we own. We also talked about moving off the vendor, though that never happened. Close went out on time. The replay test caught the same class of bug in a different service two months later. Which felt like a nice bit of validation for the effort. What I would do differently is obvious in hindsight: I cut over on a weekend without writing the reconciliation query first, so I ended up debugging and proving correctness at the same time. Sorry, that was a long one.

The 90-second version. 209 words, 91 seconds:

Situation, 0:00. We migrated a reporting service onto a new message queue over a weekend, and by Monday morning finance was seeing Friday's numbers as Monday's. Task, 0:10. I had signed off the cutover plan, so the fix and the explanation were both mine, and month-end close was nine days out. Action, 0:20. I stopped the rollout instead of rolling forward, because we could not yet tell how many records were affected. I had the old consumer back in ninety minutes. Then I wrote a query comparing row counts by ingest timestamp across both paths: 1,400 duplicated rows inside a two-hour window, not across the whole weekend. I reconciled those by hand with the finance lead watching, so she saw the before and after herself. Then I found the actual cause: the new consumer acknowledged messages before the write committed, so any retry reprocessed them. I added an idempotency key on the write, and a replay test in CI that fires a duplicate at every consumer we own. Result, 1:10. Close went out on time, and the replay test caught the same class of bug in a different service two months later. What I would do differently: I cut over without writing the reconciliation query first, so I was debugging and proving correctness at the same time.

3. "Tell me about a time you took initiative"

This one does not need the full ninety. Some stories are worth about a minute, and the budget scales rather than one beat shrinking: Situation 8 seconds, Task 10, Action 32, Result 17.

The long version. 258 words, 1 minute 52 seconds:

So, initiative. The honest answer is that most of what I do is assigned, but there is one thing. Our on-call rota was generating about forty pages a week, and most of them were the same three alerts. We had grown from two services to eleven in about a year, and nobody had revisited the alerting since the original setup. Nobody owned alert quality. I raised it in a retro once and it went on the board and stayed there. I was on call the week it got bad enough that I stopped sleeping through the night. I exported ninety days of pages into a spreadsheet and sorted by alert name. Which took an afternoon, mostly because the export was paginated and I had to script it. Three alerts were 61% of the volume, and not one of them had ever led to a customer-visible incident. I raised the threshold on two, deleted one outright, and wrote a one-line rule: any alert that pages twice without action gets an owner or gets deleted. I took that rule to the team as a proposal rather than a decision. Some of the discussion got quite heated, to be fair. Pages went from about forty a week to eleven, and the rule is still in our runbook. People definitely seemed happier on call afterwards. The part I got wrong: I deleted the alert before I proposed the rule, and one person was rightly annoyed about that. Anyway. Not the most dramatic story, but it is the one I am proudest of.

The 65-second version. 154 words, 67 seconds:

Situation, 0:00. Our on-call rota was generating about forty pages a week, and most of them were the same three alerts. Task, 0:08. Nobody owned alert quality, and I was on call the week it got bad enough that I stopped sleeping through the night. Action, 0:18. I exported ninety days of pages into a spreadsheet and sorted by alert name. Three alerts were 61% of the volume, and not one of them had ever led to a customer-visible incident. I raised the threshold on two, deleted one outright, and wrote a one-line rule: any alert that pages twice without action gets an owner or gets deleted. I took that rule to the team as a proposal rather than a decision. Result, 0:50. Pages went from about forty a week to eleven, and the rule is still in our runbook. The part I got wrong: I deleted the alert before I proposed the rule, and one person was rightly annoyed about that.

Look at what survived all three cuts. Every sentence left standing is a decision, a reason, or a number. Everything struck was context, chronology or feeling. That is the whole test: read your draft and ask of each sentence, "could an interviewer write this on a scorecard?" If not, it is narration, and narration is what pushes you to three minutes.

When 90 seconds is the wrong target

• "Tell me about yourself" is not a STAR answer. It wants 60 to 75 seconds of trajectory and fit. Forcing it into four beats makes it sound like a case study.
• Senior deep-dives. At staff and principal level an interviewer may deliberately spend the whole round on one project. Still open with the 90-second version, then let their questions choose the branch rather than guessing which branch matters.
• Follow-ups reset the clock. "And then what happened?" hands you a fresh 60 to 90 seconds on exactly the part they care about. The budget governs your first pass, not the conversation.
• Panels and scored loops. Where there is a timekeeper and a fixed question list, overrunning costs someone else their question, and that gets noticed.
• Recorded one-way video. These commonly cap at two or three minutes with a countdown on screen. Fill about two thirds of the cap. Talking until the buzzer reads as poor judgement rather than thoroughness.

If you need raw material to time, work from the questions you are actually likely to face rather than a generic top-50. Our interview questions bank is one starting point, and the company Q&A generator builds a set for a specific company and role, which is what you want when you are choosing which three stories to rehearse.

Where a copilot helps with this, and where it does not

Worth being straight about this, given a vendor is writing it. OfferPilot AI's Interview Copilot hears the question and puts a grounded draft on screen in about a second, which genuinely helps when your mind goes blank on a story you have not told in a year. What it cannot do is time you. It does not hear your pace, it does not know you are at 0:55 with the Result still ahead, and if you read a full draft aloud word for word you will run long and you will sound like you are reading. Treat a draft as a scaffold: take the beat you lost, then say it in your own words.

Two further honest limits. It runs on Windows 10 and 11 only, so on a Mac none of this applies. And for delivery practice specifically, the best tool in the room is not AI at all. It is your phone's voice recorder and a stopwatch. Record the answer, play it back, and count the seconds before you reach the first thing you actually did. If that number is above 25, you have found your problem, and no model is going to hand you that number.

Pick your three strongest stories. Write each one out, count the words, cut to 200, then say it into a recorder until it lands between 80 and 95 seconds without you racing. Three answers held to that standard will carry you through most behavioural rounds, because the follow-ups do the rest of the work.

Related guides

• Tell Me About a Time You Had a Conflict With a Coworker
• Prepare Behavioral Interview Answers in One Day: 4-Hour Plan
• How Many Behavioral Stories to Prepare? 8 Cover 30 Questions
• HireVue Interview Format: What to Expect, Question by Question
• Hiring Manager Interview Questions: The 3 Decisions Being Made