Prefix Sum — Stale Snapshot Breaks Range Queries
Updating array after building prefix sum gives wrong results — range queries may return negative sums.
20+ years shipping production code across the stack, with years spent interviewing engineers. Everything here is grounded in real deployments.
- ✓Solid grasp of fundamentals
- ✓Comfortable reading code examples
- ✓Basic production concepts
- Prefix sums precompute cumulative totals in O(n) for O(1) range queries
- Range sum = prefix[right] - prefix[left-1] (0-indexed) or prefix[right+1] - prefix[left] (1-indexed)
- Hashmap variant counts/finds subarrays with target sum in O(n)
- 2D prefix sums use inclusion-exclusion for rectangle queries
- Biggest production pitfall: using prefix sum on mutable data — every update requires full rebuild
Prefix sum is a preprocessing technique that transforms an array into a cumulative sum array, enabling O(1) range sum queries at the cost of O(n) build time and O(n) extra memory. Instead of summing elements from index i to j in O(n) time per query, you compute prefix[i] = sum of elements 0..i, then range sum = prefix[j] - prefix[i-1] (with edge handling).
This pattern solves the fundamental problem of repeatedly summing contiguous subarrays, which naive iteration kills at scale — think real-time analytics dashboards or game leaderboards where latency matters.
In the ecosystem, prefix sum is the simplest member of the range-query family. For mutable arrays, you'd reach for Fenwick trees (BIT) or segment trees instead, as they handle point updates in O(log n). Prefix sum is static: once built, any change requires rebuilding.
It's the right tool when data is immutable or batch-processed, like precomputing daily sales totals or pixel intensities in image processing. Companies like FAANG lean on it heavily in interviews because it's a gateway to understanding how space-time tradeoffs work in practice.
Where prefix sum shines is in problems that don't obviously mention sums — counting subarrays with a target sum, finding equilibrium indices, or detecting subarrays divisible by k. The trick is recognizing that any property expressible as a difference of cumulative values can be optimized this way.
For 2D grids, it extends naturally: prefix[x][y] = sum of rectangle from (0,0) to (x,y), giving O(1) any-rectangle queries. This is the foundation for image blurring, geographic heatmaps, and game-of-life simulations. When you see repeated range queries on static data, prefix sum is your first and often best weapon.
Imagine you're a cashier at the end of a very long checkout line, and someone asks 'what's the total of items 5 through 12?' Instead of adding them up on the spot every single time, you kept a running receipt where each line shows the total SO FAR. Now answering any range question takes one subtraction instead of a full recount. That running receipt IS a prefix sum array — a precomputed table of cumulative totals that turns expensive repeated work into instant lookups.
Range queries are everywhere in software: analytics dashboards summing sales between two dates, game engines calculating cumulative scores, financial systems aggregating transactions over arbitrary windows. The naive approach — loop over the subarray every time — works fine once, but collapses the moment you have thousands of queries on millions of data points. That's not a theoretical problem; it's the exact bottleneck that gets spotted in production and in whiteboard interviews alike.
Prefix sums solve a deceptively simple problem: given an array, answer 'what is the sum of elements from index i to index j?' in O(1) time, after a single O(n) preprocessing pass. The trick is that any subarray sum can be expressed as the difference between two prefix totals. Once you see that, you also start seeing it everywhere — subarray problems, sliding window variants, 2D grid queries, even problems disguised as hash-map lookups all share the same DNA.
By the end of this article you'll be able to: build a prefix sum array from scratch, apply it to solve classic interview problems like 'subarray sum equals K' and 'range sum query', extend the pattern to 2D matrices, and recognise the three or four disguises this pattern wears in real interviews so you can reach for it confidently the moment you see a range or subarray problem.
What Prefix Sum Actually Does for Range Queries
A prefix sum array transforms a static sequence into a structure that answers range sum queries in O(1) time. Precompute cumulative sums from index 0 to i: prefix[i] = arr[0] + arr[1] + ... + arr[i]. Then sum(L, R) = prefix[R] - prefix[L-1] (with prefix[-1] = 0). That's the entire mechanic — no hidden complexity.
Key property: prefix sums are only correct when the underlying array never changes. Any mutation invalidates all subsequent prefix values. This O(1) query speed comes at the cost of O(n) precomputation and zero tolerance for writes. The array must be immutable for the lifetime of the prefix structure.
Use prefix sums when you have a static array and need many range queries — think analytics dashboards, game leaderboards, or financial reports. In real systems, this pattern appears in materialized views and precomputed aggregations. The moment data updates, you either rebuild (O(n)) or switch to a mutable structure like a Fenwick tree.
Building the Prefix Sum Array — The Foundation Everything Else Rests On
A prefix sum array (also called a cumulative sum array) is built by a single left-to-right pass where each cell stores the sum of all elements from index 0 up to and including that index. That's it. The magic comes from what you can do with it afterward.
If you want the sum of elements from index left to index right (inclusive), the formula is:
rangeSum = prefix[right] - prefix[left - 1]
Why does this work? Because prefix[right] already contains the total of everything from 0 to right. Subtracting prefix[left - 1] strips away everything before your window. What remains is exactly the subarray you care about.
The most common implementation uses a 1-indexed prefix array — meaning you shift the prefix array one position to the right and set prefix[0] = 0. This eliminates the need for an annoying left == 0 edge case check. It's a small discipline shift that pays off every time.
Time complexity for building: O(n). Space: O(n). Each query after that: O(1). That trade-off is almost always worth making when you know multiple queries are coming.
package io.thecodeforge.prefixsum; public class PrefixSumFoundation { /** * Builds a 1-indexed prefix sum array. * prefix[i] = sum of scores[0..i-1] * prefix[0] = 0 (sentinel — eliminates left-edge special cases) */ public static int[] buildPrefixSum(int[] scores) { int n = scores.length; int[] prefix = new int[n + 1]; prefix[0] = 0; for (int i = 1; i <= n; i++) { prefix[i] = prefix[i - 1] + scores[i - 1]; } return prefix; } /** * Returns the sum of scores[left..right] (0-indexed, inclusive) * in O(1) time using the 1-indexed prefix array. */ public static int rangeSum(int[] prefix, int left, int right) { // Shift to 1-indexed access: prefix[right+1] - prefix[left] return prefix[right + 1] - prefix[left]; } public static void main(String[] args) { int[] monthlySales = {120, 340, 210, 480, 95, 310, 275}; int[] prefix = buildPrefixSum(monthlySales); System.out.println("Sales months 1-3: " + rangeSum(prefix, 0, 2)); } }
prefix[right+1] - prefix[left] with zero special cases. Interviewers notice clean, case-free code. Make it a reflex.Subarray Sum Equals K — The Classic FAANG Interview Problem
This is the problem that separates candidates who understand prefix sums deeply from those who just memorised the array-building step. The problem: given an array of integers (can include negatives) and a target K, count how many contiguous subarrays have a sum equal to K.
The brute force is O(n²) — try every start and end pair. The prefix sum + hash-map approach is O(n) and it's beautiful.
Here's the insight: a subarray from index i to j sums to K when:
prefix[j] - prefix[i-1] = K ⟹ prefix[i-1] = prefix[j] - K
So as you scan the array left to right, maintaining a running prefix total, you ask: 'how many times have I seen the value currentPrefix - K before?' Each time you've seen it is another valid subarray ending right here. You track the count of each prefix value seen so far in a HashMap.
Negative numbers? No problem — this approach handles them naturally because you're not making any assumptions about monotonicity. That's why it beats a sliding window for this specific problem.
package io.thecodeforge.prefixsum; import java.util.HashMap; import java.util.Map; public class SubarraySumEqualsK { /** * FAANG-standard implementation using the Prefix Sum + Hashmap pattern. * Space Complexity: O(N) | Time Complexity: O(N) */ public static int countSubarraysWithSum(int[] nums, int k) { Map<Integer, Integer> map = new HashMap<>(); // Seed the map with the base case: sum 0 seen once. map.put(0, 1); int sum = 0; int count = 0; for (int num : nums) { sum += num; // If (current_sum - k) was seen before, it means a subarray sums to k. if (map.containsKey(sum - k)) { count += map.get(sum - k); } map.put(sum, map.getOrDefault(sum, 0) + 1); } return count; } public static void main(String[] args) { int[] temperatureDeltas = {3, -1, 2, 1, -2, 4, -3, 2}; int target = 3; System.out.println("Result: " + countSubarraysWithSum(temperatureDeltas, target)); } }
prefixSumCount.put(0, 1) before the loop, you'll miss every subarray that starts at index 0. This is the single most common bug in this problem. It handles the case where the entire prefix up to index j equals K exactly — without it, you silently under-count.2D Prefix Sums — Extending the Pattern to Grid Problems
Once you're comfortable with 1D prefix sums, the 2D extension is a natural next step — and it appears in interviews more than you'd expect (image processing, grid-based games, matrix range queries).
The idea is the same: precompute a cumulative sum table where each cell prefix[row][col] stores the sum of ALL elements in the rectangle from (0,0) to (row, col). Then any rectangular subgrid sum can be computed in O(1) using inclusion-exclusion.
Building the table: prefix[r][c] = grid[r][c] + prefix[r-1][c] + prefix[r][c-1] - prefix[r-1][c-1]
The minus corrects for double-counting the overlap in the top-left corner.
Querying a rectangle from (r1, c1) to (r2, c2): sum = prefix[r2][c2] - prefix[r1-1][c2] - prefix[r2][c1-1] + prefix[r1-1][c1-1]
Again, inclusion-exclusion: start with the big rectangle, subtract the two strips above and to the left, then add back the corner you subtracted twice.
Using a 1-indexed table (padding row 0 and column 0 with zeros) makes the formula work uniformly for every cell, including the top-left corner of the grid — no special cases.
package io.thecodeforge.prefixsum; public class Grid2DPrefixSum { private final int[][] prefix; /** * Constructor builds the 2D prefix table in O(M*N) time. */ public Grid2DPrefixSum(int[][] grid) { int m = grid.length, n = grid[0].length; prefix = new int[m + 1][n + 1]; for (int i = 1; i <= m; i++) { for (int j = 1; j <= n; j++) { prefix[i][j] = grid[i-1][j-1] + prefix[i-1][j] + prefix[i][j-1] - prefix[i-1][j-1]; } } } /** * Queries rectangular sum in O(1). */ public int sumRegion(int r1, int c1, int r2, int c2) { return prefix[r2 + 1][c2 + 1] - prefix[r1][c2 + 1] - prefix[r2 + 1][c1] + prefix[r1][c1]; } public static void main(String[] args) { int[][] grid = {{2, 4, 6}, {5, 3, 8}, {1, 7, 4}}; Grid2DPrefixSum forgeGrid = new Grid2DPrefixSum(grid); System.out.println("Sum of sub-rectangle (0,0) to (1,1): " + forgeGrid.sumRegion(0, 0, 1, 1)); } }
Recognising Prefix Sum Disguises — When the Problem Doesn't Say 'Sum'
The hardest prefix sum problems in interviews don't announce themselves. They look like completely different problems until you squint. Knowing the disguises is the real skill.
Disguise 1 — Binary arrays with equal counts: 'Find the longest subarray with equal numbers of 0s and 1s.' Replace every 0 with -1. Now you want the longest subarray summing to 0. That's a prefix sum + HashMap problem: find the earliest index where you've seen the same prefix value before.
Disguise 2 — Equilibrium index: 'Find an index where the sum of elements to the left equals the sum to the right.' Total sum minus prefix up to that point versus prefix up to that point — a single prefix scan solves it in O(n).
Disguise 3 — Product arrays: 'Build an array where each element is the product of all others.' Left prefix products and right suffix products, combined without division.
Disguise 4 — Difference arrays for range updates: When you need to apply an increment to a range [l, r] repeatedly, you record diff[l] += val and diff[r+1] -= val, then take one prefix sum at the end to get the final state. This is the inverse direction of prefix sums and turns O(n) per update into O(1) per update.
The pattern recognition test: does the problem involve subarrays, ranges, or cumulative aggregation? If yes, ask yourself if a prefix precomputation turns repeated work into O(1) lookups.
package io.thecodeforge.prefixsum; import java.util.HashMap; import java.util.Map; public class PrefixSumDisguises { /** * Disguise 1: Longest Subarray with equal 0s and 1s. * Strategy: Map 0 to -1, then find longest subarray with sum 0. */ public static int findMaxLength(int[] nums) { Map<Integer, Integer> map = new HashMap<>(); map.put(0, -1); int maxlen = 0, count = 0; for (int i = 0; i < nums.length; i++) { count = count + (nums[i] == 1 ? 1 : -1); if (map.containsKey(count)) { maxlen = Math.max(maxlen, i - map.get(count)); } else { map.put(count, i); } } return maxlen; } public static void main(String[] args) { int[] binarySignals = {0, 1, 0, 0, 1, 1, 0}; System.out.println("Longest equal subarray: " + findMaxLength(binarySignals)); } }
Prefix Sum with Modulo — Subarray Divisibility Problems
Another powerful disguise: problems that ask for subarrays whose sum is divisible by K. Example: 'Given an array of integers, return the number of subarrays with sum divisible by K.'
This is a direct extension of the hashmap pattern. Instead of tracking sum - K, you track sum % K. The key insight: if prefix[j] % K == prefix[i-1] % K, then the subarray from i to j has sum divisible by K. Because (prefix[j] - prefix[i-1]) % K = 0.
You seed the map with {0: 1} again — the empty prefix has remainder 0. Then for each prefix remainder, you count how many times it has appeared before.
This works for negative numbers too — just take care to normalise the modulo result to a non-negative value in languages where % can be negative (Java, C++). The formula: ((sum % K) + K) % K.
Time: O(n), Space: O(K) in the worst case (only K distinct remainders).
package io.thecodeforge.prefixsum; import java.util.HashMap; import java.util.Map; public class SubarraysDivisibleByK { public static int countSubarraysDivisible(int[] nums, int k) { Map<Integer, Integer> map = new HashMap<>(); map.put(0, 1); int sum = 0; int count = 0; for (int num : nums) { sum += num; int remainder = ((sum % k) + k) % k; // normalise if (map.containsKey(remainder)) { count += map.get(remainder); } map.put(remainder, map.getOrDefault(remainder, 0) + 1); } return count; } public static void main(String[] args) { int[] stockReturns = {4, 5, -2, 3, 1, -4, 6}; int k = 5; System.out.println("Divisible subarrays: " + countSubarraysDivisible(stockReturns, k)); } }
-3 % 5 returns -3, not 2. Always normalise: ((sum % k) + k) % k. Forgetting this causes the hashmap to miss matches and produce wrong counts. Python's % already returns a non-negative remainder.int mod(int a, int b) that handles negatives.Product of Array Except Self — Why Prefix Thinking Isn't Always Sums
Here's where most devs get stuck: they see 'prefix' and think 'addition'. But the technique is about _cumulative state_, not just addition. The classic 'Product of Array Except Self' problem proves it. You're asked to return an array where output[i] equals the product of all elements except nums[i]. No division allowed.
The trick? Build a prefix product from the left, then a suffix product from the right. For each index i, output[i] = left_product[i-1] * right_product[i+1]. This is the same pattern as prefix sum, but with multiplication. The WHY: you're accumulating a value that represents 'everything before this point' and 'everything after this point'. That's the prefix mindset.
Most juniors reach for division and get burned when zeros appear. The prefix approach sidesteps that entirely. You don't need two arrays either — compute left products in the output array, then multiply by a running suffix product in one backwards pass. O(n) time, O(1) extra space.
// io.thecodeforge — interview tutorial def product_except_self(nums): n = len(nums) result = [1] * n # left pass: prefix products prefix = 1 for i in range(n): result[i] = prefix prefix *= nums[i] # right pass: multiply by suffix suffix = 1 for i in range(n - 1, -1, -1): result[i] *= suffix suffix *= nums[i] return result print(product_except_self([1, 2, 3, 4])) print(product_except_self([-1, 1, 0, -3, 3]))
Longest Subarray With Sum K — When Prefix Sum Meets Hash Maps
The 'Subarray Sum Equals K' problem counts subarrays. But what if they ask for the _longest_ subarray with sum K? That changes the game. You can't just increment a counter — you need to track positions.
Here's the pattern: compute prefix sums as you iterate. For each prefix sum current_sum, store its first occurrence index in a hash map. When you see current_sum - k in the map, the subarray from that index+1 to the current index has sum K. Track the maximum length.
Why does this work? The prefix sum at index j minus the prefix sum at index i gives the sum of subarray [i+1, j]. If that difference equals K, you've found a match. Storing the _first_ occurrence ensures you get the longest possible span. Storing the _last_ would give the shortest. Pick your battles.
The map starts with {0: -1} — edge case for subarrays starting at index 0. Forget that and you'll miss the subarray [0..j] with sum K. Seen it break production code more than once.
// io.thecodeforge — interview tutorial def longest_subarray_sum_k(nums, k): prefix_sum = 0 first_occurrence = {0: -1} max_len = 0 for i, num in enumerate(nums): prefix_sum += num if prefix_sum - k in first_occurrence: length = i - first_occurrence[prefix_sum - k] max_len = max(max_len, length) if prefix_sum not in first_occurrence: first_occurrence[prefix_sum] = i return max_len print(longest_subarray_sum_k([1, -1, 5, -2, 3], 3)) print(longest_subarray_sum_k([-2, -1, 2, 1], 1))
{0: -1}. It's the most common off-by-one bug in prefix sum problems. Interviewers know this — they'll test it with a subarray starting at index 0.Equilibrium Index — The Minimalist Prefix Application
Let's get back to basics with a problem that looks deceptively simple: find an index where the sum of elements to the left equals the sum to the right. That's the equilibrium index. If your first instinct is 'two pointers' or 'brute force sum on each side', you're not thinking like a senior.
The cleanest solution uses prefix sums to compute total sum in O(n) once, then iterate while maintaining a running left sum. For each index i, the right sum is total_sum - left_sum - nums[i]. Compare. No extra array needed. O(n) time, O(1) space.
This is the kind of problem where overcomplicating will sink you. You don't need cumulative arrays or binary search. Just one pass to get total, another to find equilibrium. The WHY: equilibrium problems test your ability to compute both sides of a partition with a single variable. It's the same muscle as 'split array into two equal sum subarrays'.
Edge cases: multiple equilibrium indices exist? Return the first. No equilibrium? Return -1. Negative numbers? Works fine — sum is sum.
Consider this a warm-up. If you can't solve this in 5 minutes, you're not ready for harder prefix variations.
// io.thecodeforge — interview tutorial def find_equilibrium(nums): total = sum(nums) left_sum = 0 for i, num in enumerate(nums): right_sum = total - left_sum - num if left_sum == right_sum: return i left_sum += num return -1 print(find_equilibrium([1, 7, 3, 6, 5, 6])) print(find_equilibrium([1, 2, 3]))
Filters — Why Your Prefix Sum Interview Pattern Needs Guard Rails
A common trap is applying prefix sums everywhere, even when constraints mismatch. The prefix sum pattern is powerful but has specific filters: it thrives when queries are static (no in-place updates) and range-based (subarray, submatrix). If the problem allows BST or BIT for dynamic ranges, don't force prefix sums. Another filter: memory cost. A 2D prefix sum is O(n*m), which is lethal for large grids with sparse queries — here, a Fenwick tree is cleaner. Also, watch for negative values: prefix sums work fine with negatives, but subarray sum equality problems then require hash maps (not just two-pointer). The real filter is: does the problem reduce to a commutative, associative operation? Sum fits; min/max do not. Use prefix products (log-space) or XOR prefix when operation matches. The filter saves you from overengineering: if the problem says "any order" or "permutation", prefix sums likely don't apply. The rule: if you can't answer "what aggregation over contiguous range", stop and reconsider.
// io.thecodeforge — interview tutorial # Filter: static array, range sum query arr = [3, -1, 2, 5] n = len(arr) prefix = [0] * (n + 1) for i in range(n): prefix[i + 1] = prefix[i] + arr[i] # range [l, r] inclusive def range_sum(l, r): return prefix[r + 1] - prefix[l] print(range_sum(1, 3)) # (-1 + 2 + 5) = 6
Topics — The Three Axes That Define Every Prefix Sum Problem
Prefix sum interview problems decompose into three core topics: range query, hash map extension, and modular arithmetic. Range query is the beginner tier: given a static array, compute sums over intervals in O(1) — e.g., Equilibrium Index or standard subarray queries. The hash map extension is where FAANG lives: Subarray Sum Equals K uses prefix sums with a dictionary to find count or length in O(n). This pattern generalises to longest subarray with sum K, also zero-sum subarrays, and even XOR subarrays. The third topic, modulo prefix sums, transforms the problem into remainder tracking. When a problem asks "subarray sum divisible by K", you store prefix_sum % K in a map. Key edge: negative modulo in Python requires (prefix[i] % K + K) % K to avoid wrong buckets. Topics also hide in disguise — look for "average", "median shift" (using prefix count), or "range product" (convert to log or use prefix product with zero handling). Recognising which axis the problem sits on instantly narrows your solution space from 5 patterns to 1.
// io.thecodeforge — interview tutorial # Topic: hash map extension for subarray sum arr = [1, 2, 3, -2, 5] k = 5 prefix_map = {0: 1} current = 0 count = 0 for num in arr: current += num target = current - k count += prefix_map.get(target, 0) prefix_map[current] = prefix_map.get(current, 0) + 1 print(count) # subarrays summing to 5
The Week the Sales Dashboard Reported Negative Revenue
- Prefix sums are static snapshots — treat them like read-only caches.
- Always document the assumption: 'prefix sum is valid only if the underlying array has not changed since build.'
- In high-update environments, choose a BIT or segment tree from the start.
print(prefix[right+1] - prefix[left]) for left=0,right=0 must equal arr[0]Compare with brute-force sum for small rangeSystem.out.println(map.getOrDefault(0, -1) == 1);Print map before loop: must contain {0=1}Check prefix[0][*] and prefix[*][0] are zeroCompute sumRegion(0,0,0,0): must equal grid[0][0]| Approach | Preprocessing | Single Query | Handles Negatives | Space | Best For |
|---|---|---|---|---|---|
| Brute Force (nested loops) | None — O(1) | O(n) per query | Yes | O(1) | One-off single query on a small array |
| 1D Prefix Sum Array | O(n) | O(1) | Yes | O(n) | Multiple range sum queries on a fixed array |
| Prefix Sum + HashMap | O(n) | O(n) total for all queries | Yes | O(n) | Count/find subarrays with a target sum (negatives OK) |
| Sliding Window | None | O(n) total | No — breaks with negatives | O(1) | Max/min subarray problems on non-negative arrays only |
| 2D Prefix Sum Table | O(m×n) | O(1) per rectangle query | Yes | O(m×n) | Repeated rectangular region queries on a grid |
| Difference Array | O(1) per update | O(n) to read final state | Yes | O(n) | Many range-increment updates, read result once |
| Prefix Sum + Modulo HashMap | O(n) | O(n) total for all queries | Yes (with normalisation) | O(K) worst-case | Counting subarrays with sum divisible by K |
| File | Command / Code | Purpose |
|---|---|---|
| io | public class PrefixSumFoundation { | Building the Prefix Sum Array |
| io | public class SubarraySumEqualsK { | Subarray Sum Equals K |
| io | public class Grid2DPrefixSum { | 2D Prefix Sums |
| io | public class PrefixSumDisguises { | Recognising Prefix Sum Disguises |
| io | public class SubarraysDivisibleByK { | Prefix Sum with Modulo |
| ProductExceptSelf.py | def product_except_self(nums): | Product of Array Except Self |
| LongestSubarraySumK.py | def longest_subarray_sum_k(nums, k): | Longest Subarray With Sum K |
| EquilibriumIndex.py | def find_equilibrium(nums): | Equilibrium Index |
| prefix_filter_demo.py | arr = [3, -1, 2, 5] | Filters |
| topics_demo.py | arr = [1, 2, 3, -2, 5] | Topics |
Key takeaways
{0: 1} in the map represents the empty prefix and is never optional.Common mistakes to avoid
4 patternsOff-by-one in the range formula
prefix[right] - prefix[left] instead of prefix[right+1] - prefix[left] with a 1-indexed table silenty excludes the element at right from your sum. Results are consistently one element short.prefix[right] - (left > 0 ? prefix[left-1] : 0)) or 1-indexed (prefix[right+1] - prefix[left]). Stick to it across your whole solution.Forgetting to seed the HashMap with {0: 1} before the loop
prefixSumCount.put(0, 1) as the very first line after declaring the map, before touching the input array.Using prefix sum on mutable data without rebuilding
Ignoring modulo normalisation for negative numbers
(-3) % 5 in Java/C++ returns -3 instead of 2. You'll miss valid matches and under-count.((sum % k) + k) % k. Write a small helper method to avoid forgetting.Interview Questions on This Topic
Given an array of integers that may contain negatives, find the total number of subarrays that sum to exactly K. What's your time complexity and why can't a sliding window solve this?
(currentSum - K) exists in the map — if so, we add its frequency to the count. Seed the map with (0,1) to account for subarrays starting at index 0. Time = O(n), space = O(n). Sliding window fails here because negative numbers mean the window sum doesn't behave monotonically — expanding and contracting the window cannot reliably find all subarrays with a given sum.How would you extend a 1D prefix sum to handle a 2D matrix, and what's the formula to query the sum of any rectangular subgrid in O(1)? Walk me through the inclusion-exclusion reasoning.
dp[i][j] = sum of all elements from (0,0) to (i-1,j-1) using 1-indexed padding. Build formula: dp[i][j] = grid[i-1][j-1] + dp[i-1][j] + dp[i][j-1] - dp[i-1][j-1]. Query for rectangle from (r1,c1) to (r2,c2) (0-indexed): sum = dp[r2+1][c2+1] - dp[r1][c2+1] - dp[r2+1][c1] + dp[r1][c1]. Inclusion-exclusion: start with the whole rectangle from origin, subtract the left and top parts, then add back the overlapping corner that was subtracted twice.You're given an array and told that up to 10,000 range-increment updates will be applied before anyone reads the final values. How does a difference array beat a prefix sum here, and what's the total complexity of both approaches?
diff[l] += val and diff[r+1] -= val (O(1) per update). After all updates, we do one prefix sum scan to recover the final array (O(N)). Total is O(U + N) ~ 10,000 + N, which is far cheaper. That's why difference arrays are the right tool for batch-update-then-read scenarios.Given a binary array, find the longest subarray with equal numbers of 0s and 1s. How would you transform this into a prefix sum problem?
Frequently Asked Questions
A sliding window expands and contracts a window in a single pass and works best for problems with non-negative numbers or where you want max/min window properties. A prefix sum precomputes cumulative totals for instant range lookups and works even with negative numbers. For 'count subarrays summing to K' with negatives, only the prefix sum + HashMap approach works — sliding window breaks because shrinking the window doesn't predictably reduce the sum when negatives are involved.
Use a prefix sum when the array is static (no updates between queries) — it gives O(1) queries with O(n) preprocessing and is much simpler to code. Switch to a segment tree or Fenwick tree when the array can be updated between queries, because those structures support O(log n) point updates alongside O(log n) range queries. Prefix sums don't support updates without a full O(n) rebuild.
Because multiple subarrays can have the same prefix sum, and you need to count ALL of them — not just detect one. If the prefix sum value P has appeared three times before the current index, then there are three different starting points that produce a valid subarray ending right here. The HashMap's integer value tracks that frequency. Without it, you'd only count one match per prefix value and under-report the total.
Yes — as long as the operation you're accumulating is associative and has an inverse. For sums, subtraction is the inverse. But for products, division is the inverse (if no zeros). For XOR, XOR is its own inverse. For min/max, there is no inverse, so you cannot use prefix sums to get range min/max in O(1) — use a segment tree or Sparse Table instead.
Use long (64-bit) in Java/C# or long long in C++. In Python, integers are unbounded. If even 64-bit might overflow (e.g., sums of 10^9 over 10^6 elements), use BigInteger in Java or switch to modular arithmetic where the problem allows. For interview problems, the constraints usually stay within 64-bit range.
20+ years shipping production code across the stack, with years spent interviewing engineers. Everything here is grounded in real deployments.
That's Coding Patterns. Mark it forged?
8 min read · try the examples if you haven't