Technical interviews reward clear thinking under pressure, not perfect recall. If you’ve ever blanked on a “medium” problem you’d solved before, this post is for you. Here’s a repeatable framework you can apply to almost any coding question.

The 7-Step Interview Framework

1) Restate the problem (out loud)

Before you touch the keyboard, paraphrase the prompt and confirm constraints.

• “Input is an array of ints, output is an index pair?”
• “Are duplicates allowed?”
• “Should I return any pair or all pairs?”

Tip: This buys time and prevents solving the wrong problem.

2) Ask for constraints that change the approach

A single constraint often dictates the data structure.

• Size of n (1e3 vs 1e6)
• Memory limits
• Sorted vs unsorted
• Streaming vs batch

3) Walk through a tiny example

Pick a small input and narrate expected output.

• Use edge cases: empty input, single element, all duplicates
• Identify what “state” you need to track

4) Propose a brute-force baseline

Even if you won’t implement it, describe it.

• Shows you understand the problem
• Creates a stepping stone to optimize

5) Optimize using a known “lever”

Common levers:

• Hash map / set to trade memory for speed
• Two pointers for sorted arrays or “pair” style problems
• Sliding window for contiguous subarray constraints
• Heap for top-k and streaming
• BFS/DFS for graphs/trees with visitation state

Call out time/space complexity before coding: “This becomes O(n) time, O(n) space.”

6) Code in clean, testable chunks

While coding, narrate intent:

• “I’ll store seen values in a set.”
• “Now I’ll update the left pointer to restore the invariant.”

Mini-checklist:

• Clear variable names
• Avoid clever one-liners
• Handle edge cases early

7) Test like an engineer

Don’t just say “it works.” Actually run 2–3 tests verbally.

• Normal case
• Edge case
• Stress/constraint case

Common Mistakes (and quick fixes)

• Silence while thinking → Talk through options and tradeoffs.
• Jumping to the optimal solution too fast → Start with baseline, then optimize.
• Forgetting invariants (e.g., sliding window) → State the invariant explicitly.
• No complexity analysis → Make it a habit after every approach.

Quick practice prompt

Pick one problem you’re currently studying and try this structure verbatim. You’ll be surprised how much calmer you feel.

Which step do you struggle with most in real interviews—asking constraints, finding the optimization lever, or testing/debugging out loud?