Technical interviews can feel like a race to memorize patterns—but the strongest candidates rely on a repeatable problem-solving system. Here’s a practical framework you can use in live coding, whiteboards, and technical assessments to perform consistently (even on unfamiliar problems).

1) Start with a 60-second problem “restate + clarify”

Before writing code, earn trust by showing you understand the ask.

• Restate the problem in your own words (1–2 sentences).
• Ask 2–4 targeted clarifying questions:
  • What are the input constraints (n, value ranges)?
  • Are duplicates possible? Are inputs sorted?
  • What should happen with empty/invalid input?
  • What are the time/memory expectations?

Tip: If constraints are unknown, propose reasonable assumptions and confirm: “If n can be up to 1e5, we should avoid O(n²). Is that fair?”

2) Outline your approach before coding

Interviewers aren’t only grading correctness—they’re grading reasoning.

• Name the likely technique: two pointers, sliding window, BFS/DFS, heap, hashmap, DP.
• Give a quick complexity target: “This should be O(n) time with O(n) space.”
• Mention alternatives briefly: “A brute-force exists, but it’s O(n²).”

Tip: If you’re stuck, list candidate data structures and what they buy you (fast lookup, ordering, min/max, etc.).

3) Choose 1–2 examples and “dry run” your logic

Pick examples that expose edge cases:

• Minimum size input (empty, single element)
• Duplicates / repeated values
• Negative numbers / overflow possibilities
• Already sorted vs. unsorted

Write down (or say out loud) the evolving state: pointers, stack, queue, hashmap counts. This often reveals bugs before they happen.

4) Code in interview-friendly increments

Write clean, testable steps instead of a giant block of code.

• Implement the core loop first.
• Add helper functions only if they improve clarity.
• Use descriptive names (left, right, freq, visited).
• Narrate decisions: why this condition, why this data structure.

Tip: If you make a mistake, don’t panic—debug out loud. Interviewers value calm, methodical correction.

5) Finish strong: test + complexity + trade-offs

Before you hand it over:

• Run through 2–3 tests verbally (include an edge case).
• State time/space complexity.
• Mention a realistic improvement if constraints shift (e.g., streaming input, memory limits).

Quick self-check (use this every time)

• Did I clarify constraints?
• Did I explain an approach before coding?
• Did I test edge cases?
• Did I communicate trade-offs?

What part of the technical interview process do you find hardest right now—coming up with the approach, coding under pressure, or explaining your reasoning clearly?