Algorithm

Odd Even Linked List

Linked List Pattern

Odd Even Linked List

Reorder a singly linked list such that all nodes at odd indices (1st, 3rd, 5th...) come first, followed by all nodes at even indices (2nd, 4th, 6th...). The relative order within each group must be preserved.

CONSTRAINTS
  • The number of nodes is in the range [0, 10,000]
  • -1,000,000 <= Node.val <= 1,000,000
  • Must solve in **O(1) extra space** and **O(N) time**.
EXAMPLE 1
Input: head = [1,2,3,4,5]
Output: [1,3,5,2,4]
The 1st, 3rd, and 5th nodes (values 1, 3, 5) are grouped at the front. The 2nd and 4th nodes (values 2, 4) follow them.
EXAMPLE 2
Input: head = [2,1,3,5,6,4,7]
Output: [2,3,6,7,1,5,4]
The nodes at odd positions (2, 3, 6, 7) are pulled forward, while even-position nodes (1, 5, 4) form the tail.
EXAMPLE 3
Input: head = [1]
Output: [1]
A single node list is already partitioned by definition. No traversal is necessary.
Is this based on the node's value or its position?
Position. The 1st node, 2nd node, 3rd node... regardless of whether the internal value is 10, 5, or 100.
Do relative orders within the odd and even groups need to be preserved?
Yes. If the original order was (1, 3, 5), the output must keep them as (1, 3, 5) without swapping.
What should return for an empty list?
An empty list should return null immediately.

We must regroup a list by position: all nodes sitting at odd indices (1st, 3rd, 5th...) come first, then all nodes at even indices (2nd, 4th, 6th...), and inside each group the original order is kept. Read the word carefully — this is about where a node sits, not its value. In [2,1,3,5,6,4,7] the odd-position nodes are 2, 3, 6, 7 (values are irrelevant), and they end up ahead of 1, 5, 4.

The honest first idea, and its memory cost

The obvious plan: walk the list, drop odd-position nodes into one array and even-position nodes into another, then chain them together. It's correct and easy to reason about, but it spends O(N) extra space on the two buffers — and the problem explicitly demands O(1) space. The buffers exist only to hold nodes aside until we know both groups; if we could grow the two groups in place as we walk, we wouldn't need them at all.

The reframe: braid two chains out of the one you already have

Notice that odd-position and even-position nodes already alternate in the original list: odd, even, odd, even. So a node's next-of-the-same-parity is simply its neighbor's neighbor — two hops away. That means we can grow two separate chains simultaneously without any buffer: an odd chain and an even chain, each advancing by "skip over the other parity." Every node stays exactly where it lives in memory; we only re-point arrows so that odds link to odds and evens link to evens. At the end we bridge the two chains: the tail of the odd chain points to the head of the even chain.

The mechanism: two writers and one anchor

We keep an odd pointer (writing the odd chain, starting at the head) and an even pointer (writing the even chain, starting at the second node). Crucially we also save even_head — the first even node — before the loop, because once we start rewiring we'll need it to perform the final bridge, and it will no longer be reachable as head.next.

python
if not head or not head.next:
    return head                 # 0 or 1 node: nothing to regroup

odd = head
even = head.next
even_head = even                # SAVE the even chain's head for the bridge

while even and even.next:
    odd.next = even.next        # odd links to the next odd (skip the even)
    odd = odd.next
    even.next = odd.next        # even links to the next even (skip the new odd)
    even = even.next

odd.next = even_head            # bridge: odd tail -> start of even chain
return head
Crucial Noteeven_head must be captured before the loop and the bridge done after it — those are the two moves people drop. Skip the save and you cannot reconnect the halves; skip the bridge and the odd chain simply dead-ends, silently discarding every even node. The loop guard even and even.next also does double duty across list lengths without any parity branch: on an even-length list even.next becomes null and the loop stops; on an odd-length list even itself becomes null. In both cases odd finishes exactly on the true last odd node, which is precisely the node the bridge needs.
Worked Example:[1, 2, 3, 4, 5]
- Setup: odd = 1, even = 2, even_head = 2.
- Round 1: 1's next → 3 (skip 2); odd = 3. 2's next → 4 (skip 3); even = 4. Chains so far: odd 1 → 3, even 2 → 4.
- Round 2: 3's next → 5 (skip 4); odd = 5. 4's next → null; even = null. Loop stops.
- Bridge: odd tail 5's next → even_head 2.
- Result: 1 → 3 → 5 → 2 → 4 → null.
The technique this plants

Cost is one pass and a handful of pointers: O(N) time, O(1) space. The reusable idea is splitting one list into two by walking once and routing each node into the correct chain, then joining the chains — no buffers, because the nodes never move, only the arrows do. Hold onto each chain's head (to bridge) and each chain's tail (to append), and remember the tail-null-termination discipline. You'll apply the very same braid, routed by a value test instead of by parity, in Partition List.

Interactive Strategy Visualization
INDEX REORDERING ENGINE

Relative Parity Transformation

1Odd2EvenEVEN HEAD345

Operation Step

Phase 1: Dual Track Setup

We launch two independent cursors. Odd claims the first node, while Even takes the second. We cache the Even Head as an anchor for the final re-join.

Memory Threading

We are essentially threading two disjoint lists through the same memory space, then tying them together at the midpoint.

Strategy: Relative Index Leapfrogging

By advancing cursors two nodes at a time, we reorganize the entire topology in a single O(N) pass using just O(1) extra space.

O(N) Time · O(N) Space Two Buffers
O(N) Time · O(1) Space In-Place Braid