Tell me about a time you had to deliver something under a tight deadline.
answer
- name the date and why it was fixed
- state what you owned, not the team
- draw the cut line out loud
- timebox, then ask for help
- result with a number, then the change kept
basics
~10 sTests whether you stay structured when time runs short. Answer with a real date pressure, the cut line you drew early, the status you broadcast, and a shipped result — not an endurance story.
how to answer
6 beats- the deadline and why it could not moveTwo or three sentences only, roughly fifteen percent of your airtime. Say what the date was tied to and how much time you actually had, so the pressure is a fact rather than an adjective.
- what was on the list and which part you ownedQuantify the load and then narrow to your slice. Owning a well-defined part credibly is stronger than an unspecific claim on the whole effort, and it sets up the triage that follows.
- the cut line you drew and what you droppedThis is the beat that carries the signal. Name the ranking rule you used and one specific thing you removed or downgraded, including the gold-plating you abandoned. Say where you wrote the cut down.
- how you kept people informed and where you asked for helpGive the cadence and the audience of your status updates, and one moment you asked someone for something specific. A timebox on investigation before asking is a concrete detail worth including.
- what shipped, measuredClose the loop with a number and with what happened to the deferred work. Result plus reflection should be about a quarter of the answer, so do not let this become one rushed sentence.
- what you kept doing afterwardsOne sentence naming the habit or practice that survived the crunch. This turns a survival story into evidence of learning and gives the interviewer their next question.
your answer
5 story prompts- Pick a deadline you personally worked to, ideally within the last eighteen months.
- Write down what you cut or deferred, and where you announced that cut.
- Find one number for the result: items shipped, items deferred, or defects after release.
- Note the moment you asked someone for help, and how long you waited first.
- This can be the same episode as your competing-priorities answer, angled toward the date.
draft and rehearse your own answer in a learn session
go deeper
Probes execution under constraint and self-management. The interviewer wants evidence that time pressure produces triage rather than panic or silence: that you rank work, remove scope deliberately, signal status early, and ask for help before it is too late. A strong answer proves you deliver without relying on heroics that nobody can plan around.
I contribute to an open-source test-fixture library, and one cycle the maintainers set a hard freeze eleven days out because downstream package bumps were already scheduled around it. Thirty-eight issues were tagged for the release, and twelve of them sat in the fixtures area I knew best, so I volunteered to own that slice. My first move was to sort my twelve into two lists in the tracking issue: seven regressions that would break existing users, and five improvements that were genuinely nice to have. I posted that split on the first morning and said plainly that the five were coming out unless someone objected. Nobody did. I also abandoned a refactor I was halfway through, because it made the diff harder to review and bought users nothing this cycle. Then I timeboxed. Anything I could not reproduce in forty minutes got a comment asking the reporter for a failing snippet instead of me guessing at it. I left a short status comment each evening — finished, in progress, stuck — and on the fourth day I asked a maintainer for an hour of pairing on the trickiest teardown bug rather than sitting on it quietly. All seven regressions landed before freeze. Reopen rate on fixes in my area came down from twenty-six percent the previous cycle to twelve percent in this one, and the five deferred issues moved to the next milestone with notes attached. Since then I publish the cut list on day one, every time.
The signal is triage before effort: a written split on the first morning, an investigation timebox, a nightly status line, and one explicit request for help. Naming the abandoned refactor is what makes the cut real. Claiming ownership of the whole release rather than a defined slice would downlevel it into vagueness.
By the following major release I was one of the people running the triage board for the whole project rather than a single component. We had nine working days between the last feature merge and the freeze, sixty-three issues tagged, and two contributors who had joined that month and wanted real work. I ran a half-hour triage call and forced every issue into one of three buckets: blocks the release, ships with a known-issue note, or moves to the next milestone. Twenty-one moved out. The bucket I had to argue for was the middle one — two rough edges we shipped documented instead of rush-fixing, because rushed fixes in that code path were exactly what had been driving things back open. For the two newcomers I deliberately did not hand over the hard bugs. They got verification work against the release candidate, with a written checklist and a rule that anything unclear became a question in the channel inside twenty minutes rather than an hour of silent struggle. That kept them moving without me reviewing late at night. We froze on time with sixty-one of sixty-three either resolved or consciously deferred. Across the two cycles that followed, reopen rate on release fixes went from nineteen percent to eight, mostly because we stopped shipping same-day patches for issues nobody could reproduce. The known-issue bucket is now a standing part of how the project triages a release.
What lifts this to mid-level scope is the public tradeoff: a documented known-issue bucket defended out loud, and load shaped for two newer contributors instead of absorbed personally. The measured aftermath ties the cut to quality. Dropping the reasoning behind the middle bucket would leave it sounding like ordinary triage.
Own one slice honestly and show the mechanics: how you ranked your own tasks, what you dropped, when you asked. A well-run small scope beats a vague claim on the whole release.
Show the tradeoff you made across a feature or component and who you aligned with before making it. Name what you deliberately shipped imperfect and why that was the right call.
Cover the team and production scope: the scope decision you took on others' behalf, how you kept reviewers and stakeholders calibrated, and the prevention you put in afterwards.
Talk about the conditions that produced the crunch and the mechanism you changed so the next one is smaller — planning cadence, definition of blocking, or how commitments are made.
saying these in an interview costs you the question
- Resolving the story with heroics and lost sleep instead of decisions
- No cut line — everything was somehow finished at full quality
- Going quiet on stakeholders until the deadline arrived
- Blaming whoever set the date rather than showing what you controlled
- A two-minute setup and a ten-second result with no measurement
- We-language throughout, so your own contribution never becomes visible
- What did you decide not to do, and who did you tell?This is the beat interviewers most often find missing. Name one concrete thing you cut, say where you announced it, and say who could have objected. If nobody knew about the cut, admit that and say what you would publish now.
- What would you do differently if you had that deadline again?Give one specific, earlier action — publishing the cut list on day one, asking for a reviewer sooner, escalating a dependency. Avoid answering that you would just start earlier; it reads as unreflective and blames the calendar.
- How did the quality of what you shipped hold up afterwards?Interviewers are checking whether speed left a mess. Give the honest aftermath: defects found later, follow-up work you scheduled, or a metric that held. Owning one thing that came back is stronger than claiming it was flawless.
## One question, several wordings This prompt arrives in almost every loop, in several wordings: - tell me about a time you worked under a tight deadline, - describe a high-pressure situation you handled, - when did you last have more to do than time to do it, - or tell me about your busiest week. They are the same question, and the same story answers all of them. ## What the interviewer is actually scoring Not whether you delivered — most candidates say they did. They are scoring **the shape of your decision-making** when the resource that ran out was time. Concretely: - did you rank work explicitly, - did you remove something, - did anyone else know what was happening before the deadline arrived, - and did you ask for help at a point when help was still useful. A candidate who describes a chaotic week that ended fine is scored lower than one who describes a smaller problem handled deliberately. ## The weak answer and the strong answer, side by side - **The weak version is an endurance narrative:** the deadline was brutal, I put my head down, I worked evenings, we made it. It has no decisions in it, so there is nothing to evaluate, and it quietly signals that your response to time pressure is to spend more of your own hours — a strategy that does not scale and that a manager cannot plan around. - **The strong version has a visible cut:** here is what was on the list, here is the line I drew, here is who I told and when, here is what I dropped and what happened to it afterwards. The pressure is the setting; **the triage is the story**. ## Evidence that lands One number in the result is enough, and it does not have to be a business metric — items shipped versus deferred, defects found after release, how many days before the date you flagged the risk. What lands even harder is a piece of evidence that shows the communication happened: - a status update you posted daily, - a written cut list, - a message where you asked a specific person for a specific hour of their time. That converts a claim about your process into an **artefact**. ## Airtime Most candidates spend a minute establishing the context because it is the easy part to narrate, then compress the interesting part into a sentence. - **Situation and task** should be about fifteen to twenty percent of the answer. - **The actions** — how you triaged, what you cut, how you signalled — deserve roughly sixty percent, - and **the result plus reflection** the remaining twenty to twenty-five. ## How the bar moves - **At the earliest levels**, a clean story about your own task list is fully sufficient and is what the rubric expects; do not inflate it into team ownership. - **From mid-level**, the interviewer wants a tradeoff made in public: something shipped knowingly imperfect, with the reasoning and the person you aligned with. - **At senior**, the scope shifts to decisions made on other people's behalf and to the prevention that followed — what changed so that this specific crunch does not recur in the same form. - **At principal**, the answer should touch how commitments get made at all, not just how one was rescued. ## Two traps 1. **First, the invisible team:** if the crunch involved other people and your answer never mentions them, it reads as either exaggeration or poor collaboration. 2. **Second, the perfect ending:** an answer with no cost — nothing deferred, nobody inconvenienced, no follow-up work — is usually a story that has been sanded down, and a follow-up probe will find the seam. Name the cost yourself.