Loading…

easyArraysFrequently asked

Sherlock and Array

Q: How do you solve Sherlock and Array using the Brute Force — Recompute Both Sides approach?

When to use it: State it to fix the definition, then point out it re-sums the right side at every index for O(n²). The literal reading: for each index i, add up everything to its left, add up everything to its right, and compare. **Why it's the natural baseline.** The problem is phrased per-index — 'is there an i where left equals right?' — so the obvious code loops over i and, inside, runs two more loops to build the two sums. It's plainly correct. **The single-element case is free.** When n = 1, both inner loops run zero times, both sums are 0, and we return YES — no special casing needed. **Why we don't ship it.** Re-summing the right side from scratch for every pivot repeats almost all the work. For n = 10⁵ that's ~5 billion additions per query and times out. The fix is to carry a running left sum and derive the right sum in O(1). Time complexity: O(n²). Space complexity: O(1).

Q: How do you solve Sherlock and Array using the Running Prefix Sum (Optimal) approach?

When to use it: The answer they want: one pass, O(1) space, suffix derived from the total. Compute the total once. Then sweep left to right holding `left`, the sum of elements strictly before the current index. At index i the right side is everything except the left part and the pivot, so `right = total − left − arr[i]`. If `left == right`, return YES. **Why the suffix is free.** The total never changes. Once you know how much sits to the left of i, the rest (minus the pivot) must be to the right. That's a subtraction, not a loop — so each index costs O(1) and the whole sweep is O(n). **Why update left after the check.** The invariant is 'left = sum of indices 0..i−1'. At index i we compare *before* folding arr[i] in; only then do we add arr[i] so the invariant holds for i+1. Adding first would wrongly include the pivot in the left side. **Single element and edges.** For n = 1, the loop checks i = 0 with left = 0 and right = total − 0 − arr[0] = 0 → YES. For the first index, left starts at 0 (empty prefix); for the last index, right computes to 0 (empty suffix). All handled by the same formula. **Overflow note.** With n = 10⁵ and values up to 2×10⁴, the total can reach 2×10⁹ — just over the 32-bit signed limit. Use a 64-bit accumulator (long in Java) for total and left to be safe. Time complexity: O(n). Space complexity: O(1).

Arrays & Hashing · 77 of 83 · 7 min

Watson gives Sherlock an array of integers. He asks whether there exists an index such that the sum of the elements to the left of that index equals the sum of the elements to the right of that index.

For each query, print YES if such an index exists, otherwise print NO. The element at the chosen index is counted on neither side.

In plain English

We want a pivot index i that splits the array into a left part (indices 0..i−1) and a right part (indices i+1..n−1) with equal sums; arr[i] itself is in neither part. Because the total is fixed, knowing the running left sum gives the right sum instantly: right = total − left − arr[i]. Sweep once and check equality at each index.

Examples

Example 1

Input: arr = [5]
Output: YES
Note: Single element: left sum = 0, right sum = 0. They're equal, so YES.

Example 2

Input: arr = [1, 2, 3]
Output: NO
Note: i=0: left 0 vs right 5. i=1: left 1 vs right 3. i=2: left 3 vs right 0. No index balances → NO.

Example 3

Input: arr = [1, 2, 3, 3]
Output: YES
Note: At i=2 (value 3): left = 1+2 = 3, right = 3. Equal → YES.

Constraints

1 ≤ t ≤ 10 (number of queries)
1 ≤ n ≤ 10⁵
1 ≤ arr[i] ≤ 2×10⁴
There may be more than one valid index; you only need to know if at least one exists

Clarifying questions4First question: Is the pivot element included in either side?Explore questions

Q1.Is the pivot element included in either side?
No — it sits between the two sides and counts toward neither. The right sum is total minus left sum minus the pivot value.
Q2.What about a single-element array?
It's a YES. The only index has empty left and right, both summing to 0, which are equal.
Q3.Can values be negative or zero?
Per these constraints values are positive, but the running-sum logic works unchanged for negatives — don't write code that assumes positivity.
Q4.If multiple indices balance, which do I report?
The problem only asks existence (YES/NO), so the first match lets you return immediately.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Find an index i where the sum of everything to its left equals the sum of everything to its right; print 'YES' if one exists, else 'NO'. Compute the total once, then sweep left to right keeping a running leftSum. At each i the rightSum is total − leftSum − arr[i]; if leftSum == rightSum you've found a pivot. That's a single O(n) pass with O(1) extra space.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Whether you avoid recomputing the right-hand sum from scratch at every index by maintaining a running left sum and deriving the right sum as total − left − current in O(1).

