Mid-level 5 min · March 05, 2026

Next Greater Element — O(n²) Timed Out at 10k Updates/sec

10,000 updates/sec caused 30+ second timeouts from O(n²).

N
Naren · Founder
Plain-English first. Then code. Then the interview question.
About
 ● Production Incident 🔎 Debug Guide
Quick Answer
  • Next Greater Element finds the first larger value to the right of each array element
  • The monotonic stack processes each element once — O(n) time, O(n) space
  • Stack stores indices, not values — duplicates don't break resolution
  • Performance: 10,000 elements processed in ~0.2ms vs 100ms brute force
  • Production insight: Without a stack, real-time stock alerts would lag hours behind
  • Biggest mistake: Pushing values instead of indices — wrong answers with duplicates
Plain-English First

Imagine you're standing in a queue at a theme park, and everyone wants to know: 'Who is the first taller person standing behind me?' You could turn around and check every single person one by one — but that's exhausting. A smarter move? Use a notepad to track people who haven't found their 'taller neighbour' yet, and cross them off the moment someone taller shows up. That notepad is your stack, and this exact idea is the Next Greater Element algorithm.

Every time a stock trader asks 'when will this stock price exceed today's value again?' or a weather app calculates 'how many days until a warmer day?', they're solving a variant of the Next Greater Element problem. It's not an academic curiosity — it's a pattern that shows up constantly in time-series analysis, histogram calculations, and real-time data stream processing. If you've ever felt like brute-force nested loops were the only way to compare elements across an array, this article will change how you think about sequential data.

The core problem is this: given an array of numbers, for each element find the first element to its right that is strictly greater than it. The naive approach — check every element against every other element to its right — costs O(n²) time. With millions of data points, that's catastrophically slow. The stack-based solution does the same job in a single pass, O(n) time, by remembering only the elements that are still 'waiting' to find their greater neighbour.

By the end of this article you'll understand not just how the monotonic stack solution works, but exactly why the stack is the right data structure here, when to reach for this pattern in the wild, how to handle circular arrays (a classic interview twist), and which gotchas trip up even experienced developers. You'll walk away with fully runnable Java code, a clear mental model, and the confidence to answer any interview variant of this question.

Next Greater Element — Plain English and Algorithm

For each element in an array, find the first element to its right that is strictly greater. If none exists, the answer is -1.

Naive approach: for each element, scan right until a greater one is found. O(n^2).

Optimal approach — monotonic decreasing stack: 1. Initialize empty stack (stores indices). 2. For i from 0 to n-1: a. While stack non-empty and arr[stack[-1]] < arr[i]: pop j. result[j] = arr[i]. b. Push i. 3. Any index remaining in stack: result[j] = -1.

Worked example on [2, 1, 2, 4, 3]: i=0(2): push 0. stack=[0]. i=1(1): arr[0]=2 >= 1. Push 1. stack=[0,1]. i=2(2): arr[1]=1 < 2. Pop 1. result[1]=2. arr[0]=2 >= 2. Push 2. stack=[0,2]. i=3(4): arr[2]=2 < 4. Pop 2. result[2]=4. arr[0]=2 < 4. Pop 0. result[0]=4. Push 3. stack=[3]. i=4(3): arr[3]=4 >= 3. Push 4. stack=[3,4]. End: result[3]=-1, result[4]=-1. Result: [4, 2, 4, -1, -1].

Production Insight
Real-world arrays often have 10^5+ elements; the naive O(n²) will timeout.
Always benchmark your code with the expected maximum input size.
If you see O(n²), you're probably missing a stack or hash map.
Key Takeaway
The algorithm is simple, but the stack pattern is what makes it O(n).
Store indices, not values — always.
Result is populated during pop events, not push.

The Brute-Force Baseline — And Why It Breaks Down

Before reaching for the elegant solution, let's be honest about the naive one. For each element at index i, you scan every element to its right until you find one that's larger. The moment you find it, that's your answer. If you reach the end without finding one, the answer is -1.

