- Time Allocation (2h for Div 2)
- The Order of Operations
- 0️⃣ Before Contest
- 1️⃣ Read ALL Problems First (5 min)
- 2️⃣ Solve A (5-15 min)
- 3️⃣ Solve B (10-25 min)
- 4️⃣ Solve C (30-45 min)
- 5️⃣ Solve D (if time)
- Attack Patterns by Problem Type
- "Implementation" problems (A, easy B)
- "Math" problems
- "Greedy" problems
- "Binary search on answer" problems
- "Graph" problems
- "DP" problems
- Common Mistakes Checklist
- Mental Game
Contest Strategy
Contest Strategy — Codeforces Div 2
Time Allocation (2h for Div 2)
| Phase | Time | Problems | Goal |
|---|---|---|---|
| Read & Categorize | First 5 min | All A,B,C,D | Decide which to skip |
| Solve A | 5-15 min | A | 100% |
| Solve B | 10-25 min | B | 100% |
| Solve C | 30-45 min | C | Target |
| Solve D | 30-40 min | D | If time remains |
| Stress test / Hack | Last 10 min | A,B | Avoid stupid fails |
The Order of Operations
0️⃣ Before Contest
- Set up template with boilerplate already in editor
- Have fast I/O ready
- No distractions, good chair, water
1️⃣ Read ALL Problems First (5 min)
Skim through A,B,C,D — note: - What's the input/output format? - What's the constraint range? (n ≤ 20 → bitmask/DP, n ≤ 2000 → O(n²), n ≤ 2e5 → O(n log n)) - Does it smell like a known pattern? (XOR, parity, gcd, constructive) - Which problem looks most accessible after A?
2️⃣ Solve A (5-15 min)
If you can't solve A in 15 min, you're overcomplicating it. Read again, simplify.
3️⃣ Solve B (10-25 min)
B is usually greedy or constructive after a bit of reasoning. - If stuck >20 min on B, read C — sometimes B is harder than C for you.
4️⃣ Solve C (30-45 min)
This is where the real fight happens. C is the rating gatekeeper. - 1200-1400 rating C: binary search, math, DP, graphs - If nothing >30 min → read editorial after contest, don't waste more - The 30-min rule: If no concrete progress in 30 min, write down what you tried, submit brute-force if applicable, move to D
5️⃣ Solve D (if time)
D is usually a data structure / combinatorial problem (1400-1700). - If you're unrated/new, D is bonus — don't sacrifice C for D
Attack Patterns by Problem Type
"Implementation" problems (A, easy B)
- Write the brute-force translation directly
- Test on sample, submit immediately
"Math" problems
- Try small examples manually, find pattern
- Test edge cases: n=1, n=2, all zeros, all equals, max values
- Check parity, modulo, gcd
"Greedy" problems
- "What's the optimal choice at each step?"
- Prove with exchange argument: "If optimal solution does NOT pick X, swapping gives better"
- Try sorting and processing in some order
"Binary search on answer" problems
- "What's the minimum X such that condition holds?"
- Can you write
check(X)that returns true/false? - If yes, is check monotonic? (true for X≥something, false otherwise)
"Graph" problems
- Build graph from description (not given explicitly)
- Check if implicit graph (grid, functional, complement)
- Consider: is it a tree? Bipartite? DAG?
"DP" problems
- State: what changes between subproblems?
- Transition: how do I go from smaller to larger?
- If 2D, can I reduce to 1D?
- Check for segment tree optimization
Common Mistakes Checklist
Before submitting ANY solution: - [ ] Have I overflowed? (Use int64 for sums/multiplications) - [ ] Are array indices zero or one-based? - [ ] Have I handled n=1 / empty input? - [ ] Have I handled modulo correctly? (negative results?) - [ ] Is my DP initialized correctly? (INF for min, 0 for count) - [ ] Does the sample pass? - [ ] Can I come up with a custom edge case?
After failing pretest / Wrong Answer: 1. Re-read the problem statement — did I misread? 2. Check for off-by-one in loops 3. Add debug output for edge cases 4. If still stuck, move on and review later
Mental Game
- Stay calm — panic kills reasoning
- One problem at a time — don't think about C while solving B
- Skip and come back — sometimes the insight hits during another problem
- Read editorial after every contest — for every problem you didn't solve, write down the one-sentence insight
- Practice virtual contests — simulate contest conditions weekly
- Rate is just a number — the learning is in the process, not the number