Technical interviews can feel brutal—not because you don’t know the material, but because time pressure + ambiguity can scramble your thinking. The good news: you can train a repeatable process that keeps you moving even when you’re stuck.

The “4-Step Recovery Plan” (use this when you blank)

1) Restate the problem and lock requirements (60 seconds)

Before you write code, say back what you heard:

• Inputs/outputs, constraints, and edge cases
• Clarify assumptions (e.g., “Can the array be empty?” “Are values negative?”)
• Confirm goals (e.g., runtime/memory)

Tip: Treat this like a mini-contract. It prevents rework and buys you thinking time.

2) Pick a baseline solution first (even if it’s not optimal)

When nervous, people jump to the “best” approach and stall. Instead:

• Describe the simplest working solution (often brute force)
• Estimate complexity out loud
• Use it to discover patterns that lead to optimization

Why it works: Interviewers value momentum and reasoning. A correct baseline is a platform—not a failure.

3) Narrate your tradeoffs with a template

If you’re unsure which approach to take, use:

• Option A: (data structure/approach) → complexity + why it might fit
• Option B: alternative → complexity + when it’s better
• Decision: choose one based on constraints

Examples of common pivots:

• Sorting to enable two-pointers
• Hash map to trade memory for speed
• Stack for “previous greater/next smaller” patterns

4) Code in “checkpoints” and verify as you go

Avoid writing the entire solution before testing mentally.

• Start with function signature + helper stubs
• Implement core loop
• Add edge-case guards
• Run a tiny manual test (happy path)
• Run one edge case (empty, one element, duplicates)

Tip: If you realize a bug mid-way, say: “I’m going to pause and validate invariants.” That sounds confident and professional.

Micro-skills that separate strong candidates

• Talk in invariants: “At this point, the map stores counts for the current window.”
• Name variables for intent: left, right, freq, bestLen beats i, j, m, ans.
• Ask for permission to optimize: “I have an O(n²) version; want me to optimize to O(n)?”

A quick practice drill (10 minutes/day)

Pick one problem and practice only the process:

1. Restate + edge cases
2. Baseline solution
3. Optimal approach
4. Checkpoint coding plan (no full code needed)

This builds interview reflexes faster than grinding dozens of problems mindlessly.

Discussion: What’s your most common “freeze moment” in interviews—blanking on an algorithm, getting lost in edge cases, or struggling to explain your thinking—and what have you tried to fix it?