Technical interviews reward clear thinking under constraints, not just pattern recall. If you’ve ever solved a problem at home but froze in a live setting, you likely need a repeatable process—a “playbook” you can run even when you’re nervous.

A 10-Minute Playbook You Can Use in Any Coding Interview

1) Restate the problem + clarify constraints (1–2 minutes)

Before touching code, align with the interviewer.

• Inputs/outputs: types, sizes, format
• Constraints: n up to? values range? duplicates? negative numbers?
• Edge cases: empty input, single element, extreme values
• Success criteria: optimize for time, memory, readability?

Tip: Say what you’re doing: “I’m going to confirm constraints so I don’t over/under-optimize.”

2) Talk through a brute force baseline (1 minute)

Even if it’s not optimal, propose a simple approach.

• Helps you demonstrate understanding
• Gives you a fallback if time runs short
• Sets up the optimization story (“We can do better by…”)

3) Identify the core pattern (2 minutes)

Ask yourself: what is the problem really about?

Common signals:

• “Subarray/substring + max/min” → sliding window / prefix sums
• “Nearest greater/smaller” → monotonic stack
• “Shortest path / fewest steps” → BFS
• “Optimal decisions” → DP / greedy with proof
• “Repeated queries” → preprocessing, hashing, indexing

Tip: If you’re unsure, list 2–3 candidate patterns and rule them out based on constraints.

4) Commit to an approach with complexity (1 minute)

State:

• Time complexity: e.g., O(n log n)
• Space complexity: e.g., O(n)
• Why it fits constraints

Interviewers love hearing you choose intentionally rather than wander.

5) Code in “checkpoints” (3–4 minutes)

Write your solution in small, verifiable chunks:

• Function signature + helper structures
• Main loop with invariants (what stays true each iteration?)
• Carefully handle edge cases

Narrate tradeoffs as you code: readability vs. micro-optimizations.

6) Test like a pro (1–2 minutes)

Run through:

• A normal case
• A tricky edge case
• A case that stresses constraints (large n, duplicates, etc.)

Then ask: “Any additional cases you’d like me to validate?”

Two interview behaviors that instantly raise your signal

• Think aloud, but stay structured: use headings in your speech (“Now I’ll confirm constraints…”)
• Invite collaboration: “Would you prefer I optimize now or after we confirm the baseline?”

What’s the hardest part for you in technical interviews: finding the right pattern, staying calm under pressure, or explaining your thinking clearly while coding?