Meet Alex and Blake. Both are senior engineers. Both just implemented prefix sum range queries for the same production system. Both wrote unit tests. Both are confident their code is correct.

Alex's formula: prefix[r] - prefix[l]

Blake's formula: prefix[r+1] - prefix[l]

For the query “sum from index 2 to 4” on arr = [3, 1, 4, 1, 5], Alex computes prefix[4] - prefix[2] = 9 - 4 = 5. Blake computes prefix[5] - prefix[2] = 14 - 4 = 10. Different answers. One of them is wrong.

But here's the unsettling part: they both pass most of their test cases. The bug hides in plain sight because most ranges produce plausible-looking numbers. Neither formula gives an obviously absurd result — one is just consistently off by one element.

The difference isn't a logic error. It's a convention error. Alex built a 0-indexed prefix array where prefix[i] = sum(arr[0..i]). Blake built a 1-indexed prefix array where prefix[i] = sum(arr[0..i-1]) and prefix[0] = 0. They're using different definitions of what prefix[i] means, and each definition demands a different formula.

This is the most common source of prefix sum bugs in interviews. Not misunderstanding the concept — misaligning the convention. It's the algorithmic equivalent of mixing up metric and imperial: the math is right, the units are wrong, and the spacecraft misses Mars by 200 kilometers.

Watch them race — and see if you can spot the moment it breaks.

Each robot uses a different formula for the same query. Trace both formulas — do they always agree? What happens when the range starts at the very beginning of the array?

The bug you just caught has a name: the fencepost error. It's the #1 source of prefix sum bugs in interviews — and it's entirely preventable.

Let's trace through both conventions side by side so the difference is visceral, not abstract.

Take arr = [3, 1, 4, 1, 5] and the query “sum from index 1 to 3.”

Convention A: 0-indexed, no sentinel. prefix = [3, 4, 8, 9, 14] where prefix[i] = arr[0] + ... + arr[i]. Formula: prefix[r] - prefix[l-1]. Result: prefix[3] - prefix[0] = 9 - 3 = 6. Correct. But now try l = 0: prefix[r] - prefix[-1]. Crash. You need a special case for ranges that start at the beginning.

Convention B: 1-indexed with sentinel. prefix = [0, 3, 4, 8, 9, 14] where prefix[i] = arr[0] + ... + arr[i-1] and prefix[0] = 0. Formula: prefix[r+1] - prefix[l]. Result: prefix[4] - prefix[1] = 9 - 3 = 6. Correct. And for l = 0: prefix[r+1] - prefix[0] = prefix[r+1] - 0 = prefix[r+1]. No special case. No crash. Just works.

The sentinel — that leading zero — isn't a cosmetic choice. It's a structural guarantee. It means prefix[l] is always a valid index for any l >= 0. Without it, your formula has a hole at the boundary, and boundary holes are exactly where interview bugs breed.

Now test your understanding — this is the exact question that trips people up under interview pressure:

Why is 1-indexed + sentinel strictly safer? Three reasons:

First, it eliminates the boundary special case. Every formula you write works for all valid l and r without an if (l === 0) guard. One formula to rule them all.

Second, it makes the semantics readable. prefix[i] means "the sum of the first i elements." prefix[0] = sum of zero elements = 0. prefix[n] = sum of all n elements. These are self-documenting.

Third, it aligns with how you'll build 2D prefix sums, difference arrays, and Fenwick trees. All of these use the same 1-indexed convention. Choosing it now means you never have to translate between conventions mid-problem — and convention translation under time pressure is where the real bugs come from.

Here's the rule: before you write a single line of prefix sum code in an interview, commit to 1-indexed + sentinel. Write prefix[0] = 0 first. Then build. Then query with prefix[r+1] - prefix[l]. If you start with a different convention and try to switch halfway through, you will get bitten.