Technical interviews can feel brutal because you’re being evaluated while thinking out loud. The good news: most “blanking” moments are predictable—and preventable—with a repeatable process. Here’s a simple 4-step game plan you can use in almost any coding interview.

1) Clarify the problem like a pro (2–3 minutes)

Before touching code, reduce ambiguity.

• Ask about input constraints (size, ranges, sorted? duplicates?)
• Confirm edge cases (empty input, single element, negatives, overflow)
• Restate the problem in your own words: “So we need to…”
• If allowed, propose a quick example and walk through expected output

Pro tip: Many candidates lose points by coding the wrong interpretation fast.

2) Pick an approach—and defend it

Interviewers want to see decision-making, not just syntax.

• Start with the simplest approach and state its complexity: “Brute force is O(n²)….”
• Then propose an improvement: “We can do O(n) using a hash map because….”
• Mention tradeoffs: time vs. space, readability, constraints

If you’re stuck, say what you’re considering:

• “This looks like a two-pointer pattern if the array is sorted.”
• “This resembles BFS shortest path on an unweighted graph.”

3) Write code in small, verifiable chunks

Avoid the “big-bang” solution that only compiles at the end.

• Start with a clean function signature
• Build helper functions if it clarifies logic
• Use meaningful variable names (e.g., left, right, freq, visited)
• Add a quick comment for the key invariant: “window contains at most k distinct…”

Tactical habit: After each major block, do a 10-second mental check—“Does this line match the plan I just explained?”

4) Test like an engineer (not a student)

Don’t just run the happy path—actively try to break your code.

• Walk through one normal case, one edge case, one stress-ish case
• Call out off-by-one risks (loops, boundaries)
• If time permits, discuss complexity and possible optimizations

Mini-script for when you freeze

Keep this in your back pocket:

1. “Let me restate the goal and constraints.”
2. “I’ll try a small example to see the pattern.”
3. “Brute force would be…, but we can improve by….”

This shows calm control—and often unlocks the next step.

Your turn

What part of the technical interview do you find hardest right now: clarifying, choosing the right pattern, writing bug-free code, or testing under pressure—and what’s one moment you wish you handled differently?