Mid-way through an interview answer you have drifted into background history — how do you recover?

## Recovery is a skill, not an accident Everyone drifts. Under pressure, background is the safest material to narrate, and a candidate who is buying time while deciding what to claim will slide into it without noticing — narrating three years of org history before reaching the thing that was actually asked. What separates a strong candidate is not never drifting; it is noticing within a sentence or two and cutting cleanly. The recovery is worth rehearsing precisely because it happens live and cannot be scripted around. ## The recovery move Four steps, roughly five seconds: 1. **Finish the sentence you are in.** Cutting yourself off mid-clause sounds like panic and forces the listener to reparse. One more clause costs nothing. 2. **Name the move.** A short transition tells the listener this is deliberate: *"Let me give you the headline first, then the detail."* 3. **Deliver the point in one line.** The outcome, in past tense, in a single sentence. 4. **Resume at the decision.** Continue from the choice that actually mattered, not from where you left off in the backstory. Worked example. A hiring manager for a platform team asks about a time you unblocked other engineers, and the candidate has spent a while on how the team came to own the deployment tooling: > "...and ownership had been split between us and infrastructure since the merge. Let me give you the headline first, then the detail: releases could only be run by me, and I got every team on the platform shipping without me. The decision that mattered was..." The drift is now invisible. What the listener heard was a candidate who noticed they were in the weeds and steered out — which is itself a signal, since it is the same skill that keeps a design review or an incident call on track. ## What not to do - **Do not apologise at length.** "Sorry, I'm rambling — where was I? — anyway, so, the point I was making..." spends more airtime on the meta-commentary than the recovery. One clause of self-editing, then move. - **Do not restart the answer.** Beginning again from the top doubles the cost of the mistake and tells the listener the first attempt was wasted. - **Do not speed up.** Compressing the remaining material into faster speech keeps everything that was not worth saying and adds strain to the delivery. - **Do not ask them to repeat the question** unless you genuinely lost it. Asking is fine early; asking after ninety seconds of talking reads as never having engaged with it. - **Do not silently keep going** and hope the ending redeems it. It rarely does, and by then the airtime is spent. ## The check-in pause: recovering before you need to The cheaper version of recovery is a planned one. At around the ninety-second mark — roughly the point where a two-to-three minute answer has covered its shape — stop and hand control back: > "That's the shape of it. Do you want the detail on the decision, or on how it landed?" This does several things at once. It converts a monologue into a conversation before the listener has to interrupt. It surfaces which part they actually care about, so the remaining airtime is spent on their interest rather than your outline. And it gives you a legitimate exit from a story that is going long, without the exit reading as a failure. One pause is the budget. Two or three turns a narrative into a series of permission requests and pushes the work of running the answer onto the listener. ## Reading the signals that you have drifted You usually get warning before the interruption: - The note-taking stops. Someone scoring an answer writes during the decisions and stops during context. - Backchannel noises thin out — the small acknowledgements disappear. - You get a question that you already answered, or one that restates the original prompt. That is a rescue attempt, and the right response is to take it as a headline cue rather than to defend the tangent. - You hear yourself using "and then" repeatedly. Chained clauses are a chronology tell. ## Why the skill transfers A hiring manager is not only scoring the story. Noticing that your listener is lost and correcting for it in real time is the same behaviour they need from you in a design review, an incident bridge or a status update to a stakeholder who is not technical. A candidate who recovers cleanly demonstrates that skill under observation, which is a better outcome than one who never drifted and never had to show it.