Skip to main content

🧱 When an Easy Problem Isn't

🤔 The Setup​

The problem sounded simple:

You have a row of cubes with positive lengths. You can take cubes from either end and stack them vertically, as long as each cube on top is less than or equal to the one below.

So I figured: Okay, this is just constrained sorting. All the values are positive — surely I can reorder them into a non-increasing sequence by carefully picking left/right.

I was confident enough in that assumption that when I saw the negative example test case (cannot make stack) — [1, 3, 2] — I was genuinely confused.

“How can this ever be false??”

🧠 The Slow Realization​

It didn’t click immediately. I stared at the test case. Tried various pick orders. Read the explanation.

Eventually — finally — it landed:

❗️ You can only place cubes on top of the stack.

You’re not building a sorted array. You’re building a stack, where each cube must be ≤ the one below — and you can only grab from the ends.

The problem description says:

“Create a vertical pile.”

Cool. But just say stack, please. I ended up getting twisted, asking the question, "Can i place it anywhere?" if i can place it anywhere then the answer it always true. So how can this test case return false?

🌀 The False Confidence Spiral​

I understand most of the problem at this point, but I still need get the process mapped out. > How do i know if i can push the item, and how do i know which one to push (leftmost or rightmost)?

So did a proper simulation — following the left/right constraint — I built this:

1
2
3

Picked 1 (left), then 2 (right), then 3 (right). Totally legal moves.

And I thought:

“Okay, that’s clearly valid. Why would this test case fail?”

I had flipped the rule, though it took longer than I want to admit. I don’t have a timer, but it was probably more than a minute before I noticed, nor do i know the process by which i noticed.

The problem says:

“If A is on top of B, then A ≤ B" → So the stack must be non-increasing from bottom to top.

But somehow I flipped it. In my head I was pushing if B >= A and then writing the number on the paper when it satisfied this made-up inverse rule, rather than the actual one.

Since I dont know the process by which I found my incorrect reasoning, here's my potential lessons learned: > Explicitly write the comparison maybe:

abis a < b?Action
n/a (1st element)2implicit yespush 2
21Yespush 1
31Nocan't push

> If you're going to draw your array like data structure in a non left-to-right manner, label your picks — or you'll gaslight yourself with your own diagram.

idx | item | 0 | 2 | 1 | 1 | 2 | 3... wait this doesnt work! |

...and maybe by adding some more labels and things I would have been saved from the next problem... (because I would have realized I just need to compare the greater of the two (left and right) to the item on the top of the stack)

📊 The Push vs. Pick Shift​

Another subtle trap I fell into was trying to solve this as:

“Given the current array state, can I push either left or right?” and if so, how do i choose which one?

But that mindset is too cautious and overcomplicates things. I ended up looking at arr[left] v, arr[left + 1] and arr[right] v. arr[right + 1] and honestly it just became too tedious. The real shift came when I realized:

First, choose the larger of the two ends (b/c you can always push the smaller end after this you push the larger one) Then, check: can I push it on top of the current stack?

I didn’t need to evaluate both sides or simulate both paths. I just needed to:

  • Pick greedily (max of left/right)
  • Check if that value can legally go on top of the stack (i.e. is it ≤ the previous top?)

That simplification made the entire structure clean.

💪 The Final Fix​

Eventually I nailed the logic:

  • Always choose the larger of the two ends (left or right)
  • If it's ≤ the current top of the stack → push it
  • Otherwise → reject

Simple, greedy, clean.

Except... 4 of 5 test cases still failed.

🤦‍♂️ The Final Bug​

I had forgotten to convert the input strings to integers:

blocks = input().split()  # ← still strings

Which meant comparisons like "10" < "2" were returning True.

Thanks, Python.

Fixing it was simple, just make sure we cast to ints before doing any comparisons

And just like that… all test cases passed.

✅ Lessons Learned / Reinforced​

  • If something feels like a non-problem, it's probably a misread / implicit constraint:

    • Note: This is why I love whiteboarding. In a whiteboarding interview, you can pause and say, "Wait, the problem might be flawed," and talk through it. The interviewer might nudge you — not help you — and say, "Are you sure you can do that?" And you'd respond, "Yeah, why not? We're just creating a vertical pile — it’s just sorting." And then they'd raise a good counter: what if the items are extremely heavy and you can only place them on top because you physically can’t hold two at once. Now the constraint makes sense, and you’ve uncovered it together. That’s the beauty of interactive problem solving.

  • Always verify test cases before diving into logic.

  • Greedy problems don’t always start as greedy in your head — sometimes they feel like sorting.

  • If you're going to draw your array like data structure in a non left-to-right manner, label your picks — or you'll gaslight yourself with your own diagram.

  • And most importantly…

Just say stack if you mean stack.