In a live-coding round, why name a brute-force solution before optimizing?

## The baseline is a protocol move, not a confession Candidates often skip the brute force because saying it feels like admitting they cannot see the smart answer yet. In a live round the effect is the opposite. Announcing a correct-but-slow solution is the fastest way to prove you understood the problem, and understanding is the thing the interviewer cannot otherwise verify while you sit thinking in silence. The move takes half a minute: *the straightforward version compares every pair, which is quadratic in the number of records; I think we can do better by trading memory for the repeated scan.* ## Three concrete things it buys **A floor.** From the moment the baseline is on the board, the worst outcome of the round is that you implement something correct and slow. Without it, the worst outcome is an empty board at minute thirty-five. That asymmetry is why experienced candidates state the baseline even when they already see the optimal approach. **Evidence of comprehension.** A slow solution that is *correct* demonstrates you have the problem right — the inputs, the boundaries, the output contract. Interviewers routinely give partial credit here even when the optimal solution never arrives, because comprehension is a separate rubric line from optimality. **A frame for the optimization.** An improvement is only legible relative to something. If you jump straight to a lookup-based approach with no baseline, the interviewer hears an assertion. If you say the naive version rescans the whole list for every element and the improved version replaces that scan with a single pass plus a lookup structure, they hear a tradeoff — extra memory bought a cheaper repeated operation. That is the sentence rubrics reward. ## Saying it without sounding like it is your best idea Register matters. Deliver the baseline as a stepping stone with an explicit next move attached, never as an offer. Compare: - Weak: *I guess I could just check every pair? Is that okay?* — this hands the interviewer a decision you should be making and signals you may stop there. - Strong: *The naive version is all-pairs, quadratic. I do not want to spend the round on that, so I am going to look for a single-pass version first — I will keep the naive one as a fallback if that stalls.* The second sentence makes the baseline explicitly disposable, which is what stops it reading as your ceiling. ## Should you actually implement it? Usually not, and this is worth asking rather than guessing: *do you want me to code the naive version first, or go straight to the improved one?* Most interviewers will say go straight, and now you have their agreement on the record. Implement the baseline when the improved approach is not yet clear and more than half the coding time remains, when the problem is small enough that the naive version is genuinely near-optimal, or when the interviewer asks for it. Do not implement it at minute thirty as a consolation prize — at that point a clear description plus a partial improved solution reads better than a rushed complete slow one. ## The complexity claim needs to be honest, not decorative When you name the baseline's cost, name what drives it: *quadratic because for each of the n records I walk the whole list again.* A bare complexity label with no mechanism behind it is the kind of claim an interviewer will probe, and the probe is much worse if you cannot say where the cost comes from. If you are unsure, say the shape rather than a symbol — *this rescans everything for every element, so it degrades badly as the feed grows.* ## Worked example The same mid-level mobile candidate, at the Series C scale-up, is now asked to find the first activity record that appears in both of two feeds. The editor is blank and has no runner. They say: *The obvious version takes each record in the first feed and scans the second for it — correct, but it rescans on every step, so it gets bad fast on a heavy account with a few thousand records. I would rather build a lookup of the second feed once and then walk the first feed a single time; that trades some memory for dropping the repeated scan. Want me to go straight at that, or see the naive one written out?* The interviewer says go straight. Roughly forty seconds spent, comprehension demonstrated, a fallback banked, and the optimization now arrives with a stated motivation instead of appearing from nowhere. ## The failure mode it prevents The pattern this replaces is the long silence: a candidate who hears the problem, says nothing, and spends four or five minutes internally searching for the elegant solution. From the outside that is indistinguishable from being lost. If the elegant solution arrives, the candidate has spent five minutes of a 45-minute round buying nothing; if it does not arrive, they are now behind the clock, still have nothing on the board, and are much more likely to freeze rather than fall back — because there is no fallback to fall back to.