Reverse Linked List is rated Easy — but it is the single most important linked list problem you will ever solve. Every harder linked list problem (Reverse in k-Group, Palindrome Linked List, Reorder List) uses this as a building block. If you don't understand the mechanics deeply, those harder problems become nearly impossible.
Our analysis of 10,385 verified interview questions across 259 companies shows it appeared 27 times across 13 companies — including Google, Meta, Apple, Microsoft, Bloomberg, ByteDance, and J.P. Morgan.
This guide goes beyond just showing you the code. We'll break down exactly why each pointer move happens in the iterative solution, how the call stack unwinds in the recursive solution, what the most common mistakes are and why they happen, and how this problem directly unlocks 6 harder variants.
| Metric | Value |
|---|---|
| Total Interview Appearances | 27 verified mentions |
| Companies That Ask It | 13 companies |
| Difficulty | Easy |
| Core Patterns | Linked List, Recursion |
Google, Meta, Apple, Microsoft, Bloomberg, ByteDance, J.P. Morgan, Cisco, Expedia, Accenture, Deloitte, Luxoft, and NetApp.
LeetCode #206 — Reverse Linked List
Given the head of a singly linked list, reverse the list and return the reversed list's head.
Input: head = [1 → 2 → 3 → 4 → 5] → Output: [5 → 4 → 3 → 2 → 1]
Input: head = [1 → 2] → Output: [2 → 1]
Input: head = [] → Output: []A singly linked list node only has a val and a next pointer. There is no prev pointer. The list only knows how to go forward. Your job is to make every node point backward instead — in-place, without creating a new list.
You cannot simply "walk backward" through a singly linked list. Once you redirect curr.next, you permanently lose access to the rest of the list unless you saved it first. This is the entire challenge of the problem.
Most beginners try something like this on their first attempt:
# What beginners try:
curr = head
while curr:
curr.next = prev # ← redirects the pointer
prev = curr
curr = curr.next # ← curr.next is now prev (already changed!)
# we've lost the rest of the list foreverThe problem is the order of operations. The moment you write curr.next = prev, the original curr.next (the next node in the list) is gone. You can never reach it again. So on the next line, curr = curr.next moves curr to prev, not forward — creating an infinite loop or immediately terminating.
The fix is simple but crucial: save curr.next before you redirect anything. This is the entire secret of the iterative solution.
The iterative solution uses three pointers that each have a specific role:
prev — represents the already-reversed portion of the list. Starts at None because the new tail (originally the head) should point to null.curr — the node currently being processed. Starts at head.next_node — a temporary variable that saves curr.next before we break the forward link. Without this, we'd lose the rest of the list.At each iteration, you execute exactly four operations in this exact order:
next_node = curr.next — preserve the forward reference before breaking itcurr.next = prev — point current node backwardprev = curr — the reversed portion now includes currcurr = next_node — move to the next unprocessed nodeWhen curr becomes None, the entire list has been reversed and prev is pointing at the new head (the original last node). Return prev.
Let's trace through [1 → 2 → 3 → 4 → 5] completely:
Initial state:
prev = None
curr = 1
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration 1: curr = Node(1)
next_node = 2 ← save: next_node points to Node(2)
curr.next = None ← redirect: 1 now points to None (prev)
prev = Node(1) ← advance prev: reversed portion is [1 → None]
curr = Node(2) ← advance curr: move forward
State: None ← 1 2 → 3 → 4 → 5
↑prev ↑curr
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration 2: curr = Node(2)
next_node = 3 ← save Node(3)
curr.next = Node(1) ← redirect: 2 now points to 1
prev = Node(2) ← advance prev: reversed portion is [2 → 1 → None]
curr = Node(3) ← advance curr
State: None ← 1 ← 2 3 → 4 → 5
↑prev ↑curr
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration 3: curr = Node(3)
next_node = 4
curr.next = Node(2) ← 3 now points to 2
prev = Node(3)
curr = Node(4)
State: None ← 1 ← 2 ← 3 4 → 5
↑prev ↑curr
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration 4: curr = Node(4)
next_node = 5
curr.next = Node(3) ← 4 now points to 3
prev = Node(4)
curr = Node(5)
State: None ← 1 ← 2 ← 3 ← 4 5
↑prev ↑curr
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Iteration 5: curr = Node(5)
next_node = None ← save None (end of list)
curr.next = Node(4) ← 5 now points to 4
prev = Node(5)
curr = None ← advance curr: now None
State: None ← 1 ← 2 ← 3 ← 4 ← 5
↑prev curr=None
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
curr is None → loop ends → return prev = Node(5)
Result: 5 → 4 → 3 → 2 → 1 → None ✅class ListNode:
def __init__(self, val=0, next=None):
self.val = val
self.next = next
def reverseList(head: ListNode) -> ListNode:
prev = None
curr = head
while curr:
next_node = curr.next # Step 1: save — MUST come first
curr.next = prev # Step 2: redirect — break forward, point back
prev = curr # Step 3: advance prev — grow the reversed portion
curr = next_node # Step 4: advance curr — move to next unprocessed node
# When curr is None, prev points to the new head
return prevclass Solution {
public ListNode reverseList(ListNode head) {
ListNode prev = null;
ListNode curr = head;
while (curr != null) {
ListNode nextNode = curr.next; // Step 1: save
curr.next = prev; // Step 2: redirect
prev = curr; // Step 3: advance prev
curr = nextNode; // Step 4: advance curr
}
return prev; // new head
}
}var reverseList = function(head) {
let prev = null;
let curr = head;
while (curr) {
const nextNode = curr.next; // Step 1: save
curr.next = prev; // Step 2: redirect
prev = curr; // Step 3: advance prev
curr = nextNode; // Step 4: advance curr
}
return prev; // new head
};The recursive approach is more elegant but harder to understand because the key action happens on the way back up the call stack, not on the way down.
Here is the mental model in two phases:
We keep calling reverseList(head.next) recursively, doing nothing except moving forward, until we hit the base case: a node with no next (the last node). That last node becomes our new_head — the head of the final reversed list. We return it all the way up unchanged.
Now, on the way back up, at each stack frame we have access to head (the current node) and we know head.next still points to the next node (which is already part of the reversed suffix). We do two things:
head.next.next = head — the node after head should now point back to head. This wires head into the reversed chain.head.next = None — break the original forward link from head to its successor. If we don't do this, head still points forward AND backward, creating a cycle.Then we return new_head unchanged all the way up. Every stack frame does the same two operations — wire the current node into the reversed chain, break the forward link — and passes the same new_head up.
━━━━━━━━━━━━━━━━ DESCENDING (building call stack) ━━━━━━━━━━━━━━━━
reverseList(1) → calls reverseList(2)
reverseList(2) → calls reverseList(3)
reverseList(3) → head.next is None → BASE CASE
return Node(3) as new_head
━━━━━━━━━━━━━━━━ ASCENDING (unwinding call stack) ━━━━━━━━━━━━━━━━
Back in reverseList(2): head = Node(2), new_head = Node(3)
At this point: 1 → 2 → 3 → None (original forward links still exist)
head.next.next = head
→ Node(3).next = Node(2) ← 3 now points back to 2
→ State: 1 → 2 ← 3 (2 still points forward to 3 too — cycle risk!)
head.next = None
→ Node(2).next = None ← break 2's forward link
→ State: 1 → 2 3 → 2 → None ← wait, let's re-read...
→ Actually: 1 → 2 → None and 3 → 2 → None
(2's forward link is broken, 3 now owns 2)
return new_head (Node 3) ← pass it up unchanged
━━━━━━━━━━━━━━━━
Back in reverseList(1): head = Node(1), new_head = Node(3)
At this point: 1 → 2 → None (2 was already severed from 3)
3 → 2 → None (reversed suffix is built)
head.next.next = head
→ Node(2).next = Node(1) ← 2 now points back to 1
→ State: 3 → 2 → 1 (1 still forward-links... to null already)
head.next = None
→ Node(1).next = None ← confirm 1 points to null (already was)
return new_head (Node 3)
━━━━━━━━━━━━━━━━
Final result: 3 → 2 → 1 → None ✅
new_head = Node(3) returned to original callerhead.next = None is CriticalAfter head.next.next = head, both head and head.next point to each other — a cycle. The line head.next = None breaks head's forward link, converting the cycle into a clean chain. Forgetting this line creates an infinite loop when traversing the result.
def reverseList(head: ListNode) -> ListNode:
# Base case: empty list or single node — already reversed
if not head or not head.next:
return head
# Phase 1 (descend): recurse all the way to the last node
# new_head will be the last node, returned unchanged all the way up
new_head = reverseList(head.next)
# Phase 2 (ascend): wire current node into the reversed chain
# head.next is the node immediately after head — it's already in the reversed suffix
head.next.next = head # make that node point BACK to head
head.next = None # break head's original forward link (prevents cycle)
# Pass new_head (the last node) unchanged up the call stack
return new_headclass Solution {
public ListNode reverseList(ListNode head) {
// Base case
if (head == null || head.next == null) return head;
// Descend to the end, capture new head (last node)
ListNode newHead = reverseList(head.next);
// Ascend: wire current node into reversed chain
head.next.next = head; // node after head points back to head
head.next = null; // break forward link, prevent cycle
return newHead; // propagate unchanged
}
}var reverseList = function(head) {
// Base case
if (!head || !head.next) return head;
// Descend to end, capture new head
const newHead = reverseList(head.next);
// Ascend: wire current node into reversed chain
head.next.next = head; // node after head points back to head
head.next = null; // break forward link, prevent cycle
return newHead; // propagate unchanged
};Writing curr.next = prev before saving next_node = curr.next. Once you redirect curr.next, the original next node is permanently lost. The save step must always come first.
curr.next = prev; next_node = curr.next; ...next_node = curr.next; curr.next = prev; ...
head.next = None (Recursive)After head.next.next = head, nodes point to each other creating a cycle: head → next → head → next → .... Without head.next = None, printing or traversing the result causes an infinite loop. The original tail (node 1 in a 5-node list) already has next = None from its base case return, but every other node needs it explicitly set.
head Instead of prev (Iterative)After the while loop, head still points to the original first node (now the tail). prev is the original last node (now the head). Always return prev.
If head is None (empty list), both solutions handle it correctly — the iterative loop doesn't execute and returns prev = None; the recursive base case returns None. But if you write a custom base case as if not head.next only, you'll get an AttributeError on None.next. Always check if not head or not head.next.
| Approach | Time | Space | Notes |
|---|---|---|---|
| Iterative | O(n) | O(1) | Visits each node once. Only 3 pointer variables regardless of list size. |
| Recursive | O(n) | O(n) | Each call adds a frame to the call stack. For n=5000 nodes, that's 5000 stack frames — risk of stack overflow on very large inputs. |
In interviews, always lead with the iterative solution. The recursive solution is elegant and worth knowing, but the O(n) space cost from the call stack is a real drawback that interviewers will ask about.
Once you own LC #206, these six problems become significantly more approachable — they all use reversal as a core subroutine:
| Problem | How It Builds on #206 | Difficulty |
|---|---|---|
| LC #92 — Reverse Linked List II | Reverse only nodes from position left to right. Requires finding the sublist boundaries first, then applying the same three-pointer reversal on just that segment. | Medium |
| LC #25 — Reverse Nodes in k-Group | Reverse every k consecutive nodes. Checks if k nodes remain, reverses them, reconnects groups. Uses reversal as a helper function called repeatedly. | Hard |
| LC #234 — Palindrome Linked List | Find the middle (Floyd's algorithm), reverse the second half, compare both halves node by node, then optionally restore. Reversal is one of three steps. | Easy |
| LC #143 — Reorder List | Find middle, reverse second half, interleave first and second halves. Identical reversal subproblem as #234. | Medium |
| LC #24 — Swap Nodes in Pairs | Special case of k-group reversal with k=2. Can be solved iteratively by manipulating 4 pointers per pair. | Medium |
| LC #61 — Rotate List | Find the new tail (length - k % length steps in), reverse the connection. Uses reversal concept but solves it via pointer reconnection instead. | Medium |
Do them in this sequence: #206 → #92 → #234 → #143 → #24 → #25. Each problem adds exactly one new concept on top of the previous. By the time you reach #25 (Hard), you'll find it manageable because you've built the foundation incrementally.
Remember the four operations in order: Save → Redirect → Advance prev → Advance curr. If you forget the order in an interview, say "SRAA" mentally and you'll reconstruct the solution correctly every time.
Phase 1 is passive — just descend to the last node. Phase 2 is active — head.next.next = head wires the node in, head.next = None breaks the cycle. Two lines. Same two lines at every stack frame.
[1→2→3] on paper for the recursive version — draw the call stack explicitly.left, apply the three-pointer reversal for right - left steps, then reconnect the four boundary pointers.Tag on DSAPrep.dev under Linked List and Recursion.