Why state a brute-force solution aloud before optimizing in a coding interview?
answer
- think about what the interviewer can score
- silence and being stuck look identical
- you may need something to fall back on
- confirms you solved the right problem
- state it with its Big-O, then improve
basics
~20 sA stated brute force proves you understood the problem, gives the interviewer a correct baseline to score, and becomes your fallback if the clever idea collapses. Silence while hunting for the optimal answer reads as being stuck.
solid answer
~50 sI say the obvious approach in one or two sentences together with its time and space cost, label it explicitly as a baseline rather than my final answer, and then ask for a moment to improve it. That does four things at once: it confirms I am solving the problem the interviewer meant, it gives them something correct to score, it anchors the complexity conversation so "better" has a number to be better than, and it leaves me a working solution to fall back on when the clever idea does not converge. It also converts silent thinking into visible progress — from the other chair, a candidate quietly searching for the optimal solution and a candidate who is stuck look identical. I do not implement it unless asked or the clock forces it; stating it is the move.
go deeper
Be ready to open any problem with one sentence of naive approach plus its Big-O, then say you want to do better. Practise the exact wording until it is automatic — it is the single habit that most changes how a screen goes.
Explain what the baseline buys beyond politeness: it pins down your reading of the problem, gives the complexity discussion an anchor, and preserves a fallback. Show that you know when to state it versus when to actually implement it.
Demonstrate judgment about the clock: decide out loud whether the baseline is acceptable for the stated input bounds, and manage the switch back to it when an optimization stalls without losing composure or narration.
Own this as a hiring signal. Be able to say why a stated baseline with a correct cost is scored as strength on a rubric, and how you would coach a team that equates 'mentioned the obvious solution' with 'could not do better'.
## The move, in one line "Brute force first" means: within the first few minutes of a problem, say out loud the most obvious correct approach — the one that just enumerates everything — together with its time and space complexity, mark it as a baseline, and then start improving. It is a *statement*, not usually an *implementation*. A typical delivery is three sentences: "The obvious approach is to compare every pair of records, which is O(n^2) time and O(1) extra space. That is correct but I think we can do better. Can I take a minute to look for something faster?" Thirty seconds, and the whole conversation changes shape. ## What it actually buys you **1. It checks you are solving the right problem.** The cheapest moment to discover you misread the requirement is before you have written any code. When you describe an enumeration in plain terms, the interviewer hears your interpretation of the input, the output and the success condition, and corrects you immediately if it is wrong. Candidates who go straight to a clever technique often discover at minute 25 that they optimized the wrong question. **2. It gives the interviewer something to score.** Interview rubrics are not a single pass/fail on the optimal solution; they score problem understanding, communication, correctness and complexity analysis separately. A stated baseline with a correct complexity already earns marks on two of those axes before you have solved anything. **3. It anchors the optimization conversation.** "Faster" is meaningless until there is a number to be faster than. Once O(n^2) is on the table, everything after it is measured against it: the interviewer can ask what you are aiming for, you can say what the gap is, and both of you are talking about the same thing. Without the anchor, discussion of an improvement floats. **4. It is a safety net.** Interview time runs out. If your optimized idea is not converging with ten minutes left, you already have a solution you have described and agreed on; you implement that, get it correct, and narrate the improvement you would have made. A correct baseline plus a well-described optimization scores far better than a half-finished clever solution that never ran. **5. It makes thinking visible.** This is the underrated one. Silence is ambiguous. A candidate reasoning brilliantly in their head and a candidate frozen produce exactly the same signal from the other side of the table. Stating the baseline puts a floor under the interviewer's read of you and buys you permission to think. ## The wrong belief this aims at Many candidates believe that naming a naive approach reveals that naive is all they have — that it "looks weak". The opposite is true in practice. Interviewers are trained to reward structure, and "here is the obvious approach and its cost, now let me beat it" is textbook structure. What actually looks weak is a long silence, a solution that appears with no stated cost, or an optimized approach the candidate cannot compare to anything. There is a real failure mode nearby, though, and it is worth separating: *stopping* at the brute force. The baseline is a starting position, not an answer. If you state it and then sit on it without attempting to improve — or wait to be asked — you have converted a strength into a weakness. State it, label it as a baseline, and immediately signal intent to do better. ## When you should actually implement it Three cases. First, when the interviewer says so — "go ahead and code that" is common, and it usually means they want working code from you before discussing optimization, or the naive approach is genuinely acceptable for the stated input size. Second, when the constraints make it acceptable: if the problem promises at most a few hundred items, a quadratic pass is fine, and insisting on the clever solution wastes the clock. Third, when time is nearly gone and you need something that runs. Otherwise, keep it verbal. Spending eight minutes typing an enumeration you already know you will throw away is the single most common way candidates run out of time. ## The phrasing that works Say the approach, say its cost, label it, and ask for time. Naming the cost is not optional — a described baseline without a complexity is only half the signal, because the whole point of the baseline is to give the optimization something to be measured against. And when you move on, make the transition explicit ("so the quadratic part is the pairwise comparison; that is what I want to remove") so the interviewer can follow you rather than guessing whether you abandoned the baseline or forgot it.
- The interviewer says 'just code that' right after you describe the baseline. Is that a bad sign?No. It usually means they want working code from you before the optimization discussion, or the naive cost is fine for the stated input size. Code it cleanly, keep narrating, and when it runs, offer the improvement and its expected complexity rather than waiting to be asked.
- You have ten minutes left and the optimized idea is not converging. What do you do?Announce the switch, implement the baseline you already described, get it correct, and walk through a small example. Then narrate the optimization you were chasing and the complexity it would have reached. A correct, tested baseline plus a described improvement outscores an unfinished clever solution.
- How long should the brute force take before you move on?A sentence or two, well under two minutes. It is a statement with a complexity attached, not a design exercise. Implement it only when the interviewer asks, when the stated input bounds make it acceptable, or when the clock forces you to have something that runs.
It is the pencil sketch before the painting: quick, obviously not the finished piece, and it proves to everyone in the room that you are drawing the right subject.
saying these in an interview costs you the question
- Thinks naming a naive approach makes them look weak
- Searches silently for the optimal solution for several minutes
- Describes the baseline but never states its complexity
- Starts typing the enumeration immediately, unasked
- Presents the baseline as the final answer and stops there