Linked Lists Coding Interview: Narrate Pointer Moves

A linked-list question in a coding interview is rarely about whether you have seen the problem before. It is about whether you can hold a small amount of state in your head, move it correctly, and explain what you are doing while you do it. Most candidates who struggle here can already write a loop over a list. What they cannot yet do is narrate the loop out loud without losing the thread.

This guide treats linked lists coding interview questions as a reasoning-and-communication exercise. You will practise drawing the list, naming your pointers, stating time and space complexity honestly, and recovering in public when a pointer goes wrong. No memorised catalogue of tricks required.

Why linked lists coding interview questions show up

Linked lists test pointer discipline and edge-case thinking more than library knowledge. There is no index to lean on, no length property you can trust, and no random access. Every step forward is a decision about which reference you keep and which you overwrite.

Interviewers use these questions to watch how you reason when the data structure gives you almost nothing for free. They want to see whether you check the shape of the input, whether you notice the empty list, and whether you can explain a pointer move in a sentence a colleague could follow.

Set your expectations accordingly. The goal is a clear, honest explanation of your approach, not a rehearsed script delivered at speed. If you can draw the list and talk through the moves, you are already doing the thing being assessed.

Start by drawing the list, not by writing code

Before you type anything, sketch nodes and arrows. Say what each arrow represents: a reference from one node to the next, or null at the end. A five-node drawing takes fifteen seconds and saves you from most off-by-one errors.

Name your variables out loud and keep the names stable. prev, curr and next are conventional for a reason. If you rename them halfway through, the interviewer has to rebuild their mental model, and so do you.

Confirm the shape of the input before you commit to an approach:

Is it singly or doubly linked?
Is it sorted, or can values appear in any order?
Can the list be empty?
Is a cycle possible, or is the list guaranteed to terminate?
Do you need to mutate the list in place, or can you allocate new nodes?

Ask these as real questions, not as a ritual. The answers change the solution: a doubly linked list makes reversal trivial, and a sorted input makes merging a linear walk instead of a search problem.

If you want to build a consistent way of talking through problems across data structures, the same drawing-and-narrating habit shows up in our full-stack development interview questions guide, which covers how to discuss trade-offs out loud.

The four moves that solve most linked-list questions

Nearly every linked-list interview question is built from a small set of pointer moves. Learn them as moves, not as solutions, and you can assemble an answer on the spot.

Traversal with a single pointer

One pointer walking from head to null is enough when you only need to visit each node once: counting nodes, finding a value, printing the list. Say so plainly. "I only need to look at each node once, so a single pointer is enough." That sentence signals you are choosing the simplest tool that works.

Two pointers at different speeds

Two pointers moving at different rates give you position information without knowing the length in advance. A slow pointer that moves one node per step and a fast pointer that moves two will put the slow pointer at the middle when the fast one reaches the end. The same setup detects a cycle: if there is a loop, the fast pointer laps the slow one.

Prev, curr and next rewiring

When you need to change the direction of the links, you carry three references: the node behind you, the node you are on, and the node ahead. The order of assignments matters, and saying the order out loud is how you avoid losing the rest of the list.

Dummy head plus tail pointer

When you are building a new list or merging two, a dummy node in front removes the special case for the first element. You keep a tail pointer on the last real node and append to it. Justify it in one line: "The dummy node means I never have to check whether the result list is empty."

For each move, give one short algorithm example and narrate the pointer state after each step. "After this iteration, prev is the old head, curr is the second node, and next holds the third." That single sentence is worth more to the interviewer than ten silent lines of code.

Reasoning out loud: a worked example

Take the classic task: reverse a singly linked list in place. Here is how to narrate it.

Start with prev as null, curr as the head, and next unset. Say the invariant: "Everything to the left of curr is already reversed; everything from curr onward is untouched."

Each iteration has three beats:

Save the rest of the list: next = curr.next. Say why: "If I rewire curr now without saving this, I lose every node after it."
Flip the link: curr.next = prev. State the new state: "curr now points backwards, into the reversed part."
Advance both pointers: prev = curr; curr = next. State the state again: "prev is the node I just reversed, curr is the first untouched node."

When curr becomes null, the loop ends and prev is the new head. Say that out loud too, because it is the part people forget to explain.

Check your own work mid-way. Trace two or three nodes on paper and compare with what the code would produce at that point. If your drawing and your code disagree, the drawing is usually right and you have found the bug early.

The same narration works for cycle detection. Move slow one step and fast two steps per iteration. When they meet, explain why in plain language: inside a loop, the fast pointer gains one position on the slow pointer every step, so it must eventually land on it. You do not need a formal proof, just the intuition that the gap closes by one each round.

Time and space complexity without hand-waving

State complexity in terms of n, the number of nodes, and say what n counts. "n is the number of nodes in the list" is a complete sentence and it prevents ambiguity.

Reversing a singly linked list is O(n) time and O(1) extra space. You touch each node once, and you allocate a fixed number of pointer variables regardless of list length. Merging two lists is O(n + m) time, where n and m are the two lengths, with O(1) extra space if you relink existing nodes.

