Linked List Interview Questions: 3 Patterns to Know

Linked list interview questions test whether you can manipulate pointers correctly under pressure, not whether you know the textbook definition of a node. Almost every question in this category comes down to one of three recognizable patterns: a fast and slow pointer, a dummy node that simplifies edits at the head, and in-place reversal, and each one runs in a single pass with O(1) extra space once you know the shape. This guide walks through those three patterns with a worked example, the clarifying questions worth asking before you write anything, the mistakes that sink most attempts, and the specific questions you are most likely to actually see.

How Are Linked List Questions Different From Array Questions?

Linked list questions are different because you give up random access in exchange for cheap insertion and deletion, and the interview is really testing whether you understand that trade and can move a pointer correctly instead of reaching for index math out of habit. An array lets you jump straight to index 500. A linked list makes you walk there one node at a time, and that single fact drives almost every design decision in these problems, from why you keep a trailing pointer around to why "just look at the next few nodes" is rarely as simple as it sounds.

The trade-offs show up clearly once you line the structures up side by side.

| Operation | Array | Singly linked list | Doubly linked list | | --- | --- | --- | --- | | Access by index | O(1) | O(n) | O(n) | | Insert at the head | O(n), shifts every element | O(1) | O(1) | | Insert at the tail (no tail pointer kept) | O(1) amortized | O(n) | O(1) with a tail pointer | | Delete a node you already have a reference to | O(n), shifts every element | O(n), you need the previous node | O(1) | | Search by value | O(n) | O(n) | O(n) |

That table is also why interviewers reach for linked lists so often: it gives them a clean way to check whether you actually reason about complexity or just recite it. A candidate who defaults to "let me copy this into an array first" usually gets asked why, and "because arrays are easier" isn't an answer that holds up once the interviewer points out you just paid O(n) space and a full extra pass to avoid learning a pointer trick that solves it in place.

There is a second, quieter trade-off worth knowing even though it rarely changes your algorithm: an array's elements sit next to each other in memory, so scanning one is friendly to the CPU cache and fast in practice even when the Big O looks the same as a linked list scan. A linked list's nodes can live anywhere on the heap, so walking one means chasing a pointer to wherever the next node happens to be, which is slower in the real world despite carrying the same O(n) label. You are unlikely to need this for the algorithm itself, but naming it when an interviewer asks "so a linked list scan and an array scan are both O(n), are they the same speed in practice" is exactly the kind of detail that separates a candidate who has only memorized complexity classes from one who understands what is actually happening in memory.

What Are the Three Patterns That Solve Most Linked List Questions?

The fast and slow pointer pattern, often called Floyd's algorithm, moves one pointer one step at a time and a second pointer two steps at a time through the same list. If the list has a cycle, the fast pointer eventually laps the slow one and the two meet inside the loop, which is how you detect a cycle in O(n) time and O(1) space without a hash set to track visited nodes. The same two-speed idea finds the middle of a list in one pass: when the fast pointer reaches the end, the slow pointer is sitting on the middle node, which is the setup most palindrome-check and list-splitting problems start from.

The dummy node pattern solves a narrower but constantly recurring problem: editing the head of a list is awkward because there is no node before it to point at, so any operation that might delete or replace the head needs special-case code unless you sidestep the issue. Create a dummy node, point its `next` at the real head, run your normal logic using the dummy as if it were one node before the actual list, and return `dummy.next` at the end. Every deletion, insertion, or merge that might touch the head now behaves exactly like one that touches any other node, and the special case disappears.

In-place reversal flips the direction of the `next` pointers as you walk the list once, using three tracking variables so you never lose access to the part of the list you haven't reversed yet.

def reverse_list(head):
    prev = None
    current = head

    while current:
        next_node = current.next
        current.next = prev
        prev = current
        current = next_node

    return prev

`prev` starts as `None` because the new tail of the reversed list needs to point at nothing. On each step, you save `current.next` before overwriting it, since that overwrite is exactly what would strand the rest of the list if you did it first. By the time `current` reaches the end, `prev` is sitting on the new head, which is why the function returns `prev` and not `current`. The whole thing runs in one pass with three pointers and no extra memory, and it is the building block behind harder variants like reversing just a sub-section of a list or reversing it in groups of k nodes.

Most linked list questions that look unfamiliar at first glance are actually one of these three patterns wearing a different problem statement, sometimes combined: detecting where a cycle begins uses fast and slow pointers to find the meeting point, then a second pass to find the entry node; reordering a list around its middle uses fast and slow pointers to split it, then reversal on the second half.

A close cousin worth knowing separately is the gapped two-pointer trick behind "remove the nth node from the end." Since a singly linked list has no length property and no way to count backward, you advance one pointer n steps ahead of a second pointer, then move both together until the lead pointer hits the end. At that point the trailing pointer sits exactly n nodes from the end, which is the node you needed, and the whole thing still runs in one pass with two pointers instead of two separate passes (one to count the length, one to walk to the target).

What Clarifying Questions Should You Ask Before You Start Coding?

Before writing anything, confirm a handful of details that change how you approach the problem:

Is the list singly or doubly linked, and is a tail pointer maintained?
Can you modify the list in place, or does the interviewer want a new list returned untouched?
Should the function handle a null or empty head gracefully, and what should it return in that case?
Are values allowed to repeat, and does that change what "the answer" means for this problem?
Is there a rough size hint that would make an O(n) two-pass solution acceptable over a trickier one-pass version?

Asking these signals that you think about the shape of the input before committing to a pattern, and it occasionally saves you from building the wrong solution entirely, such as writing a reversal that mutates the list when the interviewer actually wanted the original preserved.

What Mistakes Sink a Linked List Answer in an Interview?

