When to Stop Optimizing: The Stopping Rule Strong Candidates Use
Most candidates lose time chasing a faster solution the interviewer never wanted. Here’s how to know when you’re done, and why stopping at the right moment is itself a skill being graded.
There’s a particular way to fail a coding interview that almost nobody warns you about.
You don’t freeze.
You don’t write broken code.
You solve the problem correctly, with a clean and efficient solution, and then you keep going, hunting for a marginally faster version the interviewer never asked for, burning the minutes you needed for testing and follow-ups, and you walk out having delivered less than the candidate who simply stopped.
The instinct is understandable.
Months of prep have trained you that “optimal” is the goal and anything less is a failure. But real interviews don’t reward optimization for its own sake. They reward judgment, and one of the clearest signals of engineering judgment is knowing when a solution is good enough and moving on.
Senior engineers are defined as much by what they choose not to do as by what they build. Knowing when to stop is not laziness; it’s a skill, and it’s being graded.
This post gives you the stopping rule: a concrete way to recognize the moment you’re done, so you stop optimizing when you should and keep going only when it genuinely matters.
Why over-optimizing quietly costs you the round
First, understand what you’re actually trading away when you chase an unnecessary optimization, because the cost is larger and more hidden than it looks.
An interview is a fixed time budget, usually 35 to 45 minutes, and that budget has to cover several things the interviewer is scoring: understanding the problem, choosing an approach, writing correct code, testing it, and handling follow-up questions.
Every minute you spend squeezing a constant factor out of an already-good solution is a minute stolen from those other categories.
The candidate who reaches a solid O(n) solution and spends the remaining time testing thoroughly and discussing tradeoffs looks far stronger than the one who reached the same O(n) solution and then spent ten minutes failing to shave it further, leaving no time to verify it works.
There’s a second, subtler cost.
Over-optimizing often introduces bugs.
The clean, readable solution you had at minute fifteen becomes a tangled, clever, error-prone version by minute twenty-five, and now you’ve traded a correct, clear answer for a faster one you’re not sure is right and can’t fully test.
In engineering terms, you’ve increased complexity and risk for a benefit nobody needed.
Interviewers notice this, because it’s exactly the behavior that causes problems on real teams: premature optimization that makes code harder to maintain for gains that don’t matter.
So the cost of not knowing when to stop isn’t just wasted time. It’s wasted time plus added risk plus a worse signal about your judgment. That’s a steep price for chasing “optimal” past the point of usefulness.
The core stopping rule
Here’s the rule, stated simply, then unpacked:
Stop optimizing when your solution’s time complexity is good enough that further improvement would be a constant-factor gain rather than a complexity-class gain, unless the interviewer signals they want more.
In simple words: you’re done when you’ve reached a good Big-O class for the problem and any further effort would only tweak the details, not change the fundamental efficiency.
Going from O(n²) to O(n) is a complexity-class improvement and almost always worth pursuing.
Going from one O(n) solution to a slightly different O(n) solution that saves a few operations is a constant-factor tweak and almost never worth your interview time.
The skill, then, is recognizing which kind of improvement is still on the table.
If you can still drop a whole complexity class, keep going, that’s real.
If all that’s left is shaving constants, stop, state that you’ve reached what you believe is the optimal complexity, and move to testing.
How to know you’ve hit “good enough”
Translating the rule into a moment-to-moment decision, here are the concrete signals that you’ve reached the stopping point.
You’ve matched the likely optimal complexity for the problem. With practice you develop a sense of the floor: many problems can’t do better than O(n) because you must examine every element at least once, and many can’t beat O(n log n) because they require sorting. When your solution hits that floor, you’re almost certainly done. A good habit is to say it out loud: “I think O(n) is optimal here, since we have to look at every element at least once.” If that’s true, there’s nowhere better to go, and stating it shows you know that.
Further improvement would only reduce a constant or a lower-order term. If you’re contemplating a change that turns 2n operations into n operations, or removes a second pass that doesn’t change the Big-O, that’s a constant-factor optimization. In the vast majority of interviews, this is not worth the time, and chasing it signals you don’t understand what actually matters at scale.
The remaining gains require significantly more complexity for marginal benefit. Sometimes a faster solution exists but only via a much more intricate approach, a complicated data structure, a non-obvious mathematical trick. Unless the interviewer is steering you there, the simpler solution that’s one notch slower is often the better answer, because it’s correct, clear, and verifiable. Real engineering constantly makes this trade, and choosing the maintainable solution is a point in your favor, not against you.
When you hit any of these, the move is the same: state where you are, state that you believe it’s optimal (or optimal enough), and pivot to testing and discussion.
Don’t optimize in silence past the finish line.
The other half: when you should NOT stop
A stopping rule is only useful if it also tells you when to keep going, because stopping too early is its own failure.
You should absolutely continue optimizing in these situations.
Your current solution is in a worse complexity class than achievable. If you’ve written an O(n²) brute force and an O(n) solution clearly exists, you are not done, and stopping here is a real miss. The interviewer’s classic prompt “can you do better?” is the explicit signal that a complexity-class improvement is available and expected. This is exactly the kind of optimization that matters, so pursue it.
The interviewer asks for more. This sounds obvious, but read the signal correctly. “Can you do better?” almost always means “improve the time complexity,” usually by trading some space. It is a hint that a better class exists, not idle curiosity. When you hear it, keep going, and it’s often pointing you toward using extra memory (a hash map, a cache) to cut the time.
You haven’t yet stated your complexity at all. Sometimes candidates stop without even knowing where they are. Before you decide you’re done, you must actually know your solution’s time and space complexity. If you can’t state it, that’s not a stopping point, that’s a sign you haven’t finished analyzing.
The symmetry is the whole point: keep going while complexity-class improvements remain or the interviewer asks; stop once only constant-factor tweaks are left and no one’s asking for more.
The script for stopping well
Stopping isn’t just an internal decision; it’s something you say, and saying it well is part of the signal.
When you reach the stopping point, narrate it.
Something like:
“This is O(n) time and O(n) space. I believe O(n) time is optimal here because we have to examine each element at least once, so rather than micro-optimize further, I’d like to test this and walk through some edge cases.”
Look at everything that sentence accomplishes. It states your complexity (showing you analyzed it), claims optimality with a reason (showing you understand the lower bound), explicitly chooses to stop (showing judgment), and redirects to testing (showing good engineering habits). That single sentence converts “I stopped” from a potential weakness into a clear strength.
Compare it to silently continuing to fiddle, which communicates none of that and risks looking like you don’t know you’re done.
And if you’re genuinely unsure whether more optimization is wanted, ask:
“I have an O(n) solution. I think that’s optimal, but I can look at reducing the space if that’s valuable, otherwise I’ll move to testing. What would you prefer?”
Asking is itself a strong signal, it shows you’re managing your time deliberately and collaborating rather than guessing.
A quick illustration
Imagine the two-sum problem: find two numbers in an array that add to a target. You start with the brute-force nested loop, O(n²).
This is a worse complexity class than achievable, so you should not stop, you keep going.
You realize a hash map lets you do it in one pass, O(n) time at the cost of O(n) space.
Now you’re at the optimal time complexity, you genuinely can’t beat O(n) because you must look at the elements, and the only remaining “improvements” would be constant-factor or space tweaks.
This is the stopping point.
The strong candidate says: “That’s O(n) time, O(n) space, and O(n) time is optimal since we have to read every element. I’ll test it now.”
The weak candidate, having reached the identical O(n) solution, instead spends the remaining minutes trying to eliminate the hash map’s space without changing the time, gets tangled, and runs out of clock before testing.
Same solution, opposite outcomes, decided entirely by knowing when to stop.
Frequently asked questions
Isn’t the optimal solution always the goal?
Optimal complexity class is usually worth reaching. Optimal constant factors almost never are, in an interview. The goal is a correct solution at a good complexity, delivered with time left to test and discuss, not the theoretically fastest possible code.
What if I stop and the interviewer wanted more?
Then they’ll ask, with some version of “can you do better?”, and you continue. That’s why stating your complexity and your reasoning out loud matters: it invites them to redirect you if needed. Stopping with a clear narration is safe; stopping silently is what’s risky.
How do I know what the optimal complexity even is?
This comes with practice and pattern recognition, but a reliable heuristic: if you must examine every element, O(n) is likely the floor; if the problem requires sorting, O(n log n) is likely the floor; if you can use a hash map to avoid nested loops, O(n) is often achievable. State your best guess at the floor and let the interviewer confirm.
Does stopping early make me look lazy?
The opposite, when done right. Stopping at a correct, optimal-complexity solution and pivoting to testing looks like senior judgment. What looks bad is stopping at a suboptimal solution without trying to improve it, or never knowing your complexity at all. The distinction is whether real improvement remained on the table.
Should I mention optimizations I’m choosing not to do?
Yes, briefly, it’s a strong move. “I could shave a constant factor by combining these two passes, but it wouldn’t change the O(n) complexity, so I’ll keep it readable and move on.” That sentence proves you saw the optimization and made a deliberate engineering choice, which is exactly the judgment being graded.
The bottom line
Strong candidates optimize until they hit a good complexity class, then stop and shift their energy to testing, edge cases, and discussion.
Weak candidates either stop too early, leaving a clear complexity-class improvement on the table, or stop too late, chasing constant-factor gains that cost them time, introduce bugs, and signal poor judgment.
The rule that separates them: keep going while a whole complexity class can still be improved or the interviewer asks for more, and stop once only constant-factor tweaks remain, narrating the decision as you make it.
Knowing when to stop is not the absence of skill. It’s one of the most senior skills there is, the recognition that “good enough, correct, and verified” beats “theoretically optimal but untested” almost every time.
Practice reaching that line and naming it out loud, and you’ll deliver more, and look stronger, than the candidate still optimizing when the clock runs out.