Linked Lists Coding Interview: Draw First, Then Narrate

Linked list questions usually go wrong because you lose track of pointer state, not because you forgot a trick. In a linked lists coding interview, the fix is a routine: draw three or four nodes with arrows, say what must stay true after each step, change exactly one pointer per line of code, then check that invariant before moving on. That gives the interviewer a picture to follow and gives you a way back when a bug appears. The same routine carries you through reverse, merge, cycle detection and most follow-ups.

Why do linked lists coding interview questions trip people up even when they know the theory?

With an array, the picture in your head barely changes as you work. Index 3 stays index 3, and you can point at it on the whiteboard. A linked list is different: every assignment changes the shape of the structure, and one wrong reassignment can drop the rest of the list with no error message. The problem is state tracking, not syntax.

That is why drawing matters more here than in most topics. When you draw the nodes and arrows first, you give both you and the interviewer a shared reference. When you narrate each pointer move, a slip becomes visible as a slip rather than looking like a misunderstanding of the problem.

You do not need to be fast at this. You need to be legible. An interviewer who can follow your reasoning will often help you past a bug; one who cannot tell what you are doing has to guess, and guessing usually goes badly for the candidate.

The four-step routine: draw, name the invariant, move, check

Use this on every linked list question, including the easy ones. The repetition is the point: it keeps you calm and keeps the interviewer oriented.

Draw three or four nodes with arrows. Label the pointers you plan to use, such as prev, current and next. Leave space to the right for nodes you have not touched yet.
Say what must stay true after each step. That is your invariant. In plain words: "everything to the left of current is already reversed."
Change exactly one pointer per line of code. If a line moves two things, split it. One change per line makes a wrong move easy to spot and easy to undo.
Re-check the invariant before moving on. Point at the drawing and say whether it still holds. If it does not, you have found the bug before the interviewer has to.

An invariant sounds formal but is just a sentence about what your work so far guarantees. Here is a spoken script you can borrow: "I'll keep a prev pointer that always points to the head of the reversed part. Everything before current is finished; everything from current onward is untouched." That single sentence tells the interviewer your plan and your safety condition at once.

Worked example: reversing a singly linked list out loud

Take a list of three nodes: 1 → 2 → 3 → null. Draw it, then talk through it as you code.

Before you start, name the edge cases: an empty list returns null, a single node returns itself unchanged, and two nodes are the smallest case where the loop runs more than once. Mentioning them first shows you have thought about the boundaries before the code gets interesting.

Then narrate line by line:

"I start with prev as null and current at the head."
"I save next so I do not lose the rest of the list."
"I point current.next backwards at prev."
"I advance prev to current."
"I advance current to the saved next."
"When current is null, prev is the new head, so I return it."

Here is the same thing as a short spoken answer you can practise:

"I'll walk the list once with three pointers. prev is the head of the reversed part, current is the node I'm working on, and next is my saved link to the rest. Each step I save next, flip current.next to prev, then move both pointers forward. The invariant is that everything to the left of current is already reversed. At the end, prev points at the old tail, which is the new head."

Then give the complexity with a reason: "One pass over n nodes, so O(n) time. I keep three pointers regardless of list length, so O(1) extra space." The reason matters as much as the answer; it shows you know why the numbers are what they are.

Worked example: detecting a cycle with fast and slow pointers

Draw a list that loops back on itself, for example 1 → 2 → 3 → 4 → 2. Mark a slow pointer moving one node per step and a fast pointer moving two.

Explain the reasoning rather than reciting the code: "The fast pointer gains on the slow one by one node each step. Inside a loop, that gap has to close, so they must meet. It cannot be skipped, because the gap shrinks by exactly one each time." That sentence is the whole argument, and it is what an interviewer is listening for.

If there is no loop, the fast pointer reaches null first and you return false. If there is a loop, the two pointers meet and you return true. State the complexity honestly: O(n) time and O(1) space.

A hash set version is also correct: store each node you visit and check for repeats. It uses extra memory that grows with the list, because you keep a record of every node. Saying that out loud shows you can compare two valid approaches instead of defending one blindly. For more on choosing between pointer strategies, see Two Pointers Coding Interview: A Reasoning Guide for Live Problems.

How do you talk about time and space complexity without sounding rehearsed?

Use a three-part sentence: what you traverse, how many times, and what extra memory you allocate. That pattern keeps the answer specific and stops it from sounding like a memorised line.

