# Linked List Problem Solving Techniques: A Complete Guide to LeetCode Mastery

> Master linked list problems with dummy heads, fast/slow pointers, stitch-and-link operations, and systematic pointer updates. Avoid cycles and errors in this complete LeetCode guide.

- Repository: [lucifer/leetcode](https://github.com/azl397985856/leetcode)
- Tags: how-to-guide
- Published: 2026-03-06

---

**Master linked list problems by combining visualization with four core techniques—dummy heads, fast/slow pointers, stitch-and-link operations, and systematic pointer updates—while avoiding cycles and boundary errors.**

Linked list questions on LeetCode and in technical interviews revolve around precise pointer manipulation rather than complex algorithms. This guide distills the proven **linked list problem solving techniques** documented in the `azl397985856/leetcode` repository, specifically analyzing the methodology outlined in [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 31‑226) and its English counterpart [`thinkings/linked-list.en.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.en.md). By internalizing these patterns, you can solve over 90 % of linked list problems using a systematic, repeatable approach.

## The One Principle: Visualize Before You Code

According to [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 31‑38), the single most important habit is **drawing a diagram first**. Sketch nodes as boxes and pointers as arrows to clarify the flow of references before writing code. This visualization prevents subtle bugs such as accidental cycles or losing the tail of a list during splicing. Treat this step as mandatory; it transforms abstract pointer operations into concrete, verifiable steps.

## Two Core Operations in Linked List Problem Solving

The repository identifies two fundamental operations that form the basis of virtually all linked list algorithms (lines 44‑48 in [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md)).

### Pointer Modification

**Pointer modification** involves changing the `next` reference of one or more nodes to alter the list structure. The most common example is **reversal**, where you iteratively redirect `next` pointers to point backward. This operation requires careful tracking of the previous, current, and next nodes to avoid losing the remainder of the list.

### Linking and Splicing

**Linking** (or splicing) connects two separate sub‑lists or reconnects segments after a local modification. For example, after reversing a middle segment, you must link the node preceding the segment to the new head of the reversed portion, and the tail of the reversed portion to the node that followed the segment. The repository refers to this as the **“穿针引线”** (stitch‑and‑link) technique.

## Three Critical Pitfalls to Avoid

[`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 76‑81) highlights three categories of errors that trap even experienced developers.

### Accidental Cycles

Creating a **cycle** unintentionally is the most insidious bug. It typically occurs when you redirect a `next` pointer to a node that is already part of the current traversal path, causing infinite loops. Always verify that your pointer updates do not create backward references unless explicitly required (as in cycle detection problems).

### Boundary Cases

**Boundary cases** include empty lists, single‑node lists, and operations that affect the head or tail. Failing to handle these results in null pointer exceptions or lost nodes. The **dummy head** technique eliminates most head‑related boundary issues by ensuring the head is never a special case.

### Traversal Order

Choosing between **pre‑order** (iterative) and **post‑order** (recursive) traversal affects when pointer updates occur. Pre‑order processes the current node before moving forward, suitable for iterative reversal. Post‑order (recursion) processes the node after the recursive call returns, useful for operations that need to modify links on the way back up the call stack. Using the wrong order leads to lost references or incorrect linking.

## Four Essential Linked List Problem Solving Techniques

The repository’s [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 126‑226) details four practical tricks that form the standard toolkit for linked list algorithms.

### Dummy Head (Virtual Node)

The **dummy head** creates a placeholder node that points to the real head. This technique removes special‑case handling when the head itself might be deleted or modified. By returning `dummy.next` at the end, you automatically handle cases where the original head was removed.

```python
def delete_node(head: ListNode, target: int) -> ListNode:
    dummy = ListNode(0, head)          # virtual head

    prev = dummy
    while prev.next:
        if prev.next.val == target:
            prev.next = prev.next.next  # unlink

            break
        prev = prev.next
    return dummy.next                   # real head may have changed

```

*Referenced in the “虚拟头” trick (linked‑list.md, lines 126‑144).*

### Fast and Slow Pointers

**Fast and slow pointers** move through the list at different speeds—typically 1x and 2x—to find the middle, detect cycles, or locate the k‑th node from the end. When the fast pointer reaches the end, the slow pointer is at the midpoint. If they meet before the end, a cycle exists.

```python
def has_cycle(head: ListNode) -> bool:
    slow = fast = head
    while fast and fast.next:
        slow = slow.next
        fast = fast.next.next
        if slow is fast:
            return True
    return False

```

*Used in problem 141 (linked‑list‑cycle); see the problem file [`problems/141.linked-list-cycle.md`](https://github.com/azl397985856/leetcode/blob/main/problems/141.linked-list-cycle.md).*

### Stitch-and-Link (穿针引线)

**Stitch-and-link** (穿针引线) is the pattern of reconnecting list segments after local modifications, such as reversing a sub‑list between positions *m* and *n*. You save references to the nodes immediately before and after the segment (nodes *a* and *d*), reverse the interior, then link *a* to the new head and the new tail to *d*.

```python
def reverse_between(head: ListNode, m: int, n: int) -> ListNode:
    dummy = ListNode(0, head)
    pre = dummy
    for _ in range(m - 1):
        pre = pre.next                     # a (node before segment)

    start = pre.next                      # b (first node of segment)

    then = start.next                     # c (node after start)

    # reverse the segment (standard in‑place reversal)

    for _ in range(n - m):
        start.next = then.next
        then.next = pre.next
        pre.next = then
        then = start.next

    # a → c (already linked), b → d (already linked)

    return dummy.next

```

*Demonstrates the “a.next = c; b.next = d” stitching pattern found in [`problems/92.reverse-linked-list-ii.md`](https://github.com/azl397985856/leetcode/blob/main/problems/92.reverse-linked-list-ii.md).*

### Pre-Link, Arrange, Null-Check Sequence

The **pre‑link → arrange → null‑check** sequence is a defensive coding pattern to prevent losing references or dereferencing null. First, **pre‑link** by saving a reference to the next node before modifying any `next` pointer. Second, **arrange** by performing the pointer updates. Third, **null‑check** before accessing any node’s properties.

```python
def delete_duplicates(head: ListNode) -> ListNode:
    dummy = ListNode(0, head)
    prev = dummy
    while prev.next:
        # pre‑link: keep a reference to the next node before any change

        nxt = prev.next.next
        if nxt and prev.next.val == nxt.val:
            # arrange: skip all nodes with the same value

            dup_val = prev.next.val
            while nxt and nxt.val == dup_val:
                nxt = nxt.next
            prev.next = nxt                 # link to the first distinct node

        else:
            prev = prev.next
    return dummy.next

```

*Shows the recommended ordering to avoid lost references (linked‑list.md, lines 213‑225).*

## Real-World Applications in the LeetCode Repository

The `azl397985856/leetcode` repository demonstrates these **linked list problem solving techniques** in concrete solutions. In [`problems/25.reverse-nodes-in-k-groups.md`](https://github.com/azl397985856/leetcode/blob/main/problems/25.reverse-nodes-in-k-groups.md), the algorithm combines a **dummy head** with **stitch-and-link** to reconnect reversed k‑node segments without special‑casing the original head.

For cycle detection, [`problems/141.linked-list-cycle.md`](https://github.com/azl397985856/leetcode/blob/main/problems/141.linked-list-cycle.md) and [`problems/142.linked-list-cycle-ii.md`](https://github.com/azl397985856/leetcode/blob/main/problems/142.linked-list-cycle-ii.md) implement **fast and slow pointers** to detect cycles and mathematically locate their entry points. The **pre‑link → arrange → null‑check** sequence appears throughout [`problems/92.reverse-linked-list-ii.md`](https://github.com/azl397985856/leetcode/blob/main/problems/92.reverse-linked-list-ii.md), ensuring that segment reversal does not orphan the remainder of the list.

## Summary

- **Visualization** is the foundational step; drawing diagrams prevents pointer errors before coding begins.
- **Two operations**—pointer modification and linking—form the basis of virtually all linked list algorithms.
- **Three pitfalls**—accidental cycles, boundary cases, and incorrect traversal order—must be checked systematically.
- **Four techniques**—dummy heads, fast/slow pointers, stitch-and-link, and the pre-link sequence—provide reusable patterns for deletion, reversal, and cycle detection.
- The `azl397985856/leetcode` repository implements these patterns in [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) and concrete solutions like [`problems/25.reverse-nodes-in-k-groups.md`](https://github.com/azl397985856/leetcode/blob/main/problems/25.reverse-nodes-in-k-groups.md).

## Frequently Asked Questions

### What is the dummy head technique in linked list problems?

The **dummy head** (or virtual node) is a placeholder node inserted before the actual head of a list. According to [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 126‑144), this technique eliminates special‑case handling when the head itself might be deleted or modified. By returning `dummy.next` at the end of your algorithm, you automatically handle cases where the original head was removed, simplifying boundary logic and preventing null pointer errors.

### How do fast and slow pointers solve linked list problems?

**Fast and slow pointers** move through the list at different speeds—typically the slow pointer advances one node at a time while the fast pointer advances two. As implemented in [`problems/141.linked-list-cycle.md`](https://github.com/azl397985856/leetcode/blob/main/problems/141.linked-list-cycle.md), this technique detects cycles by checking if the pointers meet. It also finds the middle node (when fast reaches the end, slow is at the midpoint) or the k‑th node from the end, all in O(n) time with O(1) space.

### What is the stitch-and-link technique used for reversing linked list segments?

**Stitch-and-link** (穿针引线) is the pattern of reconnecting list segments after a local modification, such as reversing a sub‑list between positions *m* and *n*. As shown in [`problems/92.reverse-linked-list-ii.md`](https://github.com/azl397985856/leetcode/blob/main/problems/92.reverse-linked-list-ii.md), you save references to the nodes immediately before and after the segment (nodes *a* and *d*), reverse the interior bounded by *b* and *c*, then link *a.next* to *c* and *b.next* to *d*. This prevents orphaning the remainder of the list during the reversal.

### How do I avoid losing node references during linked list modifications?

To prevent losing references, follow the **pre‑link → arrange → null‑check** sequence documented in [`thinkings/linked-list.md`](https://github.com/azl397985856/leetcode/blob/main/thinkings/linked-list.md) (lines 213‑225). First, **pre‑link** by saving a reference to the next node before modifying any `next` pointer. Second, **arrange** by performing the pointer updates. Third, **null‑check** before accessing any node’s properties to avoid runtime errors. This defensive ordering ensures you never lose access to the remainder of the list during deletions or reversals.