ASAPUtils
The five minutes that decide everything
Most failed interviews are not failed because someone couldn’t code a heap. They’re failed because someone started coding ninety seconds in, on the wrong approach, and had no time to recover. Slowing down at the start is the highest-return habit in this entire plan.
The routine
1. Restate it in your own words. Out loud. If you can’t, you haven’t understood it. This alone catches a surprising number of misreadings.
2. Read the constraints. How big is n? Are values negative? Can the input be empty? Are
there duplicates? Is it sorted? The constraints tell you the target complexity before you have
an idea — see Big-O & reading constraints.
3. Do one example by hand. Not mentally — on paper. Then do the smallest possible input, and one weird one. Working an example by hand is often what reveals the pattern, because you notice what you did to solve it.
4. Ask the clarifying questions. Even alone, ask them, because they’re a checklist of edge cases:
- What should I return if the input is empty?
- Can there be duplicates?
- Are values negative? Can they overflow?
- Is the input sorted, or may I sort it?
- Is there always exactly one answer?
5. State the brute force. With its complexity. Never skip this. It buys thinking time, demonstrates reasoning, and the optimal solution almost always comes from the next step.
6. Ask what the brute force is wasting. This is where optimisation actually comes from:
- Recomputing the same subproblem → memoise (DP)
- Re-scanning for something you already saw → hash map
- Re-scanning a range you already summed → prefix sum or sliding window
- Checking every pair when the data is sorted → two pointers or binary search
- Re-finding the max of a set → heap
7. Name the pattern. Use the signal table on the cheat sheet. Two minutes to name it, then commit.
8. State approach and complexity before coding. In an interview, get a nod first. Alone, write it in one sentence. If you can’t write the sentence, you’re not ready to write code.
The signals worth memorising first
| The statement says… | It’s probably… |
|---|---|
| “sorted array”, find a pair | Two pointers |
| ”longest/shortest substring such that…” | Variable sliding window |
| ”next greater / next smaller” | Monotonic stack |
| ”k largest / k closest” | Heap of size k |
| ”shortest path”, unweighted | BFS |
| ”all combinations / permutations” | Backtracking |
| ”number of ways” or “max/min” with overlapping subproblems | DP |
| ”prerequisite / dependency / ordering” | Topological sort |
The full table lives on the cheat sheet. Add a row every time a problem teaches you a new signal — that growing table is your pattern recognition.
The 25-minute rule
Stuck for 25 minutes on a new problem? Read the approach only — never the code. Then close the tab and write the code yourself. Still stuck 15 minutes later? Read the code, then re-solve it from a blank file the same day.
And the rule that makes practice actually count: a problem is “solved” once, but only “mastered” after you re-solve it from blank, days later, without looking. The first pass teaches you the solution. The blank re-solve is what proves you own it.
What to write down after every problem
Three lines, no more:
- The signal — what in the statement pointed to the pattern?
- The insight — the one sentence that unlocked it.
- What I got wrong — the off-by-one, the missed edge case, the wrong first idea.
Line 3 is the valuable one. Over 150 problems these become a personal error catalogue, and it’s far more useful than any general advice — including this page.