Competitive Programming Roadmap: Codeforces & CodeChef from Newbie to Expert

Competitive programming rewards a specific kind of practice. Plenty of students solve 800 problems and stay grey on Codeforces, while others solve 300 and reach Expert. The difference is almost never talent. It is what they practise, at what difficulty, and what they do after a problem defeats them.

This roadmap is organized by rating band rather than by calendar, because that is how CP progress works: each band has a set of ideas and habits that unlock the next one. It also covers the practice loop, contest strategy, a stress-testing setup that will save you hours of wrong-answer debugging, and an honest look at how CP translates (and does not translate) into jobs in India.

How Codeforces and CodeChef Ratings Work

Both platforms use Elo-like systems: your rating moves based on your rank in a contest compared with what your current rating predicts. Beating people rated above you raises your rating faster. New accounts on Codeforces start from a low displayed rating and rise over the first few contests, so do not panic about your first numbers.

The two scales are not directly comparable; contest pools differ. As a loose rule of thumb that people use, a CodeChef rating tends to sit a few hundred points above an equivalent Codeforces rating. Do not over-interpret this.

Contest formats you will meet

• Codeforces Div. 4, Div. 3: for lower-rated participants. Div. 4 is the best place for absolute beginners to get rated.
• Codeforces Div. 2 / Div. 1: the main rounds. Div. 2 is for ratings below about 1900 or 2100 depending on the round; Div. 1 for higher.
• Educational Rounds: ICPC-style scoring (penalty time, no hacking phase during the round), very good problems for learning standard techniques.
• CodeChef Starters: weekly rated contests, usually on Wednesdays (IST evening), split into divisions by rating.
• AtCoder Beginner Contest (ABC): not covered by this roadmap's title, but excellent for clean, educational problems on weekends.

Language Choice and a Contest Setup

C++ is the standard: it is fast, the STL gives you sorting, heaps, ordered sets, maps and binary search out of the box, and nearly every editorial uses it. Java works but needs fast I/O and more code. Python is pleasant but can time out on problems with tight limits; use PyPy if the platform offers it. Our Java vs Python vs C++ comparison goes into the trade-offs in detail, and the C++ STL guide covers the containers you need.

Start every problem from a small template. Do not use a 300-line template full of macros you do not understand. This is enough:

#include <bits/stdc++.h>
using namespace std;
using ll = long long;

void solve() {
    int n; ll x;
    cin >> n >> x;
    vector<ll> a(n);
    for (auto &v : a) cin >> v;
    // Example: count pairs i < j with a[i] + a[j] <= x
    sort(a.begin(), a.end());
    ll pairs = 0;
    int i = 0, j = n - 1;
    while (i < j) {
        if (a[i] + a[j] <= x) { pairs += j - i; i++; }
        else j--;
    }
    cout << pairs << '\n';
}

int main() {
    ios::sync_with_stdio(false);
    cin.tie(nullptr);
    int t = 1;
    cin >> t;            // most modern problems have multiple test cases
    while (t--) solve();
    return 0;
}

Three habits from this template matter more than they look. Fast I/O (sync_with_stdio(false) and untying cin) prevents time-limit failures on large inputs. long long by default for sums and products avoids the most common wrong answer in CP: overflow when values reach 10⁹ and you add or multiply them. And printing '\n' instead of endl avoids flushing on every line.

Newbie to Pupil (0 to 1200): Implementation and Basic Math

At this level, problems rarely need named algorithms. They test whether you can read carefully, translate a statement into code without bugs, and notice simple mathematical observations. Most people stuck below 1200 are losing to misreading and implementation errors, not to missing knowledge.

Topics

• Loops, conditionals, arrays, strings, and 2D grids.
• Simulation: doing exactly what the statement says, carefully.
• Basic math: parity, divisibility, GCD/LCM, ceiling division (a + b - 1) / b, modular arithmetic basics.
• Counting with frequency arrays and map.
• Sorting as a preprocessing step, and simple greedy choices (take the largest first).
• Time complexity awareness: about 10⁸ simple operations per second as a rough budget, so n = 2×10⁵ means O(n log n) is fine and O(n²) is not. See our Big-O guide.

