Skip to main content

206. Reverse Linked List

easyAsked at Linear

Reverse a singly-linked list. Linear uses this to probe pointer manipulation fundamentals and to see whether you can explain both the iterative and recursive versions — and articulate which is preferred in production.

By Alex Chen, Founder, InterviewChamp.AI · Last verified

Source citations

Public interview reports confirming this problem appears in Linear loops.

  • Glassdoor (2025-12)— Cited in recent Linear SWE phone screen reports as a pointer-manipulation warm-up.
  • Blind (2025-10)— Appeared in multiple Linear early-round interview threads.

Problem

Given the head of a singly linked list, reverse the list, and return the reversed list.

Constraints

  • The number of nodes in the list is in the range [0, 5000].
  • -5000 <= Node.val <= 5000.

Examples

Example 1

Input
head = [1,2,3,4,5]
Output
[5,4,3,2,1]

Example 2

Input
head = [1,2]
Output
[2,1]

Example 3

Input
head = []
Output
[]

Approaches

1. Iterative (three-pointer)

Walk the list with prev, curr, and next pointers, redirecting each link in place.

Time
O(n)
Space
O(1)
function reverseList(head) {
  let prev = null;
  let curr = head;
  while (curr !== null) {
    const next = curr.next;
    curr.next = prev;
    prev = curr;
    curr = next;
  }
  return prev;
}

Tradeoff: O(1) extra space. Preferred in production — no call-stack growth. Slightly verbose pointer bookkeeping.

2. Recursive

Recurse to the tail, then relink on the way back up.

Time
O(n)
Space
O(n)
function reverseList(head) {
  if (head === null || head.next === null) return head;
  const newHead = reverseList(head.next);
  head.next.next = head;
  head.next = null;
  return newHead;
}

Tradeoff: Elegant but uses O(n) call stack. Risk of stack overflow on very long lists. Great for explaining recursion to an interviewer; not ideal for production use on unbounded inputs.

Linear-specific tips

Linear interviewers value explicit trade-off reasoning. When you finish the code, voluntarily compare the two approaches: 'Iterative is O(1) space and safe for long lists; recursive is more elegant but O(n) stack depth.' That kind of unprompted analysis is exactly what Linear graders are looking for.

Common mistakes

  • Forgetting to save curr.next before overwriting it — the list becomes unreachable.
  • Not returning prev instead of head at the end — prev is the new head after the loop.
  • Skipping the null/empty-list edge case — the while loop handles it, but the recursive base case needs an explicit check for head.next === null.

Follow-up questions

An interviewer at Linear may pivot to one of these next:

  • Reverse Linked List II (LC 92) — reverse only positions m to n.
  • Palindrome Linked List (LC 234) — reverse the second half and compare.
  • Can you reverse the list without modifying the node values, only by changing pointers?

Solve it now

Free. No sign-up. Python and JavaScript run instantly in your browser.

Output

Press Run or Cmd+Enter to execute

FAQ

Which approach is better?

Iterative for production (O(1) space, no stack overflow risk). Recursive for whiteboard clarity. Say this explicitly — Linear grades trade-off reasoning.

What does prev start as, and why null?

null becomes the new tail's next pointer. After reversal, the original head becomes the tail, and its next should point to null.

How do you handle an empty list?

Both approaches handle null gracefully: the while loop never runs, and iterative returns null (prev's initial value). The recursive base case explicitly returns null.

Practice these live with InterviewChamp.AI

Drill Reverse Linked List and other Linear interview questions under real-loop conditions with instant feedback on your reasoning, complexity claims, and code.

Practice these live with InterviewChamp.AI →