Brute Force vs Optimal Solution Strategy
Fast recall
Quick revision
Core answer
Whether the candidate can balance correctness with optimization
Getting stuck for 10 minutes searching for the optimal solution instead of showing any progress
State the brute force with its Big-O complexity then say let me think about how to improve this while narrating the optimization process
Interview-ready guide
Interview answer
No, you shouldn't always try to give the optimal solution first.
The smarter strategy is to start with a brute-force solution that definitely works, then optimize from there. Here's why. If you spend ten minutes staring at the problem trying to find the perfect algorithm, you might run out of time with nothing to show.
But if you implement a simple brute-force version in three or four minutes, at least you have a working solution. Interviewers value that because it shows you can actually solve problems, not just theorize about them. So what I do is say okay, the straightforward way to do this is to check every pair with nested loops.
That'll be O of n-squared time. Let me code that up first. Then I write it, test it on the example, and confirm it works.
After that, I say this works but it's slow for large inputs. Let me think about how to optimize it. Often, the act of writing the brute-force helps me see the pattern.
For example, if I'm checking every pair to find two numbers that sum to a target, I realize I'm doing a lot of redundant lookups. That makes me think wait, I could use a HashMap to store numbers I've seen, and then I only need one loop. Boom, now I've gone from O of n-squared to O of n.
The interviewer sees my thought process—I didn't just magically know the optimal solution, I reasoned my way there. One mistake freshers make is thinking that saying I'll do it the slow way first makes them look bad. Actually, it makes you look practical and engineering-minded.
In real jobs, you often ship a simple version first then optimize based on profiling. That's exactly what you're doing in the interview. Another mistake is not stating the complexity of your brute-force.
Always say this is O of n-squared because we have nested loops. That shows you understand algorithmic analysis, even if the solution itself isn't fancy.
Brute Force vs Optimal Solution Strategy
Direct Answer
No. Start with a brute-force solution to prove you can solve the problem correctly, then iteratively optimize. Mentioning the brute-force time complexity and explaining why you want to improve it shows analytical thinking.
Code Example
// Problem: Find indices of two numbers that add up to target
// Input: nums = [2, 7, 11, 15], target = 9
// Output: [0, 1] because nums[0] + nums[1] = 2 + 7 = 9
import java.util.*;
public class TwoSumSolver {
// Brute force: check every pair - O(n^2) time, O(1) space
public int[] twoSumBruteForce(int[] nums, int target) {
for (int i = 0; i < nums.length; i++) {
for (int j = i + 1; j < nums.length; j++) {
if (nums[i] + nums[j] == target) {
return new int[]{i, j};
}
}
}
return new int[]{}; // not found
}
// Optimized: use HashMap to avoid nested loop - O(n) time, O(n) space
public int[] twoSumOptimized(int[] nums, int target) {
var seen = new HashMap<Integer, Integer>(); // value -> index
for (int i = 0; i < nums.length; i++) {
int complement = target - nums[i];
if (seen.containsKey(complement)) {
return new int[]{seen.get(complement), i};
}
seen.put(nums[i], i); // store for future lookups
}
return new int[]{};
}
}
Common Mistakes & Pitfalls
- Spending 10+ minutes silent trying to find the optimal solution: Interviewers can't read your mind. If you're stuck, say I'm thinking through approaches and start coding the brute-force while you think. Progress is visible even if it's not optimal.
- Implementing brute-force without stating its complexity: Always say this is O of n-squared time because we check every pair. This shows you understand the inefficiency and didn't just stumble into it.
- Giving up after brute-force: Don't just stop there. Even if you can't implement the optimization in the remaining time, verbally explain how you'd improve it. Say I'd use a HashMap to store complements which would bring it down to O of n.
Check your understanding
Answer these without looking back at the article.
- How do you decide when your brute-force solution is good enough to present?
- What is the typical time complexity improvement you aim for when optimizing?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.