Competitive Programming Setup¶
LeetCode and Codeforces require different tooling mindsets. LeetCode is a sandbox — the judge runs your code, gives you clean error messages, and you can resubmit 50 times. Codeforces is a real contest: 2–3 hour window, wrong answer penalties (in rated contests), no explanations from the judge, and problems designed to break naive solutions. This document covers the CP-specific setup that goes beyond what the basic IDE guide covers.
Codeforces Account Setup¶
Creating Your Account¶
Go to codeforces.com
Register — use your real handle (it’s public and permanent). Do NOT use your real name as the handle if you prefer pseudonymity.
Verify email
Go to Settings → Edit profile → set your country to India (affects leaderboard visibility and community context)
Contest Participation (First Time)¶
Go to codeforces.com/contests
Find an upcoming Div. 3 or Educational Round (check IST time using +2:30 offset from MSK — see 04_india_specific.md)
Click “Register” before the contest starts (register early, not in the last minute)
Read the rules: wrong answers add 50-minute penalty to your solve time (affects rank, not rating in Educational Rounds)
Virtual Contests — The Right Way to Practice¶
Virtual contests let you replay past contests as if they’re live (timer, same problem order, scoring). This is how you build contest stamina without waiting for a real contest.
How to run a virtual contest:
Go to codeforces.com/contests
Click on any past contest (start with Div. 3 rounds from 2023–2024)
Click “Virtual participation”
Set your start time
Treat it exactly like a real contest: no hints, no editorial, timer running
Target for Phase 3 (when you start CF): One virtual Div. 3 per week. Your goal is to solve A + B reliably, attempt C. A typical Div. 3 has 6–7 problems (A being easiest, difficulty increases sharply).
Codeforces Rating System¶
For context:
Gray: <1200 (unrated or beginner)
Green: 1200–1399
Cyan: 1400–1599
Blue: 1600–1899
Violet: 1900–2099
Orange: 2100–2399
Red: 2400+
For this 9-month plan, reaching Green (1200+) by April 2027 is a realistic and meaningful milestone. Blue (1600+) is achievable with consistent effort and would represent genuine CP competence.
Competitive Companion Browser Extension¶
URL: Search “Competitive Companion” in Chrome Web Store or Firefox Add-ons
This extension is the single most impactful tooling decision for CP workflow. When you visit a problem page on Codeforces, AtCoder, LeetCode, CSES, or any of ~50 supported judges, clicking the Competitive Companion button parses the problem statement, extracts all sample test cases, and sends them directly to CPH (Competitive Programming Helper) in VS Code.
Result: You open a problem, click one button, and VS Code has the solution file created and all test cases loaded. You solve, press run, see which test cases pass. No copy-paste, no manual file creation.
Setup:
Install Competitive Companion in Chrome/Firefox
Install CPH extension in VS Code (
DivyanshuAgrawal.competitive-programming-helper)In VS Code, CPH should show a panel (View → CPH: Judge)
Open a CF problem in browser, click the Competitive Companion button (puzzle piece icon)
CPH receives the test cases and creates a solution file
First-time setup time: 10–15 minutes. Saves that time on every single problem thereafter.
CF-Tool (Command-Line Codeforces Interface)¶
URL: github.com/xalanq/cf-tool Maintenance status (2026): The original cf-tool has had maintenance gaps. A community fork exists and is more actively maintained. Search “cf-tool codeforces” on GitHub to find the current most-maintained version.
What it does:
Submit solutions to CF from terminal without opening a browser
Fetch problem test cases from terminal
Parse entire contest’s problems at once
Show submission verdict in terminal
Verdict: Useful for users who prefer terminal workflow. If you’re comfortable with VS Code + Competitive Companion + CPH, cf-tool is additive, not required. Add it in Phase 3+ once your CF workflow is established and you want to optimize further.
Stress Testing — How to Catch Wrong Answers Before Submitting¶
Stress testing is the most powerful debugging technique for competitive programming. The idea: for a given problem, write two solutions — your optimized one and a brute-force that is definitely correct — then generate random inputs and compare their outputs. If they ever differ, you’ve found a failing case.
When to use it¶
When you’re WA (Wrong Answer) on CF but all sample test cases pass
When you have an “almost works” optimized solution and want to find the edge case
When your solution handles all sample cases but you’re not confident about edge cases
How to set it up locally¶
Step 1: Write a brute force solution
File: brute.cpp — simple, obviously correct, can be O(n³) or worse. Correctness only.
Step 2: Write a random input generator
File: gen.cpp:
#include <bits/stdc++.h>
using namespace std;
int main(int argc, char* argv[]) {
mt19937 rng(atoi(argv[1])); // seed from command line
int n = rng() % 10 + 2; // random n between 2 and 11
cout << n << "\n";
for (int i = 0; i < n; i++) {
cout << (int)(rng() % 100) << " ";
}
cout << "\n";
return 0;
}
Step 3: The stress test runner script
File: stress.sh:
#!/bin/bash
g++ -O2 -o sol sol.cpp
g++ -O2 -o brute brute.cpp
g++ -O2 -o gen gen.cpp
for i in $(seq 1 1000); do
./gen $i > test_input.txt
./sol < test_input.txt > out_sol.txt
./brute < test_input.txt > out_brute.txt
if ! diff -q out_sol.txt out_brute.txt > /dev/null; then
echo "DIFFERENCE FOUND on test $i:"
cat test_input.txt
echo "--- Sol output:"
cat out_sol.txt
echo "--- Brute output:"
cat out_brute.txt
break
fi
done
echo "All tests passed (or diff found above)"
Run: chmod +x stress.sh && ./stress.sh
When the first diff appears, you have a reproducible failing case. Debug your solution against that specific input.
This technique eliminates an entire category of CF frustration: “All sample cases pass but I’m WA on test 47.” Stress testing finds test 47 for you locally before you submit.
Template Library Management¶
What goes in a template library¶
As you learn algorithms, you’ll implement them once and want to reuse the implementation. The competitive programming answer to this is a “template library” — a personal library of verified code snippets.
Organize by category:
templates/
├── data_structures/
│ ├── disjoint_set_union.cpp
│ ├── segment_tree.cpp
│ ├── fenwick_tree.cpp
│ └── sparse_table.cpp
├── graph/
│ ├── dijkstra.cpp
│ ├── bellman_ford.cpp
│ ├── kruskal_mst.cpp
│ └── topological_sort.cpp
├── string/
│ ├── kmp.cpp
│ └── z_function.cpp
└── math/
├── sieve.cpp
├── modular_exponentiation.cpp
└── gcd_lcm.cpp
The rule for adding to your template library: Only add code you have: (a) implemented from scratch at least once, (b) verified correct on at least 2 problems. Do not copy-paste from CP-Algorithms into your template library without implementing and verifying it first.
Build your library progressively¶
Phase 0: Just your main template.cpp
Phase 2: Add segment tree, Fenwick tree after implementing them
Phase 3: Add graph algorithms as you complete each one
Phase 5: Add string algorithms
By Phase 6, your template library will have 15–20 implementations you can paste into a solution in under 30 seconds.
CSES Specific Notes¶
CSES (cses.fi/problemset) is a structured problem set, not a competitive judge. Problems have no contest, no timer, no rating. This makes it ideal for deliberate practice.
How to submit on CSES:
Create account at cses.fi
Go to cses.fi/problemset
Click a problem, write solution, submit
Verdict shows immediately (AC / WA / TLE / RE)
CSES submission tips:
CSES uses C++17 by default. Your template.cpp compiles cleanly.
CSES time limits are reasonable for correct solutions. If you TLE on CSES, your algorithm is wrong, not your constant factors.
CSES does not show what test case failed — this is where stress testing becomes useful.
Navigation: ← 02_problem_tracking.md | → 04_day1_checklist.md