Distinguish O(1) extra space from O(n) extra space, and explain what counts as extra. The output list itself does not count; the auxiliary variables and any new nodes you allocate do.

The common trap is recursion. A recursive reversal looks short, but each call sits on the call stack, so the extra space is O(n) even though the code is three lines. Say that explicitly. Interviewers notice when a candidate flags their own hidden cost.

Practise saying the complexity sentence in one breath: what you traverse, how many times, and what you allocate. "I walk the list once, so O(n) time, and I only keep three pointers, so O(1) extra space." That is the whole answer, and it is the kind of line that makes a linked lists coding interview feel calm rather than rushed.

Edge cases interviewers listen for

You do not need to list every edge case. You need to say which ones you will test and why.

Empty list: does your code return null cleanly, or does it dereference a missing head?
Single node: does the reversal leave the node pointing at itself, or at null?
Two nodes: the smallest case where the order of assignments can break.
A cycle that returns to the head: does your traversal terminate?
Duplicates and unsorted input when merging or removing nodes: does your comparison still hold?

The failure mode worth naming out loud is losing the rest of the list by overwriting next before saving it. If you mention that risk before you write the loop, the interviewer knows you understand why the save step comes first.

When your pointer logic breaks mid-interview

It will happen. The recovery matters more than the mistake.

Pause, re-draw the current state, and say what you expected versus what you see. "I expected curr to be the third node, but it is null, so I advanced one step too far." That sentence turns a bug into evidence of reasoning.

Narrate the fix as a hypothesis, then verify it on a small example. "If I move the advance step after the rewire, the three-node case should work. Let me trace it." Then trace it, out loud, on three nodes.

Avoid silent debugging. The interviewer can only credit reasoning they can hear. Staring at the screen for ninety seconds tells them nothing, even if you solve it.

If you are stuck, describe a slower approach that you know works, then optimise. Copying the list into an array, reversing the array and rebuilding is O(n) extra space but correct. Saying "here is a correct approach, and here is how I would improve it" is a strong answer, not a weak one.

How to practise linked-list questions on your own

Work in short sessions. One problem, spoken aloud, then a written summary of what you missed. The summary is where the learning happens; the problem is just the prompt.

Record yourself and check whether your narration matched the code you actually wrote. Most people find a gap the first time: they said "save next" but typed the rewire first.

Re-solve the same problem a week later without notes to test retention. If you can narrate it cold, you own the move, not the solution.

The narration habit carries across data structures, so it is worth practising it on more than one shape of problem. Our dynamic programming coding interview guide covers reasoning out loud when the state is a table rather than a pointer, and the object-oriented design interview questions guide shows how to answer and then defend your trade-offs. Rotating between them keeps your linked lists coding interview narration sharp, because you are practising the explanation rather than one problem's answer. You can also browse the blog for the rest of the series.

Linked-list questions reward the candidate who draws first, names their pointers, says the complexity plainly and keeps talking when something breaks. Practise the narration as seriously as you practise the code, and the interview becomes a conversation about your reasoning rather than a memory test.

Frequently asked questions

Do I need to memorise linked-list solutions for a coding interview?

No. Memorised solutions tend to fall apart the moment the interviewer changes a constraint, such as allowing a cycle or asking for a sublist reversal. It is more useful to learn the small set of pointer moves — single-pointer traversal, two-speed pointers, prev/curr/next rewiring, and a dummy head with a tail pointer — and practise assembling them for the problem in front of you. That way you can adapt when the question shifts.

How do I explain pointer changes out loud without confusing the interviewer?

Draw the list first, then keep your variable names stable and describe the state after each step rather than the mechanics of each line. A sentence like "after this iteration, prev is the node I just reversed and curr is the first untouched node" gives the interviewer a checkpoint they can follow. Short, repeated state descriptions are easier to track than a long explanation of the code.

What is the time complexity of reversing a linked list, and how should I say it?

Reversing a singly linked list in place is O(n) time and O(1) extra space, where n is the number of nodes. Say it in one breath and define n: "I walk the list once, so O(n) time, and I keep only three pointers, so O(1) extra space." If you use recursion instead, the extra space becomes O(n) because of the call stack, and it is worth saying that out loud.

Should I use a dummy head node, and how do I justify it?

Use one when you are building or merging lists, and justify it in a single sentence: the dummy node removes the special case for the first element, so you never have to check whether the result list is empty. It costs one extra node and makes the loop uniform. If you are only reversing in place, a dummy head adds nothing and you can skip it.

What should I do if I lose track of the pointers during the interview?

Pause, redraw the current state, and say what you expected versus what you actually see. Then state your fix as a hypothesis and verify it by tracing two or three nodes on paper. Keep talking while you do this — silent debugging gives the interviewer nothing to assess, whereas a narrated recovery shows exactly the reasoning they are looking for.

How much time should I spend on edge cases before writing code?

Enough to name the ones that change your approach: empty list, single node, two nodes, and whether a cycle is possible. Say which cases you will test and why, rather than reciting a full list. A few seconds of clarification at the start is usually cheaper than discovering mid-loop that the input can be empty.

Practise one linked-list question out loud today.