The Most Common Coding Interview Topics, Ranked by Frequency

"Cover all your bases" is the advice that gets you three weeks deep into knapsack problems and still completely blank when the interviewer asks you to count duplicates in an array.

Interview topics are not distributed evenly. LeetCode tags 1,100+ problems under Array. Hash Table sits around 665. Dynamic Programming: 545. Those numbers should drive your prep schedule, not vibes, not whatever Blind told you was hot last month, not "it's Google so I need to do hard problems."

The shape of the distribution matters. Most candidates invert it. This post tries to fix that.

Here's the breakdown, from "you will absolutely see this" to "real topic, sure, but not before your trees are solid."

Tier One: The Substrate Everything Else Runs On

Arrays, strings, and hash tables appear in virtually every interview, at every company, at every level. Not most interviews. Every interview.

If you can't manipulate arrays and strings fluently, you can't solve graph problems, tree problems, or DP problems. You'll be translating "how do I reverse a subarray in-place" into syntax while your interviewer watches the clock. Prefix sums, frequency counts, two-pointer setups: the core tricks all live here. They're not glamorous. They're the floor.

There's a specific failure mode that comes up constantly. You've spent four weeks on dynamic programming. Tabulation, memoization, state transitions. You understand all of it. You walk into a phone screen and get asked to find two numbers that sum to a target. You write an O(n²) nested loop because the O(n) hash set solution never crosses your mind. The interviewer hints at a better approach. You don't see it. Interview over.

Hash tables deserve a dedicated callout because people underestimate how cross-cutting they are. Hash map and hash set operations appear inside solutions that are formally tagged as graph, tree, array, or string. When the problem asks "have I seen this element before?" or "how many times does X appear?", that's hash table territory every time. It's the most widely applicable structure on the list. The candidates who treat it as obviously easy are usually the ones who've internalized it so thoroughly that it actually is.

"Fluent" has a specific meaning here. Not "I know what a hash map is." More like: you can, without thinking, write a frequency counter, detect a duplicate, build an index from list to indices, or check membership in O(1). It comes up in a different form in every other tier.

Tier Two: Trees and Graphs Are Not Optional

Most candidates treat trees and graphs as the "advanced section they'll get to eventually." Interview pools disagree.

DFS alone has around 670 tagged problems on LeetCode. More than DP. BFS has roughly 360. A tree problem appears in almost every on-site loop. At Google, Meta, and Amazon. At fintech startups that swear they do "practical" interviews and then open round two with "serialize and deserialize a binary tree."

You need recursive and iterative traversals. You need to spot the graph-versus-tree distinction fast, because they require different logic. Trees have no cycles and exactly one path between any two nodes; graphs have neither guarantee. Your traversal, cycle detection, and handling of disconnected components all change at that boundary.

DFS and BFS are the same underlying pattern in different clothes. Master one and the other takes about two sessions.

The specific trap: candidates write only recursive traversals in practice, then freeze when asked to do it iteratively. A stack-based iterative inorder traversal is not an exotic request. Learn both forms. The iterative version also matters for space analysis. Recursion burns call stack depth at O(h). Tabulation doesn't.

One more thing about graphs: you also need to know how to represent them (adjacency list vs adjacency matrix), how to handle directed vs undirected edges, and how to detect cycles without infinite loops. These aren't hard topics. They just don't appear in the "easy" filter.

Tier Three: Techniques That Multiply Your Reach

Most frequency rankings list data structures and skip the techniques that actually separate O(n) solutions from O(n²) ones. That gap quietly ends a lot of interviews.

Two pointers. Sliding window. Binary search. These aren't a standalone interview category; they're how you solve array and string problems at the right complexity class. The difference between a brute force and an efficient solution in a string problem almost always comes down to whether you recognized the window.

Two pointers and sliding window together handle most "optimize the brute force" moments in array and string interviews. Binary search extends further than most candidates realize: answer ranges, matrix search, rotation detection, anywhere you can define a monotonic predicate. "If the answer is at least X, then everything below X is also valid" should trigger binary search immediately. The non-obvious applications of binary search (minimum speed to eat bananas, minimum days to make bouquets) are real interview questions, not edge cases.

If you've worked through the sliding window algorithm guide, you already know how far one pattern actually travels.

Treating these as minor appendices is how candidates arrive at the interview with technically correct O(n²) solutions and no obvious path to improving them before the timer runs out.

Tier Four: DP and Backtracking Are Worth It, Just Not First

Dynamic programming gets disproportionate prep time relative to how often it actually shows up. Roughly 10 to 15 percent of real interview rounds include a DP problem. That number skews higher at Google than anywhere else. Backtracking is comparable in frequency but gets a fraction of the prep attention.

Both are worth mastering. The mental models transfer well. A candidate who understands the decision-tree shape of backtracking and the "subproblem dependency graph" frame for DP can handle variants they haven't seen before.

The mistake is inverting the pyramid: spending 80% of prep on DP because it feels hard and impressive, before the core tiers are solid.

Three weeks of knapsack variants and you're still "not qualified" because the hash set solution didn't show up.

If your binary tree traversal has edge-case bugs, another week on subset enumeration is not the fix. The dynamic programming framework earns its place after tiers one through three are locked in, not before.

One more note that actually helps: DP is learnable as a set of shapes, not a set of problems. There are roughly eight fundamental patterns. 1D sequences, 2D grids, string operations like edit distance and LCS, knapsack variants, interval DP, bitmask DP for small state spaces. Learn those shapes, learn to recognize which shape a new problem resembles, and you're actually prepared. You don't need to have memorized 200 DP problems. You need to have internalized maybe eight frames.

Backtracking is even simpler to define: you're building a decision tree, and you prune branches that can't lead to valid solutions. Subsets, permutations, combinations, constraint satisfaction. Once you see the template, most problems fall into it.

Tier Five: Learn the Specialist Tier Last

Heaps and priority queues, interval merging, monotonic stacks, union-find. These appear in real interviews. Just not at the frequency of tier one or two, and not at every company.

Heaps unlock "k largest" and "k closest" problems and anything involving continuous priority ordering. Interval problems cluster at specific companies; if your target is on that list, learn interval merging thoroughly. Monotonic stack solves the "next greater element" family of problems that would otherwise need O(n²) loops.

Learn these after the core tiers are solid, not as a panic move the week before your interview.

Union-find is worth calling out separately. The implementation is short and the concept is elegant. It handles graph connectivity, dynamic connected components, and redundant edge detection efficiently. It's also easy to forget the exact path compression implementation at 10am in a shared doc, so add it to your rotation early.

The Right Study Order Is Just Frequency Order

The priority: arrays and strings, hash tables, trees, graph traversal, core techniques (two pointers, sliding window, binary search), DP and backtracking, then specialist structures.

Most candidates invert this. They grind the interesting hard stuff first because it feels like real progress. They discover in the actual interview that their hash map instincts are slow and their tree traversal has bugs at the leaf boundary.

The frequency data is not a guarantee. You might walk into a round with zero array problems and a DP question straight out of a Google prep guide. But studying proportional to frequency is just expected value math. You bet on the horse that wins most races.

One practical move: when a practice problem stumps you, categorize it by tier before reading the solution. If it's a tier-one problem and you missed it, that's your signal. More tier-five prep won't close that gap.

Practice identifying patterns out loud, not just solving them in silence. SpaceComplexity puts you in a realistic mock interview where you have to name the pattern before you write a line of code. That narration step is exactly what the frequency distribution rewards.