How to Use This Course

Reading a pattern page is not learning the pattern. This page is the method.

The loop, per pattern

One pattern, one sitting, roughly ninety minutes:

1. Read the cue and nothing else (2 min). Before any code, make yourself answer: given a problem statement, what words would tell me it is this pattern? Write it down.
2. Step the visualization (5 min). Not passively. Pause on a frame and predict the next one before pressing step. Where your prediction is wrong is exactly where your understanding is.
3. Read the template, then close the page and retype it (10 min). From memory, into the browser exercise. Getting it wrong here is the point — that is the retrieval that builds recall.
4. Do the dry run on paper (10 min). Actual paper. The interview is a shared doc with no interpreter; the muscle you need is tracing state by hand.
5. Solve the two easiest problems in the ladder (20 min). Aim for correct-first, not fast.
6. Solve one medium without looking at the template (25 min). This is the real test of the sitting.
7. Read the pitfalls and follow-ups (10 min). Half of these will describe a mistake you just made, which is when they actually land.
8. Take the self-check quiz and read the recall card (5 min). Then leave.

Do not do “one more problem”. The next sitting is worth more than the eleventh problem in this one.

When you are stuck

Have a rule and follow it, because indecision costs more time than either choice.

Time stuck	What to do
0–10 min	Keep thinking. Re-read the constraints — they usually encode the intended complexity, and therefore the intended approach.
10–20 min	Write a brute force. Get something correct. Then ask what work it repeats — that question is where almost every optimisation comes from.
20–30 min	Re-read the cue sections of two or three adjacent patterns. Misclassification, not incompetence, is the usual reason a problem feels impossible.
30–40 min	Read the first paragraph of the editorial only, then close it and finish alone.
40 min+	Read the full solution. Then — this part is not optional — close everything and rewrite it from scratch. Reading a solution teaches nothing; reproducing it teaches the pattern.

The trap: reading solutions and feeling productive

A solution you understood is not a solution you can produce. The feeling of clarity while reading is not evidence of anything. If you have read a solution, you owe yourself a from-scratch reimplementation within twenty-four hours, otherwise the time is spent and nothing is retained.

Revising 300 problems without redoing them

Re-solving everything does not scale, and it is not what interviews test anyway. What they test is recognition: seeing a statement and knowing, within thirty seconds, which pattern it is.

So revise recognition, not implementation. For each problem you have solved, spend twenty seconds answering:

• Which pattern is this?
• What is the invariant the loop maintains?
• What is the complexity, and where does it degrade?

If all three come instantly, that problem is done. If any hesitates, re-solve that one. This turns a week of re-solving into an hour of drilling, and it targets the skill that actually transfers.

That is what each page’s Recall card exists for. Five lines, deliberately.

The three-pass schedule

For a three-month plan:

• Weeks 1–8, first pass. Phases in order. One pattern per sitting. Do not skip ahead to a pattern that sounds more interesting — the phases are ordered by dependency, and DP without recursion is unlearnable.
• Weeks 9–10, mixed practice. Phase 20’s problem sets and the sheet trackers. This is the first time you face problems without being told which pattern they are, and it will be humbling. That gap is the whole point of the pass.
• Weeks 11–12, timed pressure. Two problems in forty-five minutes, out loud, to an empty room or a friend. Talking while coding is a separate skill from coding, and it is the one that fails first under pressure.

Talk while you code, from day one

Every big-tech coding round scores communication alongside correctness, and at Google the interviewer’s written notes are the only evidence that reaches the hiring committee. Unexplained correct code scores worse than explained near-miss code.

Practise saying these five things on every problem, from your very first one:

1. “Let me restate the problem to check I have it.” Then do.
2. “The constraints say n up to 10^5, so I am aiming for O(n log n) or better.”
3. “This looks like a [pattern], because [the cue].”
4. “Before I code, let me name the edge cases: empty input, single element, all-identical, duplicates, negatives.”
5. “Time is O(…), space is O(…), because [reason].”

Saying these aloud while alone feels absurd. It is also the single cheapest improvement available to you, and the one candidates most reliably skip.

Choosing a sheet

Any of them works. Pick one and finish it rather than sampling three.

• Starting from zero? Striver’s A2Z. It is the only one that teaches the basics rather than assuming them.
• Know the data structures, need interview coverage? NeetCode 150. The default for good reason.
• Two weeks out? Blind 75, and accept the gaps.
• Want the tedious-but-real implementation problems too? LeetCode’s Top Interview 150 — it includes the string-parsing and Roman-numeral problems the pattern-first sheets skip, and those do get asked.

Whichever you pick, the consensus problems — the ones appearing in three or more sheets — come first.

Next: The Sheets, Mapped — how much the sheets overlap, and the smallest set of problems that covers all of them.