Technical interviews often don’t test whether you’re “smart enough”—they test whether you can think clearly under pressure while communicating your approach. Here’s a simple, repeatable structure you can use in live coding, whiteboard rounds, and technical assessments to stay calm and perform consistently.

1) Start with a 60-second problem framing

Before touching code, earn easy points by showing you’re methodical.

• Restate the problem in your own words (confirms alignment).
• Ask 2–3 clarifying questions:
  • Input constraints? (size, sortedness, duplicates)
  • Output expectations? (order, ties)
  • Edge cases? (empty input, negative numbers, overflow)
• State assumptions explicitly: “I’ll assume X unless you say otherwise.”

2) Talk through a baseline first (even if it’s not optimal)

Interviewers want to see reasoning, not magic. A quick baseline helps you:

• Show you understand the task
• Create a bridge to optimization
• Avoid long silent gaps

Example phrasing:

• “A straightforward approach would be O(n²) by… This will work but may be slow for large inputs. Let’s optimize.”

3) Choose the right data structure with a “why”

Many solutions become obvious once you name the tool.

Common patterns:

• Hash map / set → membership, counting, de-duplication
• Two pointers → sorted arrays, subarrays, partition-like problems
• Stack → “next greater”, parentheses, monotonic properties
• Heap → top-K, streaming data
• BFS/DFS → shortest path (unweighted), connectivity, grid problems

Tip: Say the tradeoff out loud: time vs. space, and what the constraints imply.

4) Write code in checkpoints (and narrate as you go)

Instead of attempting a perfect final solution, code in small verified steps:

• Define function signature
• Handle edge cases early
• Implement core loop/recursion
• Add helper functions if needed

Narration ideas:

• “I’m going to implement the loop first, then we’ll test with a small example.”

5) Test like an engineer (not like a gambler)

After coding, do a quick walk-through with 2–3 test cases:

• Happy path (normal input)
• Edge case (empty/single element)
• Stress-ish case (duplicates, extremes, large values)

If you find a bug, stay composed:

• “Good catch—this fails when __. I’ll adjust the condition and re-test.”

6) If you get stuck, use a “recovery script”

Stuck moments happen. What matters is how you recover.

• Re-anchor: “Let me restate what we need…”
• Narrow: “What if we solve a smaller version?”
• Probe: “Can I confirm constraints on…?”
• Fallback: “Here’s a correct baseline; now I’ll optimize.”

Quick challenge for the community

Pick one interview problem you recently struggled with. Which step above would have helped the most—and what would you say out loud in that moment to regain momentum?