Technical interviews rarely reward perfect recall—they reward structured thinking, clear communication, and steady progress under uncertainty. Here’s a practical approach you can use in nearly every coding interview (and it works great for live mock interviews too).

1) Start with a 60-second “problem framing”

Before writing code, restate the problem in your own words and confirm constraints.

• Inputs/outputs: What types? What size?
• Constraints: Time/memory limits, sorted vs unsorted, duplicates, negatives?
• Edge cases: Empty input, one element, very large values.

Tip: Ask at least one clarifying question. It signals maturity and often prevents wasted time.

2) Make the interviewer your teammate (think out loud)

Silence reads like uncertainty. Narrate your intent:

• “I’m considering a hash map to track counts…”
• “This seems like a sliding window because we need a contiguous range…”
• “Let’s sanity-check complexity before coding.”

Tip: If you’re stuck, say what you do know (e.g., brute force baseline) and what you’re trying to optimize.

3) Always propose a baseline, then improve it

Even if you know the optimal solution, starting with a baseline shows judgment.

• Baseline approach: Often O(n²) or O(n log n)
• Optimization path: Identify the bottleneck and reduce it

Example language: “Brute force compares every pair (O(n²)). We can reduce repeated work by using a set for O(1) lookups, making it O(n).”

4) Use a repeatable “pattern checklist”

When you see a new problem, scan these common patterns:

• Hash map / set: fast membership, counts, complements
• Two pointers: sorted arrays, partitioning, pair sums
• Sliding window: subarray/substring constraints, “longest/shortest”
• BFS/DFS: graphs/trees, connected components, shortest path variants
• Heap: “top K,” streaming, merging

Tip: Name the pattern explicitly—interviewers love hearing your reasoning.

5) Code like you’re writing production (within reason)

Interview code doesn’t need full architecture, but it should be readable and safe.

• Use meaningful variable names
• Add 1–2 short comments for key logic
• Handle edge cases early
• Prefer small helper functions if it clarifies logic

6) Test with intention (not just one happy path)

Run through quick mental tests:

• Smallest case
• Typical case
• Tricky case (duplicates, negatives, boundaries)

Tip: Say out loud what you expect to happen; it demonstrates ownership and correctness thinking.

If you tried this approach recently: which step do you find hardest under time pressure—framing, choosing the pattern, or testing—and why?