MY CP + CM + ICPC JOURNEY

Aditya Raj -

aka how i started by randomly giving contests for fun and ended up grinding my way into regionals and candidate master :)

1. The Accidental Beginning

I didn’t plan any of this. zero strategy, zero destiny vibes. I never had some master plan of becoming a CP person. It just… happened.
back in end of 1st sem, my roommate used to leave the room every friday evening for pb hustle (if you know, you know). I’d watch him prep, come back with that smug "i did cp" energy and think, why not? so one friday I opened an account for fun and gave a contest. That was it, pure curiosity, pure fomo, purely random, zero seriousness.
at that time, i barely knew coding. literally only basic C language from my 1st sem. My first few contests were also in C, soon i switched to C++ because honestly it’s 10x easier for CP with STL and all that jazz.

and somehow, in just a few months:

  • i hit specialist in 2 months
  • reached expert in 4.5 months
  • then… drumroll.. got stuck badly like the infamous hard stuck expert era, patience tested. Eventually, after a lot of boring nights and ugly WA verdict, i finally hit CM, felt sweet :p

2. CM journey (the purple badge struggle)

Being stuck in expert for 1.5 years sucked so here’s what changed things:

  1. upsolving (the problems you couldn’t solve teach you the most)
  2. editorials aren’t cheating(reading them is like speedrunning knowledge)
  3. consistency matters more than crazy grind (1 - 2 problems daily > 12 problems one day and ghosting cp for 2 weeks)

3. WHY PRACTICE IS NECESSARY BUT NOT ENOUGH

Based on my experience, i think the only way to improve is to practice. "practice makes perfect" is famous, and true-ish, only a few coders improve without enough practice
However and this is key, practice is necessary, not sufficient.

I’ve seen people solve thousands of problems and still feel stuck
The missing ingredient is scientific training. Here’s what that means practically (this is pulled directly from how i did it and from advice i follow):

  1. try problems 200 - 400 rating above your current rating
  2. give each such problem 60 minutes of focused attempt
    • if you can’t solve within 60, read the solution and think through it
    • 60 is flexible, i chose it because in contests, once something is unsolved in ~40 minutes it usually becomes impractical to continue, so i add buffer
  3. too easy problems give no growth; too hard problems just cause anxiety
  4. 200 - 400 is the sweet spot, pushes you, doesn’t break you

4. ALGORITHMS = MINDSET (NOT JUST TOOLS)

I think some "algorithms", like:

  • prefix sums
  • binary search
  • dfs / bfs
  • dp (basic knapsack and dp on tree)
  • greedy

are actually mindsets. They are used repeatedly because they are fundamental. In a contest, you rarely invent something brand new, you recognize which standard mindset fits the problem, reduce it, and implement the pieces you already know.

So don’t just memorize code. learn to see problems as these patterns
That recognition step is 50% of the battle

5. CONTEST MINDSET - WHAT TO FOCUS ON

Whenever giving a contest, don’t care about rating drops. Your aim should be to solve as many problems as possible. That helped me improve my performance.

  • speed matters and fewer errors matter more
  • I’m an average typer, not blazing fast, but i still solve more problems, focus on solving more
  • upsolve at least 1 problem you couldn’t solve during the contest (mandatory)
  • find weak areas and start solving those problems slowly and steadily
  • discuss with friends, talking makes things stick
  • most important: don’t give up. many start CP excited and leave after 1 - 2 months because they see no progress. This is normal, keep grinding :)

also accept luck, sometimes the correct solution hits you in 5 min. sometimes not. Both are fine

6. DETAILED PROBLEM SOLVING CHECKLIST (USE THIS EVERY ROUND)

When reading the problem statement

  • why is this limitation here? how would the problem change if it’s not here?
  • what is unusual?
  • what exactly is the problem asking?
  • can i reformulate it as a standard problem? a play on a standard problem? a special case of something hard?

While solving the problem

  • how would i solve an easier version? (reduce constraints)
  • change the underlying object to something simpler:
    • graph → connected graph → cactus → unicycle → tree → bamboo/array or star
    • matrix/grid → array
  • is there an observation that generalizes?
  • how to answer one query? how to solve a small case on paper? how to do it with no constraints?

Before implementing

  • what’s the complexity? is it acceptable?
  • do i understand the problem correctly?
  • what helper functions do i need?
  • which places are tricky and require care?
  • which part is heaviest to implement, can I simplify?
  • which place is slowest, where do constants matter? where can i choose simpler implementation?

