algorithmsbeginner 18m read

LeetCode — From Basics to Interview-Ready (65 Sessions)

LeetCode is a motor skill, not a knowledge skill. A 65-session pattern-first curriculum: one pattern per session, five problems that are that pattern in disguise, and a spaced queue that makes it stick.

Series hub · 65 sessions · 75 minutes each · every other day · browse the full index

Why this exists

I already have a 130-session curriculum that teaches concepts. Twelve of those sessions cover data structures and algorithms — which is enough to understand a heap, and nowhere near enough to reach for one under a timer while a stranger watches you type.

Those are different skills. The first is knowledge. The second is motor memory.

You do not get better at LeetCode by reading about two pointers. You get better by reproducing the two-pointer skeleton from a blank file, cold, on a Tuesday morning, for the eleventh time — until the shape of the problem summons the shape of the solution without conscious effort. That is a physical skill, closer to scales on an instrument than to reading a textbook.

So it gets its own track, its own time slot, and its own rules.

Common misconception

✗ What most people think

If I solve 500 problems, I'll be good at LeetCode.

Why the myth is so sticky

Volume without pattern structure produces a person who has seen 500 problems and can solve maybe 40 of them again. Every problem feels novel because nothing was ever consolidated into a reusable shape. The people who grind 500 random problems and the people who grind 150 pattern-organised problems do not end up in the same place — and the second group gets there faster.

The core idea: patterns, not problems

There are roughly thirty distinct patterns behind the overwhelming majority of interview questions. Sliding window. Two pointers. Monotonic stack. Topological sort. Binary search on the answer. Each one is a shape — a recognisable configuration of constraints that admits a particular skeleton of code.

An interview question is a pattern wearing a costume. "Find the longest substring with at most K distinct characters" and "find the smallest subarray whose sum is at least S" look nothing alike and are the same problem: expand right, shrink left, maintain an invariant.

Once you see this, the job changes completely. You are no longer trying to memorise problems. You are building a classifier — something in your head that takes a problem statement and, within sixty seconds, emits a pattern name. Everything after that is execution, and execution is trainable.

From first principles

1
An interview gives you ~20 minutes and an unseen problem, because that resembles real work under uncertainty.
2
Because time is short, you cannot derive an algorithm from nothing — you must retrieve one.
3
Because you retrieve rather than derive, the bottleneck is recognition speed, not raw intelligence.
4
Because recognition is the bottleneck, practice should optimise for classification reps, not solve count.
5
Because classification improves with varied examples of the same underlying shape, problems should be grouped by pattern and met repeatedly over spaced intervals.
6
Therefore: a session teaches one pattern and immediately supplies five differently-costumed instances of it — and predicts that after ~30 such sessions, unseen Mediums become classifiable in under a minute.

How a session runs

Seventy-five minutes, every other day, morning slot so it never competes with evening concept study.

Blank-file warm-up (5 min). Before anything else, open an empty file and type the pattern template from memory. Not from notes. If you can't, that's today's real finding.

Pattern anatomy (10 min). What shape of problem summons this? What is the invariant being maintained? What is the skeleton?

Guided solve (15 min). One Easy, fully worked, narrated out loud.

Solo timed (30 min). Two Mediums, fifteen minutes each, timer visible.

Post-mortem (10 min). For anything that failed, one question only: what cue did I miss that should have told me which pattern this was? Write the cue down. The cue is the asset, not the solution.

Spaced queue (10 min). Re-solve whatever is due from previous sessions.

Mental model

A locksmith's ring of skeleton keys. You are not learning to pick every lock in the world — you are collecting about thirty keys and learning, by feel, which key a given lock wants.

🔔 Fires when you see

When a problem feels unfamiliar, stop trying to invent a lock-pick. Ask instead: which of my thirty keys is this shaped like?

The two-attempt rule

This is the rule people break, and breaking it is why their grinding doesn't compound.

Fifteen minutes stuck → read the editorial → close it → re-solve from scratch the next day.

The failure mode is reading the solution, nodding, feeling the click of understanding, and moving on. That click is real but it is recognition, not retrieval, and interviews test retrieval. A problem you understood but never re-derived is a problem you will fail again in six weeks, with the added indignity of remembering that you once knew it.

Spaced repetition, concretely

Every solved problem gets a status and a return date:

Cold — unaided, under fifteen minutes, optimal → returns in 60 days
Warm — unaided but slow or suboptimal → returns in 21 days
Hint — needed a nudge or a peek → returns in 7 days
Failed — read the editorial → returns in 2 days, then 7

The ten-minute queue at the end of each session pulls whatever is due. This is not optional garnish. Re-solving on a spacing schedule is the mechanism by which a pattern moves from "I've seen it" to "it's in my hands".

The tradeoff

Breadth-first — many problems, one pass each

+ you gain Wide exposure; feels productive; good for spotting the variety of costumes

− you pay Almost nothing consolidates; six weeks later you can re-solve very little of it

Depth-first — fewer problems, spaced re-solves

+ you gain Patterns become retrievable rather than merely familiar; performance under time pressure improves sharply

− you pay Feels slow; the visible problem count grows much less impressively

What a senior engineer actually does

Depth-first, unless you already re-solve a random past Medium unaided in under fifteen minutes — if you can do that, you have consolidation and can afford breadth.

The five phases

Phase 0 · Foundations (L01–L06). How to read a problem, constraints as hints, Big-O by counting rather than vibes, the twenty Python idioms that buy you free speed, and the UMPIRE framework. Assumes you have never opened LeetCode.

Phase 1 · Core patterns (L07–L32). The eighty percent. Two pointers, sliding windows, prefix sums, the three flavours of binary search, stacks and monotonic stacks, linked lists, all four faces of trees, heaps, four graph modules, and backtracking. This phase is the spine of the whole track.

Phase 2 · Dynamic programming (L33–L44). The wall. Twelve sessions because DP is not one pattern but a family, and because the standard advice ("practise more DP") is useless without the mechanical recursion → memo → table progression that makes it stop feeling like magic.

Phase 3 · Advanced and specialised (L45–L56). Tries, bit manipulation, intervals, greedy and how to actually prove it, matrix work, design problems, custom comparators, segment trees, string algorithms, weighted graphs.

Phase 4 · Interview simulation (L57–L65). Not new knowledge — pressure. Timed mixed sets, narrated solves, a gap audit against the Blind 75, targeted repair of whatever the audit exposes, a live contest, and finally a maintenance plan so the skill doesn't decay the week after you stop.

Key points

What done looks like

By the end of Phase 1, you can classify an unseen Medium into a pattern within sixty seconds. By the end of Phase 2, DP no longer feels like a different species of problem. By the end of Phase 4, you can take a forty-five minute mock containing one Medium and one Hard, narrate your way through both, and finish unaided.

That's the target. Not a problem count.

Start here: L01 · The LeetCode Game — How to Read a Problem · Full session index