PROJECT · 75 minutes

Solving Hard Problems Under Constraints

A repeatable four-move method for unfamiliar problems — decompose, reason from examples, time-box, debug systematically — with a full worked walkthrough.

Problem-Solving Is a Skill You Can Practice

Knowing every algorithm in this path and actually cracking an unfamiliar problem are two different skills. The gap is not knowledge — it is method. I have watched strong engineers stall on problems well within their ability, not because they lacked the technique, but because they had no repeatable procedure for the moment when the path forward is not obvious.

The last time I hit this hard was when I was debugging a subtle ordering issue in my orchestration framework's DAG executor. Jobs were completing in the wrong sequence on certain diamond-shaped dependency graphs. I had all the right primitives — topological sort, priority queues, concurrency locks — but the bug eluded me for two hours because I kept patching symptoms without forming a hypothesis about the root cause.

When I finally stopped and forced myself to draw the smallest possible diamond graph on paper, trace each step by hand, and ask "what assumption in my topological sort is wrong?", the bug was obvious in five minutes. That is the method: decompose the problem, reason from a concrete example, and debug with a hypothesis — not with hope.

This module treats hard problems as a process you can rehearse. The method has four moves. The rest of the module is organized around them.

The Four-Move Method

Restate the problem in your own words. Then ask: what smaller problems do I already know how to solve that this reduces to? Most hard problems are composed of two or three easy sub-problems, each of which you have solved before under a different name.

Example decomposition: "Find all substrings of S that are permutations of P" decomposes into:

What is the character frequency of P? (Counter — O(k))
Maintain a sliding window of size k over S. (sliding window — O(n))
At each window, is its frequency map equal to P's? (dict comparison — O(k))

That is three patterns from this path. None of them is new. The novelty is only in how they compose.

Move 2: Reason from Examples

Work two or three concrete inputs by hand before writing code. Not toy examples — ones that include the edge cases the problem describes.

The goal is not to verify your solution. It is to discover the algorithm. The pattern you find by tracing a specific input is almost always the one that generalizes.

What to trace:

The smallest non-trivial input (usually size 3-4)
An input that includes the boundary condition (empty array, single element, all equal)
An input where the naive approach would fail

Move 3: Time-Box

Set a budget for any single approach. When the timer expires, step back and try a different decomposition — do not push harder on a failing idea. For a medium-difficulty problem in a 60-minute session, 15-20 minutes per approach is a reasonable box.

The failure mode this prevents is rabbit-holing: committing to the first idea and spending the entire session patching it. Rabbit-holing feels like progress because code is being written. It is not progress if the approach is fundamentally wrong.

When this bites: the most common rabbit-hole is an O(N^2) brute-force that almost works. You can often get it to pass on small test cases, which makes the approach feel close. The time-box forces you to ask "is this the right algorithm?" before "why is it failing on this test case?"

Move 4: Debug Systematically

When a solution is wrong, form one hypothesis about why, test it against a small input, and narrow the search. Never guess-and-tweak.

The hypothesis loop:

Identify the smallest failing input.
Trace your code on that input by hand.
Find the first line where actual behavior diverges from expected.
Form a hypothesis: "I think my boundary condition at index 0 is wrong."
Test the hypothesis. If correct, fix it. If wrong, revise the hypothesis.

flowchart TD
  A["Problem arrives"] --> B["Decompose into sub-problems"]
  B --> C["Reason from 2-3 concrete examples"]
  C --> D["Implement first approach"]
  D --> E{"Correct?"}
  E -->|Yes| F["Done"]
  E -->|No, time remaining| G["Form one hypothesis\nabout why it's wrong"]
  G --> H["Trace smallest failing input"]
  H --> I{"Hypothesis confirmed?"}
  I -->|Yes| J["Fix the specific bug"]
  I -->|No| G
  J --> E
  E -->|No, time-box expired| K["Step back — try\ndifferent decomposition"]
  K --> B
  style F fill:#4ade80

Worked Walkthrough — Trapping Rain Water

Let's apply the four-move method to a genuinely hard problem.

Problem: Given heights of bars in a histogram, compute how much water can be trapped after rain. heights = [0, 1, 0, 2, 1, 0, 1, 3, 2, 1, 2, 1] — answer: 6.

Step 1: Decompose

Restate: at each position, how much water sits above it? Water level = min(max_left, max_right) - height[i]. That decomposes into three sub-problems:

For each position, find the maximum height to its left.
For each position, find the maximum height to its right.
Sum max(0, min(left_max[i], right_max[i]) - heights[i]) for each position.

Each sub-problem is a linear scan. The hard problem is three easy ones composed.

Step 2: Reason from Examples

Trace heights = [3, 0, 2] by hand.

Position 0 (height 3): left_max=3, right_max=3. min(3,3)-3=0. No water.
Position 1 (height 0): left_max=3, right_max=2. min(3,2)-0=2. Water = 2.
Position 2 (height 2): left_max=3, right_max=2. min(3,2)-2=0. No water.

Total: 2. Draw it: a bar of height 3 on the left, empty in the middle, a bar of height 2 on the right. The middle cell collects water up to height 2.

Step 3: Implement from the Decomposition

Trapping Rain Water — Two-Pass O(N) Solution

python

Step 4: Debug Hypothesis — the Two-Pointer Optimization

After the two-pass solution works, you might wonder: can you reduce to O(1) space? This is where reasoning from examples pays off again.

The insight: when left_max < right_max, the water at the left pointer is determined solely by left_max — the right side is already taller, so whatever the actual right maximum is, it cannot reduce the water below left_max. You can process the left pointer without knowing the exact right maximum.

Trapping Rain Water — Two-Pointer O(1) Space

python

