06 — Deliberate Practice Protocol¶
Deliberate practice is not the same as grinding. Grinding is doing volume. Deliberate practice is doing the right kind of work at the right difficulty with immediate feedback and intentional analysis of failure. K. Anders Ericsson, whose research defines the concept, was specifically clear: experts don’t just practice more — they practice at the edge of their current ability, with a goal for each session, and they correct in real time. Most people who plateau in competitive programming are grinding, not practicing deliberately. This file shows you the difference and gives you the system to do it correctly.
The Virtuous Cycle¶
Deliberate practice for competitive programming follows a closed loop. Every iteration of this loop is one unit of real growth:
Attempt → Fail or Succeed → Analyze → Study the gap → Retry → Succeed → Extract pattern → Move to next level
The loop only produces growth when all steps are taken. Breaking the loop at “Fail” (by moving to the next problem without analysis) accumulates volume without understanding. Breaking it at “Succeed” (by not extracting the pattern) means you’ll face the same problem type again without faster recognition. The exit is always “Move to next level” — the next problem that pushes you one step further.
How to Choose the Right Problem Difficulty¶
This is the most underrated variable in practice quality. The difficulty should create a tension — enough challenge that you’re working, not so much challenge that you’re just guessing.
The calibration target: aim for a 50–70% solve rate on problems at your current level. This means:
If you’re solving everything you attempt without much struggle, you’re practicing below your level. Move up.
If you’re solving less than 30% and spending sessions completely lost, the level is too high. Move down one tier and build the prerequisite patterns.
The 50-70% zone is where your brain is actually adapting. It feels uncomfortable. That’s correct.
On Codeforces, this translates to: find the highest rating level where you solve roughly half of problems in ~40 minutes. That’s your practice tier. Spend 70% of your problem-solving time there.
The “Tag Removal” Practice¶
This is one of the most effective techniques for building real pattern recognition and one of the least used.
The method: solve problems with all tags/categories hidden. On LeetCode, don’t use the “Problems by Topic” filter — go to a difficulty level and pick problems blindly. On Codeforces, use the filters to hide problem tags or use Codeforces Gyms / virtual contests where tags aren’t front-loaded.
Why it works: when you can see tags, your brain takes a shortcut. “Oh, it says ‘Dynamic Programming’” — now you’re looking for the DP formulation instead of truly diagnosing the problem structure. Removing tags forces genuine recognition. When you’re in a contest, there are no tags. Practice the way you’ll compete.
Protocol:
3 out of every 5 practice problems should be tag-hidden.
After solving (or upsolving), check the tags. If your pattern identification was wrong, write the mismatch in your lab notebook.
Virtual Contests: The Highest-Fidelity Practice¶
A virtual contest is taking a past Codeforces round as if it were a live rated contest — same time limit, same problem order, no looking up editorials, no skipping around.
This is the closest approximation to real contest conditions outside of actual rated contests, and it trains things that problem-by-problem practice cannot:
Time pressure decision-making (do I keep trying this or move on?)
Contest pacing and energy management
The feeling of submitting with uncertainty
Penalty awareness (you won’t feel the cost of wrong submissions until they cost you something)
Recommended cadence: one virtual contest per week, alongside one real rated contest per week. This doubles your contest experience without affecting your Codeforces rating during the learning phase.
How to run a virtual contest on Codeforces:
Go to any past round (filter by Div. 2).
Click “Virtual participation.”
Set your start time. Run it for the full duration.
After time is up, apply the upsolver protocol (see
01_contest_strategy.md) within 24 hours.
The Practice Log¶
One of the things that separates improving practitioners from those who plateau is a practice log — a record of what you actually did, not what you intended to do. Without it, sessions blur together, weaknesses go unnoticed for months, and you have no signal for what to change.
What to record after every session (takes 3-5 minutes):
Date: 2027-04-10
Duration: 90 minutes
Problems attempted: 3
- CF 1234B (Div 2 B, ~1300 rating) — SOLVED in 25 min. Pattern: greedy + sort. Clean.
- CF 1456C (Div 2 C, ~1600 rating) — FAILED. Tried DP but couldn't find state. Read hint.
After hint: realized it was a graph problem disguised as DP. Common trap.
Pattern missed: "minimum cost across states" ≠ DP if states form a graph.
- CF 1101D (Div 2 D, ~2000 rating) — Attempted 40 min, gave up, read full editorial.
Pattern: segment tree + offline query. Not my level yet. Revisit in 4 weeks.
Weakest area this session: graph modeling — 2nd problem missed because I didn't see the graph structure.
Next session focus: 2-3 graph modeling problems (Dijkstra / BFS disguised as other problem types).
This log is the data source for your monthly review. Without the log, the monthly review is a guess. With the log, it’s a diagnosis.
The Monthly Review¶
Once per month, spend 30 minutes reviewing the last 4 weeks of practice logs. The output is a single decision: what is my weakest pattern this month, and what am I doing next month to fix it?
Review questions:
Which pattern type did I miss the most? (Count mismatch entries in your log)
Which problem difficulty am I actually at? (What’s my current 50-70% solve-rate tier?)
Am I upsolving consistently? (Check: did I upsolve all contest problems I missed within 24 hours?)
Is my virtual contest practice regular?
What one thing, if I fixed it, would most improve my performance?
Resist the temptation to make big changes. One focused adjustment per month compounds. Five simultaneous adjustments create noise.
The “Revisit” Queue¶
Not every problem you don’t solve is a problem you failed. Some problems are simply above your current level and worth returning to later. Keep a revisit queue — a simple list of problem IDs with a target revisit date (usually 3-4 weeks out).
The rule: when a problem is more than 300 rating points above your current level and the editorial makes no sense after 30 minutes, put it in the revisit queue. Don’t abandon it — schedule it. That problem is future growth.
When you revisit a problem and it feels easy, that’s a concrete signal that you’ve leveled up in that pattern. Those moments are worth noting. They’re how you actually see progress.
What Most People Get Wrong¶
The most common failure in deliberate practice is volume optimization over difficulty calibration. People solve 5 easy problems a day to feel productive, hit 200 problems solved, and wonder why their rating isn’t moving. Volume at the wrong difficulty level is not deliberate practice — it’s habit confirmation. You’re reinforcing what you already know.
The second failure: stopping at “I solved it.” The solve is not the unit of practice. The extracted pattern, written in your own words, is the unit. A solved problem with no written extraction is experience without learning. You’ll face the same structure again and feel the same uncertainty.
The third failure: no monthly review. Weaknesses that go undiagnosed for months become entrenched. A 30-minute review once a month is one of the highest-leverage habits in this entire 9-month plan. Don’t skip it.