If you read enough interview-prep posts, you'll eventually think you need to know every variant of every tree (AVL, red-black, splay, B-tree, B+, treap) before you sit down in front of a recruiter. You don't. Not in 2026, and honestly not for the last decade either.

Across the 1,400+ coding interviews run on LastRound AI in Q1 2026, eight data structures account for about 95% of the prompts. The other 5% are weighted toward staff-level and specialty roles (compilers, databases, distributed systems). For everyone else, the list below is the list.

Here's what comes up, with the complexity numbers you'd actually need to defend on a whiteboard, and the patterns that go with each one.

The complexity table you should memorize

Before the eight structures, the cheat sheet. Most candidates fumble at least one cell when asked. The column that trips people up most: insert/delete for arrays vs linked lists, and access for hash tables (there's no such thing). Worth burning in.

1. Arrays

The most common structure by a wide margin. Roughly 60% of the prompts we see start with an array or end up needing one. The patterns that come up over and over: two pointers, sliding window, prefix sums, in-place modification.

The trap: candidates reach for a hash table when a sorted array + two pointers would be cleaner. If the input is already sorted, try two pointers first. (This is the "Two Sum II" gotcha.)

2. Hash tables

The "trade space for time" structure. If your brute-force solution is O(n²) and the operation is "for each element, look something up about another element," a hash table gets you to O(n). That single transformation explains maybe a third of all medium-level Leetcode problems.

Common patterns: frequency counting, grouping anagrams (key = sorted-letters tuple), caching computed values, tracking last-seen index for sliding windows.

3. Linked lists

Less common than they used to be. Maybe 8-10% of prompts. When they show up, it's almost always for one of four patterns: reverse the list, find the middle, detect a cycle (Floyd's tortoise-and-hare), or merge two sorted lists. Know these four cold and you'll handle most linked-list interviews.

The implementation you should be able to write without thinking:

# Reverse a singly linked list
prev, curr = None, head
while curr:
    nxt = curr.next
    curr.next = prev
    prev, curr = curr, nxt
return prev

4. Stacks and queues

Stacks come up more than people think. Valid parentheses is the classic, but the bigger family is "monotonic stacks": daily temperatures, next greater element, largest rectangle in histogram. If a problem asks "for each element, find the next/previous one that satisfies X," it's probably a monotonic stack.

Queues are mostly about BFS. The Python idiom that wins points: from collections import deque with popleft(). Using list.pop(0) is O(n) and panels notice.

5. Trees

About 15-20% of prompts. The four things to know cold:

• The three traversals (inorder, preorder, postorder), iterative and recursive.
• BST invariant (left subtree all less, right subtree all greater, applied recursively).
• BFS / level-order, using a queue.
• The "recursion with helper" pattern for tree DP problems (path sums, max depth, diameter).

The detail panels listen for: do you understand that inorder traversal of a BST gives sorted output? That one fact powers "validate BST" and a dozen other problems.

You don't need AVL, red-black, or splay trees. Twice in two years has someone asked me about AVL specifics on a mock, and both candidates were interviewing for database internals teams.

6. Heaps (priority queues)

Heaps fit one specific family of problems: "top K", "median from stream", "merge K sorted lists", "task scheduler with cooldown". When the problem mentions "kth", "K largest", or "K smallest", reach for a heap.

The Python gotcha that gets candidates: heapq is min-heap only. For a max-heap, push negated values and negate again on pop. For "kth largest," push the first k elements then push/pop the rest, and the top of the heap is your answer. (You can also use heapq.nlargest but interviewers usually want the manual approach.)

7. Graphs

Probably the second-hardest category after dynamic programming, and the one where the rep ceiling is highest. Most problems boil down to: traverse the graph (BFS or DFS), and detect or compute something along the way.

What to actually know:

• Adjacency list (not matrix, in 95% of cases) and how to build one from edge tuples.
• BFS for shortest path on unweighted graphs.
• DFS for connected components, cycle detection, topological sort.
• Topological sort via Kahn's algorithm (the in-degree version is easier to reason about live).
• Dijkstra at a sketch level. Almost never asked to implement, occasionally asked to explain.

Union-Find (disjoint set) is technically a graph-adjacent structure and worth 30 minutes of study. It shows up maybe 5% of the time, but when it does, nothing else works as cleanly.

8. Tries

The least common of the eight. Maybe 3% of prompts. Worth learning anyway, because when a trie is the answer, nothing else is close: autocomplete, prefix counting, "word search II" on a grid, longest common prefix.

A reasonable implementation in 15 lines:

class TrieNode:
    def __init__(self):
        self.children = {}
        self.is_end = False

class Trie:
    def __init__(self):
        self.root = TrieNode()

    def insert(self, word):
        node = self.root
        for ch in word:
            if ch not in node.children:
                node.children[ch] = TrieNode()
            node = node.children[ch]
        node.is_end = True

What we'd skip if time is short

If you have less than two weeks before an interview, here's what I'd cut: balanced-BST internals (AVL, red-black), segment trees, Fenwick trees, suffix arrays, bloom filters. They're interesting; they're almost never the right answer in a 45-minute interview. Gergely Orosz's interview-prep breakdown says the same thing from the staff-engineer end of the ladder.

The exception: if you're interviewing for an infra, database, or distributed-systems team specifically, then add LSM trees, B+ trees, and consistent hashing to your list. The Grokking system-design materials cover these well, and they crossover hard with the system-design round.

A four-week order, if you're starting from scratch

• Week 1. Arrays and hash tables. They are 50%+ of what you'll see; build the muscle here first.
• Week 2. Linked lists, stacks, queues. Implement reverse-list and valid-parentheses from memory.
• Week 3. Trees. All three traversals, BFS, validate-BST, and the recursion-with-helper pattern.
• Week 4. Graphs and heaps. BFS shortest path, topo sort, top-K, merge-K. Tries if you have a spare evening.

I don't know if this generalizes to every candidate. It's the plan I've seen work for the engineers I've coached who landed offers at Stripe, Snowflake, and Anthropic in the last six months. Your mileage may vary, especially if you're rusty on recursion.