The progression pattern: easy decomposition → working O(N) space solution → insight from tracing → optimized O(1) space. This is almost always the right order. Jumping to the optimized solution first is usually a dead end because the insight that enables the optimization only becomes clear after you understand the simpler version.

Mid-Module Checkpoint

Try these from memory:

Name the four moves in order.
Rabbit-holing vs freezing — which failure mode does time-boxing address?
In Trapping Rain Water, why does left_max[i] record the max of heights[0..i] rather than the max of heights[0..i-1]?
What is the first step in the systematic debugging loop when a test case fails?

Reflective prompt: The four-move method is designed for constraint-filled situations — a timer, a blank editor, an unfamiliar problem. How does your usual debugging process at work differ from this? Where do you rabbit-hole, and what personal signal tells you it's time to step back? Naming your own failure modes is what makes the recovery moves automatic rather than aspirational.

Test Your Understanding

Questions on the four-move method, failure modes, and systematic debugging

1. You have spent 45 minutes on one approach that isn't working, and you keep finding ways to patch it. Which failure mode is this, and what is the recovery move?

A)Freezing — recovery: work a concrete example by hand
B)Rabbit-holing — recovery: time-box expired, step back and try a different decomposition
C)Rabbit-holing — recovery: add more test cases to validate the approach
D)Freezing — recovery: read the problem statement again

Show Answer

Correct Answer: B

Committing to one approach and refusing to abandon it despite evidence it isn't working is rabbit-holing. The recovery move is to stop, acknowledge the time-box has expired, and start a different decomposition — not to patch the failing approach further.

2. Before writing any code for a new problem, the most effective first step is:

A)Search for the algorithm category (DP, greedy, graph) and implement it
B)Work two or three concrete examples by hand to find the pattern
C)Write the brute-force solution immediately to have something running
D)Estimate the time complexity of the optimal solution first

Show Answer

Correct Answer: B

Working concrete examples by hand forces you to simulate the algorithm you haven't yet written. Patterns and constraints that are invisible in the abstract problem statement become obvious when you trace specific inputs. This is faster than staring at the problem and faster than debugging a premature implementation.

3. You are given Trapping Rain Water: for each cell, the trapped water equals the minimum of (max height to the left, max height to the right) minus the cell's height. What is the key sub-problem decomposition?

A)Sort the heights and fill from tallest to shortest
B)For each position, compute left-max and right-max arrays, then combine
C)Use BFS from the edges inward
D)Use a stack to track the current water level

Show Answer

Correct Answer: B

The sub-problem decomposition: (1) build left_max[i] = max of heights[0..i]; (2) build right_max[i] = max of heights[i..n-1]; (3) water[i] = max(0, min(left_max[i], right_max[i]) - heights[i]). Each sub-problem is a simple linear scan — the hard problem becomes three easy ones.

4. Your solution passes 49 of 50 test cases. The failing case is `[3, 0, 2, 0, 4]`. What is the most effective debugging approach?

A)Add print statements to every line and look for something surprising
B)Form a hypothesis (e.g., 'the boundary condition at index 0 is wrong'), trace the specific case, confirm or refute the hypothesis
C)Run the brute-force solution on the failing case and compare output
D)Submit again — it might pass this time

Show Answer

Correct Answer: B

Systematic debugging starts with a hypothesis: what specific thing might be wrong? Trace the failing input through your code with that hypothesis in mind. Confirm or refute it — if refuted, form a new hypothesis. This is always faster than either scattering print statements everywhere or staring at the code hoping to spot the bug.

5. You have 60 minutes for a problem. A reasonable time-box for your first approach before stepping back is:

A)5 minutes — switch immediately if not solved
B)The full 60 minutes — commit to the first approach
C)15-20 minutes — enough to build and test a complete approach
D)Only step back if you get a compile error

Show Answer

Correct Answer: C

A time-box of 15-20 minutes is enough to attempt a complete solution on a medium-difficulty problem. If you are not making progress after that time, you have evidence the approach is wrong — not just slow. Stepping back at this point costs little but can save the remaining 40+ minutes.

6. The two-pointer approach for Trapping Rain Water uses left and right pointers converging from both ends. When left_max < right_max, you process the left side. Why?

A)Because left heights are always smaller than right heights
B)Because the water at the left pointer is bounded by left_max — right_max is irrelevant since it is larger
C)To avoid revisiting elements
D)Because the left pointer always moves first

Show Answer

Correct Answer: B

Water at position left = min(left_max, right_max) - heights[left]. When left_max < right_max, the bottleneck is left_max — you already know right_max is at least left_max, so the actual right maximum (which we haven't seen fully) doesn't matter. You can safely compute the water and advance the left pointer.

Capstone: Apply the Method

This is a multi-step exercise. Do not skip the decomposition and reasoning steps — they are the practice.

Problem: Container With Most Water. Given heights[i] (heights of vertical lines), find two lines that together with the x-axis form a container holding the most water. Return the maximum water volume.

Step 1: Decompose in writing (before any code). The water in a container formed by lines at index i and j is:

Your task: find the pair (i, j) that maximizes this.

Step 2: Reason from examples. Trace heights = [1, 8, 6, 2, 5, 4, 8, 3, 7] for the pairs (1, 8) and (0, 8) by hand. Which gives more water?

Starter

python

Hint 1: Use two pointers starting at both ends. The area shrinks as pointers converge (width decreases). To maximize, you want the height to increase — so move the pointer pointing at the shorter line.

Hint 2: Exchange argument: if you move the pointer at the taller line, you keep the bottleneck (the shorter line) and lose width — the area can only decrease. Moving the shorter line at least gives the area a chance to increase if you find a taller line.

Worked Solution

python

You've completed this path

Nice work. Here's what's next.

Back to this path Or book the diagnostic call