Two Pointers

Two pointers is the technique behind an entire class of problems where a nested loop feels natural but is actually wasted work — because the data has some structure (usually: it's sorted) that lets you rule out large chunks of the search space just by comparing.

What "two pointers" actually means

Instead of one index scanning the whole array while an inner loop re-scans it again, you keep two indices moving through the data, and you decide which one to move based on a comparison — never both blindly, never re-checking work you've already ruled out. Because each pointer only ever moves forward (never backward, never resets), the total number of steps across the *whole* algorithm is bounded by how far each pointer can travel — O(n), not O(n²).

The three shapes this technique actually takes

• Opposite ends, converging inward. One pointer starts at index 0, the other at the last index; each step moves whichever side the comparison says can't possibly be part of a better answer. This needs the data to be sorted (or the comparison to be meaningful regardless of order, like heights in Container With Most Water). Two Sum II, Valid Palindrome, Container With Most Water, Trapping Rain Water, 3Sum, Squares of a Sorted Array.
• Slow / fast, same direction. Both pointers start together and move the same way, but the slow one only advances when it needs to record something — this is how you compact or filter an array in place without extra space. Remove Duplicates, Move Zeroes.
• One pointer per sequence. Two separate sequences (two arrays, or a string against another string), each with its own pointer, advancing independently based on a comparison between them. Merge Sorted Array, Is Subsequence.

Why moving the "wrong" pointer would break it

In the opposite-ends shape, the entire correctness argument rests on one claim: whichever side you move away from can be proven to never produce a better answer than what you already have. Container With Most Water makes this concrete:

// The container's water is capped by the SHORTER of the two walls.
// If height[left] < height[right], every container using "left" paired
// with anything between left+1 and right is STILL capped by height[left]
// -- and narrower, so worse. There's no point ever pairing "left" with
// anything closer than "right" again. Moving "right" instead would throw
// away the one candidate (the current "left") that might still pair
// better with something further in -- that's the bug.
if (height[left] < height[right]) ++left;   // left is the limiting side -- advance it
else --right;

This is the part that actually separates understanding the technique from pattern-matching it: being able to say why the pointer you moved was the correct one to move, not just that the code happens to pass.

Common mistakes

• Using this technique on unsorted data when the opposite-ends shape needs sortedness to be valid — if the problem doesn't guarantee sorted input, you sort first (O(n log n)), which is still better than the O(n²) alternative, but it's an extra step people forget.
• Off-by-one on the stopping condition — left < right vs left <= right changes whether the pointers are allowed to land on the same index, which matters when a single middle element needs to be considered on its own (binary search has the exact same trap).
• Forgetting to skip duplicates in problems that ask for unique combinations (3Sum) — without it, the same triplet gets added multiple times as the pointers pass over repeated values.
• Merging into a buffer from the front when you should merge from the back (Merge Sorted Array) — writing from the front overwrites values in the destination you still need to read.