If not AC

  • did you handle the tricky parts you thought about?
  • is the solution idea wrong or the code buggy?

If you have a failing test

  • is the solution doing what it was supposed to?
  • is the bug in code or idea?

If stress test can’t find counter test

  • do you really understand the problem?
  • is your "stupid" solution actually dumb, or do you assume something?
  • are you generating all test variants? multitest?

After getting accepted

  • what could i have done better?
  • which parts took too long?
  • are there tricks to simplify for next time?

7. PRACTICAL TRICKS & TRAPS (KEEP THIS ON YOUR DESK)

  • Any even number > 2 can be split into two primes (useful sometimes)
  • Sum - Xor property:
a + b = a ⊕ b + 2 * (a & b)
  • Extended identities:
a + b = a | b + a & b
a ⊕ b = a | b − a & b
  • Sometimes brute force / linear search is better because constants and simplicity win
  • For start/end events: give negative to start, positive to end, sort pairs, and sweep
  • unordered_map can cause WA or TLE due to hacks, use a custom hash when risk is high
  • Do not write a segment tree if you can’t calculate one query for n < 1000, know the small case first
  • not many people know this, but if you want to create a std::set from a vector
    and realize that set doesn’t directly have a vector constructor,
    you might end up writing something like this with a straight face :
set<int> S;
for (int x : a) {
    S.insert(x);
}

but actually std::set has a constructor that takes two iterators.
so you can simply write:

set<int> S(all(a)); // where all(a) = a.begin(), a.end()
  • sometimes you just wanna peek at the last few bits of a number, you don’t need to manually mask & shift stuff. C++ already got you covered:
cout << bitset<20>(n) << "\n";
  • sometimes you might be tempted to chain min like:
int x = min(min(min(a, b), c), d);

umm, it works but it’s ugly af
the cooler way? just throw everything into a brace init list:

int x = min({a, b, c, d});

Pattern recognition > Memorizing implementations
Focus on recognizing binary searchy problems or prefix sums problems, not just doing topic by topic solving

too many tricks to fit in one section.. and honestly who even scrolls till the end, just go solve problems and you’ll discover them the hard way

Platforms i actually used / recommend (other than CF):

  • CSES - solid core problems (avoid advanced/additional/geometry when starting)
  • USACO Silver & Gold - teaches structured problem solving
  • AtCoder DP - dp patterns that are pure gold
  • CodeChef - math heavy problems, good number theory problems

Video creators i watched:

  • Love Babbar - basics array, strings, recursion
  • Striver - Dp, Trees, standard patterns explained nicely
  • Kartik Arora - his Dp explanations clicked well for me
  • TLE Eliminator - graph intuition videos (absolute Op when you’re stuck)

Consistency > Intensity
Don’t burn out

9. ICPC CHENNAI - THE STORY (PRACTICE ROUND CHAOS -> REAL CONTEST)

Man, ICPC onsite was something else...
It was a great experience, travelling to Chennai with my team to attend the regionals at IIIT Kanchipuram.
There was a practice round before the actual contest, It was 2 hrs and we couldn’t solve a single problem lol, cuz we three are trying 3 different problems. By seeing our performance in practice round we were little nervous for the actual contest which was 5 hr long, but we managed to solve 5 problem out of 11 problem, if only we didn't make that silly mistake in sparsh table code, we would have solve 6th one also, but still it was a nice experience, we got 59 rank out of 130 team.

The real fascination was the environment there, surrounded by the best competitive programmers from across the country, from various top institutions like IIT, NIT, IIITs etc., The vibe was insane. I realized I’m still average in this ocean but it felt motivating instead of intimidating.

And you know what’s funny? Being an Expert on Codeforces felt kinda average in that room. Like normally, people hype it up but there? Bro, it was just mid. Everyone was either Expert or above, so you had to level up to vibe with the crowd.

10. FINAL LAZY THOUGHTS

If i have to sum everything up in a lazy tweet: grind smart, chill harder, and stick to it.

i started because my roommate left for pb hustle and i was curious, now i have Candidate Master, an ICPC regional run, lots of ugly WA stories, and some decent memories.

If you’re starting, don’t overthink
Just open your laptop, pick a problem, and start
Progress will be slow, sometimes invisible, but trust me breakthroughs come when you least expect them.

All these things I wrote are from my POV. I’m still figuring stuff out. I’m not some guru giving gyaan. I’m nowhere close to the legends out there, just doing my lil thing, just sharing what worked and what failed for me :p

Enjoy the grind
Enjoy the code
Keep going

Peace ✌️