Contest Strategy¶

How to Actually Compete¶

Most people treat a contest like a homework assignment: start at problem 1, finish it, move to problem 2. That approach will cost you rating points and, more importantly, will cost you time on problems you could have solved. Contest performance is a skill separate from problem-solving skill. You can know every algorithm and still place in the bottom half because your contest process is broken.

This file fixes the process.

The First 5 Minutes: Read Everything Before You Start Anything¶

This is the single highest-leverage habit in competitive programming and the one most beginners ignore.

When a contest starts:

Open all problems simultaneously (or tab through them quickly)
Read the title and first 2 sentences of each
Note the constraints
Mentally tag each problem: “immediate,” “probably know it,” “need to think,” “skip for now”
Start with “immediate” — the problem you can code in 10 minutes flat

Why this matters: Problem A is not always the easiest problem. In Codeforces Div. 2, problem B is frequently easier than A for people with certain backgrounds. In LeetCode weeklies, Q2 sometimes has a cleaner solution than Q1 if you know the pattern. A 5-minute read of all problems before touching any code has won contests. Skipping this step has lost them.

What to extract in those first 5 minutes:

Problem type (counting, optimization, graph, string, geometry?)
Input size (tells you required complexity class — see 02_pattern_recognition_at_speed.md)
Any obvious special structure (tree? DAG? sorted input?)
Your confidence level: “I’ve done this exact type before” vs “new territory”

Problem Ordering Strategy¶

The default A→B→C→D ordering is a trap. Use this instead:

Step 1: After the first-5-minutes scan, sort problems by your personal estimated solve time.

Step 2: Solve them in order of fastest-to-slowest, not easiest-to-hardest as rated by the problem setter.

These are related but not the same. You might have done 40 problems on monotonic stacks last month. If problem C involves one and problem B is a pure math observation you haven’t drilled, do C first.

The rule: Your goal in the first 45 minutes is to maximize the number of problems you’ve submitted, not to work through them in order. Every accepted submission in the first half of a contest earns disproportionately more rating than the same submission in the second half.

Penalty arithmetic matters on Codeforces: Wrong submissions add 50-minute penalties. A correct first submission at minute 10 is worth far more than a correct first submission at minute 40 after 2 wrong attempts. Submit only when you’re confident.

Time Boxing: The 20-Minute Rule¶

If you are stuck on a problem for more than 20 minutes with no real progress, move on.

“No real progress” means: you haven’t identified the pattern, you haven’t written any correct subproblem, you’ve been staring at the same wrong approach for 15 minutes.

This is hard to internalize because it feels like quitting. It isn’t. It’s triage. You may have 2 other problems you could solve in 15 minutes each. Staying stuck on one problem while those expire is the single most common way capable competitors underperform their rating.

The comeback rule: After you’ve worked other problems, return. Fresh eyes after 20 minutes of other work often unlock the stuck problem immediately. Your brain’s pattern-matching runs in the background.

The “Confident Submission” vs “Exploratory Submission” Distinction¶

A confident submission is: “I’ve verified the algorithm is correct, I’ve checked edge cases, I’ve tested on the examples, I believe this is right.” Submit immediately.

An exploratory submission is: “I think this might work, let me just try it and see.” Do NOT submit exploratory solutions in rated contests.

Wrong submissions on Codeforces cost you 50 minutes per wrong submission added to your solve time for that problem. In a 2-hour contest, 2 wrong submissions on a problem you eventually solve at minute 60 means your effective solve time is 160 minutes — worse than not solving it at all.

Before every submission, ask: Did I test on the provided examples? Did I check the edge case for n=1? Did I check for integer overflow if values are up to 10^9?

If the answer to any of these is “no,” spend 3 more minutes before submitting.

Penalty Awareness in Practice¶

Codeforces: wrong submissions add 50-minute penalty to that problem’s solve time. Your score is determined by solve time, not just number of problems solved.

LeetCode: wrong submissions don’t count in weekly contests (as of 2024-2026). You can submit exploratory solutions more freely. Use this difference.

Practical implication: On Codeforces, verify before you submit. On LeetCode, submit early to check if your logic is right, then optimize if you get WA.

The Upsolver Habit: The Real Training Happens After the Contest¶

This is what separates competitors who plateau from competitors who grow. After every contest:

Note every problem you didn’t solve during the contest
Within 24 hours, attempt each one again with no external help
If you can’t solve it in 45 more minutes, read the editorial (see 03_reading_editorials_correctly.md)
Implement the solution yourself — never copy
Write one sentence in your practice log: “This was [pattern]. I missed it because [reason].”

The upsolve session is worth 3x the contest session for skill development. The contest gives you the problem under pressure. The upsolve gives you the analysis of why your brain didn’t get there. That analysis is the actual learning.

What most competitive programmers get wrong: They upsolve the solutions, not the reasoning. They read the editorial code, type it out, and move on. They have solved zero new problems. They’ve transcribed code. Always implement from the approach, not from the code.

Tracking Your Improvement¶

Rating is a lagging indicator. It reflects where you were 2 weeks ago, not where you are today. Don’t panic when your rating dips. Don’t relax when it spikes.

Track these instead:

Metric	How to Measure	Target (M9)
Div. 2 A solve rate	% of A problems solved during contest	>90%
Div. 2 B solve rate	% of B problems solved during contest	>80%
Div. 2 C solve rate	% of C problems solved during contest (attempt + solve)	>60%
LeetCode weekly percentile	Bottom of problem list after contest	Top 30%
Upsolve completion	% of unsolved problems upsolvedwithin 24h	>85%
Pattern ID accuracy	After upsolve: did you correctly name the pattern?	Track in log

Keep these in your practice log. Look at them monthly, not daily.

Weekly Contest Schedule Recommendation¶

You have limited time. Be selective and be consistent. Consistency > volume.

Recommended minimum for this phase:

1 Codeforces Div. 2 or Div. 3 per week (rated, live)
1 LeetCode weekly contest per week (Sunday 8am IST / Saturday 8pm IST for biweekly)
1 virtual Codeforces contest per week (past rounds, timed)

That’s 3 contests a week, roughly 6 hours of contest time plus 3-4 hours of upsolving. This fits in your 10-15 hour budget.

Don’t chase every contest. Missing one is fine. Missing 3 in a row because you’re “busy” means you’re not in a consistent practice mode. Schedule them like meetings.

What Most Competitive Programmers Get Wrong¶

Rating is addictive. People start optimizing for rating instead of for learning. They avoid problems slightly above their level because a wrong attempt might drop their rating. They stick to comfortable problem types because they know those will add rating points.

This is rational short-term and disastrous long-term.

Rating is a lagging indicator of learning. If you spend 3 weeks upsolving hard problems and your rating dips 50 points in that period, you have done 3 weeks of real growth. If you spend 3 weeks cherry-picking A/B problems and your rating climbs 80 points, you have done 3 weeks of stagnation with a cosmetically improving number.

At your stage, the goal is to maximize pattern exposure, not to protect rating. A stable rating means you’re not pushing your ceiling. Push it.

Navigation: ← README | 02 Pattern Recognition → | Back to Roadmap