Weak: "It's O(n)."

Stronger: "One pass over n nodes, and I only keep three pointers, so constant extra space."

The stronger version works because it gives the interviewer the reasoning behind the number. If they follow up with "what if the list is huge?", you already have the vocabulary to answer.

Watch for the recursion trap. A recursive reverse looks short, but each call sits on the stack, so it uses O(n) stack space even though the code has no explicit pointers. If you propose recursion, say that cost out loud; volunteering it is much better than being asked. For a related reasoning pattern on tree structures, see Binary Search Trees Coding Interview: Reason Out Loud.

The three mistakes that cost the most in linked list interviews

Reassigning before saving next. You flip current.next and the rest of the list is gone. Catch it by making "save next first" a spoken step every time, not a silent habit.

Forgetting a dummy head, then special-casing the first node. In deletion and merge problems, a dummy node in front of the head removes the special case for the first element. If you find yourself writing an if for the head, ask whether a dummy node would delete that branch. For merge and similar problems, the same reasoning appears in Binary Search Trees Coding Interview: Reason Out Loud.

Coding in silence. When you go quiet, the interviewer cannot tell whether a bug is a slip or a misunderstanding. Narrate the invariant and each move, and a slip becomes a small correction instead of a failed answer.

What to do when the interviewer adds a follow-up mid-problem

Extend, don't repeat. Restate the invariant you already have, say what changes, then adjust one pointer rule. That keeps your earlier work visible and shows you can build on it.

Take "reverse in groups of k" as an example. The first thirty seconds of reasoning might sound like this: "My invariant is still that everything left of current is reversed. What changes is that I reverse in blocks of k, so I need to find the end of each block before I flip it, and carry the previous block's tail forward as the new prev." You have not written code yet, but the interviewer can see exactly where you are going.

The general habit is to name what stays the same before you name what changes. For a fuller method, see Respond to Follow-Up Questions in an Interview: Extend, Don't Repeat.

A 20-minute practice loop you can run before the interview

Pick three problems: reverse a singly linked list, merge two sorted lists, and detect a cycle. Run the same loop on each.

Draw the nodes and arrows before writing anything.
Say the invariant out loud in one sentence.
Code while narrating each pointer move.
Say the complexity sentence without looking at your notes.
Record yourself once and listen for silences or skipped invariants.

The recording is the part people skip and the part that helps most. You will hear exactly where you went quiet, and that is where the interviewer would have lost you. If you tend to rush or over-explain, Stop Rambling Interview: A Live Answering Plan gives you a way to tighten the narration without losing the reasoning.

Before you walk in

The linked lists coding interview rewards a visible routine more than a fast first attempt. Draw first, name the invariant, move one pointer at a time, then say the complexity with a reason. Next, run the 20-minute loop once and listen to the recording. That single pass will show you more than another hour of reading solutions.

Frequently asked questions

Should I use a dummy head node even when the problem doesn't seem to need one?

Often yes, when the first node might be removed or replaced. A dummy node in front of the head means every real node has a predecessor, so deletion and merge logic stops special-casing the head. If the problem never touches the first node, such as plain traversal or in-place reversal, a dummy node adds a step without removing a branch. Decide by asking whether the head could change.

Is it acceptable to write the code first and explain afterwards if I'm nervous?

It is allowed, but it costs you. An interviewer who watches silent coding cannot tell whether a wrong line is a slip or a gap in understanding, and they cannot help you early. If nerves make you quiet, say one sentence before you type: the invariant and the pointers you plan to use. That gives them enough to follow, and you can explain in more detail as you go.

How do I handle a linked list question in a language without explicit pointers, like Java or Python?

Talk about references and objects instead of pointers. The reasoning is the same: a variable holds a reference to a node, and reassigning a field changes what the next reference points to. Say "this node's next reference now points at prev" and draw the same arrows. The interviewer cares about the state changes, not the vocabulary of the language.

What if I blank on the fast and slow pointer trick during the interview?

Rebuild it from the question instead of recalling it. Ask yourself what you need to know: whether the list loops. Then reason about two walkers at different speeds in a loop and note that the faster one must catch the slower. Say that reasoning out loud. Even if you cannot finish the code, the interviewer sees a correct line of thought rather than a missing memory.

Practise the draw-first routine out loud and review how each answer landed.