Why “more problems” isn’t always the answer

A lot of candidates grind dozens (or hundreds) of problems—then freeze when the interviewer changes one constraint. The goal isn’t to memorize solutions; it’s to build a repeatable problem-solving loop you can apply under pressure.

The 5-step loop interviewers actually want to see

Use this structure for every coding question, even easy ones:

1. Clarify requirements (30–60 seconds)
   Ask about input sizes, edge cases, and constraints.

   • Are inputs sorted? Can there be duplicates?
   • What’s the expected time/space complexity?
   • Any constraints like streaming data or memory limits?

2. State a baseline solution
   Give the simplest correct approach first (even if it’s O(n²)). This shows correctness and creates a bridge to optimization.

3. Optimize with a named technique
   Explicitly say what you’re using:

   • Hash map for counting / fast lookups
   • Two pointers for sorted arrays or “closest” problems
   • Sliding window for subarray/substring constraints
   • BFS/DFS for graph traversal and connectivity
   • Binary search for monotonic conditions (not just sorted arrays)

4. Talk through complexity and tradeoffs
   Mention Big-O and why the approach fits the constraints. If there’s an alternate solution, say when you’d pick it.

5. Test like a professional
   Before running anything, walk through:

   • A normal case
   • A smallest edge case (empty, 1 element)
   • A tricky case (duplicates, negatives, large values)

Communication tips that consistently raise scores

Even strong coders lose points for silence or messy structure.

• Narrate intent before typing: “I’m going to build a frequency map first…”
• Use meaningful variable names: left, right, freq, visited, inDegree
• Checkpoint often: After each block, confirm: “At this point, we’ve ensured…”
• If stuck, verbalize options: Interviewers reward structured thinking more than perfect speed.

Practice smarter: fewer problems, deeper review

Instead of 50 random problems, do 15–20 with deliberate review:

• After solving, write a 3-bullet summary:
  • Pattern used
  • Key invariant (what must remain true)
  • Common bug/edge case
• Re-solve the same problem 48 hours later without notes.
• If you needed hints, tag it and revisit weekly.

Quick self-check before your next interview

Pick one recent problem you solved and ask yourself:

• Could I explain why this technique applies?
• Could I derive it again if the prompt changed slightly?
• Could I test it confidently without running code?

What’s one interview problem you’ve solved before—but struggled to explain clearly—and what part of the explanation broke down (constraints, approach, or edge cases)?