How to Practice

beginner15 min

The short version

Improvement comes from solving problems slightly above your current level, and from reading the solution when you are genuinely stuck rather than grinding indefinitely. Both halves matter. Only doing easy problems builds speed but not range. Never reading solutions means you rediscover standard techniques slowly instead of learning them.

Picking the right difficulty

Work at your current level and one step above it. Solve problems at your level until you can do most of them, then move up.

Signs you have the difficulty wrong

  • Too easy: you see the approach immediately on almost every problem. Move up to harder problems.
  • Too hard: you have no idea where to start on most problems, even after twenty minutes. Move down, or work through the topic lessons for the techniques you are missing.
  • About right: you solve some after real thought, and get stuck on others in a way that makes sense once you read the solution.

The best source is the past-problem archive of whichever contest you are aiming at. Past problems share the style, the format, and the graders of the real thing.

How long to stay stuck

There is no exact number, but a useful guideline is 30 to 60 minutes of genuine effort on a problem at your level before looking at hints.

“Genuine effort” means writing things down: what the input looks like, what a small case does, which techniques might apply. Rereading the statement for the fifth time while hoping for insight is not the same thing.

When you get stuck

  1. Work a small case by hand. N = 3 or N = 4. Often the pattern appears.
  2. Ask what the constraint is telling you. N ≤ 20 means subsets; N ≤ 200,000 means sorting or a log-factor structure.
  3. Ask what a simpler version of the problem would be, and whether you can solve that.
  4. Look for a hint rather than the full solution — the technique name is often enough.
  5. If still stuck, read the solution properly. Then close it and implement it yourself from memory.

Step 5 is the part people skip. Reading a solution and nodding is not learning it. Implementing it without looking is.

After you solve it

The few minutes after a solve are the highest-value minutes available.

Do these before moving on

  • Read the official solution even though you solved it. There is often a shorter or cleaner approach.
  • Name the technique out loud. “This was two pointers on a sorted array.” Problems are recalled by technique, not by story.
  • Note what cost you time. If you lost twenty minutes to an overflow bug, that is a checklist item, not bad luck.
  • If your solution was much longer than the official one, work out why.

After you give up

Do not just move on. A problem you failed and then read about is worth more than one you solved easily, provided you close the loop.

Closing the loop

  1. Identify the specific insight you missed. Not “I did not think of DP” — rather, “I did not notice that the order of items does not matter, which is what makes it a knapsack.”
  2. Implement the solution yourself, from understanding, not by copying.
  3. Find another problem that uses the same technique and solve that one.

Step 3 is what converts a read solution into a technique you own.

Contest simulation

Once you are solving individual problems reliably, practice under contest conditions: three problems, four hours, no reference material beyond what you would have in the real contest, no breaks that stop the clock.

This trains things that individual problem practice does not — deciding which problem to attempt first, deciding when to abandon one, and managing the last thirty minutes when you have a partial solution and a choice about whether to risk changing it.

Contest-day decisions worth rehearsing

  • Read all three problems before writing any code. Roughly ten minutes.
  • Start with the one you are most confident about, not necessarily the first.
  • If you have made no progress on a problem in 45 minutes, switch. You can come back.
  • With an hour left, prefer securing partial credit on a problem you understand over starting something new.
  • Submit working partial solutions as you go. A correct brute force banked is better than an ambitious solution that is unfinished at the deadline.

Keeping a record

A short log is worth the effort. For each problem: the name, the technique, and one sentence on what you missed or learned. After a couple of months, patterns become visible — you will find that a particular category keeps costing you, which tells you what to study.

This does not need to be elaborate. A plain text file is enough.

Set up your practice loop

Concrete first week:

  1. Pick five problems at your current level from a past-contest archive.
  2. Give each a real 45 minutes before looking at anything.
  3. For each one, write down the technique and one sentence about what you learned.
  4. For any you did not solve, implement the solution yourself afterward, then find one more problem using the same technique.
  5. At the end of the week, look at your notes and name the one topic that cost you the most.

Next

Contest Strategies