Brute Force First: A Coding Interview Strategy That Works

Published 2026-09-25 · Luna Interview

Many candidates treat brute force like a confession of weakness. Interviewers often treat it like a green flag. A brute-force-first coding interview strategy gets correct structure on the board quickly, proves you understand the problem, and creates a clean runway to optimize—without the freeze that comes from hunting a remembered editorial in silence.

Why brute force first works

Live rounds grade process under time. Optimal-from-second-zero fails when:

You misremember the trick
Constraints did not require the trick
You cannot explain the clever version
You blank and have nothing running

Brute force first gives you:

A correct mental model
Visible progress
A baseline complexity to improve
Something to dry-run while you think

Senior signal: “Here’s the clear O(n²). Given n, I’ll move to O(n log n) next.”

Junior signal: silent struggle for an O(n) trick that never lands.

The strategy in five steps

1. Clarify until the goal is crisp

Constraints decide whether brute force is acceptable. Ask bounds on n, value ranges, and edge behavior before you commit.

2. State the brute plan out loud and on the pad

Two lines max:

Brute: for each i, scan remainder / recompute
Correct; time O(n²); space O(1) or O(n) if copying

If you cannot state a correct brute force, you do not understand the problem yet—keep clarifying or walk an example longer.

3. Implement the clear version (or a clear sketch)

Depending on time:

Full implement when n is small or the brute is short
Sketch + complexity when the brute is obviously too slow but proves correctness, then jump to optimize with interviewer buy-in

Say which path you are taking.

4. Call the bottleneck explicitly

“The inner scan repeats work. I can precompute / use a map / maintain a window to remove it.”

Name the repeated work. Optimization without a named bottleneck sounds like guessing.

5. Optimize on purpose, then dry-run

Change one thing at a time. After the better version, walk three cases before “done.”

Talk tracks that land well

Permission to start simple:

“I’ll start with a correct brute force so we share the same model, then optimize for the constraints.”

When constraints kill brute force:

“O(n²) won’t fly for n=10^5. I’ll outline brute for correctness, then implement the O(n log n) version.”

When time is nearly up:

“I have a correct O(n²). If we have two minutes I’ll sketch the heap approach and its complexity.”

Partial credit with clear tradeoffs beats a half-typed clever idea.

Patterns where brute → better is the whole interview

Family	Brute	Typical upgrade
Subarray / substring	Nested scan	Sliding window / prefix
Top-k	Sort all each time	Heap / count + sort
Pair sums	Nested loops	Sort + two pointers / hash
Path existence	DFS retry from scratch	BFS / visited set
Duplicates	Compare all pairs	Sort or hash set

Practice saying the upgrade sentence before you code it.

Mistakes that make “brute first” fail

Spending fifteen minutes coding a brute you already know is impossible for the given n, without saying so
Never naming complexity
Optimizing without a dry-run of the brute mental model (you “optimize” into a wrong idea)
Being apologetic: “sorry this is dumb…”—drop the apology; keep the plan
Skipping clarifying questions so your brute solves the wrong problem efficiently

How this interacts with freeze recovery

If you blank, brute force is often the smallest next step:

Narrate last understanding
Restate goal
“Smallest step: write the O(n²) plan”
Put it on the pad

You are no longer blank. You are executing a strategy interviewers recognize.

Practice plan (one week)

Day	Focus
Mon	Medium: force full brute implement, then upgrade
Tue	Medium: outline-only brute + full optimal (time-box 8 minutes for outline)
Wed	Same in company tool (CoderPad / shared doc)
Thu	Review bottlenecks catalog (table above)
Fri	Timed mock: must say a brute→better sentence out loud

Score yourself on whether the brute was correct and whether the bottleneck was named.

Soft tooling note (practice only)

If you want a Chrome side panel beside your question and pad while you rehearse brute→better under a timer with narration, Luna Interview is built for that practice loop. Use it for structured practice and calm under pressure—not as a substitute for knowing the material or for anything that violates interview rules.

FAQ

Will they think I’m junior if I start with brute force?

Not if you call complexity and constraints. They think you’re junior if you only have brute force and cannot discuss improvements—or if you thrash silently for an optimal you cannot explain.

What if the only intended solution is a specific trick?

Outline brute, name why it fails constraints, then move to the intended approach. You still showed understanding. Many interviewers prefer that path to a memorized trick with no model.

Should I always code the full brute?

No. Use judgment. Tiny n → code it. Huge n → outline and upgrade. Always make the choice explicit.

Bottom line

Brute force first is not laziness. It is a coding interview strategy: correct model, visible progress, named bottleneck, intentional optimize, dry-run. Practice saying the sentences until they are boring. Boring tradeoff talk is what strong rounds sound like.

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