How to use this guide

The goal is a skill you can repeat: read a problem you've never seen, find an approach, make it fast enough, explain why it works, and write the code without anyone handing you the key idea.

Study in two modes. In learning mode, read a chapter, study a worked example, and solve a related problem, with help if you need it. In test mode, hide the tags and notes, mix topics you've studied, and try a problem you haven't seen. Keep track of the two separately. Solving a problem after a hint is progress, but it's not the same as solving it alone.

For each problem you're learning from, follow these steps:

1. Restate the input, the output, the limits, and any unclear cases.
2. Work a small example by hand.
3. Describe a simple solution that's clearly correct, and its cost.
4. Find exactly which work it repeats or doesn't need.
5. Look for a fact about the input that removes that work.
6. Say what your solution keeps true at each step, and why each step is safe.
7. Write the code, trace it by hand, and test it.
8. Close the explanation and rebuild the reasoning yourself.
9. Come back a few days later and use the idea on a different problem.

Start with 20–30 minutes of real effort before taking a hint, and adjust for your experience and the problem. Keep going as long as you're still coming up with new ideas. When a technique is completely new to you, study a worked example first. These time limits and review gaps are coaching advice, not tested rules, and strong competitors disagree about when to read the solution S4.

When you review, write out the reasoning before you look at code. Try reviewing after a day or two, then a week, then a few weeks, and adjust to how well you remember. Experiments show that practicing recall after a delay helps memory, though the classic study used prose, not code S6.

In a 60-minute session, try 10 minutes recalling old problems, 30 minutes on a new one, 15 minutes explaining or rebuilding a solution, and 5 minutes writing down the idea you missed. Once you know several techniques, mix them in one session. Mixing topics helps in math experiments; that it helps with choosing algorithms is a reasonable guess, not a tested result S7.

Keep a progress log. For each problem, write down: whether you solved it alone or with help, your first wrong assumption, the idea you missed, what the solution keeps true, your coding mistake, and a variation to try next. Write what you can actually do, such as "explained why the left pointer never moves back", not a vague confidence score.