Recognize the shape
before you write the loop.

Four ideas carry the whole topic

None of them are syntax. You already know how a for-loop works; the depth budget goes entirely on why a technique works and how to spot it under disguise.

Start from the brute force

Canonical problem: given a sorted array, is there a pair summing to a target? The brute force checks every pair and ignores the one fact handed to us for free — that the array is sorted.

for i in 0..n:
    for j in i+1..n:
        if a[i] + a[j] == target: return (i, j)

Here’s the waste: when a sum comes out too small, the brute force never eliminates anything — it re-derives “too small / too big” from scratch every time. Put one pointer at each end instead, and sortedness lets you retire a whole row or column of the pair-matrix per step:

Say that sentence out loud in the interview and you pass. Pattern-match “pointers at both ends, move toward the middle” without it and you fall apart the moment the problem is disguised — Container With Most Water, Trapping Rain Water — because you won’t know which pointer to move or why it’s safe.

Why moving the smaller side is always safe

Abstract arguments don’t survive pressure, so make it numeric. Array [1, 4, 6, 8, 11, 15], target 19:

We never checked (1,11), (1,8), (4,11) — but we proved none of the 1-pairs could win before discarding, and the answer survived. Proof-before-discard is the whole game.

Brute force vs two pointers, racing

Same sorted array, same target. Step through it, or hit Play, and watch the comparison counters diverge. The right one barely moves while the left grinds through rows — that’s O(n) vs O(n²) as a count you watched accumulate, not a Big-O claim.

The three shapes of two pointers

There are three distinct geometries, and recognizing which one a problem wants is half the battle.

The simulator steps through one variant of each of the first two shapes. Pick a problem, hit Step, and watch the color-coded regions — finalized (teal), the active window, and the pointer cells (amber) with their role labels. The same visual vocabulary describes structurally different problems.

Three things to notice. In two-sum, cells outside [L, R] dim out — the invariant erasing proven-dead candidates. In remove-duplicates, the teal prefix is the entire answer; everything past it is scratch space you’re allowed to clobber. In valid-palindrome, outer cells turn matched-teal as the pointers march inward — the converging frontier is the only place work happens.

The Dutch national flag

Dijkstra’s problem: given elements of three kinds — red / white / blue, or <pivot / ==pivot / >pivot — sort them in a single pass with O(1) space. Three pointers maintain four regions at all times. Memorize it as a picture:

[ 0 .. low )      < pivot   reds, finalized
[ low .. mid )    == pivot  whites, finalized
[ mid .. high ]   unknown   not yet examined
( high .. n )     > pivot   blues, finalized

mid is the scanner. The logic falls straight out of the invariant: a value below pivot swaps into the red zone (low++ mid++); a value equal to pivot is already placed (mid++); a value above pivot swaps to the blue zone (high--) and — the one rule everyone gets wrong — does not advance mid, because the element pulled in from high is unexamined.

Two pointers vs sliding window

The two are constantly confused. Two pointers works on a static structure: pointers converge from opposite ends or chase each other forward, and the answer is a pair, a partition boundary, or an in-place rearrangement. Movement is driven by a comparison against a fixed target or predicate.

Sliding window maintains a contiguous subarray with a property — longest substring without repeats, smallest subarray summing to ≥ K. Both edges move forward only; the right expands to admit elements, the left contracts to restore the property. The window’s contents are the answer.

Where this lives in real systems

Two pointers is the in-place discipline that shows up wherever you move structured data through a pipeline without paying for copies. Consider a command-line tool that ingests tabular row-and-column data and runs a query pipeline over it: filter rows by a predicate, select columns, sort the result — minimizing copying as data flows through each stage.

Engineers building that kind of tabular-data-query CLI reach for two pointers in two concrete places. First, in-place partitioning: splitting rows into “passes the filter” and “fails the filter” before a sort step is structurally identical to the Dutch-flag partition — track region boundaries and swap rows into place rather than allocating a new collection. Second, boundary-tracking instead of reallocating: filtering rows by walking a write pointer over the same backing buffer mirrors the exact “don’t recompute, just advance a boundary” discipline the interview problems test.

Problem set — 10

Skewed toward custom-bank favorites at research-lab-tier loops: heavy on partition and greedy-proof problems, light on filler. Tap any card to expand. Four are flagged with the widget above that re-parameterizes onto them — reuse the visual, don’t relearn the picture.

Pseudocode templates

Runnable-logic-correct, no hand-waving. The three shapes, one block each.

function converge(a, target):           # a is sorted
    lo = 0
    hi = length(a) - 1
    while lo < hi:
        s = a[lo] + a[hi]               # or any monotonic condition
        if s == target:   return (lo, hi)
        else if s < target: lo = lo + 1      # smaller side proven doomed
        else:              hi = hi - 1      # larger side proven doomed
    return NONE

function compact(a):
    n = length(a)
    if n == 0: return 0
    slow = 0                            # last index of finalized region
    for fast from 1 to n - 1:
        if keep(a[fast], a[slow]):      # e.g. a[fast] != a[slow]
            slow = slow + 1
            a[slow] = a[fast]           # in-place write at the boundary
    return slow + 1                     # length of finalized region

function three_way_partition(a, pivot):
    low = 0                             # a[0 .. low)   < pivot
    mid = 0                             # a[low .. mid) == pivot
    high = length(a) - 1                # a[mid .. high] unknown
    while mid <= high:
        if a[mid] < pivot:
            swap(a[low], a[mid]); low += 1; mid += 1
        else if a[mid] == pivot:
            mid += 1
        else:                           # a[mid] > pivot
            swap(a[mid], a[high]); high -= 1   # do NOT advance mid

Further reading