Practice targets

Filter the Codeforces problemset by rating 800 to 1100. Solve problems A and B from Div. 3 and Div. 4 rounds. Aim to solve 800-rated problems within 10 minutes and 1000 to 1100 within 20 to 30 minutes. Participate in every Div. 4 and Div. 3 round you can, and in CodeChef Starters.

Exit criteria: you consistently solve the first two or three problems of a Div. 3/4 round in contest, and your rejections are rare and come from ideas rather than bugs.

Pupil to Specialist (1200 to 1400): The Core Toolkit

This is the band where named techniques start appearing, typically as the main idea of a Div. 2 B or C. The good news: the list is short and very learnable.

The mindset shift: observations

Div. 2 B and C problems usually hinge on one observation that collapses the problem. "The answer is always 1, 2, or 3." "Only the parity of the count matters." "We can always sort without loss of generality." Train this by asking, after every problem you solve or read the editorial for: what was the key observation, and how could I have found it? Usual routes are small cases by hand, extreme cases (all equal, n = 1), and invariants (what never changes under the allowed operation).

Exit criteria: you solve Div. 2 A and B reliably in contest and sometimes C. Your practice problems are mostly 1300 to 1500.

Specialist to Expert (1400 to 1600): Thinking Problems and First Algorithms

To reach Expert you need to solve Div. 2 C regularly and quickly, and sometimes D. Problems become more about reasoning than knowledge, but a few standard algorithms now appear as building blocks.

Topics

• Constructive algorithms: "output any array satisfying...". Practise building answers from small patterns. These are the most common Div. 2 C type and the hardest to prepare for by memorizing.
• Dynamic programming basics: 1D and 2D DP, knapsack style, DP on subsequences, simple DP on grids. See knapsack patterns and DP interview questions.
• Graphs: BFS, DFS, connected components, bipartite check, cycle detection, trees (subtree sizes, depths, DFS order), and Dijkstra.
• Disjoint set union for connectivity queries; see union-find problems.
• Combinatorics with modular arithmetic: precomputed factorials and inverse factorials for nCr mod p.
• Interactive problems: learn the flush rules and the binary-search style query budgets.
• Harder greedy: priority queues, sweeping over events, exchange arguments.

What you can postpone

Segment trees, lazy propagation, heavy-light decomposition, suffix arrays, flows and FFT come up, but rarely as the deciding factor below 1600. Learn segment trees near the end of this band; leave the rest for after Expert. Students who study advanced data structures at 1200 tend to stay at 1200, because their bottleneck is reasoning speed, not knowledge.

The Practice Method That Actually Moves Your Rating

Solving easy problems feels productive and teaches very little. Rating comes from repeatedly working at the edge of your ability. Here is a loop that works.

1. Pick problems in a band. Use the Codeforces problemset filtered by rating: your current rating + 100 to 300. Hide tags in your settings so you do not know the technique in advance; recognizing the technique is half the skill.
2. Think with a timer. Give yourself a fixed window: 30 minutes at first, up to 60 minutes as problems get harder. Write observations on paper. Try small cases by hand.
3. Read the editorial in stages. When the timer ends, read only the first hint or paragraph, then try again for 10 to 15 minutes. Read fully only if still stuck.
4. Implement yourself. Never copy editorial code. Implementing a solution you understood is where bugs and gaps surface.
5. Write a one-line lesson. Keep a log: problem link, rating, key observation, why you missed it. Review the log weekly.
6. Re-solve after a week. Problems where you needed the editorial go into a re-solve queue. If you cannot solve it cleanly a week later, you did not learn it.

A sample weekly plan for a college student

Virtual contests are underused. When there is no live round, take a past Div. 2 round as a virtual participation: same time limit, no editorials. It trains the contest pressure that pure practice does not.

Contest Strategy and Upsolving

Practice builds skill; contests convert skill into rating and build speed under pressure. A few practical rules:

• Read the first three problems before coding. Sometimes B is easier for you than A.
• Penalty matters. In standard Codeforces rounds, problem score decreases with time and wrong submissions cost points. Test on samples and a couple of your own edge cases before submitting.
• Edge cases to check every time: n = 1, all elements equal, maximum values (overflow), negative numbers, already-sorted input.
• Do not quit a bad contest. Leaving after a slow start trains you to avoid discomfort. Keep working on the next problem; upsolving starts there.
• Do not obsess over single-round deltas. Rating is noisy. Look at the trend over 10 contests.

Upsolving is solving, after the contest, the problems you could not solve during it. Specifically, upsolve the first problem you failed to solve. If you solved A and B and failed C, then C is your priority, because that is the problem at your exact edge. Ignore F.

Debugging Wrong Answers With Stress Tests

"Wrong answer on test 7" with hidden tests is the most frustrating part of CP. The professional answer is a stress test: write a slow brute-force solution you are confident in, generate thousands of small random inputs, and compare outputs until they differ. The failing case is usually tiny and immediately shows the bug.

#include <bits/stdc++.h>
using namespace std;
int main() {
    int t; cin >> t;
    while (t--) {
        int n; long long x; cin >> n >> x;
        vector<long long> a(n);
        for (auto &v : a) cin >> v;
        long long pairs = 0;
        for (int i = 0; i < n; i++)
            for (int j = i + 1; j < n; j++)
                if (a[i] + a[j] <= x) pairs++;
        cout << pairs << '\n';
    }
}

import random, sys
random.seed(int(sys.argv[1]))
print(1)                                  # one test case per input
n = random.randint(1, 8)                  # keep inputs tiny
x = random.randint(-10, 20)
print(n, x)
print(*[random.randint(-10, 10) for _ in range(n)])

import subprocess, sys
for seed in range(1, 1001):
    inp = subprocess.run([sys.executable, "gen.py", str(seed)],
                         capture_output=True, text=True).stdout
    fast = subprocess.run(["./sol"], input=inp, capture_output=True, text=True).stdout
    slow = subprocess.run(["./brute"], input=inp, capture_output=True, text=True).stdout
    if fast != slow:
        print("Mismatch on seed", seed)
        print(inp, "expected:", slow, "got:", fast)
        break
else:
    print("All 1000 tests passed")

Compile both with g++ -O2 -std=c++17 -o sol sol.cpp and g++ -O2 -o brute brute.cpp, then run python stress.py. Keep n small (under 10) so the counterexample is readable. Small values (like -10 to 10) also make edge cases such as duplicates and negatives far more likely to appear.

Also compile locally with sanitizers while practising: g++ -std=c++17 -g -fsanitize=address,undefined sol.cpp catches out-of-bounds access and signed overflow that otherwise produce "works locally, fails on judge" bugs. (Sanitizer support depends on your toolchain; it works out of the box on Linux and macOS.)

Does Competitive Programming Help in Getting a Job?

Yes, but in specific ways, and it is worth being precise so you allocate your time sensibly.

The gap between CP and interviews is real. In mock interviews, strong competitive programmers commonly make the same mistakes: they jump to code without explaining, use variable names like a, b, dp2, skip input validation discussion, and struggle when asked to discuss a simpler or alternative approach. If you are CP-strong, spend a few weeks on interview-style practice: solve LeetCode-style problems out loud, as covered in our guide on thinking out loud in coding interviews.

For most students, a balanced path works best: CP until around Specialist or Expert for problem-solving speed, then shift a larger share of time to interview patterns, projects and core CS. If you enjoy CP and are aiming for ICPC or companies known for hard OAs, keep going further. Our LeetCode vs Codeforces vs InterviewBit comparison discusses how to split time between platforms.

ICPC for Indian students

ICPC is a team contest (three people, one computer). Indian regionals have historically been held at host institutes with an online preliminary round. Participating is valuable even if you do not reach the regionals: team practice teaches you to split problems and debug under pressure, and "ICPC regionalist" is a respected resume line. Check the ICPC site and your college's coding club for the current year's schedule.

Breaking a Rating Plateau

Almost everyone plateaus. Diagnose before you change anything.

Competitive programming is a skill that compounds. The first 300 rating points come from carefulness, the next 300 from a core toolkit, and the next 300 from thinking about problems longer before giving up. Keep your practice at the edge, upsolve without exception, and treat your rating as a lagging indicator of habits you control.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.