Which bugs does a dummy head sentinel fail to prevent, and which one does it add?

## The scope of what a sentinel buys A dummy head removes the branches that exist because the first node has no predecessor. That is the entire claim. Candidates who have just learned the trick tend to over-extend it into "sentinels remove the edge cases", and an interviewer will probe that by asking what is still broken. **Unchanged by a sentinel:** - Reaching the last node of a singly-linked list is still O(n) unless a tail reference is kept as well. - Every operation keeps its asymptotic cost; a scan is still a scan. - Search, comparison and payload semantics are untouched. - Anything that depends on holding a reference to a node still depends on holding it. ## The hazard the sentinel adds: a node inside the structure, outside the data The sentinel occupies the chain but represents nothing. Every read path must therefore be written to exclude it, and each place that forgets is a defect: 1. **Off-by-one in size.** A count that starts at the sentinel and walks while non-null returns n+1. If size is maintained incrementally instead, the initialiser must start at zero even though the chain already contains one node. 2. **Leaking the anchor.** Handing callers a reference to the sentinel instead of `sentinel.next` exposes a node with a meaningless payload, and lets external code splice around the structure's own anchor. 3. **Phantom matches.** This is the subtle one. Suppose a ledger stores entries of (signed amount, timestamp) and its sentinel is allocated with the default payload — amount 0, timestamp 0. A report that scans for zero-amount entries, starting from the sentinel rather than from `sentinel.next`, returns one hit that no one ever recorded. The defect survives every test whose fixture avoids the default value, so it typically ships. 4. **A shared anchor.** One sentinel object reused by more than one list is catastrophic: both handles walk the same chain, an insert into one appears in the other, and clearing one strands the other's nodes. Each list must allocate its own sentinel in its own constructor. 5. **Clear and reuse.** Emptying the list means resetting `sentinel.next` to null (or, in a ring, back to the sentinel) — not discarding the sentinel. Code that rebuilds the list from scratch on clear reintroduces the null-handle case the sentinel was there to remove. ## The right fix is positional, not value-based The robust discipline for phantom matches is never to compare the sentinel's payload in the first place: start every traversal at the node after the anchor, and terminate on the structural condition (null in a null-terminated list, the anchor itself in a ring). Guarding by value — "skip the node whose amount is 0 and timestamp is 0" — makes correctness depend on the payload domain, so the first real entry that happens to look like the default is dropped. Where the node type forces a payload to exist, treat it as uninitialised and never read it. ## How to talk about it in an interview Say what the sentinel is for, then volunteer its boundary: it collapses the mutation branches; it does not make the tail cheap, does not change any complexity, and it introduces exactly one new discipline — the anchor is inside the chain and outside the data, so every read path starts one node in. That framing is what separates someone who has used the pattern in anger from someone who read about it. ## A quick checklist for review - Does every traversal start at `sentinel.next`? - Does the size accounting exclude the anchor? - Can a caller ever receive the sentinel? - Is the sentinel allocated per list, not shared? - Does clear reset the anchor rather than replace the list? - Is any search reliant on the anchor's payload not colliding with real data?