Home / Blog / When to Optimize Your Coding Interview Solution

When to Optimize Your Coding Interview Solution

Published 2026-10-05 · Luna Interview

You have a brute force that works. Now what? Some candidates optimize too early and run out of time with nothing working. Others code the brute force, say "done," and miss that the interviewer was waiting for a better approach. Both cost points.

Knowing when to optimize your coding interview solution is a judgment call, and it is one of the clearest signals of experience. This guide gives you a decision framework based on input size, time left, and what the interviewer is telling you.

The three options at every decision point

After you understand the problem, you have three choices:

1. Code the brute force first, then optimize.
2. Optimize in your head first, then code the better version directly.
3. Code the brute force and stop, spending remaining time on testing and edge cases.

None is always right. The trick is picking the right one for this problem, this interviewer, and this clock.

Signal 1: input size and constraints

Constraints often tell you what complexity is expected. A rough guide many candidates use:

These are rules of thumb, not guarantees. If no constraints are given, ask:

"Roughly how large can the input get? That'll tell me whether a quadratic approach is OK."

If the answer is "small," a clean brute force may be the full solution.

Signal 2: time left in the round

A working, tested O(n²) solution with a clear explanation of the O(n) idea usually reads better than a half-written O(n) solution that does not run.

Signal 3: what the interviewer says

Interviewers often hint at what they want. Listen for:

When in doubt, just ask. It is a normal question and shows you care about their priorities.

The talk track that covers all cases

Use this right after you understand the problem:

"The brute force is checking every pair, which is O(n²). I think we can get to O(n) with a hash map storing values we've seen. Would you like me to code the O(n) version directly, or start with the brute force?"

This shows you know both, names complexity, and lets the interviewer steer. Many interviewers will say "go for the better one," and now you have their buy-in.

When optimizing first is the right call

• You see the optimal approach clearly and it is not much harder to code.
• Constraints make the brute force clearly unacceptable.
• The interviewer asked for the best approach up front.
• The brute force is so trivial that coding it adds little signal.

In these cases, state the brute force in one sentence for completeness, then go straight to the better version.

When to code the brute force first

• You are not sure the optimization is correct.
• The optimization is complex (tricky DP, careful pointer logic).
• You are nervous and need a win on the pad.
• The interviewer said "start with something that works."

A working baseline gives you a correctness reference. You can test your optimized version against it mentally.

When to stop optimizing

Optimization has diminishing returns. Stop and move to testing when:

• You have reached the complexity the constraints suggest.
• The interviewer seems satisfied ("Great, let's test it.").
• Further gains are constant-factor tweaks with less than 10 minutes left.
• You would have to rewrite large sections and risk breaking working code.

Then say:

"I think O(n log n) is the best we'll get here because we need sorted order. Let me test it on a few cases."

Testing and edge cases are part of the score. Do not trade them away for micro-optimizations.

Optimize in steps, out loud

When you do optimize, narrate the step, not just the final result:

1. Name the bottleneck: "The inner loop searches for the complement each time."
2. Name the tool: "A hash map can make that lookup constant time."
3. State the new complexity: "That brings it to O(n) time and O(n) space."
4. Name the tradeoff: "We're using extra memory to save time."

That four-part pattern works for most optimizations: sorting, hash maps, prefix sums, two pointers, heaps, memoization.

Common mistakes

• Spending 20 minutes searching for the optimal approach with nothing on the pad
• Coding brute force and declaring victory without mentioning a better approach
• Optimizing space when the interviewer cares about time, or vice versa
• Micro-optimizing (bit tricks, loop unrolling) instead of fixing the complexity class
• Breaking a working solution while optimizing without a way to verify
• Never asking the interviewer which they prefer

Practice drills

1. Constraint read. For ten problems, read only the constraints and guess the target complexity before reading the rest.
2. Two-version drill. Code brute force, then optimize, and compare time spent on each.
3. Talk-track repetition. Say the "brute force is X, I think we can get to Y, which would you like?" sentence on every practice problem for a week.
4. Stop rule. Practice ending optimization at a fixed time and switching to testing.

Soft practice note

Deciding when to optimize under a clock is a habit, not a fact you memorize. If you want a Chrome side panel to run timed sessions where you practice the brute-force-then-optimize talk track, Luna Interview is built for calm, structured practice. It is a rehearsal tool and not a way around interview rules.

Day-of checklist

• [ ] Ask about input size if constraints are missing
• [ ] State brute force and its complexity in one sentence
• [ ] Offer the optimized idea and ask which to code
• [ ] Code what you can finish and test
• [ ] Stop optimizing when constraints are met or time is short
• [ ] Narrate: bottleneck, tool, new complexity, tradeoff

The best candidates do not always code the optimal solution. They pick the right moment to optimize and explain why.

Rehearse with an AI interview copilot, then browse commonly reported interview questions.