I’ve watched a lot of people go into coding interviews with weeks of LeetCode prep and still bomb them, not because they didn’t study enough, but because they studied the wrong things first. The distribution of what actually shows up in interviews is much more skewed than prep guides suggest.
This is my attempt to give an honest prioritization, which means being direct about what to deprioritize too.
The six structures that appear in most interviews
If you’re preparing for a role at most tech companies and you have 3 to 4 weeks, these are the only structures that matter for passing the screening round:
Arrays and strings are unavoidable. Two-pointer and sliding window patterns alone will get you through a surprisingly large portion of medium-difficulty problems. If you haven’t drilled those two patterns until they feel automatic, start there before touching anything else.
Hash maps come up constantly because they trade space for time in a way that simplifies a lot of otherwise painful problems. “Find duplicates,” “group anagrams,” “two sum” and about 40 variations of those ideas all collapse to hash map problems once you recognize the pattern.
Trees are heavy at Google, Meta, and Amazon. Mostly binary trees, occasionally BSTs. The patterns to know are: DFS (recursive and iterative), BFS with a queue, and how to detect the lowest common ancestor. After those three, you’re set for 90% of what comes up.
Graphs show up less often in screening rounds than trees but more often in onsites. BFS for shortest path, DFS for connected components, union-find for detecting cycles. The topology sort pattern comes up occasionally for dependency problems.
Stacks and queues usually appear in “valid parentheses” style problems and monotonic stack variations. Once you understand the monotonic pattern, a whole category of “next greater element” problems becomes much more tractable.
Heaps are niche but high-signal. “Top K elements” and “median from a data stream” are two patterns that show up specifically because they filter for candidates who know when a sorted structure is overkill.
What the Stack Overflow data actually shows
The Stack Overflow Developer Survey 2024 found that the most commonly used data structures in production code are arrays, hash tables, and trees, roughly in that order. That maps pretty closely to interview frequency. The things you’d use most in a job are also the things they ask most in interviews. Linked lists are a notable exception, which I’ll get to.
What you can safely deprioritize (and what to do instead)
Linked lists are the subject of a lot of interview prep content. I think that’s disproportionate to how often they actually appear. In 47 interviews across various companies over a few years, the number of standalone linked list questions I saw was small, maybe 4 or 5. The reversals and cycle detection problems that linked lists are famous for are worth knowing, but an hour on those is probably enough.
Tries are genuinely useful for autocomplete and prefix-matching problems, but they come up rarely. If you’re interviewing at a company that does search or NLP work, spend 90 minutes there. Otherwise, skip it until you’ve exhausted the tier-one structures.
Segment trees, Fenwick trees, and skip lists: unless you’re applying to a trading firm, a competitive programming company, or an explicitly algorithms-focused role, I’d skip these entirely during interview prep. They show up in maybe 3% of interviews and the prep time doesn’t pay off for most people.
The thing about time complexity that most guides miss
Knowing the Big O of each operation is table stakes. What’s actually harder, and what separates good candidates from okay ones, is space complexity reasoning and being able to trade off between them.
Here’s a simplified reference:
| Structure | Average lookup | Average insert | Notes |
|---|---|---|---|
| Array | O(1) by index | O(n) at middle | Cache-friendly, contiguous memory |
| Hash map | O(1) average | O(1) average | O(n) worst case with collisions |
| Binary tree (balanced) | O(log n) | O(log n) | Degrades to O(n) if unbalanced |
| Heap | O(n) general, O(1) min/max | O(log n) | Used for priority queues |
| Stack/Queue | O(n) | O(1) push/enqueue | LIFO vs FIFO access patterns |
The interviewer wants to hear you reason through the tradeoff, not recite the table. “I’m using a hash map here, which costs O(n) space, but it gets lookup down to constant time, which matters if this runs in a hot loop” is what they want to hear.
A realistic study schedule if you have 4 weeks
Week 1: arrays, strings, and hash maps. Do 20 to 25 problems of varying difficulty. Focus on recognizing patterns over finishing them quickly.
Week 2: trees and basic graph traversal. Do BFS and DFS implementations from scratch until you can write them without reference. Then do 15 problems applying those patterns.
Week 3: heaps, stacks, queues, and the monotonic stack pattern. Do 10 to 12 problems here. Start doing timed sessions (35 minutes per problem).
Week 4: linked lists, tries (if relevant to your target company), and a mix of everything. Do mock interviews. Two or three mocks with another human will surface communication gaps that solo practice can’t.
The BLS projects software developer employment growing 17% through 2033. There are more candidates and the bar for new grad and junior roles in particular has risen over the past two years. Practicing communication alongside the code is worth treating as seriously as the algorithm work itself.
Pattern recognition beats memorization
The single biggest mistake I see is people memorizing solutions to specific problems instead of learning to recognize which pattern a new problem is asking for. “This has a sliding window structure” should be what your brain produces in the first 60 seconds, before you write a single line of code.
How long a given pattern takes to internalize varies a lot by person. Some people get sliding window in 5 problems. For others it takes 15. Neither is a sign of anything except that the number varies.
What’s the structure type that feels most inconsistent for you right now? That’s where to start the next session.