Technical interviews can feel less like a test of skill and more like a test of composure. The good news: you can practice recovery. Here’s a practical playbook for what to do when you get stuck—without spiraling.

Why “getting stuck” isn’t a deal-breaker

Most interviewers don’t expect perfection. They’re watching for:

• How you reason under uncertainty
• How you communicate tradeoffs
• Whether you can make progress with constraints

If you can demonstrate structured thinking, you can often turn a rough start into a strong performance.

The 60-second reset (use this the moment you feel stuck)

1. Restate the problem in your own words (and confirm edge cases).
2. Name the inputs/outputs + constraints (size limits, time, memory).
3. Write 1–2 small examples and trace expected output.

This creates momentum and reassures the interviewer you’re in control.

A step-by-step strategy to unblock yourself

1) Start with the “obvious” solution—on purpose

Even if it’s slow, propose a baseline:

• “Brute force would be… O(n²) because…”
• “This works but won’t scale if n is large.”

Why it helps: It anchors the conversation and gives you something to optimize.

2) Ask: “What’s repeated?”

Most optimizations come from spotting repetition:

• Recomputing subproblems → memoization / DP
• Re-scanning ranges → prefix sums / sliding window
• Searching repeatedly → hash maps / sets
• Matching ordering constraints → two pointers / sorting

3) Choose one invariant and say it out loud

Examples:

• “My window always contains unique characters.”
• “The stack is monotonic.”
• “left only moves forward.”

Interviewers love invariants because they signal correctness.

4) Narrate tradeoffs like an engineer

When deciding between approaches, explicitly compare:

• Time complexity (best/avg/worst if relevant)
• Space complexity
• Implementation risk (bugs, edge cases)

A simple phrase that works: “If constraints are small, I’d do X; if large, I’d do Y.”

Communication moves that help (and don’t annoy)

• Good: “I’m going to test my logic with a small input.”
• Good: “I’m stuck between two approaches—here’s the tradeoff.”
• Avoid: Long silent coding. If you need time, say: “Give me 20 seconds to think.”

Quick practice drill (10 minutes/day)

Pick any problem and rehearse:

1. 2-minute problem restatement + examples
2. 3-minute baseline solution
3. 3-minute optimization attempt
4. 2-minute complexity + edge-case review

Do this consistently and your “freeze moments” shrink fast.

What’s your go-to technique when you get stuck mid-interview—and what kind of problem triggers it most often (DP, graphs, system design, etc.)?