How to Approach Any LeetCode Problem in 5 Steps: A Jedi’s Guide

The Quest Begins (The “Why”)

I still remember the first time I stared at a LeetCode screen and felt like I’d been dropped into the middle of a nebula with no map. The problem was “Container With Most Water”, and my brain instantly went to brute force: try every pair of lines, calculate the area, keep the max. It worked on the tiny examples, but the moment I hit the test with 50 000 heights, my solution timed out and I felt the familiar sting of defeat.

Why does this happen to so many of us? We dive straight into coding, hoping our intuition will carry us, but we skip the most important part: understanding the problem’s shape. When you treat every LeetCode question like a mysterious artifact, you end up hammering at it with the same old chisel instead of figuring out where the weak point is.

So I decided to build a repeatable mental framework—five steps that turn a confusing prompt into a clear battle plan. I’ve used it on everything from sliding‑window puzzles to graph traversals, and it’s saved me hours of frustration. Let’s walk through it together, using the container problem as our practice grounds.

The Revelation (The Insight)

The breakthrough came when I stopped asking “How do I compute the area for every pair?” and started asking “What makes one pair better than another?”

Look at the container formed by two lines at indices i and j. The area is min(height[i], height[j]) * (j - i). Notice two things:

1. The width (j - i) only shrinks as we move the pointers inward.
2. The height is limited by the shorter line.

If we ever want to increase the area, we can’t rely on getting a wider width later—width only goes down. So the only lever we have is to try to get a taller line. And the only way to possibly get a taller line is to move the pointer that points to the shorter line, hoping we’ll find a taller one behind it.

That’s the “aha!” moment: always discard the shorter line. It’s counter‑intuitive at first because we feel like we might be missing a better pair, but mathematically discarding the shorter line can never eliminate the optimal solution.

Once I saw that, the algorithm fell into place like a lightsaber snapping into its hilt—clean, precise, and instantly powerful.

Wielding the Power (Code & Examples)

The Struggle: Brute Force (O(n²))

def maxArea_bruteforce(height):
    max_area = 0
    n = len(height)
    for i in range(n):
        for j in range(i + 1, n):
            width = j - i
            max_area = max(max_area, min(height[i], height[j]) * width)
    return max_area

Why it hurts: For n = 50 000 we’re looking at ~2.5 billion iterations. The runtime explodes, and LeetCode gives us the dreaded “Time Limit Exceeded.”

The Victory: Two‑Pointer Greedy (O(n))

def maxArea(height):
    left, right = 0, len(height) - 1
    max_area = 0

    while left < right:
        width = right - left
        # area is limited by the shorter line
        current_area = min(height[left], height[right]) * width
        max_area = max(max_area, current_area)

        # move the pointer at the shorter line
        if height[left] < height[right]:
            left += 1
        else:
            right -= 1

    return max_area

What changed?

• We replaced the double loop with a single while‑loop that runs at most n times.
• Each iteration makes a local decision that is provably safe: discard the shorter line.

Common Traps to Avoid

1. Moving the taller pointer – It feels like we’re “making progress,” but you’ll actually shrink the possible height without gaining any width benefit.
2. Updating max_area after moving pointers – You must compute the area before you shift, otherwise you’ll miss the container formed by the current pair.

If you keep those two pitfalls in mind, the algorithm is bulletproof.

Why This New Power Matters

Adopting this five‑step mindset—clarify, explore patterns, hypothesize a greedy invariant, prove it (or at least convince yourself), then code—turns every LeetCode problem from a monster into a puzzle you can solve with confidence.

You’ll start to notice that many hard problems share the same skeleton: a monotonic property, a sliding window, or a two‑pointer trade‑off. Once you internalize the “discard the worse option” idea, you’ll see it popping up in “Longest Substring Without Repeating Characters,” “Trapping Rain Water,” and even “Minimum Size Subarray Sum.”

The real win isn’t just a faster submission; it’s the shift in mindset. You stop fearing the blank editor and start feeling excited to dissect the next challenge. It’s like leveling up in a game where each boss teaches you a new move that makes the next encounter easier.

---

Your Turn

Pick a problem you’ve struggled with lately—maybe “Maximum Subarray” or “Word Break.” Apply the five steps:

1. Read the problem aloud, rewrite it in your own words.
2. Draw a small example and look for patterns.
3. Ask: “What decision can I make now that won’t hurt the optimal answer?”
4. Sketch the algorithm in plain English (or pseudocode).
5. Code, test on edge cases, and refactor.

When you crack it, come back and share your insight in the comments—I’d love to hear what “aha!” moment you discovered. Happy coding, and may your pointers always point toward victory!