This works perfectly for small arrays. Write it once and you'll understand the problem deeply — that's actually valuable. The problem is cost. For an array of size n, the worst case is a descending array like [5, 4, 3, 2, 1]. Every element scans all the way to the right and finds nothing. That's n + (n-1) + (n-2) + ... + 1 comparisons — O(n²) time.

At 10,000 elements that means up to 100 million comparisons. At 1 million elements (totally normal for financial data), you're looking at a trillion operations. The brute force doesn't just 'run slow' — it becomes completely unusable. This is the exact moment where understanding data structures stops being academic and starts being a professional skill.

NextGreaterElementBruteForce.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
public class NextGreaterElementBruteForce {

    /**
     * For each element, scan rightward to find the first element
     * that is strictly greater. Returns -1 if none exists.
     *
     * Time:  O(n^2) — nested loops over the array
     * Space: O(n)   — result array
     */
    public static int[] findNextGreaterBruteForce(int[] prices) {
        int totalElements = prices.length;
        int[] nextGreater = new int[totalElements];

        for (int currentIndex = 0; currentIndex < totalElements; currentIndex++) {
            // Assume no greater element exists to the right
            nextGreater[currentIndex] = -1;

            // Scan every element to the right of currentIndex
            for (int lookAheadIndex = currentIndex + 1; lookAheadIndex < totalElements; lookAheadIndex++) {
                if (prices[lookAheadIndex] > prices[currentIndex]) {
                    // Found the first greater element — record it and stop scanning
                    nextGreater[currentIndex] = prices[lookAheadIndex];
                    break;
                }
            }
        }
        return nextGreater;
    }

    public static void main(String[] args) {
        int[] stockPrices = {73, 74, 75, 71, 69, 72, 76, 73};

        int[] result = findNextGreaterBruteForce(stockPrices);

        System.out.println("Stock Price  →  Next Greater Price");
        System.out.println("-------------------------------------");
        for (int i = 0; i < stockPrices.length; i++) {
            String nextVal = result[i] == -1 ? "none" : String.valueOf(result[i]);
            System.out.printf("    %-6d   →      %s%n", stockPrices[i], nextVal);
        }
    }
}
Output
Stock Price → Next Greater Price
-------------------------------------
73 → 74
74 → 75
75 → 76
71 → 72
69 → 72
72 → 76
76 → none
73 → none
Why Start Here:
Always implement the brute-force solution first in an interview. It proves you understand the problem, gives you a reference to test your optimised solution against, and interviewers explicitly want to see this thought process before you jump to the clever answer.
Production Insight
In a recent incident, a financial data pipeline crashed because O(n²) on 500k rows took 12 hours.
The team assumed 'small data' and didn't profile before deployment.
Never ship O(n²) to production without a hard size cap.
Key Takeaway
The brute force is educational but deadly in production.
Always estimate worst-case complexity before coding.
If you see O(n²), you're probably missing a stack or hash map.

The Monotonic Stack — One Pass, O(n) Time

Here's the insight that makes everything click: when you're scanning left to right and you encounter a new element, it might be the 'next greater' answer for several previous elements simultaneously. The brute force misses this — it answers one question at a time. The stack lets you answer many questions at once.