Losing the head reference is the most common failure, and it happens almost every time someone starts walking the list with the same variable that is supposed to still point at the start. Once `head` has been reassigned inside a loop, there is no way back to the original list, and the fix (keep a second variable, walk with that one instead) is trivial once you know to expect the trap.

Off-by-one errors on "the nth node from the end" or "the middle node" account for most of the remaining wrong answers, usually from an unclear definition of where counting starts. Decide out loud whether the list is zero-indexed or one-indexed for this problem, whether "the middle" of an even-length list means the first or second of the two center nodes, and state your convention before you write the loop, not after the interviewer asks why your output is shifted by one.

Forgetting to null out a node's `next` pointer after removing it from a list can silently create a cycle that a later cycle-check step would misreport, or that would cause an infinite loop when someone later tries to print the result. This one rarely shows up in a small manual trace, so it tends to survive until the interviewer runs a larger test case and the program hangs.

Reaching for a hash set or an array copy before considering whether a pointer trick solves the same problem in O(1) space is a mistake of a different kind: it usually still passes, but it signals that you haven't internalized the patterns above, and most interviewers will follow up by asking whether you can do it without the extra structure. Naming the O(1)-space version unprompted, even if you end up coding the simpler one first, tends to land better than waiting to be asked.

What Are the Most Commonly Asked Linked List Interview Questions?

A small set of problems accounts for most of what actually gets asked, and each one maps cleanly to a pattern from earlier in this guide:

Reverse a linked list, or reverse just the nodes between two positions, using the three-pointer reversal walk.
Detect whether a list has a cycle, and if it does, find the node where the cycle begins, using fast and slow pointers twice.
Merge two already-sorted lists into one sorted list, using a dummy node to avoid special-casing whichever list starts smaller.
Find the middle node of a list in one pass, using fast and slow pointers.
Remove the nth node from the end of a list in one pass, using two pointers kept n nodes apart.
Check whether a list reads the same forwards and backwards, using fast and slow pointers to find the middle, then reversal on the second half.
Flatten a multilevel list where some nodes point to a separate child list, a harder combination question that tests whether you can keep track of multiple "next" chains at once.

The design question that shows up constantly alongside these is an LRU cache, which pairs a doubly linked list with a hash map so that both lookup and eviction run in O(1). Our walkthrough of that exact problem is worth working through once the patterns above feel comfortable, since it is one of the few linked list questions that also tests whether you can combine two data structures correctly under time pressure.

What Should You Say Out Loud While You Solve One?

Name the pattern before you touch the keyboard. If you notice the problem wants a cycle check or a middle node, say "this looks like a fast and slow pointer problem" and briefly explain why, before writing a single line. If the head might change, say "I'll use a dummy node here so I don't need to special-case the head," which tells the interviewer you have already spotted the trap most candidates fall into silently.

As you write the reversal or traversal loop, narrate what each pointer is doing and why you saved a reference before overwriting it, the same habit that matters in our breakdown of how to reason about complexity for any pattern, not just this one. Trace through a short example by hand once the code is on the screen, including an edge case like a one-node list or an empty list, and state the final complexity claim out loud: "this runs in O(n) time with one pass and O(1) extra space, since I'm only tracking a fixed number of pointers." Interviewers grade this family of questions heavily on whether you can defend that claim under a follow-up, not just state it.

How Should You Practice Linked List Questions Without Grinding Everything?

Work through the three patterns in order rather than jumping straight to the hardest combination question you can find. Reversal first, since it is the most mechanical and the easiest to trace by hand. Fast and slow pointers next, starting with cycle detection before moving to the middle-node and palindrome variants. Dummy node last, since it only clicks once you have felt the pain of special-casing the head a few times without it.

Our curated question bank pulls from real onsite reports rather than an unfiltered public archive, so the linked list problems you find there reflect what is actually showing up in loops right now instead of a static list that stopped updating years ago. Once these three patterns feel automatic, our guide to spotting patterns before you code covers how they relate to the other pattern families you will need, including two pointers on arrays and the sliding window technique covered in our sliding window guide, so you aren't learning each pattern as an isolated trick.

Frequently Asked Questions

What are the most common linked list interview questions?

Reversing a list, detecting a cycle, merging two sorted lists, finding the middle node, removing the nth node from the end, checking a palindrome, and designing an LRU cache account for most of what actually gets asked. Each one maps to one of three underlying patterns: fast and slow pointers, a dummy node, or in-place reversal.

What is the fast and slow pointer technique used for?

Fast and slow pointers, also called Floyd's algorithm, move through a list at two different speeds to detect cycles and find the middle node in a single pass without extra memory. If a cycle exists, the faster pointer eventually meets the slower one inside the loop.

Why do linked list interview questions use a dummy node?

A dummy node removes the special case of editing the head of a list, since there is normally no node before the head to point at. Every insertion, deletion, or merge that might affect the head behaves the same as one that affects any other node once you run your logic starting from the dummy.

Can you reverse a linked list without extra memory?

You can, and interviewers usually expect exactly that. In-place reversal uses three pointers (the previous node, the current node, and a saved reference to the next node) to flip the direction of every link in a single pass, using O(1) extra space and no auxiliary list or array.

Do linked list interview questions ever combine multiple patterns?

They often do, especially once a question moves past the easy tier. Finding where a cycle begins uses fast and slow pointers twice, and checking a palindrome uses fast and slow pointers to find the middle, then in-place reversal on the second half before comparing the two halves node by node.

Is a doubly linked list interview question different from a singly linked one?

The core patterns still apply, but a doubly linked list adds a `prev` pointer that needs updating alongside `next` on every insertion, deletion, and reversal step. The LRU cache question is the clearest example, since it relies on the `prev` pointer for O(1) eviction from the middle of the list.