Where candidates slip

Including the pivot element in one of the sides, recomputing the suffix sum each iteration (O(n²)), or mishandling the single-element case.

How to stand out

State the invariant explicitly: 'after processing index i, left holds the sum strictly before i+1.' Note the single-element YES case and that the pivot is excluded from both sides before writing code.

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Brute Force — Recompute Both Sides	`O(n²)`	`O(1)`	State it to fix the definition, then point out it re-sums the right side at every index for O(n²).	Read
2	Running Prefix Sum (Optimal)Optimal	`O(n)`	`O(1)`	The answer they want: one pass, O(1) space, suffix derived from the total.	Read

Interactive decision treeInteractiveChoose the right approachFollow the branches and learn why each constraint changes the solution.First decision previewtotal = sum(arr)i < n ?NoYesExplore the full tree

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Brute Force — Recompute Both Sides

TimeO(n²)SpaceO(1)

State it to fix the definition, then point out it re-sums the right side at every index for O(n²).

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

For each candidate pivot i, what two quantities do you need to compare?

2Hint 2Explore hint

Sum the elements before i and the elements after i separately for every i.

3Hint 3Explore hint

Return YES the moment those two sums match; if no i works, return NO.

A · Core idea

The literal reading: for each index i, add up everything to its left, add up everything to its right, and compare.

Why it's the natural baseline. The problem is phrased per-index — 'is there an i where left equals right?' — so the obvious code loops over i and, inside, runs two more loops to build the two sums. It's plainly correct.

The single-element case is free. When n = 1, both inner loops run zero times, both sums are 0, and we return YES — no special casing needed.

Why we don't ship it. Re-summing the right side from scratch for every pivot repeats almost all the work. For n = 10⁵ that's ~5 billion additions per query and times out. The fix is to carry a running left sum and derive the right sum in O(1).

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

arr = [1, 2, 3, 3]

Array state

i=2

left {1,2}=3, right {3}=3 → match

[0]

[1]

i ↓

[2]

[3]

Current pointerResolved stateNot processed

Final resultYES

C · Code with teaching comments