The stack stores elements that are 'waiting' — they've been seen, but haven't found their next greater neighbour yet. Crucially, the stack stays in decreasing order from bottom to top (that's what makes it a monotonic stack). When a new element arrives: 1. While the stack isn't empty AND the new element is greater than the top of the stack — pop the top, and record the new element as its answer. 2. Push the new element onto the stack.

After one full pass, anything left in the stack never found a greater element, so their answer is -1.

Why does this work? Every element is pushed once and popped at most once. That's O(n) operations total, regardless of array shape. The stack ensures you never re-check a pair you've already resolved — you're spending zero effort on dead comparisons.

NextGreaterElementStack.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
import java.util.Arrays;
import java.util.Stack;

public class NextGreaterElementStack {

    /**
     * Uses a monotonic decreasing stack to find the next greater element
     * for every position in a single left-to-right pass.
     *
     * Time:  O(n) — each element is pushed and popped at most once
     * Space: O(n) — stack can hold at most n elements (e.g. descending input)
     */
    public static int[] findNextGreater(int[] temperatures) {
        int totalDays = temperatures.length;
        int[] nextWarmerTemp = new int[totalDays];

        // Fill with -1 as the default: "no warmer day found"
        Arrays.fill(nextWarmerTemp, -1);

        // Stack holds INDICES (not values) so we can update the result array
        Stack<Integer> waitingIndices = new Stack<>();

        for (int today = 0; today < totalDays; today++) {

            // While today's temperature beats the temperature at the top of the stack...
            while (!waitingIndices.isEmpty()
                    && temperatures[today] > temperatures[waitingIndices.peek()]) {

                // ...the day on top of the stack has found its answer: today's temperature
                int resolvedDay = waitingIndices.pop();
                nextWarmerTemp[resolvedDay] = temperatures[today];
            }

            // Today hasn't found ITS next greater yet — add it to the waiting list
            waitingIndices.push(today);
        }

        // Any index still in the stack had no greater element to its right — stays -1
        return nextWarmerTemp;
    }

    public static void main(String[] args) {
        // Real-world framing: daily temperatures, find the next warmer day's temperature
        int[] dailyTemperatures = {73, 74, 75, 71, 69, 72, 76, 73};

        int[] result = findNextGreater(dailyTemperatures);

        System.out.println("Day  │ Temp │ Next Greater Temp");
        System.out.println("─────┼──────┼──────────────────");
        for (int day = 0; day < dailyTemperatures.length; day++) {
            String answer = result[day] == -1 ? "none" : String.valueOf(result[day]);
            System.out.printf(" %-3d │  %-3d │  %s%n", day + 1, dailyTemperatures[day], answer);
        }
    }
}
Output
Day │ Temp │ Next Greater Temp
─────┼──────┼──────────────────
1 │ 73 │ 74
2 │ 74 │ 75
3 │ 75 │ 76
4 │ 71 │ 72
5 │ 69 │ 72
6 │ 72 │ 76
7 │ 76 │ none
8 │ 73 │ none
Store Indices, Not Values:
Always push array indices onto the stack, not the actual values. You need the index to update the correct position in your result array. You can always get the value back with array[index] — but you can't get the index back from a value if duplicates exist.
Production Insight
The stack approach reduced response time from 12 hours to 2 seconds in that same pipeline.
But the stack can grow to n in descending arrays — O(n) memory is fine.
Watch out: nested calls inside the while loop can accidentally mutate state.
Key Takeaway
One pass resolves all unresolved elements in batch — that's the O(n) magic.
Every element pushed once, popped once.
Indices are the key — never store values directly.

The Circular Array Variant — The Interview Curveball

Once you've nailed the linear version, interviewers love throwing this at you: what if the array is circular? Meaning, after the last element, you wrap around to the first. For [5, 4, 3, 2, 1], the next greater element for 4 is 5 (which is at index 0, to the 'right' when wrapping around).

The trick is elegant: simulate two passes over the array by iterating from index 0 to 2n-1, using modulo to wrap the index. Critically, on the second pass you should NOT push new indices onto the stack — you're only resolving elements that are still waiting. A clean way to enforce this: only push during the first pass (i < n).

This technique — doubling the loop with modulo — is a classic pattern for any circular array problem, not just Next Greater Element. Internalise it and you'll use it again.

NextGreaterElementCircular.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
import java.util.Arrays;
import java.util.Stack;

public class NextGreaterElementCircular {

    /**
     * Finds the next greater element in a circular array.
     * Elements wrap around: after the last element, search continues from index 0.
     *
     * Technique: iterate 0 to 2n-1, use (index % n) to wrap around.
     *            Only push indices during the first pass (index < n).
     *
     * Time:  O(n) — each element is pushed/popped at most once across both passes
     * Space: O(n) — stack size
     */
    public static int[] findNextGreaterCircular(int[] circularPrices) {
        int size = circularPrices.length;
        int[] nextGreater = new int[size];
        Arrays.fill(nextGreater, -1);

        Stack<Integer> waitingIndices = new Stack<>();

        // We loop 2*size to simulate wrapping around the array
        for (int iteration = 0; iteration < 2 * size; iteration++) {

            // Wrap the iteration index back into a valid array index
            int wrappedIndex = iteration % size;

            // Resolve all waiting elements that the current element is greater than
            while (!waitingIndices.isEmpty()
                    && circularPrices[wrappedIndex] > circularPrices[waitingIndices.peek()]) {
                int resolvedIndex = waitingIndices.pop();
                nextGreater[resolvedIndex] = circularPrices[wrappedIndex];
            }

            // Only push during the first full pass — second pass is for resolution only
            if (iteration < size) {
                waitingIndices.push(wrappedIndex);
            }
        }

        return nextGreater;
    }

    public static void main(String[] args) {
        // In a circular market: after price[last], the search continues from price[0]
        int[] circularMarketPrices = {5, 4, 3, 2, 1};

        int[] result = findNextGreaterCircular(circularMarketPrices);

        System.out.println("Circular Array: [5, 4, 3, 2, 1]");
        System.out.println();
        System.out.println("Price  │  Next Greater (circular)");
        System.out.println("───────┼──────────────────────────");
        for (int i = 0; i < circularMarketPrices.length; i++) {
            String answer = result[i] == -1 ? "none" : String.valueOf(result[i]);
            System.out.printf("  %-4d │  %s%n", circularMarketPrices[i], answer);
        }
    }
}
Output
Circular Array: [5, 4, 3, 2, 1]
Price │ Next Greater (circular)
───────┼──────────────────────────
5 │ none
4 │ 5
3 │ 5
2 │ 5
1 │ 2
Watch Out: Don't Push on the Second Pass
If you push indices during both passes, you'll add duplicates to the stack and corrupt results. The condition if (iteration < size) is the guard that keeps the second pass in resolution-only mode. Remove it and your output will be wrong in subtle, hard-to-debug ways.
Production Insight
Circular arrays appear in circular buffer monitoring and ring topology problems.
Forgetting the push guard causes incorrect results that are hard to catch in unit tests.
Always test with a uniform array to verify circular logic.
Key Takeaway
The two-pass technique is reusable for many circular array problems.
Only push during the first n iterations.
Modulo is your friend — but use it correctly.

Next Greater Element Index Variant — Returning Distances, Not Values

LeetCode 739 'Daily Temperatures' is one of the most frequently asked Next Greater Element variants in real interviews. Instead of returning the next greater value, it asks: how many days until a warmer temperature? This is a small twist — instead of storing the value at the resolved index, you store the distance between the two indices.

This variant tests whether you truly understand what you're storing in the stack (indices, not values!) and whether you can adapt the pattern quickly. The stack logic is identical — the only change is one line in the result update.

This is also a great example of real-world application: think of it as 'wait time until the next event exceeds a threshold'. Used in financial analytics for breakout detection, in IoT sensor networks for anomaly detection, and in game development for AI aggression triggers.

DaysUntilWarmerTemperature.javaJAVA
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
import java.util.Arrays;
import java.util.Stack;

public class DaysUntilWarmerTemperature {

    /**
     * For each day, returns how many days you have to wait until a warmer temperature.
     * If no warmer temperature ever comes, the answer for that day is 0.
     *
     * This is LeetCode 739 — one of the most common Next Greater Element interview variants.
     *
     * Time:  O(n)
     * Space: O(n)
     */
    public static int[] daysUntilWarmer(int[] dailyTemps) {
        int totalDays = dailyTemps.length;
        int[] waitDays = new int[totalDays]; // default 0 means "never gets warmer"

        Stack<Integer> waitingDayIndices = new Stack<>();

        for (int today = 0; today < totalDays; today++) {

            // Today's temp resolves all past days that were waiting for something warmer
            while (!waitingDayIndices.isEmpty()
                    && dailyTemps[today] > dailyTemps[waitingDayIndices.peek()]) {

                int coldDay = waitingDayIndices.pop();

                // KEY DIFFERENCE from the value variant:
                // Store the GAP between the two days, not the temperature itself
                waitDays[coldDay] = today - coldDay;
            }

            waitingDayIndices.push(today);
        }

        // Days still in the stack never found a warmer day — waitDays stays 0
        return waitDays;
    }

    public static void main(String[] args) {
        int[] weekTemperatures = {73, 74, 75, 71, 69, 72, 76, 73};

        int[] daysToWait = daysUntilWarmer(weekTemperatures);

        System.out.println("Day  │ Temp │ Days Until Warmer");
        System.out.println("─────┼──────┼───────────────────");
        for (int day = 0; day < weekTemperatures.length; day++) {
            String wait = daysToWait[day] == 0 ? "never" : daysToWait[day] + " day(s)";
            System.out.printf(" %-3d │  %-3d │  %s%n", day + 1, weekTemperatures[day], wait);
        }
    }
}
Output
Day │ Temp │ Days Until Warmer
─────┼──────┼───────────────────
1 │ 73 │ 1 day(s)
2 │ 74 │ 1 day(s)
3 │ 75 │ 4 day(s)
4 │ 71 │ 2 day(s)
5 │ 69 │ 1 day(s)
6 │ 72 │ 1 day(s)
7 │ 76 │ never
8 │ 73 │ never
Interview Gold:
When an interviewer asks you to find 'how many steps until the next greater element', they're testing whether you can pivot the same stack pattern with a one-line change. Say out loud: 'The only difference from the value variant is that instead of storing the value at the resolved index, I store today minus the resolved day.' That kind of clarity under pressure is what gets you hired.
Production Insight
LeetCode 739 tests adaptation under pressure.
In interviews, if you reuse the exact same code with one line change, you look like you truly understand the pattern.
Real-world analogy: wait time until next event exceeding threshold – used in logs, dashboards, anomaly systems.
Key Takeaway
The only difference is storing distance instead of value.
Everything else — stack logic, indices, loops — is identical.
That one-line pivot is the hallmark of deep understanding.
● Production incidentPOST-MORTEMseverity: high

Stock Price Monitoring Service Timeout in Production

Symptom
API endpoint /next-greater returned responses after 30+ seconds or timed out under high load.
Assumption
The dataset was small (a few thousand prices), so O(n²) should be fine.
Root cause
Volume of price updates peaked at 10,000 per second; nested loops caused n² complexity explosion (100 million comparisons per request).
Fix
Replaced brute-force with monotonic stack O(n) algorithm. Wire the new implementation behind a feature flag, validate with A/B comparison on historical data.
Key lesson
  • Always assume worst-case input size in production and optimize upfront.
  • Never use O(n²) algorithms for real-time data processing without strict upper bound on n.
  • Profile under load before going live — synthetic benchmarks lie.
Production debug guideCommon failure modes and how to fix them4 entries
Symptom · 01
Result array has -1 for all elements regardless of input
Fix
Check if the while condition uses correct comparison: arr[i] < stack[top] not <=. Also verify stack is not empty before peeking.
Symptom · 02
Some elements have wrong next greater values (e.g., value from left instead of right)
Fix
Ensure pushing indices left-to-right and popping only when current value strictly exceeds stack top. Duplicate handling: use < not <=.
Symptom · 03
Circular array variant gives incorrect results; some elements unresolved
Fix
Verify you only push indices during first iteration (i < n). Check modulo index calculation: i % size.
Symptom · 04
In 'days until warmer' variant, distances are off by one
Fix
Check that you store today - resolvedDay and not today - resolvedDay + 1. The distance is the difference in indices.
★ NGE Quick Debug Cheat SheetOne-liners to diagnose and fix common NGE implementation failures.
All results are -1
Immediate action
Check if while condition uses correct comparison (arr[i] < stack top)
Commands
Print stack contents at each iteration
Verify input array iteration direction (left to right)
Fix now
Ensure monotonic condition is strictly greater, not greater-or-equal.
Circular variant unresolved+
Immediate action
Check second pass doesn't push
Commands
Print iteration index and whether push occurs
Verify modulo: i % size
Fix now
Add guard: if (i < size) before push statement.
Incorrect values in distance variant+
Immediate action
Check result assignment: `result[coldDay] = today - coldDay`
Commands
Print resolvedDay and today indices
Print waitDays array after each pop
Fix now
Change result[coldDay] to today - coldDay (no +1).
AspectBrute Force (Nested Loops)Monotonic Stack (Single Pass)
Time ComplexityO(n²) — every element re-scannedO(n) — each element pushed/popped once
Space ComplexityO(1) extra (result array excluded)O(n) for the stack in worst case
Best Case InputAlready sorted ascending — still O(n²)Any input — always O(n)
Worst Case InputDescending array — n² comparisonsDescending array — all pushed, none popped mid-pass
Handles Circular ArraysYes, with a second loop passYes, with 2n iteration and modulo
Code ComplexitySimple — easy to write, easy to readModerate — requires stack mental model
When to UseArray size < 1,000, clarity matters mostProduction code, interviews, large datasets
Interview SignalShows problem understandingShows data structure mastery

Key takeaways

1
The monotonic stack works because it tracks 'unresolved' elements
the moment a new element resolves several past elements simultaneously is exactly where the O(n) efficiency comes from.
2
Always push INDICES onto the stack, never raw values
duplicates in the array make value-based stacks ambiguous and incorrect.
3
The circular array variant requires a 2n iteration with modulo, with pushes restricted to the first n iterations
this exact pattern reappears in other circular array problems.
4
The 'days until warmer' (distance) variant and the 'next greater value' variant share 100% of their stack logic
the only difference is one line: result[i] = value vs result[i] = today - i.

Common mistakes to avoid

3 patterns
×

Pushing values instead of indices

Symptom
Result array update breaks with duplicate values (e.g. [3, 1, 3, 2] — which '3' do you update?)
Fix
Always push the array index. Get the value inside the loop with array[index] when you need to compare.
×

Using wrong stack type (FIFO queue instead of LIFO stack)

Symptom
Elements processed in arrival order instead of recency order, so early elements never get resolved correctly and results are scrambled.
Fix
Use Stack<Integer> or Deque<Integer> with push/pop/peek. Never use Queue for this pattern.
×

In the circular variant, pushing indices on both the first and second pass

Symptom
Duplicate indices appear in the stack, causing some elements to be 'resolved' twice with wrong values, and others to remain unresolved.
Fix
Add the guard if (iteration < size) before the push statement so indices are only added during the first pass through the array.
INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Q01SENIOR
Can you solve Next Greater Element in O(n) time? Walk me through your ap...
Q02SENIOR
Given a circular array, how does your Next Greater Element solution chan...
Q03SENIOR
What happens to your stack-based solution if the input array contains al...
Q01 of 03SENIOR

Can you solve Next Greater Element in O(n) time? Walk me through your approach step by step, explaining what the stack contains at each point and why you chose a stack over a queue.

ANSWER
We initialize an empty stack (intentionally left) and a result array filled with -1. We iterate left to right. For each index i, while the stack is not empty and the current element is greater than the element at the top of the stack, we pop the top index j and set result[j] = arr[i]. After that, we push i. At the end, any indices left in the stack have -1. This works because the stack maintains a decreasing sequence of 'unresolved' elements. We use a stack (LIFO) because the most recently seen unresolved element is the first to be compared with the new element; a queue would break the ordering and require O(n²) again.
FAQ · 5 QUESTIONS

Frequently Asked Questions

01
What is the next greater element problem?
02
Why do we use a stack to solve the Next Greater Element problem?
03
What is a monotonic stack and how is it different from a regular stack?
04
How does the next greater element work for a circular array?
05
What is 'previous greater element' and how does it differ?
🔥

That's Stack & Queue. Mark it forged?

5 min read · try the examples if you haven't

Previous
Balanced Parentheses Problem
7 / 10 · Stack & Queue
Next
Implement Stack using Queue