How to Reverse a Linked List: Iterative & Recursive

TL;DR

Reversing a linked list means redirecting each node's next pointer — not moving nodes in memory. The standard iterative solution uses three pointers (prev, curr, next), runs in O(n) time, and uses O(1) space. For each node: save the next reference, flip the current link backward, advance both pointers. Return prev as the new head. The recursive approach trusts the sub-problem — reverse everything after head, reattach head at the tail, and cut the old forward link — but adds O(n) call stack space. In interviews, the edge cases (empty list, single node, returning the right head) and your verbal explanation of the pointer invariant matter as much as the code itself. Follow-up questions on sublists, group reversal, and doubly linked lists all use the same core pattern with different boundary rules.

You're probably here because this problem keeps showing up everywhere. LeetCode, mock interviews, phone screens, onsite prep docs, and that one friend who keeps saying, “Just know linked lists, they're easy.” Then you sit down to solve it and realize the hard part isn't the syntax. It's keeping the pointers straight while talking out loud.

That's why this question matters so much in interviews. Knowing how to reverse a linked list is useful, but being able to explain it calmly, avoid losing nodes, and recover if you make a mistake is what moves you forward. Interviewers aren't grading your ability to recite memorized code. They're watching whether you understand what each pointer is doing and whether you can reason under pressure.

Why Interviewers Ask You to Reverse a Linked List

A candidate walks into a technical interview, gets a warmup question or two, and then hears: reverse a singly linked list and return the new head. The problem sounds small. That's exactly why it's effective.

With a linked list, there's nowhere to hide. Arrays let candidates lean on indexing. Hash maps let them reach for a pattern. Reversing a linked list forces direct pointer manipulation, sequential thinking, and careful state management. If you break the chain, you lose the rest of the list. If you forget the final null handling, you can create a cycle. If you can explain the fix clearly, that tells the interviewer a lot.

What the interviewer is actually testing

They're usually checking for a few things at once:

• Pointer discipline: Can you rewire references without losing access to the remaining nodes?
• Control of state: Do you know which variables represent the reversed part, the current node, and the unexplored remainder?
• Edge-case awareness: Do you immediately think about an empty list and a single-node list?
• Communication: Can you talk through your logic instead of solely typing?

A strong answer doesn't start with code. It starts with a short framing statement like: “I'm not changing node values. I'm changing the direction of each next pointer.” That one sentence tells the interviewer you understand the structure.

What usually separates strong candidates

The best candidates don't rush. They narrate. They draw a tiny example such as 1 -> 2 -> 3 -> null, then describe what must be preserved before any pointer changes happen.

A whiteboard answer gets stronger the moment you explain what could go wrong.

If you want to sharpen that style of explanation, a structured technical interview prep guide helps more than grinding random prompts without feedback.

One more thing matters here. Interviewers often ask this problem because it invites follow-ups. Reverse part of the list. Reverse in groups. Do it recursively. Explain the trade-off. A simple question becomes a depth test fast.

Visualizing the Pointer Flip

Before you write code, fix the mental model. You are not moving nodes around in memory. You are changing which node each next reference points to.

Take this list:

A -> B -> C -> null

After reversal, you want:

C -> B -> A -> null

The values stay where they are. The arrows change direction.

Think in two regions

The cleanest way to picture the process is to split the list into two parts:

• The reversed region
• The unreversed region

At the beginning, the reversed region is empty, and the unreversed region is the whole list.

null A -> B -> C -> null

After processing A, the picture becomes:

A -> null B -> C -> null

After processing B:

B -> A -> null C -> null

After processing C:

C -> B -> A -> null

That's the whole trick. Each step removes one node from the front of the unreversed region and attaches it to the front of the reversed region.

Why people lose the list

The most common mental mistake is flipping a pointer too early.

Suppose you're standing on A. If you immediately point A.next backward before saving where A originally went, then B is gone from your reach. The rest of the list didn't disappear from memory, but your program no longer has a path to it.

That's why one temporary reference matters so much. You need to remember the old next node before you rewrite anything.

Practical rule: Save the next node first. Flip second. Advance last.

A simple analogy that actually helps

Think of each node as a train car coupled to the one behind it. You're not picking up train cars and relocating them. You're uncoupling one connection and recoupling it in the opposite direction. If you detach a car without keeping hold of the remaining train, you've made the job harder for yourself immediately.

When you explain how to reverse a linked list in an interview, this visual model helps you stay calm. It also keeps your explanation grounded in state transitions rather than memorized lines of code.

The Iterative Approach Using Three Pointers

This is the version interviewers expect most often. It's the standard in-place approach built around three pointers: prev, curr, and next. It makes one pass over the list, runs in O(n) time, and uses O(1) extra space in iterative form, as described in GeeksforGeeks' linked list reversal explanation.

What each pointer does

Don't just memorize variable names. Know their jobs.

