Rain Terraces / Trapping Rain Water
Trapping Rain Water asks how much water can sit above bars after rain. Water above index i is limited by the smaller of the tallest bar on its left and right.
Start with this mental model
Trapping Rain Water asks how much water can sit above bars after rain. Water above index i is limited by the smaller of the tallest bar on its left and right.
How it works, without unnecessary jargon
A two-pointer solution tracks leftMax and rightMax while moving the side with the smaller boundary.
This gives O(n) time and O(1) extra space.
Read the algorithm as a sequence of decisions
Restate constraints and edge cases.
Identify the pattern and invariant.
Walk through a small example before coding.
Read a tiny input by hand and write down the state after every important operation. For Rain Terraces / Trapping Rain Water, the goal is to make the invariant visible rather than to memorize code.
function trap(height) {
let l = 0, r = height.length - 1;
let leftMax = 0, rightMax = 0, water = 0;
while (l < r) {
if (height[l] <= height[r]) {
leftMax = Math.max(leftMax, height[l]);
water += leftMax - height[l++];
} else {
rightMax = Math.max(rightMax, height[r]);
water += rightMax - height[r--];
}
}
return water;
}Do not memorize the syntax. Follow the state that changes on each line and connect it to the invariant described above.
Varies by implementation / input constraints
Do not quote this complexity mechanically. Ask which operation or input dimension it describes, then derive the cost from the loops, recursion depth, data-structure operations and any preprocessing assumptions.
Good fit
- Use the recognized pattern when its invariant matches the problem constraints.
What usually goes wrong
- Jumping to code before defining the invariant.
- Optimizing before producing a correct baseline.
A professional answer shape
Explain why moving the smaller boundary is safe: the smaller side already determines the maximum water level for that position.
What problem does Rain Terraces / Trapping Rain Water solve?
Trapping Rain Water asks how much water can sit above bars after rain. Water above index i is limited by the smaller of the tallest bar on its left and right.
What should I mention about complexity?
Its typical cost here is Varies by implementation / input constraints, but a complete answer should connect that cost to the representation, input constraints and the dominant operations.
What is the most common mistake?
Jumping to code before defining the invariant.