A structured plan to go from beginner to expert in competitive programming. This roadmap assumes you can dedicate around 1-2 hours per day on weekdays and more on weekends. Adjust the timelines based on your schedule -- the important thing is consistency, not speed.
What to learn:
- C++ basics: input/output, loops, conditionals, arrays, strings, STL containers (vector, map, set)
- Simple implementation problems (translate problem statement into code)
- Basic math: modular arithmetic, GCD, checking primes
Topics to cover from the guide: Topic 1 (Implementation)
Goal: Solve Codeforces 800-rated problems comfortably. You should be able to read a problem, understand what it asks, and write clean code that passes all test cases without much struggle.
Contests to try:
- Codeforces Div 4 contests
- AtCoder Beginner Contest (problems A and B)
Tips for this phase:
- Do not rush. A strong foundation makes everything later much easier.
- Focus on writing clean, readable code. Develop good habits early -- use meaningful variable names and add comments when logic gets tricky.
- Learn to use the STL well. Knowing how to use
sort(),vector,map, andsetwill save you enormous amounts of time. - Practice reading problems carefully. Many wrong answers at this level come from misunderstanding the problem, not from wrong logic.
- Solve at least 50-80 problems at the 800 level before moving on. This sounds like a lot, but these problems are short and build your confidence.
What to learn:
- Sorting algorithms and when to use them
- Linear and binary search
- Two pointers and sliding window techniques
- Greedy algorithms
- Basic number theory: sieve of Eratosthenes, prime factorization, modular exponentiation
Topics to cover from the guide: Topics 2, 3, 4
Goal: Solve Codeforces 1000-1200 rated problems consistently. Reach Pupil rating (1200+) on Codeforces.
Contests to try:
- Codeforces Div 3 contests
- AtCoder Beginner Contest (problems A through C)
Tips for this phase:
- Binary search is one of the most important techniques in competitive programming. Make sure you truly understand it -- not just searching in a sorted array, but binary search on the answer.
- When you see a greedy problem, always ask yourself: "Can I prove this greedy choice is correct?" Greedy solutions are easy to code but hard to verify.
- Start timing yourself. Try to solve problems within a reasonable time limit (30-45 minutes for a 1000-rated problem).
- Begin participating in live contests regularly, even if you only solve 1-2 problems. The experience of thinking under pressure is valuable.
- After each contest, always upsolve at least one problem you could not solve during the contest.
What to learn:
- Dynamic programming: knapsack, LIS, LCS, grid DP, bitmask DP
- Graph algorithms basics: BFS, DFS, shortest paths (Dijkstra, Bellman-Ford), topological sort
- Union-Find (Disjoint Set Union)
- Basic combinatorics
Topics to cover from the guide: Topics 5, 6
Goal: Solve Codeforces 1200-1400 rated problems. Reach Specialist rating (1400+) on Codeforces.
Contests to try:
- Codeforces Div 2 contests
- AtCoder Beginner Contest (problems A through D)
Tips for this phase:
- Dynamic programming is where most people get stuck. Do not be discouraged. Start with the classic problems (fibonacci, coin change, knapsack) and build up gradually.
- For DP, always clearly define your state before writing code. Ask: "What information do I need to make a decision at each step?" The state definition is 80% of the work.
- For graph problems, draw the graph on paper. Visualizing the structure makes the solution much clearer.
- Learn to recognize problem patterns. Many problems at this level are variations of classic problems with a twist.
- This is the hardest phase mentally. The jump from greedy/implementation to DP/graphs is significant. Be patient with yourself.
What to learn:
- Tree algorithms: LCA, tree DP, Euler tour, heavy-light decomposition
- Range queries: segment trees, BIT/Fenwick trees, sparse tables
- String algorithms: hashing, KMP, Z-algorithm, trie
- Advanced topics: flows, geometry basics, advanced DP optimizations
Topics to cover from the guide: Topics 7, 8, 9, 10
Goal: Solve Codeforces 1400-1600+ rated problems. Reach Expert rating (1600+) on Codeforces.
Contests to try:
- Codeforces Div 2 (problems A through E)
- Codeforces Div 1 contests
- AtCoder Regular Contest
Tips for this phase:
- Segment trees are extremely versatile. Learn the basic version thoroughly, then learn lazy propagation. This single data structure appears in a huge number of problems.
- For string problems, string hashing is often the simplest approach. Learn polynomial hashing well before moving to more complex algorithms like suffix arrays.
- At this level, implementation becomes a bottleneck. Practice writing longer, bug-free code. A 100-line solution with a subtle bug will cost you more time than writing it carefully the first time.
- Start reading other people's solutions after solving a problem. You will often find cleaner or faster approaches that teach you new tricks.
- Do not try to learn every advanced topic at once. Master one area, then move to the next.
- Beginners (Phase 1-2): Aim for 2-3 problems per day. These will be shorter problems, so this is very doable in 1-2 hours.
- Intermediate (Phase 3): Aim for 1-2 problems per day. DP and graph problems take longer to think through, and that is fine.
- Advanced (Phase 4): Even 1 problem per day is great. Quality matters far more than quantity at this stage. One hard problem you truly understand is worth more than five easy problems you breeze through.
The key metric is not problems solved -- it is problems where you learned something new. If you solve 5 problems and learn nothing, that session was less valuable than solving 1 hard problem where you discovered a new technique.
Follow the 30-minute rule as a starting point:
- Spend at least 30 minutes thinking about a problem before looking at hints.
- If stuck after 30 minutes, read just the first hint or the general approach (not the full solution).
- Try again for 15-20 minutes with that hint.
- If still stuck, read the full editorial, but then close it and implement the solution yourself from memory. Do not copy code.
As you get more experienced, extend your thinking time. For Phase 3-4 problems, try for 45-60 minutes before seeking help. The struggle is where the learning happens -- but struggling for 3 hours with zero progress is not productive either. Find your balance.
Upsolving means solving problems after a contest that you could not solve during the contest. This is where the biggest improvement happens, and here is why:
- During a contest, you already spent time thinking about the problem. Your brain has started working on it. The editorial will make much more sense because you have context.
- It fills in the exact gaps in your knowledge. You could not solve it, so learning the solution teaches you something you were missing.
- It builds a habit of not giving up. Many people skip upsolving because the contest is over. The ones who upsolve are the ones who improve fastest.
Rule of thumb: After every contest, upsolve at least one problem you could not solve. Ideally, upsolve all problems that were within 1-2 levels above your comfort zone.
This is one of the most underused but effective techniques. After each contest or practice session, write down:
- The problem: Name/link and brief description.
- What went wrong: Did you misread the problem? Use the wrong algorithm? Have an off-by-one error? TLE because of wrong complexity?
- The lesson: What should you do differently next time?
- The pattern: After a few weeks, review your diary. You will notice recurring mistakes. Maybe you always forget to handle the edge case where n=1, or you consistently misjudge time complexity.
A simple text file or spreadsheet works fine. The format does not matter -- the habit does. Review it before contests to remind yourself of your common pitfalls.
Performing well in a contest is a different skill from solving problems in practice. Here is how to approach live contests:
- Make sure your template is ready (fast I/O, common macros, standard headers).
- Have a glass of water nearby. Sounds trivial, but 2-hour contests require focus.
- Clear distractions. Close social media tabs. Put your phone away.
1. Read all problems first (2-3 minutes) Quickly skim all problems. Read the problem names, point values, and the first line of each statement. This gives you a mental map of the contest.
2. Start with the easiest problem Almost always problem A. Solve it carefully. Do not rush -- a wrong submission on A because you misread the problem is demoralizing and wastes time.
3. Move sequentially, but know when to skip Work through problems in order of difficulty. If you have been stuck on a problem for 20+ minutes with no clear progress, skip it and try the next one. You can always come back.
4. Test before submitting Run through the sample test cases by hand or with your code. Check edge cases: n=1, all elements the same, maximum constraints. A wrong answer penalty is usually more costly than the 2 minutes spent checking.
5. Manage your time
- Check the clock regularly.
- If 60% of the time is gone and you have solved the easy problems, switch to reading the harder problems more carefully rather than optimizing solutions you have already submitted.
- In the last 15 minutes, focus on getting partial solutions or heuristic solutions submitted if the contest format allows it.
6. Do not panic after a wrong answer Read the problem statement again. Check your edge cases. Print your variables to debug. A calm reread catches most mistakes.
- Read the editorial for every problem, not just the ones you attempted.
- Upsolve (see above).
- Write in your mistake diary.
- Do not obsess over rating changes. Ratings fluctuate. Focus on what you learned.
- Overthinking easy problems. If a problem is worth few points and rated easy, the solution is probably simple. Do not look for hidden complexity.
- Not reading constraints. The constraints tell you what time complexity is expected. If n is up to 10^5, an O(n^2) solution will not pass. If n is up to 20, you might need bitmask DP or brute force.
- Submitting without testing. The 5 seconds you save by not testing will cost you a 10-minute penalty on a wrong answer.
- Giving up too early. Sometimes you are one small observation away from the solution. If you have an approach that feels close, keep pushing for a few more minutes before abandoning it.
Competitive programming is a marathon, not a sprint. Some people reach Expert in 6 months, others take 2 years. Both paths are completely valid. The only thing that matters is that you keep practicing and keep learning.
The roadmap above is a guide, not a strict schedule. If you need more time on DP, take more time on DP. If you find graphs easy, move through them faster. Listen to your own learning pace.
Most importantly -- enjoy the process. The feeling of solving a hard problem after struggling with it for an hour is one of the best feelings in programming. Chase that feeling, and the ratings will follow.