Technical interviews are rarely about knowing everything—they’re about showing how you think under constraints. If you tend to freeze, ramble, or jump straight into code, try this repeatable approach that keeps you calm and makes your process easy to evaluate.

The 4-Phase Framework (Use This Every Time)

1) Clarify (60–90 seconds)

Before touching code, lock down the problem:

• Restate the prompt in your own words.
• Ask about input/output format, constraints, and edge cases.
• Confirm assumptions: “Are numbers negative?”, “Can the array be empty?”, “Is the input sorted?”

Pro tip: Interviewers often expect questions. Clarifying shows maturity, not weakness.

2) Plan (2–4 minutes)

Outline your approach out loud:

• Start with a baseline solution (even if not optimal).
• Then propose the optimized approach and why it’s better.
• Identify key tools: hash map, two pointers, BFS/DFS, heap, etc.

If you’re stuck, use this prompt: “What’s the simplest brute force, and what makes it slow?” That usually reveals the optimization.

3) Execute (Code in small checkpoints)

Write code in chunks you can reason about:

• Define helper functions early if needed.
• Use descriptive variable names and avoid clever one-liners.
• After each chunk, do a quick sanity check: “Does this handle empty input?”

Common pitfall: coding the entire solution then testing at the end. Instead, build progressively so bugs don’t compound.

4) Validate (Walk through + complexity)

Always do a quick dry run:

• Pick a normal case, then an edge case.
• State time/space complexity clearly: O(n) time, O(n) space, etc.

If you find a bug, narrate calmly: “I see the issue—here’s the fix and why.” Debugging is a signal of real engineering skill.

A Mini Script When You Feel Yourself Freezing

Use this exact sentence to buy time and reset:

“Let me confirm constraints and outline a straightforward approach before optimizing.”

It communicates control and gives your brain a structured next step.

Practice Ideas That Actually Transfer to Interviews

• Do timed problems (25–35 minutes) with a strict “talk out loud” rule.
• After solving, write a 5-line solution summary: approach, key insight, complexity, edge cases.
• Re-solve the same problem one week later—retention beats volume.

What part of the technical interview trips you up most—clarifying, coming up with the approach, writing bug-free code, or explaining complexity—and what’s one example problem where that happened?