How do you approach Find Pivot Index?

The brute force recomputes both sides at every index, which is O(n^2). You only need the total.

What is the time complexity of Find Pivot Index?

Time complexity: O(n) - two passes.. Space complexity: O(1).

What are common mistakes on Find Pivot Index?

Not seeding the map with a zero-sum prefix, which loses every subarray starting at index 0. Counting the current prefix before checking for its complement, so a zero-sum range matches itself. Mixing inclusive and exclusive bounds between building the array and querying it - a consistent, invisible off-by-one.

gitGood.dev

← Back to problems

Find Pivot Index

EasyAlgorithms

Description

Given an array of integers `nums`, return the **leftmost pivot index**. The pivot index is the index where the sum of all numbers **strictly to the left** equals the sum of all numbers **strictly to the right**. If the index is on the left edge, the left sum is `0` (an empty sum); the same applies to the right edge. Return `-1` if no such index exists.

Example 1

Input: nums = [1,7,3,6,5,6]

Output: 3

Example 2

Input: nums = [1,2,3]

Output: -1

Example 3

Input: nums = [2,1,-1]

Output: 0

Constraints

- 1 <= nums.length <= 10^4 - -1000 <= nums[i] <= 1000 - Return the LEFTMOST valid index when several qualify.

Find Pivot Index: approach, complexity and pitfalls

An easy prefix sum problem, graded against 6 test cases (3 of them hidden).

The pattern: Prefix Sum

Precomputed cumulative totals so any range query becomes one subtraction.

Reach for it when you see: Repeated range-sum queries, or counting subarrays that sum to a target.

More Prefix Sumproblems →

If you are stuck

Show the 3-step hint ladder

The brute force recomputes both sides at every index, which is O(n^2). You only need the total.
Compute the total sum first. Then sweep left to right carrying leftSum.
At index i, rightSum = total - leftSum - nums[i]. Compare it to leftSum, then add nums[i] to leftSum before moving on.

The optimal approach

Show the approach: One total, one sweep

The naive approach recomputes the left and right sums at every candidate index - O(n^2). The insight is that the right sum is not independent information: once you know the array total and the running left sum, the right sum is forced.

```

rightSum = total - leftSum - nums[i]

```

So compute the total once, then sweep, comparing `leftSum` to that expression at each index and folding `nums[i]` into `leftSum` afterwards. Returning on the first match gives the leftmost pivot for free.

Negative numbers are handled correctly by this arithmetic - a common trap is assuming sums grow monotonically and trying to use two pointers, which breaks the moment a negative value appears.

Time: O(n) - two passes.
Space: O(1)

The full reference solution in every supported language stays in the editor above - reveal it there once you have had a real attempt.

What the tests check

Read off this problem's own test suite, so these are the cases a submission actually has to survive.

Single element. A one-element case is included. Two-pointer and window solutions frequently return the wrong thing when the two indices start out equal.
Duplicate values. Repeated values appear in the input, so any logic that assumes distinct elements - or that skips over equal neighbours - is exercised.
Negative numbers. The suite includes negative values. Running-sum, min/max seeding and any "initialise to zero" step need to handle them.
Zero. Zero appears in the input, which is the value most likely to break a truthiness check used in place of an explicit comparison.

Common Prefix Sum mistakes

These apply to the pattern as a whole, not just this problem.

Not seeding the map with a zero-sum prefix, which loses every subarray starting at index 0.
Counting the current prefix before checking for its complement, so a zero-sum range matches itself.
Mixing inclusive and exclusive bounds between building the array and querying it - a consistent, invisible off-by-one.