How to recognize which algorithm a problem wants

The hardest part of most algorithm problems is not implementing the answer — it’s the thirty seconds where you decide what kind of problem this is. Get the family right and the implementation is a known dance; get it wrong and no amount of clean code saves you. The good news: problem statements leak their family constantly, through specific words, constraint sizes, and data shapes. This page is a field guide to the leaks.

Read the constraints before the story

The single highest-value habit: look at n before thinking about anything else, because the constraint is the complexity budget, and the budget names the families.

n up to	Your budget	Families that fit
~20	2ⁿ or n!	brute force, bitmask DP, backtracking
~5,000	n²	nested loops, simple DP tables, plain BST
~100,000	n log n	sorting, heaps, binary search, balanced trees
~1,000,000+	n or n log n	one-pass scans, two pointers, hashing, counting

A problem with n = 15 is telling you to enumerate subsets — exponential is fine, and hunting for a polynomial trick wastes your interview. A problem with n = 10⁶ is telling you a quadratic answer will time out before you finish typing it. The constraint isn’t trivia at the bottom of the page; it’s the strongest hint the setter gives you.

Words that name their family

Some phrases are nearly one-to-one with technique:

• “Shortest path”, “fewest moves”, “minimum steps” — BFS if every move costs the same; Dijkstra the moment moves have different costs. The unweighted/weighted split is the first question to ask out loud.
• “Sorted array” in the givens — the setter paid for that sortedness and expects you to spend it: binary search, or two pointers for pair-and-window questions. An O(n) scan of sorted input often means you’ve missed the intended answer.
• “Prerequisites”, “dependencies”, “must come before” — topological sort, and its twin question “is it even possible?” is cycle detection.
• “Connected”, “groups”, “islands”, “merge accounts” — connected components: DFS/BFS if the graph is fixed, union-find if edges arrive over time or queries interleave.
• “Count the ways”, “minimum cost to reach”, “longest … subsequence” — dynamic programming; the word subsequence especially is DP’s calling card.
• “All permutations / combinations / arrangements” — backtracking, and the constraint (see table) will confirm it.
• “Top k”, “k-th largest”, “median of a stream” — a heap, and saying “heap” within ten seconds of hearing “top k” is the expected reflex.
• “Substring without repeating”, “at most k distinct”, “window” — sliding window, the same-direction cousin of two pointers.

None of these are guarantees — setters enjoy misdirection — but each is where your hypothesis should start.

Shapes that name their family

When the words are neutral, the data’s shape still talks. A grid or maze is a graph in costume: cells are nodes, adjacent cells are edges, and “escape the maze” is BFS. Nested categories or an org chart mean a tree, and “process children before parents” means post-order. A stream you can’t store means one-pass with O(1) or heap-sized state. Pairs of things to match or compare — two strings, two arrays — lean DP (alignment) or hashing (membership). And any “state you can be in, moves you can make” description — puzzle positions, dial combinations — is a graph whose nodes are states, which is how BFS ends up solving problems with no picture of a graph anywhere.

When two families both seem right

They often both are, at different costs, and interviews love the seam. Two-sum: hash map (unsorted, O(n) space) or two pointers (sorted, O(1) space) — the choice depends on the givens, and stating the trade is the answer. Shortest path with all weights equal: Dijkstra works, BFS is better — using the heavier tool costs you the “why the log factor?” follow-up. K-th largest: sort (n log n), heap of size k (n log k), or quickselect (average n) — three right answers ranked by effort, and naming the ranking beats jumping to any one of them.

The two-minute protocol

Under pressure, run this order: constraints (budget) → givens (is anything sorted / bounded / small?) → verbs and nouns from the lists above → smallest example by hand, watching which technique your hand wants to do. Then say the hypothesis aloud with its complexity, sanity-check it against the budget, and only then code. Recognition is a skill you can drill separately from implementation — every page on this site lists “problems built on this pattern” for precisely that reason: read those titles, cover the answer, and guess the family before clicking.