Reference implementation previewpublic String balancedSumsBrute(int[] arr) { int n = arr.length; for (int i = 0; i < n; i++) { long left = 0, right = 0; for (int l = 0; l < i; l++) left += arr[l];Explore the full code

solution.javaJava

Brute Force — Recompute Both Sides — reference

2 teaching notes

1
public String balancedSumsBrute(int[] arr) {
2
    int n = arr.length;
3
    for (int i = 0; i < n; i++) {
4
        long left = 0, right = 0;
5
        // Re-sum the entire left part — this inner loop is what makes it O(n²).
6
        for (int l = 0; l < i; l++) left += arr[l];
7
        for (int r = i + 1; r < n; r++) right += arr[r];
8
        // First balanced pivot answers the existence question immediately.
9
        if (left == right) return "YES";
10
    }
11
    return "NO";
12
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.12 lines

D · Why it works and complexityO(n²) timeO(1) spaceOpen the invariant and proofExplore the proof

Every iteration of the brute force recomputes a suffix sum that overlaps almost entirely with the previous iteration's. That redundancy is the signal to switch to a running prefix sum and a constant-time suffix derivation.

ComplexityO(n²) time, O(1) space — For each of n indices you sum up to n other elements → n·n/2 work, O(n²).

E · Edge cases and pitfalls3Including arr[i] in the left or right sum — the pivot belongs to neither.Explore edge cases

Pitfalls

Including arr[i] in the left or right sum — the pivot belongs to neither.
Re-summing the suffix every iteration and timing out on 10⁵ inputs.
Returning NO for a single element — it's actually YES.

03.2

Approach 2 of 2 · Optimal

Running Prefix Sum (Optimal)

TimeO(n)SpaceO(1)

The answer they want: one pass, O(1) space, suffix derived from the total.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

If you know the total of the whole array and the sum of everything to the left of i, can you get the right sum without another loop?

2Hint 2Explore hint

right = total − left − arr[i]. Keep left as a running accumulator as you sweep.

3Hint 3Explore hint

Compare left and right at each i; update left += arr[i] only after the comparison.

A · Core idea

Compute the total once. Then sweep left to right holding left, the sum of elements strictly before the current index. At index i the right side is everything except the left part and the pivot, so right = total − left − arr[i]. If left == right, return YES.

Why the suffix is free. The total never changes. Once you know how much sits to the left of i, the rest (minus the pivot) must be to the right. That's a subtraction, not a loop — so each index costs O(1) and the whole sweep is O(n).

Why update left after the check. The invariant is 'left = sum of indices 0..i−1'. At index i we compare before folding arr[i] in; only then do we add arr[i] so the invariant holds for i+1. Adding first would wrongly include the pivot in the left side.

Single element and edges. For n = 1, the loop checks i = 0 with left = 0 and right = total − 0 − arr[0] = 0 → YES. For the first index, left starts at 0 (empty prefix); for the last index, right computes to 0 (empty suffix). All handled by the same formula.

Overflow note. With n = 10⁵ and values up to 2×10⁴, the total can reach 2×10⁹ — just over the 32-bit signed limit. Use a 64-bit accumulator (long in Java) for total and left to be safe.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

arr = [1, 2, 3, 3]

Array state

i=2, pivot=3

left=3, right=9−3−3=3 → YES

[0]

[1]

i ↓

[2]

[3]

Current pointerResolved stateNot processed

Final resultYES

C · Code with teaching comments

solution.javaJava

Running Prefix Sum (Optimal) — optimal

3 teaching notes

1
public String balancedSums(int[] arr) {
2
    // 64-bit: n·max ≈ 10⁵·2×10⁴ = 2×10⁹ exceeds the 32-bit int range.
3
    long total = 0;
4
    for (int v : arr) total += v;
5
    long left = 0;
6
    for (int i = 0; i < arr.length; i++) {
7
        // Suffix sum in O(1) — total minus the prefix minus the pivot itself.
8
        long right = total - left - arr[i];
9
        if (left == right) return "YES";
10
        // Fold the pivot in AFTER comparing, so left stays 'sum strictly before next
11
        // index'.
12
        left += arr[i];
13
    }
14
    return "NO";
15
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.15 lines

D · Why it works and complexityO(n) timeO(1) spaceOpen the invariant and proofExplore the proof

The whole speedup is one identity: suffix = total − prefix − pivot. Recognizing that a suffix aggregate is recoverable from a global total and a running prefix is the reusable move — it powers equilibrium index, pivot-split, and 'can you partition into equal halves' questions alike.

ComplexityO(n) time, O(1) space — One pass to compute total, one pass to sweep — both O(n), with a couple of scalar variables → O(1) extra space.

E · Edge cases and pitfalls5arr = [5] — i=0: right = 5 − 0 − 5 = 0, left = 0 → YES. Single element always balances.Explore edge cases

Edge cases handled

arr = [5]i=0: right = 5 − 0 − 5 = 0, left = 0 → YES. Single element always balances.
arr = [2, 0, 0, 0]i=0: left 0, right = 2 − 0 − 2 = 0 → YES. The pivot can be the first index with an empty left side.

Pitfalls

Updating left before the comparison — pulls the pivot into the left side.
Using int for total/left — overflows near 2×10⁹.
Adding a second loop to compute the right sum — defeats the O(n) win.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Editable code previewpublic String balancedSums(int[] arr) { long total = 0; for (int v : arr) total += v; long left = 0; for (int i = 0; i < arr.length; i++) {Explore the playground

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Pivot included in a side

The element at the chosen index belongs to neither side. Subtracting only left (not arr[i]) leaks the pivot into the right sum.

Explore the code comparison

Don't write this

long right = total - left;          // still includes arr[i]

Write this instead

long right = total - left - arr[i]; // pivot excluded from both sides

Updating the prefix too early

If you add arr[i] to left before comparing, left no longer represents 'strictly before i' and balanced pivots are missed.

Explore the code comparison

Don't write this

for i, v in enumerate(arr):
    left += v
    right = total - left
    if left == right: return "YES"

Write this instead

for v in arr:
    right = total - left - v
    if left == right: return "YES"
    left += v

32-bit overflow on the total

n up to 10⁵ times values up to 2×10⁴ gives 2×10⁹, just past Integer.MAX_VALUE.

Explore the code comparison

Don't write this

int total = 0;

Write this instead

long total = 0;

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Total minus running prefix gives the suffix in O(1)

Code pattern to memorize

total = sum(arr)
left = 0
for i in 0..n-1:
    right = total - left - arr[i]
    if left == right: return "YES"
    left += arr[i]
return "NO"

Rules to remember

1The pivot element itself belongs to neither side — that's why rightSum subtracts both left and arr[i].
2A single-element array is always YES: left and right are both empty sums = 0.
3Update left after the comparison, so at index i it holds the sum of strictly-left elements.
4Compute total once; recomputing the right sum each step is the O(n²) trap.
5Equality can hold even with the pivot being large — only the two sides must match, the pivot is free.

Use this pattern when

Find a split/pivot point where two running aggregates balance
Equilibrium-index style questions on a 1-D array
Any 'left part equals right part' check you can do in one sweep

Choose another pattern when

You need the actual partition values, not just existence → still one pass but return i
Negative numbers with a 'first/last' tie-break requirement → be careful which index you return
Repeated queries after updates → a Fenwick/segment tree beats re-sweeping

Interview takeaway

Keep a running prefix sum and derive the suffix as total − prefix − current. That O(1) suffix lookup turns a quadratic 'compare both sides at every index' into a single linear sweep — the core equilibrium-index trick.

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Transferable patternEquilibrium / pivot via running prefix sum. Carry a prefix total and derive any suffix as total − prefix − current in O(1), collapsing a two-sided per-index comparison into a single linear sweep. Same trick behind Find Pivot Index and equilibrium-index problems.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Find Pivot Index
Coming soon
Same equilibrium check but return the leftmost index instead of YES/NO.
Equilibrium Index
Identical idea; some variants ask for all such indices.
Partition Equal Subset Sum
Coming soon
Harder cousin — split into two equal-sum subsets (not contiguous) via DP.

Same pattern

←

Minimum Loss

Continue · Next problem

Triple Sum

easyArraysFrequently asked

Sherlock and Array

Arrays & Hashing · 77 of 83 · 7 min

For each query, print YES if such an index exists, otherwise print NO. The element at the chosen index is counted on neither side.

In plain English

Examples

Example 1

Input: arr = [5]
Output: YES
Note: Single element: left sum = 0, right sum = 0. They're equal, so YES.

Example 2

Input: arr = [1, 2, 3]
Output: NO
Note: i=0: left 0 vs right 5. i=1: left 1 vs right 3. i=2: left 3 vs right 0. No index balances → NO.

Example 3

Input: arr = [1, 2, 3, 3]
Output: YES
Note: At i=2 (value 3): left = 1+2 = 3, right = 3. Equal → YES.

Constraints

1 ≤ t ≤ 10 (number of queries)
1 ≤ n ≤ 10⁵
1 ≤ arr[i] ≤ 2×10⁴
There may be more than one valid index; you only need to know if at least one exists

Clarifying questions4First question: Is the pivot element included in either side?Explore questions

Q1.Is the pivot element included in either side?
No — it sits between the two sides and counts toward neither. The right sum is total minus left sum minus the pivot value.
Q2.What about a single-element array?
It's a YES. The only index has empty left and right, both summing to 0, which are equal.
Q3.Can values be negative or zero?
Per these constraints values are positive, but the running-sum logic works unchanged for negatives — don't write code that assumes positivity.
Q4.If multiple indices balance, which do I report?
The problem only asks existence (YES/NO), so the first match lets you return immediately.

Quick interview revision

Understand

30-second explanation

Build the interview-ready mental model before comparing implementations.

Interview contextWhat is testedWhere candidates slipHow to stand outExplore interview context

What's being tested

Whether you avoid recomputing the right-hand sum from scratch at every index by maintaining a running left sum and deriving the right sum as total − left − current in O(1).

Where candidates slip

Including the pivot element in one of the sides, recomputing the suffix sum each iteration (O(n²)), or mishandling the single-element case.

How to stand out

Choose

Compare the available approaches

Use constraints and trade-offs to select the route you can defend in an interview.

Approaches at a glanceCompare before you dive in

#	Approach	Time	Space	When to mention	Jump
1	Brute Force — Recompute Both Sides	`O(n²)`	`O(1)`	State it to fix the definition, then point out it re-sums the right side at every index for O(n²).	Read
2	Running Prefix Sum (Optimal)Optimal	`O(n)`	`O(1)`	The answer they want: one pass, O(1) space, suffix derived from the total.	Read

Learn & trace

Build each solution step by step

Move from the core idea to a visual trace, implementation, proof, and edge cases.

03.1

Approach 1 of 2

Brute Force — Recompute Both Sides

TimeO(n²)SpaceO(1)

State it to fix the definition, then point out it re-sums the right side at every index for O(n²).

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

For each candidate pivot i, what two quantities do you need to compare?

2Hint 2Explore hint

Sum the elements before i and the elements after i separately for every i.

3Hint 3Explore hint

Return YES the moment those two sums match; if no i works, return NO.

A · Core idea

The literal reading: for each index i, add up everything to its left, add up everything to its right, and compare.

The single-element case is free. When n = 1, both inner loops run zero times, both sums are 0, and we return YES — no special casing needed.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

arr = [1, 2, 3, 3]

Array state

i=2

left {1,2}=3, right {3}=3 → match

[0]

[1]

i ↓

[2]

[3]

Current pointerResolved stateNot processed

Final resultYES

C · Code with teaching comments

solution.javaJava

Brute Force — Recompute Both Sides — reference

2 teaching notes

1
public String balancedSumsBrute(int[] arr) {
2
    int n = arr.length;
3
    for (int i = 0; i < n; i++) {
4
        long left = 0, right = 0;
5
        // Re-sum the entire left part — this inner loop is what makes it O(n²).
6
        for (int l = 0; l < i; l++) left += arr[l];
7
        for (int r = i + 1; r < n; r++) right += arr[r];
8
        // First balanced pivot answers the existence question immediately.
9
        if (left == right) return "YES";
10
    }
11
    return "NO";
12
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.12 lines

D · Why it works and complexityO(n²) timeO(1) spaceOpen the invariant and proofExplore the proof

ComplexityO(n²) time, O(1) space — For each of n indices you sum up to n other elements → n·n/2 work, O(n²).

E · Edge cases and pitfalls3Including arr[i] in the left or right sum — the pivot belongs to neither.Explore edge cases

Pitfalls

Including arr[i] in the left or right sum — the pivot belongs to neither.
Re-summing the suffix every iteration and timing out on 10⁵ inputs.
Returning NO for a single element — it's actually YES.

03.2

Approach 2 of 2 · Optimal

Running Prefix Sum (Optimal)

TimeO(n)SpaceO(1)

The answer they want: one pass, O(1) space, suffix derived from the total.

Stuck? Progressive hintsReveal one at a time

1Hint 1Explore hint

If you know the total of the whole array and the sum of everything to the left of i, can you get the right sum without another loop?

2Hint 2Explore hint

right = total − left − arr[i]. Keep left as a running accumulator as you sweep.

3Hint 3Explore hint

Compare left and right at each i; update left += arr[i] only after the comparison.

A · Core idea

Overflow note. With n = 10⁵ and values up to 2×10⁴, the total can reach 2×10⁹ — just over the 32-bit signed limit. Use a 64-bit accumulator (long in Java) for total and left to be safe.

B · Visual dry run

Interactive dry run

Select a frame to connect the decision with its visual state.

arr = [1, 2, 3, 3]

Array state

i=2, pivot=3

left=3, right=9−3−3=3 → YES

[0]

[1]

i ↓

[2]

[3]

Current pointerResolved stateNot processed

Final resultYES

C · Code with teaching comments

solution.javaJava

Running Prefix Sum (Optimal) — optimal

3 teaching notes

1
public String balancedSums(int[] arr) {
2
    // 64-bit: n·max ≈ 10⁵·2×10⁴ = 2×10⁹ exceeds the 32-bit int range.
3
    long total = 0;
4
    for (int v : arr) total += v;
5
    long left = 0;
6
    for (int i = 0; i < arr.length; i++) {
7
        // Suffix sum in O(1) — total minus the prefix minus the pivot itself.
8
        long right = total - left - arr[i];
9
        if (left == right) return "YES";
10
        // Fold the pivot in AFTER comparing, so left stays 'sum strictly before next
11
        // index'.
12
        left += arr[i];
13
    }
14
    return "NO";
15
}

Yellow row = the algorithm's core logic. Amber `//` lines above it = what you'd say out loud.15 lines

D · Why it works and complexityO(n) timeO(1) spaceOpen the invariant and proofExplore the proof

ComplexityO(n) time, O(1) space — One pass to compute total, one pass to sweep — both O(n), with a couple of scalar variables → O(1) extra space.

E · Edge cases and pitfalls5arr = [5] — i=0: right = 5 − 0 − 5 = 0, left = 0 → YES. Single element always balances.Explore edge cases

Edge cases handled

arr = [5]i=0: right = 5 − 0 − 5 = 0, left = 0 → YES. Single element always balances.
arr = [2, 0, 0, 0]i=0: left 0, right = 2 − 0 − 2 = 0 → YES. The pivot can be the first index with an empty left side.

Pitfalls

Updating left before the comparison — pulls the pivot into the left side.
Using int for total/left — overflows near 2×10⁹.
Adding a second loop to compute the right sum — defeats the O(n) win.

Practice

Try the solution yourself

Edit the optimal implementation, test another input, and observe the result.

Editable code previewpublic String balancedSums(int[] arr) { long total = 0; for (int v : arr) total += v; long left = 0; for (int i = 0; i < arr.length; i++) {Explore the playground

Try it — Java· run a complete program; method snippets need a driver

Avoid mistakes

Recognize the interview traps

Understand why common attempts fail before reviewing the corrected implementation.

Pivot included in a side

The element at the chosen index belongs to neither side. Subtracting only left (not arr[i]) leaks the pivot into the right sum.

Explore the code comparison

Don't write this

long right = total - left;          // still includes arr[i]

Write this instead

long right = total - left - arr[i]; // pivot excluded from both sides

Updating the prefix too early

If you add arr[i] to left before comparing, left no longer represents 'strictly before i' and balanced pivots are missed.

Explore the code comparison

Don't write this

for i, v in enumerate(arr):
    left += v
    right = total - left
    if left == right: return "YES"

Write this instead

for v in arr:
    right = total - left - v
    if left == right: return "YES"
    left += v

32-bit overflow on the total

n up to 10⁵ times values up to 2×10⁴ gives 2×10⁹, just past Integer.MAX_VALUE.

Explore the code comparison

Don't write this

int total = 0;

Write this instead

long total = 0;

Revise

Carry the pattern into the interview

Quick interview revision

Pattern to remember

Total minus running prefix gives the suffix in O(1)

Code pattern to memorize

total = sum(arr)
left = 0
for i in 0..n-1:
    right = total - left - arr[i]
    if left == right: return "YES"
    left += arr[i]
return "NO"

Rules to remember

1The pivot element itself belongs to neither side — that's why rightSum subtracts both left and arr[i].
2A single-element array is always YES: left and right are both empty sums = 0.
3Update left after the comparison, so at index i it holds the sum of strictly-left elements.
4Compute total once; recomputing the right sum each step is the O(n²) trap.
5Equality can hold even with the pivot being large — only the two sides must match, the pivot is free.

Use this pattern when

Find a split/pivot point where two running aggregates balance
Equilibrium-index style questions on a 1-D array
Any 'left part equals right part' check you can do in one sweep

Choose another pattern when

You need the actual partition values, not just existence → still one pass but return i
Negative numbers with a 'first/last' tie-break requirement → be careful which index you return
Repeated queries after updates → a Fenwick/segment tree beats re-sweeping

Interview takeaway

Continue

Transfer the pattern to another problem

Use a direct variation or pattern sibling to prove the idea is reusable.

Practice queueDirect variations and pattern siblings

Direct follow-ups

Find Pivot Index
Coming soon
Same equilibrium check but return the leftmost index instead of YES/NO.
Equilibrium Index
Identical idea; some variants ask for all such indices.
Partition Equal Subset Sum
Coming soon
Harder cousin — split into two equal-sum subsets (not contiguous) via DP.

Same pattern

←

Minimum Loss

Continue · Next problem

Triple Sum