Most linked list interview questions reduce to five patterns: two pointers (fast and slow), the dummy head node, in-place reversal, the runner gap, and merge/interleave. If you can recognize which one a problem wants in the first two minutes, the rest is careful pointer bookkeeping. The hard part is almost never the algorithm; it is the edge cases (empty list, single node, head removal) and not losing a pointer mid-operation. We run mock interviews all day, and linked list problems are where we see the most "correct idea, buggy pointers" failures.
This guide walks the patterns, maps them to real problems in our question bank, and lists the specific mistakes that cost people the hire signal.
Why interviewers still love linked lists
Linked lists are a clean test of pointer discipline. There is no indexing to hide behind, so the interviewer sees exactly how you reason about references, mutation, and memory. A single misplaced node.next = ... either drops half the list or creates a cycle, and both are instantly visible when they trace your code.
They also scale well as a conversation. A warm-up like reversing a list can grow into "reverse in groups of k," "detect a cycle," or "merge k sorted lists." That makes them a favorite for 45-minute phone screens where the interviewer wants one problem with follow-ups rather than two separate ones. For how to handle that escalation, see our guide on follow-up questions in coding interviews.
Pattern 1: Fast and slow pointers
The single highest-leverage technique. You move one pointer one step and another two steps per iteration. This single algorithm, invented by Robert Floyd in the 1960s, solves cycle detection, cycle start finding, linked list midpoint, and the Happy Number problem, all in O(n) time with O(1) space.
For cycle detection, the logic is simple: if there's a cycle, the fast pointer will eventually catch up with the slow pointer within the cycle because it's moving faster. If there's no cycle, the fast pointer will reach the end of the list (it will become NULL).
Finding the cycle's entry point is the classic follow-up, and the trick is unintuitive until you see it once. After detecting the cycle, reset one pointer to the head of the list, keep the other pointer at the meeting point, then move both pointers one step at a time. The node where they meet again is the start of the cycle.
def detect_cycle(head):
slow = fast = head
while fast and fast.next:
slow = slow.next
fast = fast.next.next
if slow is fast: # cycle confirmed
p = head
while p is not slow:
p = p.next
slow = slow.next
return p # cycle entry
return None # no cycle
The same fast/slow idea finds the midpoint in one pass: when fast hits the end, slow sits at the middle. That is the building block for "reorder list" and "palindrome linked list."
This belongs to the broader two pointers technique, which shows up across arrays and strings too, so time spent here pays off widely.
Pattern 2: The dummy head node
Whenever the head itself might change (you delete it, insert before it, or reroute it), allocate a dummy node that points at the real head and return dummy.next at the end. This single habit removes an entire class of special-case branches.
Two problems in our bank are almost pure dummy-node exercises:
- Partition List: partition around a value
xso all nodes less thanxprecede nodes greater than or equal tox, while preserving original relative order. Build two dummy-headed lists (a "less" chain and a "greater-or-equal" chain), append each node to the right one, then splice. Two dummies, zero head special-casing. - Remove Duplicates from Sorted List II: delete every node that has a duplicate value, keeping only distinct values. Because the head itself can be a duplicate, a dummy node is what lets you delete the first node without a separate code path.
def delete_duplicates(head):
dummy = ListNode(0, head)
prev = dummy
cur = head
while cur:
if cur.next and cur.val == cur.next.val:
dup = cur.val
while cur and cur.val == dup:
cur = cur.next
prev.next = cur # skip the whole run
else:
prev = cur
cur = cur.next
return dummy.next
If you find yourself writing if head is None or ... three times, that is the signal you forgot the dummy.
Pattern 3: In-place reversal
Reversing a list (or a sublist) with three pointers (prev, cur, next) is the most-asked single trick, and it appears as a subroutine in dozens of harder problems. The invariant: save cur.next before you overwrite it, point cur.next back at prev, then advance both.
def reverse(head):
prev = None
cur = head
while cur:
nxt = cur.next # save first, always
cur.next = prev
prev = cur
cur = nxt
return prev
The number one bug here is reversing the pointer before saving cur.next, which strands the rest of the list. Memorize the order: save, rewire, advance. Follow-ups that build on this include "reverse nodes in k-group" and "reverse a sublist between positions m and n," both of which combine reversal with a dummy node.
Pattern 4: The runner gap
To act on a node measured from the end of a list in one pass, advance a lead pointer n steps first, then move both pointers together until the lead hits the end. The trailing pointer now sits exactly where you need it.
Remove Nth Node From End of List is the canonical case: remove the nth node from the end and return the head. Use a dummy node (because you might remove the head), send the lead pointer n+1 steps ahead, then walk both to the tail.
def remove_nth_from_end(head, n):
dummy = ListNode(0, head)
lead = lag = dummy
for _ in range(n + 1):
lead = lead.next
while lead:
lead = lead.next
lag = lag.next
lag.next = lag.next.next
return dummy.next
Notice this pattern stacks two techniques: the gap runner plus the dummy node for safe head deletion. Most "medium" linked list problems are exactly this, two patterns composed.
Pattern 5: Merge, flatten, and interleave
The last family rewires multiple chains or multiple levels into one. Merging two sorted lists is the base case (and the merge step of merge sort on lists). Harder variants flatten nested structure:
- Flatten a Multilevel Doubly Linked List: each node has
next,prev, and achildpointer. When you hit a child, recurse or push the currentnextonto a stack, splice the child chain inline, and fix upprevpointers. The stack version is cleaner under pressure than recursion. - Flatten Binary Tree to Linked List: flatten a tree so each node's
rightpoints to the next node in preorder andleftis null. This is a tree problem wearing a linked list costume, and it rewards knowing both. - Find the Minimum and Maximum Number of Nodes Between Critical Points: a traversal problem where you track the first, previous, and last critical point (local maxima or minima) in a single pass. No fancy structure, just disciplined bookkeeping.
For the rare senior curveball, Design Skiplist asks you to build an ordered structure with O(log n) search, insert, and delete using layered linked lists and randomized levels. If you are interviewing at staff level, it is worth one practice session; for most roles it is out of scope.
The pitfalls that actually fail people
The algorithms are rarely the problem. These are:
| Pitfall | Fix |
|---|---|
Dereferencing fast.next.next without checking fast and fast.next | Guard both in the loop condition |
Reversing before saving cur.next | Save, rewire, advance, in that order |
| Head special-casing everywhere | Use a dummy node |
| Off-by-one on the runner gap | Dry-run on a 2-node list |
| Creating an accidental cycle | Set the final tail.next = None |
| Ignoring empty and single-node inputs | State both before you code |
The meta-mistake is not tracing your code. Before you say "done," walk a 2-node and a 3-node example by hand, updating each pointer out loud. We see more offers lost to an untested off-by-one than to a missing optimal approach. If debugging on the fly is your weak spot, our piece on debugging under pressure covers how to narrow a pointer bug fast.
To drill these against real company question sets, practice linked list problems with AI feedback and have it push you on the follow-ups.
FAQ
How many linked list problems should I solve before an interview?
Aim for coverage of the five patterns, not raw volume. Roughly 12 to 15 well-chosen problems (reverse, merge two lists, cycle detection, remove nth from end, partition, remove duplicates, reorder, and two or three flatten/merge variants) will expose you to every reusable idea. Doing 80 problems that are all reversal variants is wasted time.
Are linked lists still asked in 2026, given hash maps solve a lot?
Yes. Interviewers use them precisely because you cannot fall back on indexing or a library. They test pointer reasoning and edge-case discipline, which no amount of hashing hides. Expect at least one at companies like Amazon, Microsoft, and Bloomberg.
What is the most common linked list question?
Reversing a linked list, either as a standalone warm-up or as a subroutine inside "reverse in k-groups," "palindrome list," or "reorder list." Master the three-pointer reversal cold, because it reappears constantly.
Recursion or iteration for linked list problems?
Iteration is usually safer in an interview. Recursion is elegant for reversal and flatten, but it costs O(n) stack space and risks stack overflow on long lists, which a sharp interviewer will point out. Lead with iteration and mention the recursive option as a trade-off.
How do I find the middle of a linked list in one pass?
Use fast and slow pointers. Move slow one step and fast two steps per iteration; when fast reaches the end, slow is at the middle. This is the same mechanism as Floyd's cycle detection, just stopped at the end instead of at a meeting point.