How do you estimate how long a piece of engineering work will take?
answer
- decompose until pieces are comparable
- size against work you actually finished
- name the unknowns explicitly
- timebox the biggest unknown first
- range with a condition, then re-forecast
basics
~20 sProbes whether you have a repeatable method or a gut number. Describe decomposing until pieces are comparable to work you have done, naming the unknowns, buying the biggest one down with a timebox, and quoting a range you re-forecast.
how to answer
5 beats- how you break the work down before quoting anythingSay what your stopping point is — usually pieces small enough to compare against something you have actually finished. Give the unit you work in and keep this beat short and concrete.
- what you compare each piece againstExplain that you size against real past work rather than a mental model of the task, and mention the relative-sizing convention your team used if one applies. Avoid presenting any convention as universal.
- the unknowns you name, and how you buy the biggest one downThis is the beat most candidates skip and the one that separates a method from a feeling. Describe refusing to estimate a genuine unknown and asking for a short timebox to close it instead.
- how you deliver it as a range with a deciding conditionSay the range aloud together with the one thing that decides which end you hit. Naming the condition tells the listener where their influence would help, which is why it lands better than a padded single number.
- how the estimate gets updated once work startsClose with your re-forecasting cadence and what you compare against — closed work, not effort spent. Being willing to move the number in public is the credibility signal here.
your answer
4 story prompts- Write down the last estimate you gave and reconstruct how you actually arrived at it.
- Name one piece of work you refused to estimate until you had investigated it.
- Find a past ticket you compare new work against, and say why it is your reference.
- Note the bias you know you have — the step you routinely underprice.
draft and rehearse your own answer in a learn session
go deeper
This probes judgment under uncertainty and reliability as a planning partner. The interviewer wants to know whether your numbers come with assumptions attached, whether you can tell the difference between work you understand and work you have only imagined, and whether an estimate from you is something a team could plan against without being quietly surprised later.
I decompose until every piece looks like something I have done a version of before, and then I estimate the pieces rather than the whole. Concretely: last quarter I was asked how long it would take to put autoscaling behind our ingest workers so the queue-depth pages would stop. I broke it into fourteen tickets and sorted them into three groups — things I had shipped before, things I understood but had not built, and one thing I genuinely did not know, which was how our metrics agent behaves when instances churn constantly. For the first group I compared against real tickets from our history rather than a feeling. The second group I sized against those and then widened, because unfamiliar work costs more than I expect it to. The third I refused to estimate. I asked for a three-day timebox to test the agent under churn and said I would give a real number after that. The timebox found the problem: the agent needed a registration call our config service owned, and only that team could change it. So the estimate went out as four to seven weeks, with the sentence that the wide end was entirely that config change, and if it landed in the first week we were at four. We finished in five. Queue-depth pages went from thirty-one a week down to seven. The part I would keep from all of that is refusing to put a number on the unknown, and re-forecasting every Friday against what had actually closed.
The load-bearing move is refusing to estimate the third bucket and buying the unknown down with a timebox — that is what turns a description into a method. The range with a named deciding condition, rather than a padded single number, is the second signal. Dropping either leaves generic planning talk.
At team level the shape is the same, but what I owe people is a distribution rather than a number, so the method changes at the edges. When our infrastructure group took on reducing on-call load across three product squads, the ask arrived as a single question: how long until on-call is survivable. I would not answer that as one estimate. We pulled six months of paging history, ranked the sources by volume, and estimated only the top eight — each one sized by the engineer who would actually do it, because I do not size other people's work for them. For every source we published three numbers: a fast case with nothing blocked, a likely case, and a case where the two squads whose services we needed could not free anyone. I put that blocking assumption at the top of the forecast document, because it was the only part leadership could act on. They did act on it, and moved an engineer into our rotation for six weeks. We re-forecast every second Friday against sources actually closed, and I let the number move in the open instead of defending the original. It came in at four and a half months against a likely case of four. Pages per on-call shift fell from nineteen to seven, and the two sources we never reached are still listed in that document. What I coach now is that credibility comes from re-forecasting on a cadence, not from being right the first time.
Senior signal sits in three moves: refusing to answer a whole programme as one estimate, having engineers size their own work, and publishing the blocking assumption where leadership could act on it. Sizing the team's work yourself, or hiding the forecast changes, would pull this back to middle.
Estimate one task and show you know the boundary of your own knowledge. Saying 'I would want half a day to look at it before I give you a number' is a strong junior answer, not a weak one.
Show decomposition into pieces you can compare against work you have actually shipped, an explicit unknowns list, and a range with the condition that decides it. Mention how you re-forecast during the work.
You are forecasting for a team, so estimates should come from the people doing the work, and your job is aggregating, pricing the dependencies, and publishing the assumptions. Say how the forecast is refreshed on a cadence.
Talk about what your organisation hands to the business: how commitments are separated from forecasts, what earns a hard date, and how estimate quality is measured over time rather than defended after the fact.
saying these in an interview costs you the question
- A point date with no unknowns and no range anywhere in the answer
- Doubling a gut number and presenting that as a method
- Naming a framework without saying what you personally do
- Treating story points as hours wearing a different label
- No mechanism for updating the estimate once work is underway
- Claiming your estimates are essentially always right
- How big is too big for a single estimate?Give a working threshold and the reason behind it — typically the point where you can no longer compare a piece to something you have finished before. Then say what you do instead: split it, or timebox an investigation and estimate afterwards. A candidate with no threshold is estimating by feel.
- What do you do when you have never done this kind of work before?Say that you estimate the investigation, not the work: a short fixed timebox to close the biggest unknown, with a real number promised after it. Mention that uncertainty narrows as the work is explored, so the first number should be a wide range and should be labelled as one.
- How do points relate to time on your team?Handle this carefully — points are a relative-size unit, and teams derive throughput from history rather than converting points to hours. Say how your team used them and be honest if they had drifted into being hours with another name. Avoid presenting any one team's convention as the universal rule.
- How often are you right?Do not claim a high hit rate. Say what you track instead — how often the delivered result fell inside the range you quoted, and which kinds of work you are reliably optimistic about. Naming your own bias, such as underpricing review and rollout, reads as calibration rather than weakness.
## What the interviewer is listening for Not a framework name. They want to hear a **procedure with observable steps**, because the procedure predicts what happens on their team when someone asks you for a number in a meeting. - **The tell of a weak answer** is that it could have been given by someone who has never estimated anything: 'I break it down, think about risks, and add some buffer.' Every clause is true and none of it is a method. - **The tell of a strong answer** is that it contains at least one decision rule you could apply on the spot. ## Common wordings - 'How do you size a piece of work?' - 'Walk me through how your team does sprint planning.' - 'How do you decide what to tell a product manager when they ask how long something takes?' - 'How do you use story points?' The last one is narrower and invites a specific trap, discussed below, but all four are answered by the same procedure with a different emphasis. ## The procedure worth describing **Decompose** until each piece resembles work you have genuinely finished before — comparison to a real past ticket is far more accurate than introspecting about the task in front of you. Sort the pieces into three buckets: done this before, understand it but have not built it, and genuinely unknown. 1. The first bucket you estimate directly from history. 2. The second you estimate and then widen, because unfamiliarity costs more than people expect. 3. The third you do not estimate at all: you ask for a short fixed timebox to investigate, and you promise a number after it. That **refusal** is the single most credible move available in this answer, because it is the one thing an uncalibrated candidate never says. ## Ranges, not dates Uncertainty is widest before the work starts and narrows as the work reveals itself, so an early point date is a claim you cannot support. - Quote a **range** and attach the one condition that decides which end you land on — that condition is the part a listener can actually act on, because it tells them where to spend influence. - Then **re-forecast** on a fixed cadence against what has actually closed, and let the forecast move in public rather than defending the original number until the last week. ## The points trap If asked about story points or t-shirt sizes, describe them as **relative-size units** whose value comes from comparison and from a team's own throughput history. - Do not offer a conversion to hours as a fact, - and do not present one team's convention as an industry rule; conventions vary widely, and interviewers who run planning themselves will notice. It is entirely acceptable to say that your team's points had drifted into being days with a different name, and what you did about it. ## How the bar shifts - **At junior level**, honesty about the boundary of your knowledge is the whole answer. - **At middle**, decomposition plus an explicit unknowns list plus a range is expected. - **At senior**, the estimates should come from the engineers doing the work — sizing other people's work for them is a downgrade — and your contribution is aggregation, dependency pricing, and publishing the assumptions where they can be challenged. - **At principal level** the subject stops being individual estimates and becomes the estimate-producing system: what earns a hard commitment, what stays a forecast, and how the organisation learns from its own misses instead of relitigating them.