Technical interviews rarely fail because you “don’t know the answer.” More often, they fail because your process isn’t visible—or you get stuck and don’t recover. Here’s a practical framework you can use for almost any problem (arrays, strings, graphs, DP, you name it) to stay structured, communicate clearly, and earn points even before the final code works.

The 5-Step “Visible Thinking” Framework

1) Restate + Clarify (60–90 seconds)

Before touching code, confirm the goal and eliminate ambiguity.

• Restate the problem in your own words
• Ask 2–4 targeted questions:
  • Input size constraints? (e.g., n <= 1e5 changes everything)
  • Are inputs sorted? Duplicates? Negative values?
  • Expected output format? Tie-breaking rules?

Tip: If constraints aren’t provided, propose them: “If n can be large, I’ll aim for O(n log n) or better.”

2) Examples + Edge Cases (2–3 minutes)

Walk through a simple case and a “nasty” case.

• Minimal input (empty, length 1)
• All same values / all unique values
• Large values, negative values, overflow concerns
• Off-by-one traps (inclusive ranges, indices)

Why it matters: Interviewers often award points for catching edge cases early—even if the final implementation has minor bugs.

3) Choose an Approach (and say why)

Give 1–2 solution options, then pick one:

• Naive baseline to show correctness thinking
• Improved approach with time/space tradeoffs

Use clear language:

• “Brute force is O(n²). If n is big, we need O(n). A hash map gives us that at the cost of O(n) space.”

4) Implement in “Interview-Friendly” Chunks

Write code in logical blocks with micro-checkpoints.

• Start with function signature and helper structures
• Build the main loop
• Add edge case handling
• Only then optimize/refactor

Live-coding tip: Narrate intent: “I’m initializing a map to store last seen index, so we can compute window length in O(1).”

5) Test Out Loud + Debug Like a Scientist

Use 2–3 test cases and trace key variables.

• “Let’s run nums = [2,7,11,15], target=9…”
• If something fails: isolate, hypothesize, validate

Recovery line: “I see the bug: I’m updating the pointer too late. I’ll move this line before the calculation.”

A Quick Self-Check (before you hit ‘Run’)

• Did I state time/space complexity?
• Did I cover at least 2 edge cases?
• Can I explain the approach in one sentence?

What’s the step you struggle with most in real interviews—clarifying questions, choosing the approach, or debugging under pressure?