Technical interviews reward clear thinking under uncertainty, not perfect recall. If you’ve ever frozen on a “simple” problem or solved it but couldn’t explain it well, you likely need a repeatable process—a problem-solving loop—that interviewers can trust.

The 5-Step Problem-Solving Loop (Use It Every Time)

1) Clarify the task (60–90 seconds)

Before touching code, confirm:

• Inputs/outputs (types, sizes, constraints)
• Edge cases (empty, null, duplicates, negative numbers)
• What “correct” means (e.g., “any solution” vs “lexicographically smallest”)

Tip: Ask, “What’s the max input size?” This directly guides complexity.

2) State a baseline approach (even if it’s slow)

Offer a straightforward solution first:

• Brute force, sorting, scanning, etc.
• Mention time/space complexity

This shows you can deliver correctness, then optimize. Interviewers often prefer this over jumping into a complex idea with no scaffolding.

3) Identify the bottleneck and choose a pattern

Common patterns to reach for:

• Hash map / set for membership & counts
• Two pointers / sliding window for subarrays/strings
• BFS/DFS for graphs/trees
• Heap for “top K” / streaming
• Binary search for monotonic conditions

Insight: Narrate your choice: “We need fast lookup, so a hash map reduces this from O(n²) to O(n).”

4) Write code in “interview-friendly” chunks

Avoid dumping the full solution at once. Instead:

• Outline function signature + high-level steps in comments
• Implement core loop first
• Add helper functions if they simplify reasoning

Make invariants explicit (especially with pointers/windows):

• What does the window represent?
• What is always true before/after each iteration?

5) Validate with targeted tests

Talk through 2–3 tests:

• A happy path
• A boundary case
• A tricky case (duplicates, multiple optimal answers, etc.)

Then restate complexity and any tradeoffs.

A Mini “Talk Track” You Can Practice

• “Let me restate the problem to ensure I understand…”
• “A baseline solution would be…, which is O(…). We can do better by…”
• “I’m choosing X because it optimizes Y under these constraints…”
• “Let’s sanity-check with an example…”

If you practice this loop out loud, you’ll sound more senior and composed—even when you’re unsure.

Quick challenge

Pick your last missed question and ask: Which step did you skip? (Clarifying? Baseline? Bottleneck? Validation?) Fixing that step usually fixes the outcome.

What part of the loop is hardest for you during live coding—and why?