You've seen the monotonic stack find the next greater element. But what if you need the next smaller element instead? Or what if you need to look left instead of right?

There are four variants of the monotonic stack, and they all share the same basic structure — a for loop with a while loop inside that pops elements violating the ordering. The only differences are:

1. What you compare: greater or smaller
2. Which direction you scan: left-to-right or right-to-left

That gives you a 2x2 grid of variants. Tap any cell to see what it does:

Pick the wrong one and your output looks plausible — the numbers are in the right ballpark, the format is correct — but the answers are subtly, silently wrong.

Here's what makes it tricky: the relationship between the stack type and the problem type is counter-intuitive. You might assume a “decreasing stack” finds “next greater.” It doesn't. The mapping works backwards from what you'd expect, and the only way to internalize it is to see all four variants side by side.

Let's break it down before you experiment.

To find the next greater element, you maintain a monotonically increasing stack (from bottom to top, values increase). Wait — that sounds backwards. If you want greater elements, shouldn't the stack be decreasing?

No. Think about why elements get popped. An element gets popped when something arrives that violates the stack's ordering. If the stack is increasing and a smaller element arrives... nothing happens; it just gets pushed. But if a larger element arrives, it violates the increasing order and triggers pops. The popped elements just found their next greater element — the thing that arrived.

So the stack's monotonicity is the opposite of what you're searching for. Try it yourself — push a larger or smaller element and watch what happens:

The scan direction adds another axis. Scanning left-to-right finds the next element to the right. Scanning right-to-left finds the nearest element to the left. Combine both axes and you get four distinct variants that cover all “nearest X in direction Y” queries.

Here's a concrete example to ground this. Same input, four completely different outputs — tap each variant to see:

The skeleton code is nearly identical each time — a couple of comparison operators and the loop direction are the only differences. But those small changes produce radically different results.

Four variants, one array. Toggle between them, predict the output for each element, and watch how the same traversal skeleton produces completely different answers depending on two boolean choices.

Pay attention to which elements get popped and when. The pop trigger is the only thing that changes between variants — but it changes everything.

When you encounter a monotonic stack problem in the wild, the selection process is mechanical. Ask two questions:

Question 1: What relationship am I looking for? “Next greater” or “next smaller”? This determines the pop condition. If you want greater, you pop when the incoming element is larger than the top. If you want smaller, you pop when it's smaller.

Question 2: Which direction does the answer point? “To the right” means scan left-to-right — the incoming element answers the popped element's question. “To the left” means scan right-to-left — same logic, reversed direction.

Here's how real LeetCode problems map. Pick a relationship and a direction to see which problems fall out:

The four variants aren't four separate algorithms to memorize. They're one algorithm with two boolean parameters. Once you internalize the opposite rule — the stack's ordering is opposite to what you're searching for — variant selection becomes a lookup, not a decision.

In an interview, the variant selection should take you 10 seconds, not 10 minutes. Read the problem statement, identify the relationship (greater or smaller) and the direction (left or right), and the code writes itself. The hard part isn't the code — it's making sure you picked the right variant before you start writing. A wrong variant gives answers that look correct for most elements but silently fail on edge cases. That's worse than a crash — it's a trap.