Start Here: How to Practice

This roadmap works best when you treat it as a practice discipline, not a checklist. The difference between grinding a hundred problems and genuinely improving at problem-solving comes down to how you approach each one — not how many you do.

The loop

For every problem, follow the same sequence:

1. Read the problem. Don't start coding yet.
2. Name the pattern. Before you write a line of code, say out loud which pattern you think this problem needs and what triggered that recognition — a sorted array, a pair search, a contiguous subarray, a "minimise the maximum" constraint. The identification step is the skill being trained; skipping straight to code is how people grind hundreds of problems and improve at nothing.
3. Attempt it. Solve it within the time-box. No hints, no AI, no looking up solutions.
4. Check your answer. Compare against the target complexity — the judge says "Accepted" even for a brute-force solution, so your own standard is whether you hit the pattern's benchmark.

The first two steps are where the learning happens. Every time you correctly identify a pattern before writing code, that recognition gets a little more automatic.

Struggle is the mechanism

When you're stuck — when the time-box is running and nothing is working — that discomfort is the learning happening. Being handed the answer (by AI, by a solution video, by looking at the discuss tab) feels like progress and produces none. The feeling of "I almost had it" or "I was on the right track" is real progress, even if the submission didn't pass.

If you're stuck when the time-box passes, stop coding and re-read the pattern's triggers. Nine times out of ten, the block is "I didn't recognise the shape," not "I can't code this." The time-box is a cue to change activity, never a grade. Struggling past a time-box is not failure — it's the mechanism working.

How to use AI honestly

This matters because everyone reading this uses AI. It's not going away, and pretending otherwise helps nobody. The question is how to use it without letting it erode the skill you're here to rebuild.

A simple rule of thumb: ask AI to explain, never to solve.

Good uses of AI during practice: - "Why is this approach O(n²)?" - "What does this error mean?" - "Review my finished solution — where does it deviate from the target complexity?"

Uses that short-circuit the learning: - "Write the solution to this problem" - "Which pattern should I use for this problem?" - "Fix my bug"

The difference is that the first group leaves you with understanding you keep. The second group leaves you with code that evaporates the moment you close the tab. AI is a tool; if it does your thinking, you're the tool.

When to move on

You own a pattern when you can do two things without help: 1. Recognise it from the problem statement before you start coding. 2. Hit the target complexity on a new problem in that pattern's family.

That is the bar. Not "I've done every problem in the set." Repetition past that point is comfort, not practice. Each pattern page has a "test out" note on its challenge problem — if you can solve that one cleanly, you're done. Move to the next pattern.

Spacing and revisiting

Coming back to a pattern a week later and re-solving one problem from memory beats doing five new ones today. The roadmap is designed to be walked forward, but circling back to an earlier pattern for one quick solve is one of the highest-leverage things you can do. It tells you whether the recognition stuck or faded, and it costs twenty minutes.

One more thing

Every person on this roadmap either freezes on unfamiliar problems or is rebuilding skill that atrophied from disuse. Both feel some shame about it. Neither should. The fact that you're here doing structured practice — instead of grinding random problems or handing the work to AI — means you're already doing it better than most. Trust the sequence, follow the loop, and let the struggle do its job.