Competitive Programming From Zero: A 12-Week Plan
By Next Gen Remote Learning editorial team · · For: School and university students
Most people who try competitive programming quit in the first month. Not because they're not clever enough, but because they start in the wrong place. They open a contest, see five problems, solve none of them, and decide it isn't for them.
The fix is boring and effective: learn the core topics in a sensible order, practise each one on purpose, and enter contests as a way to measure progress rather than as the main way to learn.
This plan assumes you can already write basic programs in one language: variables, loops, if-statements, functions and lists. It assumes about six to eight hours a week. If you have less time, stretch each "week" to ten days. The order matters more than the speed.
Before you start: three decisions
Pick a language and stick with it
Most competitive programmers use C++, because it's fast and its standard library has the data structures you need. Python is fine for learning and for many beginner problems, but it can be too slow for some time limits. Java also works.
If you already know Python well, start with it and learn C++ later when speed starts to matter. If you're starting fresh and serious about olympiads or ICPC, learning C++ from the beginning saves a switch later.
Choose your main resources
Everything in this plan is free:
- [The CSES Problem Set](https://cses.fi/problemset/): about 300 classic problems, sorted by topic. Brilliant for structured practice.
- [The Competitive Programmer's Handbook](https://cses.fi/book/book.pdf) by Antti Laaksonen: a free, clear book that follows the same topics.
- [The USACO Guide](https://usaco.guide/): a free, well-organised guide with explanations and problems at every level.
- [cp-algorithms](https://cp-algorithms.com/): detailed articles on specific algorithms, for when you want depth.
- Contests: AtCoder Beginner Contests (weekly, beginner-friendly) and Codeforces (frequent rounds at different levels).
Make a rule about AI
Decide now: during practice and contests, no AI. You can use it afterwards to explain an editorial, but the solving is yours. The whole point is to build your own ability, and borrowed solutions build nothing. The biggest contests, ICPC and the IOI, are in person with AI prohibited, so this is also the only way to train for them.
Weeks 1–2: the foundation
Topics: reading input and printing output quickly, time complexity (why an O(n²) solution fails for n = 200,000), arrays, strings, sorting.
Practice:
- The "Introductory Problems" section of CSES. Aim for 10–15 problems.
- Your first AtCoder Beginner Contest. Expect to solve the first two problems. That's a good start.
What to focus on: learning to estimate whether your idea is fast enough before you code it. A rough rule: about 100 million simple operations per second. If your idea does n² steps and n is 100,000, that's 10 billion. Too slow.
Weeks 3–4: searching and counting
Topics: binary search (on arrays and "on the answer"), two pointers, prefix sums, basic counting and frequency arrays.
Practice:
- CSES "Sorting and Searching" section, the first 10–12 problems.
- One contest per week. Upsolve one problem you missed each time.
What to focus on: binary search on the answer is one of the most useful ideas in the whole field. "What's the smallest X such that something is possible?" If checking a guess is easy, you can binary search the answer. Once this clicks, a whole family of problems opens up.
Weeks 5–6: the standard toolbox
Topics: sets, maps and priority queues (in C++: set, map, priority_queue), stacks and queues, basic greedy algorithms.
Practice:
- Remaining "Sorting and Searching" problems you can handle.
- Five to eight greedy problems from the USACO Guide (Bronze and Silver).
What to focus on: greedy algorithms are tempting and often wrong. For each greedy idea, try to find a small example that breaks it before you code. If you can't break it, try to explain why it works. This habit saves many wrong submissions.
Weeks 7–8: recursion and dynamic programming
Topics: recursion, complete search with backtracking, and the beginnings of dynamic programming: coin change, longest increasing subsequence, simple grid paths.
Practice:
- CSES "Dynamic Programming" section, the first 8–10 problems.
- Re-solve two earlier problems recursively, just to practise.
What to focus on: dynamic programming scares people, but most beginner DP is the same recipe. Define what a state means in plain words ("dp[i] is the minimum number of coins to make sum i"), write how one state depends on smaller ones, then decide the order to fill them. Say the state definition out loud before you write any code.
Weeks 9–10: graphs
Topics: representing graphs, depth-first search, breadth-first search, connected components, shortest paths in unweighted graphs, then Dijkstra's algorithm.
Practice:
- CSES "Graph Algorithms" section, the first 8–10 problems.
- Grid problems (mazes, islands): they're graphs in disguise.
What to focus on: recognising that a problem is a graph problem at all. Cities and roads are obvious. Grid cells, states of a puzzle and people with friendships are less obvious. Once you see the graph, the algorithm usually follows.
Weeks 11–12: putting it together
Topics: review. Revisit your weakest topic from the previous ten weeks, and add one new one if you're ready (for example, basic number theory: divisibility, GCD, modular arithmetic).
Practice:
- Two contests a week if you can.
- Upsolve every problem you were close to.
- A "mixed" practice session: ten random problems from CSES sections you've covered, without looking at the section names first.
What to focus on: identification. In real contests, problems don't come labelled "binary search" or "DP". The skill you're building now is reading a problem and recognising which tool it needs.
"How much maths do I need?"
Less than people fear, at least at the start. For the first three months, you need comfortable arithmetic, a feel for how fast numbers grow (why 2 to the power 30 is about a billion), basic algebra, and simple counting, such as how many pairs you can make from n items. Most of this is school maths used in a new way.
Later topics lean on more maths: number theory, combinatorics, probability and some geometry. You can learn these when you need them, alongside the problems that use them, which is usually easier than learning them in the abstract. If maths feels like your weak point, an hour a week of targeted practice with a teacher goes a long way.
How to practise well (not just a lot)
Spend 30–45 minutes on a problem before reading a hint. Less, and you don't build problem-solving muscle. Much more, and you waste time you could spend learning.
Read editorials actively. After reading the solution, close it and write the code yourself. If you can't, you didn't really understand it yet.
Keep a mistake log. Every wrong answer has a reason: an overflow, an off-by-one error, a forgotten edge case, a misread statement. Write it down. Most people make the same five mistakes over and over, and a log helps you stop.
Upsolve after every contest. The problem you nearly solved is the one that will teach you most.
Don't skip the boring problems. Implementation-heavy problems with fiddly details build the accuracy that wins contests.
What progress looks like
After 12 weeks of steady work, a typical motivated student can solve the first three or four problems of an AtCoder Beginner Contest fairly reliably, has solved 80 to 120 practice problems, and is comfortable with sorting, binary search, prefix sums, basic DP and BFS/DFS.
That's a real foundation. It's also roughly where online rankings become noisy, because AI-assisted cheating is most common in easier rounds. Don't let that bother you. Your personal log, and in-person contests such as school olympiads or ICPC regionals, are better measures of how far you've come.
Common traps
Collecting resources instead of solving problems. You don't need a fifth course. You need to solve the next problem.
Only doing problems you can already solve. Comfortable practice feels good and teaches little. Aim for problems where you succeed about half the time.
Comparing yourself to others too early. Some people you see online have trained for years. Compare yourself to where you were last month.
Training alone for too long. A study group, a club, or a coach makes the hard weeks easier and catches misunderstandings early.
After the 12 weeks
From here, the path depends on your goal. Olympiad students should follow the USACO Guide's Silver and Gold sections and look up their national olympiad's syllabus. University students aiming at ICPC should find two teammates and start practising as a team, because team contests reward communication and division of work. Students preparing for technical interviews should mix in more practice explaining their solutions out loud.
If you'd like someone to guide you through these stages, check your solutions and help with the topics that don't click, our competitive programming teachers work one-to-one with students at every level, from first contest to national olympiad.
Twelve weeks from now, you could be solving problems that look impossible today. The only requirement is that you start with the first one.
Frequently asked questions
Which language is best for competitive programming?
C++ is the most common because it is fast and has a strong standard library. Python is fine for learning and many beginner problems but can be too slow for some time limits.
How much maths do I need for competitive programming?
At first, comfortable arithmetic, basic algebra and simple counting. Number theory, combinatorics and probability can be learned later alongside the problems that need them.
Where should a beginner practise competitive programming?
Start with the CSES Problem Set and AtCoder Beginner Contests, use the USACO Guide for structured topics, and move on to Codeforces rounds.