Technical interviews can feel random—until you start treating them like a skill you can execute on demand. Whether it’s a phone screen, live-coding round, or pair programming session, a simple framework helps you stay calm, communicate clearly, and earn points even when you don’t finish.

The 4-Phase Framework (Use This Every Time)

1) Clarify the problem (2–3 minutes)

Before writing code, earn easy credibility.

• Restate the problem in your own words.
• Ask about input constraints (size, range, sorted? duplicates?).
• Confirm expected output and edge cases.
• If anything is ambiguous, propose assumptions and get agreement.

Pro tip: If you feel stuck later, interviewers often remember you clarified well.

2) Plan out loud (3–5 minutes)

Treat this like you’re pairing with a teammate.

• Start with a baseline approach (even if slow) to show direction.
• Then improve: “This is O(n²); we can do better using a hash map to get O(n).”
• Mention tradeoffs: time vs space, simplicity vs performance.

Actionable habit: Always say the complexity before coding: “This should be O(n) time, O(n) space.”

3) Code with checkpoints

When you jump straight into code, you risk silent mistakes.

• Write small sections and do micro-tests: “If input is [..], this variable becomes …”
• Use descriptive names and keep functions short.
• If you hit a bug, narrate your debugging steps:
  • “Let me print/inspect this value.”
  • “I think the issue is an off-by-one in the loop boundary.”

Live-coding tip: If you’re unsure about a detail (like API syntax), say so and propose a workaround: “I’ll write helper logic; we can adjust syntax after.”

4) Verify and extend (2–4 minutes)

Finishing early is great; finishing correctly is better.

• Run through edge cases: empty input, single element, max size.
• Discuss improvements: streaming inputs, memory constraints, alternate data structures.
• If it’s system-facing, mention reliability: timeouts, retries, graceful failures.

Common Mistakes (and Quick Fixes)

• Mistake: Going silent while thinking.
  Fix: Share your hypothesis and what you’re testing.
• Mistake: Over-optimizing immediately.
  Fix: Baseline first, then optimize.
• Mistake: Not handling constraints.
  Fix: Ask early; constraints often determine the whole solution.

Practice Challenge (5 minutes/day)

Pick one problem you’ve solved before and rehearse:

1. your clarification questions,
2. your plan,
3. complexity,
4. two edge cases.

It’s surprising how much confidence this builds.

What phase do you struggle with most—clarifying, planning, coding, or verifying—and what’s a recent example where you got stuck?