From Codeforces Expert to ~8,000 Problems: The Practice System That Actually Worked
Over the years I’ve solved close to 8,000 problems across Codeforces, CodeChef, LeetCode, UVa, and other judges, and made Codeforces Expert in university. Pre-2022, before AI assistants, every solution unassisted under contest pressure. People assume the number came from grinding harder than everyone else. It didn’t. I grind about as hard as anyone. The number came from a system that made the grind compound.
The number is a side effect
I never set out to solve 8,000 problems. I set out to stop being stuck on the same category of problem twice. The count is just what accumulates when every solved problem teaches you something reusable. If your problem count isn’t turning into rating, you’re collecting trophies, not building skill.
1. Solve at the edge of your ability, not below it
The biggest mistake I see: people solve problems they can already solve, because it feels good. Growth happens almost entirely on the ones you can’t immediately see through — where you sit for 20–30 minutes genuinely unsure. Calibrate ruthlessly. If you’re clearing 90% on sight, your set is too easy and you’re farming dopamine, not rating.
2. The editorial is a teacher, not a confession
Reading the solution isn’t cheating. Reading it too early is. My rule: real effort first (a hard cap, 30–45 minutes of genuine attempts), then read the editorial, then re-implement from scratch without looking. The re-implementation is the whole point. Recognizing a technique and being able to produce it cold are different skills, and only the second one shows up in a contest.
3. Build a personal taxonomy of tricks
Every problem that taught me something went into a running index, organized by the idea that cracked it — not the problem, the idea. Binary-search-on-answer. Two pointers on a sorted invariant. Offline queries sorted by right endpoint. After a few hundred entries, new problems stop looking novel and start looking like combinations of things you already filed away. That recognition speed is what rating actually measures.
4. Upsolve every contest, especially the painful ones
The problems you couldn’t solve during a contest are the highest-value problems you’ll ever see, because the environment already proved you can’t do them yet. Upsolving — finishing them afterward, properly — is where almost all my rating came from. Contests diagnose. Upsolving treats.
5. Volume across judges, not just one
Different judges, different cultures. Codeforces rewards speed and observation. CodeChef’s long challenges reward depth. UVa builds breadth and patience. LeetCode maps closest to interviews. Spreading ~8,000 problems across all of them gave me range one platform never would. Grind a single judge and you over-fit to its style.
What it actually bought me
The obvious payoff is interviews — same patterns, lower stakes. The deeper payoff showed up at work: scaling a protocol past $500M+ TVL at Stader, later building payments systems, the habit of decomposing a messy problem into known sub-structures is exactly the competitive-programming muscle, just pointed at production. Algorithms practice didn’t make me good at puzzles. It made me fast at seeing structure in chaos, which is most of what senior engineering is.
The honest meta-lesson
A credential earned through thousands of hours of unassisted problem-solving means something specific now that it didn’t five years ago. It’s proof of a kind of reasoning that’s getting rare. Whatever tools exist, the ability to sit with a hard problem and derive the answer is still the thing. The 8,000 problems were just the reps. The model can’t do them for you in the room where it counts.
I’m Prajjwal Chittori — backend engineer (crypto × payments), Codeforces Expert. prajjwalchittori.com · Codeforces · GitHub.