How Do You Actually Approach a New DSA Problem?

In Google, Amazon, and Meta coding rounds, you often get a problem you haven't seen before. What separates candidates isn't just whether they know the trick — it's whether they have a clear process: clarify the problem, explore approaches, optimize, then code. This post gives you that process so you can apply it to any DSA question and pair it with DSA topics and mock interviews.

1. Clarify the problem (2–3 minutes)

Before writing a single line, make sure you and the interviewer agree on the problem. Ask about inputs (types, size, range), outputs (format, single vs multiple answers), and edge cases (empty input, one element, duplicates, negatives). Example: "Can the array be empty? Are numbers always non-negative? Should I return the indices or the values?" This shows you think in terms of contracts and avoids solving the wrong problem. Companies like Uber and Netflix value this clarity; our company interview guides often note how much interviewers care about requirement-gathering.

2. Talk through a brute-force solution

State the simplest approach that works: e.g. try every pair, check every subarray, or recurse without memoization. Say the time and space complexity. This gives you a correct baseline and shows you can reason about complexity. Many candidates skip this and jump to the optimal idea; if that idea is wrong, they have nothing to fall back on. A brute force that you can code quickly is better than a half-explained "optimal" solution. If you've practiced pattern-based lists, you'll often spot the optimization while describing brute force.

3. Optimize: look for patterns and trade-offs

Ask yourself: repeated work? → caching or DP. Sorted data? → binary search. Contiguous subarray? → sliding window or prefix sum. All combinations? → backtracking. Name the pattern and explain why it fits. Discuss time/space trade-offs (e.g. hash map for O(n) time but O(n) space). If you don't see the optimal solution immediately, it's fine to say "I could improve this by…" and iterate. Interviewers at Google and Amazon care more about clear reasoning than instant perfection.

4. Code cleanly and talk as you go

Write readable code: meaningful variable names, small functions if the problem allows. Think out loud: "I'll use two pointers here because…" Avoid long silences. If you hit a bug, trace through a small example instead of randomly changing code. If you need to simplify (e.g. assume input is non-empty to save time), say so. Practice this flow in AI mock interviews so talking while coding feels natural.

5. Test with an example and edge cases

Walk through your solution with the example the interviewer gave (or one you made up). Then mention or quickly check edge cases: empty input, single element, duplicates. Fix any issue you find. This step is often rushed, but it catches off-by-one errors and shows you care about correctness. For more on what topics to prioritize, see our DSA interview questions guide and only DSA resources you need.

Why This Order Matters

Clarifying first prevents you from building the wrong solution — a common failure at Microsoft, Apple, and other companies that value precision. Brute force next gives you a fallback and demonstrates complexity reasoning; interviewers would rather see a working O(n²) solution than a broken "optimal" attempt. Optimizing before coding forces you to name patterns (e.g. from your problem list) and discuss trade-offs, which is what senior engineers do. Coding after that is just implementation. Testing last catches bugs before the interviewer does. If you skip steps — e.g. code before clarifying — you risk wasting half the interview. Our company interview guides for Bloomberg, Salesforce, and others often note that interviewers score communication and process as much as the final code.

Quick Example: Applying the Framework

Suppose the problem is "find two numbers in a sorted array that sum to target." Clarify: Is the array always sorted? Can there be duplicates? One solution or all pairs? Brute force: Two nested loops, check every pair — O(n²). Optimize: Sorted array suggests two pointers from both ends; move left or right based on sum vs target — O(n). Code: Implement two pointers, then test with [1,2,3,4], target 6, and edge case (two elements, no solution). This same flow works for arrays, two pointers, sliding window, and most DSA questions. Practice it on every problem from NeetCode 150 or Blind 75, and run through it in AI mock interviews so it becomes automatic under pressure.

Common Pitfalls and How to Avoid Them

Silence: Long pauses make interviewers wonder if you're stuck. Keep talking — "I'm considering whether we need a hash map here…" — even when thinking. Jumping to code: Resist the urge to start typing before you have a clear approach; interviewers at Google and Amazon explicitly look for structured thinking. Ignoring edge cases: Always mention empty input, single element, duplicates, or negative numbers when clarifying and when testing. Giving up too early: If you don't see the optimal solution, state brute force and then iterate; partial progress plus clear reasoning often still gets a strong score. Practice under timed conditions with mock interviews and use our FAANG interview prep and company-specific guides to know what each company emphasizes.

Bottom line

Use the same framework every time: clarify → brute force → optimize → code → test. Communicate at each step. You don't need to know every problem; you need a consistent process and enough pattern practice (e.g. from NeetCode 150 or Blind 75) to recognize optimizations. When you're ready, try an AI mock interview to rehearse this approach in a realistic setting.