Coding Interview Patterns
The Interview Problem-Solving Method
A repeatable process — clarify, work an example, state the brute force, look for a pattern, code while narrating, then test — turns an ambiguous prompt into a working, defensible solution under time pressure.
- Clarify constraints and edge cases before coding: input size, duplicates allowed, negative numbers, empty input — assumptions stated out loud are assumptions the interviewer can correct early, cheaply
- Work a small example by hand first — it builds the intuition that later reveals the pattern, and gives you a concrete case to trace through once code exists
- State the brute-force solution and its complexity explicitly, even if you'll optimize past it — it's both a correctness baseline and a fallback if time runs out
- Look for a recognizable shape — Two Pointers And Sliding Window, Heap Top K Pattern, Backtracking Templates — to move from brute force to an efficient solution
- Narrate trade-offs while coding, and test against the worked example plus at least one edge case before declaring done — interviewers are grading the process at least as much as the final answer
| Input size n | Complexity that likely fits the time limit |
|---|---|
| n ≤ ~20 | O(2ⁿ) or O(n!) — exhaustive search, backtracking |
| n ≤ ~500 | O(n³) |
| n ≤ ~10,000 | O(n²) |
| n ≤ ~10⁶ | O(n log n) or O(n) |
| n ≤ ~10⁹ or a stream | O(log n) or O(1) — binary search, math, streaming |