• prev holds the head of the already reversed portion.
• curr is the node you're currently processing.
• next temporarily stores the remainder of the original list before you break the old link.

At the start:

• prev = null
• curr = head

Then, for each node:

1. Save curr.next into next
2. Point curr.next to prev
3. Move prev forward to curr
4. Move curr forward to next

When curr becomes null, prev is the new head.

Whiteboard walkthrough

Use a tiny example. Suppose the list is:

1 -> 2 -> 3 -> null

Initial state:

• prev = null
• curr = 1

First loop:

• save next = 2
• flip 1.next = null
• move prev = 1
• move curr = 2

Now: 1 -> null and 2 -> 3 -> null

Second loop:

• save next = 3
• flip 2.next = 1
• move prev = 2
• move curr = 3

Now: 2 -> 1 -> null and 3 -> null

Third loop:

• save next = null
• flip 3.next = 2
• move prev = 3
• move curr = null

Done: 3 -> 2 -> 1 -> null

That's the explanation I'd give out loud before writing the final code.

Python example

class ListNode:
    def __init__(self, val=0, next=None):
        self.val = val
        self.next = next

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

    while curr is not None:
        next_node = curr.next
        curr.next = prev
        prev = curr
        curr = next_node

    return prev

Java example

class ListNode {
    int val;
    ListNode next;

    ListNode(int val) {
        this.val = val;
    }
}

class Solution {
    public ListNode reverseList(ListNode head) {
        ListNode prev = null;
        ListNode curr = head;

        while (curr != null) {
            ListNode nextNode = curr.next;
            curr.next = prev;
            prev = curr;
            curr = nextNode;
        }

        return prev;
    }
}

How to explain why this works

A lot of candidates write correct code and then struggle to justify it. Keep the explanation plain:

• prev always points to the reversed prefix
• curr always points to the next node to process
• next protects access to the unreversed suffix

That invariant is what makes the loop safe.

If you can state the invariant clearly, you sound like someone who understands the algorithm instead of someone who memorized it.

What works well in interviews

A good delivery sounds like this:

• Start with edge cases
• State that you'll reverse pointers in place
• Name the three pointers
• Walk through one small example
• Write the loop
• End by returning prev

What doesn't work is jumping into code, renaming variables mid-solution, or saying “it just swaps pointers.” It doesn't swap pointers. It reassigns links one node at a time.

The Recursive Approach for a Different Mindset

Recursion is worth knowing because it shows a different way to reason about the same structure. It's less about marching forward with explicit pointer variables and more about trusting the smaller subproblem.

A classic way to think about reversal is the older head-insertion model: take each node from the front of the original list and insert it at the front of a new list. That idea has been a long-standing canonical explanation in systems programming discussions, and Lawrence Kesteloot's write-up on reverse a linked list captures why it remains such a useful mental model. Even when you use recursion, that “take one node and place it in front” mindset still helps.

The recursive leap

The key idea is this: assume you can reverse the list starting at head.next. If that smaller list comes back reversed, then your current node just needs to be attached at the end.

For a node sequence like:

1 -> 2 -> 3 -> null

You trust recursion to reverse:

2 -> 3 -> null

into:

3 -> 2 -> null

Then you make 2 point back to 1, and break 1’s original forward link.

Python example

def reverse_list_recursive(head):
    if head is None or head.next is None:
        return head

    new_head = reverse_list_recursive(head.next)
    head.next.next = head
    head.next = None

    return new_head

Java example

class Solution {
    public ListNode reverseList(ListNode head) {
        if (head == null || head.next == null) {
            return head;
        }

        ListNode newHead = reverseList(head.next);
        head.next.next = head;
        head.next = null;

        return newHead;
    }
}

How to say it out loud

If an interviewer asks for the recursive version, don't start by writing code. Start with the base case.

• If the list is empty, return it.
• If the list has one node, that node is already reversed.

Then explain the leap: reverse everything after head, attach head behind its next node, and cut the old forward pointer.

Recursion gets much easier when you stop trying to see every stack frame at once.

The real trade-off

This version is elegant, and some interviewers like seeing it because it reveals conceptual flexibility. But it's usually not the default answer when space efficiency matters. The recursive calls build up on the call stack, so many interviewers still prefer the iterative solution first.

That said, if you present recursion after solving the iterative version, it can be a strong move. It shows range without making your main answer riskier.

Handling Edge Cases and Common Pitfalls

A linked list reversal solution isn't complete because it works on 1 -> 2 -> 3. It's complete because it still works when the input is awkward, tiny, or easy to mishandle.

Interviewers notice this fast. They don't just want an algorithm. They want evidence that you won't ship pointer bugs into production code.

The checklist I'd run before saying “done”

• Empty list: If head is null, return null.
• Single node: If there's only one node, return that same node.
• Tail termination: The old head becomes the new tail, so it must end with next = null.
• Preserve the remainder: Never rewrite curr.next before storing the old next reference.
• Return the correct head: At the end of the iterative version, return prev, not curr.

