What ordered unsticking drill do you run aloud when an approach stalls mid-interview?
answer
- a fixed order beats improvising under pressure
- start concrete, not clever
- your hand solves the tiny case somehow
- then remove one dimension of difficulty
- pattern catalogue is the last rung, not the first
basics
~20 sRun a rehearsed ladder out loud: re-work a small concrete example by hand, then solve a deliberately simplified version, then scan known technique families aloud and say why each fits or fails. Announce which rung you are on.
solid answer
~60 sBeing stuck is normal; thrashing silently is what costs the round. Have three rungs ready and say which one you are climbing. **Rung one — re-work the example.** Drop back to a tiny concrete case and process it by hand out loud, watching what you actually do; the step you perform without thinking is usually the one missing from your plan. **Rung two — simplify.** Solve a strictly easier version first: one shared room before many, or a fixed-length request before variable ones. Get that right, then ask which part of it survives generalisation. **Rung three — scan technique families aloud.** Walk a short mental list — ordering the input, hashing for fast lookup, two coordinated positions, recursion with memoisation, a running extreme, a graph traversal — and say in one line why each fits or does not. Timebox the ladder; if none of the rungs move you within a few minutes, localise your blockage and ask. The narration is the point: a stuck candidate with an audible procedure is scored very differently from a stuck candidate who goes quiet.
go deeper
Have a first move ready for the moment your mind goes blank: take a tiny example and work it by hand, out loud. Saying what you are doing keeps the interviewer with you and usually surfaces the step your plan was missing.
Be able to name the rungs and explain why the order is examples, then simplification, then technique scan. Show that you can solve a deliberately restricted version and then state precisely which parts of it generalise and which break.
Demonstrate composure and timeboxing under a real clock: run the ladder audibly, cut it off when it stops paying, and take the exit by localising your blockage in one sentence. Also show the judgment to bank a correct slow solution before chasing an elegant one.
Own it as a transferable debugging discipline. Be ready to argue why a fixed recovery procedure beats improvisation when judgment is degraded, and how you would install that habit in a team facing an unfamiliar production problem with a clock running.
## The behaviour being tested Everyone gets stuck. Interviewers pick problems that make it likely, because how you *recover* discriminates far better than whether you needed to. The two bad outcomes are recognisable from across the room: silent thrashing (typing, deleting, typing, saying nothing for four minutes) and paralysis (staring, apologising, waiting for rescue). Both produce the same debrief line — *did not have a way forward* — regardless of how strong the candidate is on a good day. The antidote is a rehearsed drill, run out loud, in a fixed order. Fixed order matters because it removes decision-making at precisely the moment your decision-making is compromised. And saying which rung you are on turns being stuck into a visible, competent process rather than an absence. ## Rung one: re-work a small concrete example, by hand Step back to a case small enough to hold in your head — three or four entries on a shared calendar, chosen so the interesting situation actually occurs — and process it manually, narrating each step. Not "what would my algorithm do", but "what do *I* do". This works because human intuition solves small instances using steps you never wrote down. You will catch yourself doing something — glancing ahead, mentally arranging the entries, remembering something from earlier — and that unrecorded step is usually the missing piece of the plan. Say what you notice: "I just compared these two without checking the first one at all — why did I feel allowed to skip it?" That sentence has broken more stalls than any amount of staring at a half-written function. It is also cheap and completely safe to narrate: even if it yields nothing, the interviewer sees concrete, grounded work rather than a freeze. ## Rung two: simplify the problem, deliberately and out loud Solve a version you *can* solve, and be explicit that you are doing it: "I'm going to solve this for a single shared room first, get that right, and then ask what changes when there are many." Good simplifications remove one dimension of difficulty: - collapse a general case to a fixed one (many rooms to one room), - shrink the input to a size where brute force is obviously fine, - assume the input arrives in a convenient form and see whether that assumption alone unlocks it, - drop a requirement (ignore the reporting part, just answer yes/no) and add it back later. The last variant is quietly powerful, because the *cost* of the assumption you made is often exactly the sub-problem you were stuck on — and now you know its name. The explicit second step is what makes this a drill rather than a dodge: after solving the easy version, ask out loud which parts generalise and which break. Interviewers are generally happy to let you take this route; what they dislike is a candidate who solves a simplified version and quietly presents it as the answer. ## Rung three: scan technique families aloud Only now go to the catalogue, and make the scan audible with a one-line verdict per entry rather than a silent flip-through. A workable short list: put the input in a useful order; trade memory for fast lookup; move two coordinated positions through the data; recurse and remember sub-results; keep a running extreme as you go; model it as nodes and edges and traverse. The verdicts are the value: "ordering — plausible, the difficulty is comparing things that arrive unsorted, so that could help." "Two coordinated positions — needs a linear structure with a consistent direction, which I do not obviously have." "Graph traversal — I don't see relationships between entries beyond overlap, so probably not." Even the rejections are signal, because they show you know what each family *needs* in order to apply. A candidate who says why four techniques do not fit is demonstrating more than one who guesses right once. The order matters. Pattern-matching first is the common mistake: it is the most comfortable rung and the least grounded, and it tends to produce a technique bolted onto a problem you have not yet understood. Examples first, then simplification, then catalogue. ## Timeboxing and the exit The ladder is not infinite. Give it a few minutes; if none of the rungs move you, take the exit deliberately rather than drifting: state precisely where you are blocked and ask. "I've worked the example, I can do the single-room version, and I'm stuck on how to avoid re-examining entries I have already handled — is there an angle there I'm missing?" That is a strong sentence, not a weak one. It reports three completed attempts and localises the gap, which usually earns a small targeted hint instead of a large corrective one. ## Rehearsal is the whole point None of this is hard in the abstract; all of it is hard at minute eighteen with an audience. That is why the ladder must be practised until it is automatic — deliberately, on problems you are already stuck on, saying the rung names out loud even when alone. Under pressure you do not rise to your intentions; you fall back on your drills, and a drill you have never spoken aloud is not one you will speak aloud then.
- Why does scanning technique families come last rather than first?It is the most comfortable rung and the least grounded. Reaching for a catalogue before you understand the problem produces a technique bolted onto a shape you have not yet seen, and it is hard to abandon once you have committed code to it. Working a small example first tells you what the problem actually demands, which makes the scan far more accurate — you match against observed structure rather than against surface features of the wording.
- How do you avoid the risk of solving only the simplified version and running out of time?Announce the simplification as a step, not a destination, and bound it: "single room first, then I generalise — say five minutes." Then, immediately after it works, say aloud which parts survive and which break under the general case. That keeps the interviewer aligned and keeps you honest. The failure mode is not simplifying; it is quietly presenting the easy version as the answer and hoping the difference goes unmentioned.
- You have run all three rungs and are still stuck with ten minutes left. What now?Take the exit deliberately. Say where you are blocked in one specific sentence, name what you already ruled out, and ask for input — then, while waiting, commit to writing the working brute-force version so there is something correct on the screen. Finishing with a slow but correct solution plus an articulate account of the faster one you could not complete beats finishing with an elegant half-implementation that runs on nothing.
It is a pre-flight checklist for a stall: the value is not that each item is clever, it is that the order is fixed so you are not inventing a procedure while losing altitude.
saying these in an interview costs you the question
- Thrashes silently for minutes with no audible procedure
- Jumps straight to guessing techniques before understanding the problem
- Freezes and waits to be rescued rather than stepping down
- Simplifies the problem but never says that they did
- Refuses to abandon the stalled approach as time runs out
- Treats being stuck as evidence the round is already lost