A fresh interview problem shows no recognizable pattern cue — how do you proceed out loud?
answer
- you still need something correct on the board
- optimise an approach you have stated
- find the work being done twice
- the repeated operation names its own fix
- recall is a cache; this is the miss path
basics
~20 sState a correct brute force out loud with its cost, name the single repeated operation that dominates it, then ask which structure or precomputation removes that operation. The pattern falls out of the fix rather than out of recall.
solid answer
~50 sPattern recall is a cache, and this is the cache-miss path. First, commit to a correct brute force and say its complexity aloud — that fixes a baseline and proves you understood the ask. Second, point at the *specific* operation that makes it expensive: is it re-scanning to ask whether a value was seen, recomputing the total of overlapping ranges, re-finding the extreme of a shifting range, or re-solving the same subproblem on overlapping inputs? Third, ask what removes that one operation's cost — hashing for membership, prefix sums or a precomputed table for range aggregates, a heap or monotonic deque for a shifting extreme, memoization for overlapping subproblems. The named pattern is usually the answer to step three, so you derive it instead of recognising it. Narrate all three steps; a stated brute force plus a correctly named bottleneck is already a passing signal in most loops, even if you never reach the optimum.
go deeper
Be ready to state a correct slow approach and its cost rather than freezing. Saying 'I would check every pair, which is quadratic' is real progress and the starting point for everything that follows.
Practise naming the repeated operation precisely — a re-scan for membership, a recomputed range total, a re-found extreme — and connect each to the mechanism that makes it cheap.
Demonstrate the full derivation under time pressure and out loud, including what you would ship if the optimum never arrives. Show that you treat pattern recall as a cache with a miss path, not as the whole skill.
Own this as a bar-setting question: decide whether your loop rewards fast recognition or visible derivation, since the first selects for drilled candidates and the second for people who make progress on problems nobody has seen.
## Why this is the senior skill, not the fallback Candidates who have drilled patterns hard develop a hidden dependency: they can solve anything that *looks like* something they have seen. Interviewers know this and deliberately dress problems so the surface cue is absent or misleading. What they are measuring is whether you can still make progress when recognition returns nothing — and that is a procedure, not a talent. The procedure has three steps and each one is spoken. ## Step 1 — commit to a correct brute force, aloud, with its cost Say what the obviously-correct approach is and what it costs: "I can check every pair of samples, that is quadratic." This does three things. It proves you have understood the ask, which is the precondition for everything else. It gives you a correct fallback you could actually deliver if time runs out. And it produces the object that step two operates on — you cannot name a bottleneck in an algorithm you have not stated. The common failure here is skipping this step because the brute force feels embarrassing. It is not; refusing to state one leaves you with nothing to optimise and nothing to show. ## Step 2 — name the single dominating repeated operation Look at the brute force's inner loop and ask what work it repeats that it already did. Almost every interview optimisation is one of a small set: - **Repeated membership or complement lookup** — "have I seen this value before, and where?" A linear scan inside a loop. - **Repeated aggregate over overlapping ranges** — recomputing a total, minimum or count for spans that share almost all their elements. - **Repeated extreme over a shifting range** — re-finding the largest or smallest of a set that changes by one element at a time. - **Repeated resolution against a later element** — for each item, scanning forward until something beats it. - **Repeated identical subproblems** — the same arguments recur along different branches of the recursion. - **Repeated group or connectivity questions** — asking again and again whether two things are in the same cluster. Say which one it is, and say it precisely: not "it is slow", but "for each of the n samples I scan forward to find a stronger one, so the same suffix is walked over and over." ## Step 3 — ask what removes that operation's cost Now the question is narrow enough to have a small answer set: | Bottleneck named in step 2 | What removes it | Pattern you have just derived | |---|---|---| | Membership / complement lookup | Hashing seen values | The hash-map pass | | Aggregate over overlapping ranges | Precomputed running totals, or reuse of the previous span | Prefix sums, or a window | | Extreme over a shifting range | A heap, or a monotonic deque | Top-k, or the deque window | | Resolution against a later element | A stack of unresolved items | The monotonic stack | | Identical subproblems | Caching by argument | Memoization / dynamic programming | | Repeated grouping questions | Merging representatives | Union-find | The pattern is now a *consequence* of the bottleneck, not a guess about the statement. That is why the derivation path is more robust than recall: it works on problems you have never seen, and it produces the same answer as recall on the ones you have. ## Working the protocol on an unfamiliar statement Radio telemetry arrives as a stream of signal-strength samples, and you must report, for each sample, how many samples pass before a stronger one arrives. There is no familiar surface here. Brute force: for each sample, walk forward until you find a stronger one — quadratic, and worse on a long declining stretch. Bottleneck: the same suffix is re-walked by every sample in a declining run. What removes it: each sample only needs to be *told* when its resolver arrives, so hold the unresolved samples and let each new stronger reading resolve everything weaker beneath it — a stack, each sample pushed once and popped once, linear overall. The pattern was derived in three sentences without ever recognising it. ## What the interviewer is actually scoring Silence is the failure mode this protocol exists to prevent. An interviewer cannot grade thinking they cannot hear, and a candidate who says "I don't recognise this" and stops has produced no signal at all. A candidate who states a correct baseline, names the bottleneck precisely, and reasons about what would remove it has demonstrated the thing the whole loop is trying to measure — even when the optimal solution never arrives. If the derivation stalls, the honest move is to state the two candidate fixes you are weighing and why you are unsure; that keeps the reasoning visible and usually earns the nudge that unblocks it. The senior habit worth carrying out of the interview room: when you are stuck, the productive question is never "which pattern is this?" It is "which operation am I repeating, and what makes that operation cheap?"
- Is stating a brute force a sign of weakness in a senior loop?No — refusing to state one is. A stated brute force proves you understood the ask, gives you something deliverable if the clock runs out, and is the object the whole optimisation argument operates on. The weak version is stating it and stopping; the strong version is stating it, giving its cost, and immediately pointing at what makes it expensive.
- You have named the bottleneck but no structure obviously removes it. What now?Attack the problem's degrees of freedom instead of the operation. Ask whether the answer space is monotone enough to search over, whether processing the input in a different order removes the dependency, or whether an approximation or a bound is acceptable. Say which of these you are trying and why — an interviewer will usually confirm or redirect rather than watch you exhaust all three in silence.
- How does this protocol change if the interviewer says the intended solution is linear?It sharpens step two rather than replacing it. A linear target rules out anything that revisits earlier elements more than a constant number of times, which points at single-pass state: a running aggregate, a hash map of what you have seen, a stack or deque of unresolved items. Say that out loud — narrowing the space of admissible mechanisms is itself progress the interviewer can score.
It is the difference between recognising a fault from the symptom and profiling: when nothing looks familiar, you measure where the time actually goes and fix that one thing.
saying these in an interview costs you the question
- Goes silent when no pattern is recognised
- Cycles through remembered patterns hoping one fits
- Skips the brute force as too embarrassing to state
- Says only 'it is slow' without naming the repeated work
- Asks for the intended solution before naming a bottleneck