That list sounds basic, but it catches most failures.

The mistakes that happen under pressure

The most common bug is losing the rest of the list. A candidate sets curr.next = prev and only afterward realizes they no longer know where to go next.

Another common bug appears in recursion. Candidates reverse the back half correctly, set head.next.next = head, and forget head.next = null. That leaves the old forward edge intact and can create a cycle.

A third issue is returning the original head out of habit. In a successful reversal, the original head is no longer the head. It's the tail.

What to say when you want to sound thorough

Use a quick verbal check at the end:

1. “Empty and single-node inputs are already handled.”
2. “I preserve the next node before changing links.”
3. “I break the old forward connection so the new tail ends at null.”
4. “I return the new head, which is prev in the iterative version.”

That kind of closing summary lands well because it sounds like engineering hygiene, not theatrics.

If you want more repetition on this exact kind of delivery, especially saying your checks out loud while solving, an AI interview coach for technical practice can help you tighten the explanation without making it sound scripted.

Beyond the Basics with Interview Follow-Up Questions

Many candidates think the interview is over once they reverse the list once. It usually isn't. The first solution proves you know the mechanic. The follow-up questions test whether you understand the mechanic well enough to adapt it.

That's a better benchmark anyway. Plenty of people can memorize how to reverse a linked list. Fewer can modify the pattern under pressure.

Reverse a sublist

A common variation is reversing nodes between two positions. The core pointer logic doesn't change. What changes is setup and reconnecting the boundaries.

You usually need to:

• walk to the node just before the reversal starts
• reverse only the target segment
• reconnect the front part to the new segment head
• reconnect the segment tail to the untouched suffix

The hard part isn't the reversal itself. It's keeping track of the nodes around the segment.

Reverse in groups

Another favorite is reversing nodes in chunks. Think groups of fixed size. Again, the core operation is local reversal, but now you repeat it segment by segment and connect each processed block to the next one.

Candidates who only memorized the base problem get exposed when the problem requires deeper reasoning. The pattern is reusable, but you need to reason about boundaries, incomplete groups, and reconnection order.

Doubly linked list changes the problem

If the interviewer switches to a doubly linked list, the reversal idea is related but not identical. Now each node has both next and prev. So your mental model becomes “swap the direction of both relationships” rather than only redirecting next.

That usually simplifies some navigation but adds more bookkeeping per node.

The strongest interview answers don't treat follow-ups as new problems. They treat them as the same pointer pattern with different boundary rules.

How to respond when you don't know the full solution yet

You do not need to instantly produce polished code. A better move is to verbalize the adaptation path.

For example:

• “I'd keep the core reversal loop unchanged.”
• “I need one pointer to the node before the segment.”
• “I need to remember the segment's original head because it becomes the tail after reversal.”
• “Then I reconnect both ends.”

That answer shows transferable understanding. Interviewers often reward that.

A short follow-up drill

Before your next mock interview, practice answering these verbally:

1. How would you reverse only the middle part of a list?
2. How would you reverse every group of nodes of the same size?
3. How would your logic change if each node also had a prev pointer?
4. When would you choose recursion anyway?
5. What bug would create a cycle in the final list?

If you can answer those without rushing, you're in good shape. For more targeted drills, a bank of practice interview questions for technical and behavioral rounds is useful because it forces you to adapt instead of repeating one memorized answer.

Key Takeaways

• Reversing a linked list means changing the direction of each node's next pointer — not moving nodes in memory — and the iterative three-pointer approach (prev, curr, next) solves it in O(n) time and O(1) space with one clean pass through the list.
• The most common bug under interview pressure is rewriting curr.next before saving where curr originally pointed — always save the old next reference first, flip second, and advance last, because once you break the forward link without a saved reference the rest of the list becomes unreachable.
• The recursive approach reverses the sub-list starting at head.next, then sets head.next.next = head and head.next = null — it is conceptually clean and shows range, but adds O(n) call stack space, so most interviewers prefer the iterative solution as the primary answer.
• Edge cases are where interviews are won or lost on this problem — explicitly check for an empty list and a single-node list before writing the loop, confirm the new tail ends at null, and return prev (not curr) as the new head; a verbal checklist before submitting signals engineering discipline, not insecurity.
• Follow-up questions on reversing a sublist, reversing in groups, or handling a doubly linked list all use the same core pointer-flip pattern with different boundary setup and reconnection logic — candidates who understand the underlying invariant adapt to these variations faster than candidates who memorized a single solution.

Qcard helps candidates prepare for interviews without turning them into scripts. If you want support that stays grounded in your real experience, Qcard offers mock interviews, real-time interview coaching, AI-scored practice, and resume-locked talking points designed to keep you authentic and clear under pressure.