The candidates who freeze in coding rounds usually don’t lack raw ability. They’ve just never internalized the two lookups every strong interviewer runs in their head automatically: what does this operation cost, and what shape of problem is this. Once those are reflexes, the interview stops being a memory test and becomes what it’s supposed to be, which is a conversation about tradeoffs.
This page is the second lookup: the decision procedure for going from a problem statement to the right pattern. It sits on top of the raw cost tables rather than repeating them, so bookmark it for the morning of an onsite and read it while you’re actually solving problems.
The operation costs, in one paragraph and one link
You need the growth term for the operations you’ll actually use, and you need to say average versus worst case out loud. Hash tables are O(1) average lookup and O(n) worst case when keys collide into one bucket. Balanced trees are O(log n) for ordered operations. Dynamic arrays append in O(1) amortized (the rare resize copies everything but averages out) and delete from the end in O(1), while inserting or deleting in the middle is O(n). Heaps push and pop in O(log n) and peek at the extreme in O(1). The classic wrong answer here is claiming a singly linked list deletes a known node in O(1): that’s a doubly-linked property, because a singly linked list still has to walk from the head to find the predecessor, so it’s O(n). The full operation-cost table lives in the Big-O table interviewers expect you to have memorized, and the wider reference is the Big-O cheat sheet. If the growth curves still feel abstract, watch them diverge at real input sizes before you rely on the intuition live.
The pattern-recognition table
Nine patterns account for the large majority of a standard coding loop. Recognizing the pattern is most of the work; the code is usually short once you’ve named it. The table below is the whole decision procedure in one place: the trigger to listen for, the structure it implies, the cost, and the problems to drill until each one is automatic.
| Pattern | Trigger phrase in the problem | Data structure it uses | Typical complexity | Canonical problems to drill |
|---|---|---|---|---|
| Two pointers | Sorted array; find a pair, triplet, or partition | The array itself, plus indices | O(n) | Two Sum II (sorted input), 3Sum, container with most water |
| Sliding window | Longest/shortest contiguous subarray or substring under a constraint | Array plus a hash map of window contents | O(n) | Longest substring without repeating characters, minimum window substring, max sum subarray of size k |
| Binary search | Sorted input, or “smallest/largest value that still works” | Array or an implicit range of answers | O(log n) | Search in rotated sorted array, Koko eating bananas (min eating speed), capacity to ship within d days |
| BFS / DFS | Grids, reachability, shortest path in an unweighted graph | Queue (BFS) or stack/recursion (DFS), plus a visited set | O(V + E) | Number of islands, word ladder, clone graph |
| Topological sort | Dependencies or ordering (“must happen before”) | Adjacency list plus in-degree counts | O(V + E) | Course schedule, alien dictionary, build order |
| Union-find | Grouping, connected components, “are these two connected” | Disjoint-set array with parent pointers | Near O(1) per operation | Number of connected components, accounts merge, redundant connection |
| Heap (top-k) | k largest/smallest, or a running median, without full sort | Binary heap / priority queue | O(n log k) for top-k; running median is O(log n) per element | Merge k sorted lists, top k frequent elements, find median from a data stream |
| Backtracking | All permutations, combinations, subsets, or constraint puzzles | Recursion with an explicit undo step | Exponential (e.g. O(2ⁿ) or O(n!)) | Permutations, subsets, N-queens, Sudoku solver |
| Dynamic programming | “Count the ways,” “min/max cost to,” “can you reach” | Memo (hash map) or a DP table | O(states × transitions) | Coin change, longest common subsequence, house robber, edit distance |
How to read the table under pressure
The trigger column is the part to over-train, because in the room you hear the prompt before you see the structure. A few of these deserve a sentence of context so you don’t fall off at the graph and DP rows.
Two pointers, sliding window, and binary search
When the input is sorted or you’re asked about a pair or a contiguous run, reach for pointers. The two-pointer and sliding-window patterns turn an O(n²) nested loop into a single O(n) pass, and “contiguous subarray” or “substring” with a window constraint is the sliding-window tell almost every time. Binary search’s more valuable form is searching on the answer: when the problem asks for the smallest or largest value that satisfies a monotonic condition (a yes/no test that, once it flips to yes, stays yes as the value grows), you can binary search over possible answers even when nothing is literally sorted. Koko eating bananas is exactly that in costume.
The graph patterns
Anything phrased as grids, connections, dependencies, or reachability is a graph problem even when the word never appears. BFS gives shortest path in an unweighted graph; DFS handles connectivity and cycle detection. Two specializations earn their own rows. Topological sort is ordering tasks so every dependency comes before the thing that needs it, which is what “course schedule” is really asking. And union-find is a structure that answers “are these two things in the same group” in near-constant time per query, which is why grouping and connected-component problems collapse to a few lines with it. If you want the mechanics of dependency ordering on their own, the topological sort walkthrough covers the in-degree bookkeeping.
Heaps, backtracking, and DP
When you need the k largest or a running median and not the whole thing sorted, a heap of size k gives O(n log k), which beats sorting everything when k is small. Backtracking is for permutations, subsets, and constraint puzzles: build a partial solution, recurse, and undo the choice when it dead-ends, where the interviewer is watching whether you prune early. Dynamic programming is the one people fear, and the fear is mostly recognition. The tell is overlapping subproblems plus optimal substructure, meaning the best answer to the whole is built from best answers to smaller pieces. Start from the brute-force recursion, notice you’re recomputing the same states, and add memoization. If you can write the recurrence relation, which is just the formula expressing one state in terms of smaller ones, you’ve done the hard part; turning it into a bottom-up table is optimization, not a requirement.
How to drill this before the loop
The mistake is treating this as a list to recite. In the room, the sequence is: restate the problem, name the structure whose operations match what you need, name the pattern the trigger suggests, and only then write code. Saying “it’s sorted, so two pointers drops this from O(n²) to O(n)” before you type is worth more than a fast silent solution, because you’re being scored on how you think.
To make recognition automatic, work one pattern at a time instead of grinding random problems. Pick a row, solve its three canonical problems back to back, and only move on once you can name the pattern from the prompt alone. Browsing problems grouped by topic keeps you inside one pattern per session, and filtering by difficulty stops you from burning a week on problems that are either trivial or hopeless for where you are. Once each row of the table triggers on sight, you’ve built the reflex the interview is actually testing, and the algorithm patterns cheat sheet and the fuller coding patterns catalog are there when you want deeper worked examples. If your onsite is weeks out and you’d rather have the sequencing decided for you, a generated study plan will space the patterns for you, but the table above is enough to self-direct.
Drill the patterns next:
