How to Approach a Coding Problem You've Never Seen Before
TL;DR
- A repeatable 5-step process works for most unfamiliar coding problems: read carefully, work examples by hand, identify constraints and edge cases, find the brute force, then look for patterns to improve it.
- Start with the brute force. Always. It's not admitting defeat. It's building a foundation.
- Working through small examples by hand is the single most reliable technique for getting unstuck.
- Recognizing a problem as a variant of something familiar is a skill you build through volume, not insight.
- The process is the performance. Interviewers are evaluating how you approach the problem, not just whether you solve it.
Every coding interview contains at least one problem you haven't seen before. That's the point. If you'd memorized the exact solution, the interview wouldn't tell the interviewer much about how you actually think.
The candidates who do well in these situations don't have a larger bank of memorized solutions. They have a more reliable process for making progress when a problem is unfamiliar. That process is learnable and transferable across problem types.
Here's the one that works.
Step 1: Read the Problem Carefully and Restate It
Before you do anything else, read the problem slowly. Then close it (or scroll away from it) and restate it in your own words out loud.
This sounds almost too simple to bother with, but it catches a surprising number of problems before they become expensive mistakes. Many candidates read a problem, think they understand it, and start coding only to realize 10 minutes in that they solved a different problem.
When you restate the problem, say things like: - "So I'm given an array of integers and I need to find..." - "The input is a string, and I need to return..." - "I need to return the maximum value of X such that Y is satisfied."
After you restate it, the interviewer will either confirm or correct you. That correction at the beginning of an interview costs you almost nothing. The same correction 10 minutes in, after you've built a solution to the wrong problem, costs you the interview.
Also note during this step: what is the input format? What is the expected output? Are there constraints given (the array will have at most 10,000 elements, values are between 0 and 100)?
Step 2: Work Through 2-3 Examples by Hand
After you understand the problem, don't think abstractly. Get concrete.
Take the example input the interviewer gave you and trace through it step by step. Write down intermediate values. Don't do this in your head. Put it on paper, a whiteboard, or type it out next to the problem.
Then make your own example. Ideally a small one: 3-4 elements in an array, a string of 5 characters, a tree with 4-5 nodes. Trace through that too.
Why this works: abstract reasoning about algorithms is hard. Concrete examples make patterns visible. The step you repeat twice or the operation that seems to "reset" every time you hit a certain condition. Those are the structural features that suggest an algorithmic approach.
You are looking for: what changes as you step through the input? What stays the same? What's the rule that determines when you stop?
If the examples the interviewer gave you are trivial or small, ask for a larger one. Or construct one yourself. "Let me try with a larger example to make sure I understand the pattern." Interviewers view this as thoroughness, not stalling.
Step 3: Identify Constraints and Edge Cases
Before you commit to any approach, identify the hard constraints and edge cases.
Hard constraints are facts about the input that limit your options: - The array is sorted. (This opens the door to binary search and two pointers.) - Values are unique. (No need to handle duplicates.) - n can be up to 10^6. (An O(n²) solution will be too slow.) - The tree is balanced. (Recursion depth is bounded.)
Edge cases are inputs that could break naive solutions: - Empty array or empty string - Single element - All elements identical - Maximum possible input size - Negative numbers or zero (if those are possible) - A case where no valid answer exists
Edge cases matter during development because they often expose the flaw in an otherwise correct-looking approach. They matter during the interview because handling them explicitly shows the interviewer that you think carefully about correctness, not just the happy path.
You don't need to solve every edge case before you start coding. You need to identify them. Then you can make a plan: "I'll handle the base cases first, then write the main logic, then test against edge cases."
Step 4: Find the Brute Force Solution First
This is the most consistently underused technique in coding interview preparation.
When you see a problem you don't immediately recognize, the right first move is almost always to find the solution that definitely works, even if it's inefficient. Write it. Make it correct. Then improve it.
Here's why this matters.
First, the brute force is almost always easy to see. If the problem asks you to find a pair in an array that sums to a target, the brute force is check every pair. Two nested loops. O(n²). You can probably write that in 3 minutes.
Second, the brute force gives you a correctness baseline. Once you have a working brute force, you have something you can test against when you write a more efficient version. If both produce the same output on your examples, you have reasonable confidence the optimized version is correct.
Third, talking about the brute force shows the interviewer that you can identify a starting point, even if it's not optimal. "The brute force is O(n²) and I think we can do better. Let me think about why the brute force is slow." That's a strong opening move.
Some candidates resist starting with the brute force because it feels like admitting they don't know the "right" answer. Set that aside. Interviewers want to see your process. The brute force is part of the process.
If you're pressed for time and the optimal solution is eluding you, a working brute force is better than an attempted optimal solution that doesn't work.
In live coding interviews, narrating the brute force is particularly useful because it gives you and the interviewer a shared foundation before you try to optimize.
Step 5: Look for Patterns That Suggest a Better Approach
Now that you have a working brute force, analyze why it's slow and look for patterns that point toward something better.
This is where pattern recognition from past problems pays off. Not because you memorized solutions, but because you've seen enough problems to recognize shapes.
Common signals to look for:
The array is sorted (or can be sorted). Binary search or two pointers might apply. Sorting first and then doing linear work is often better than quadratic brute force.
You're repeatedly looking up whether something exists. A hash map or hash set turns O(n) lookups into O(1). If you have a nested loop where the inner loop is searching, you can often replace the inner loop with a single hash map lookup.
You're computing the same subproblem multiple times. That's the signal for dynamic programming or memoization. The brute force recursive solution that re-explores the same branches over and over becomes much faster when you cache results.
You're looking for the maximum or minimum subarray, substring, or subrange. Sliding window often applies.
The problem involves trees or graphs and asks about paths or reachability. BFS or DFS.
You're making choices that look locally optimal. Greedy approaches might work (though they need to be verified carefully).
If you've practiced with the common algorithmic patterns, these signals become easier to recognize. The patterns aren't magic. They're a vocabulary for categorizing what kind of problem you're looking at.
What to say when you're looking for patterns: "The brute force is O(n²) because I'm scanning the full array for each element. If I could avoid that inner scan, I'd get this down to O(n). One way to avoid linear scans is to pre-process the array into a hash map. Let me see if that's possible here."
That narration is better than silence and better than staring at the problem hoping inspiration arrives.
How to Handle a Problem That Doesn't Match Anything You've Seen
Sometimes you've done steps 1-5 and you still don't see the path to an optimal solution. This happens.
A few moves from here:
Simplify. What if the input had only 1 element? What if it had 2? What's the smallest non-trivial case? Understanding tiny cases sometimes reveals the structure of the general case.
Change representation. Can you represent the problem differently? If the input is a string, would it help to think of it as an array of characters? If the input is a list of pairs, would a graph representation help?
Work backwards. What does a valid output look like? What properties does it have? Can you construct it from those properties?
Ask for a hint. This is always available to you in a live interview. "I've tried a few approaches and I'm not seeing the path. Is there a hint you can give me about the general direction?" Most interviewers will give you something. That's not failing. That's using the resources available to you. Handling the moment when you don't know the answer covers this in more detail.
Why "Recognizing Variants" Is a Built Skill
Experienced engineers can often look at a new problem and immediately see that it's structurally similar to a problem they've solved before. "Oh, this is basically the sliding window maximum problem with an extra constraint." That recognition feels like intuition, but it's built from volume.
The way to build it:
When you solve a problem during practice, don't just move on. Ask: what was the key insight? What made this problem fall into the category it fell into? What were the signals that pointed toward this approach?
When you encounter a hard problem, after you've seen the solution, look at 2-3 variations of that problem. Same underlying structure, different surface details. Seeing the same pattern in multiple forms is what builds recognition.
You're not trying to memorize solutions. You're trying to build a map of problem shapes so that when you see a new problem, you can orient yourself: "This feels like a graph reachability problem. Let me see if BFS is appropriate here."
This is also why the Big O analysis becomes part of your pattern recognition. Knowing the typical complexity of your brute force tells you something about what improvements are possible. If you have O(n²) and there's an O(n) solution, you're probably replacing a scan with a lookup, which points toward hash maps. That's not a random insight. It's a pattern.
Putting It Together
The five steps: 1. Read carefully and restate the problem in your own words. 2. Work through 2-3 concrete examples by hand. 3. Identify constraints and edge cases before committing to an approach. 4. Find and articulate the brute force solution. 5. Analyze the brute force for inefficiencies and look for patterns that suggest improvements.
This process doesn't guarantee you'll solve every problem. No process does. What it guarantees is that you'll make systematic progress, communicate clearly, and give the interviewer the evidence they need to evaluate your thinking.
In an interview, the process is the performance. You might not reach the optimal solution in 45 minutes. But if you've shown systematic thinking, honest communication, and the ability to make progress on an unfamiliar problem, you've demonstrated the skills that actually matter in engineering work.
If you want structured practice applying this process, here's how the Globally Scoped program works.
Interested in the program?