I remember the exact moment I solved my first problem on Codeforces. It was a simple A-level problem — check if a number is even or odd, essentially. I submitted it, saw the green Accepted, and felt like I'd just cracked a bank vault.
500 problems later, that feeling hasn't gone away. It's just harder to earn.
This post isn't a tutorial. It's an honest reflection on what the journey from 0 → 500 actually looked like — the patterns I noticed, the walls I kept hitting, and what eventually broke through them.
The First 100: Enthusiasm Over Everything
The first hundred problems were pure momentum. I was solving easy A and B level problems, mostly brute force, occasionally stumbling into greedy. Every acceptance felt like a win.
What I got wrong here: I was chasing count, not depth. I'd solve a problem, see Accepted, and immediately move on. I never asked why it worked. I never tried to find a cleaner solution. I never read the editorial after solving.
That came back to bite me around problem 150, when I started hitting problems that required actual thinking — and I had no toolkit to reach for.
Lesson: Solve fewer problems, understand them more deeply. An Accepted verdict is the beginning of learning, not the end.
The 100–200 Wall: When Brute Force Stops Working
This was the hardest stretch. Problems started requiring real algorithms — binary search, prefix sums, basic graph traversal. And I had no idea how to recognize which technique applied to which problem.
I'd read a problem, stare at it for an hour, and give up. Or worse — I'd code a brute force solution that passed small test cases but TLE'd on the large ones, and I had no idea why.
The thing that helped most wasn't grinding more problems. It was slowing down and topic-grinding instead. I spent a full week on just binary search — reading the theory, solving 15 tagged problems, and really internalizing the pattern. Then a week on graphs. Then sorting and greedy.
After that, when I saw a new problem, I had something to ask: "Does this smell like a graph problem? Could binary search work here?"
Lesson: Learn techniques deliberately before trying to apply them under pressure.
200–250: Learning to Think, Not Just Code
Somewhere around problem 250, something shifted. I started actually reading problems more carefully before opening my IDE. I started sketching small examples on paper. I started thinking about edge cases before submitting.
My acceptance rate improved. My solve time dropped. Problems that used to take 2 hours started taking 45 minutes.
I also started doing something that changed everything: reading editorials even after I solved a problem. Not just when I was stuck — always. It was humbling. My O(n²) solution that barely passed? There was an O(n log n) approach that was elegant and obvious in hindsight. I started collecting these patterns like trading cards.
I also started participating in actual rated contests around this time. Contests are brutal. There's a timer. There's pressure. You can't look things up. And honestly — contests taught me more per hour than any amount of casual practice. The pressure forces you to think clearly, not just mechanically.
Lesson: Editorials are free mentorship. Use them even when you don't need them.
250–300: The Problems That Beat Me First
By the time I was approaching 500, I'd been humbled enough to genuinely enjoy hard problems — even when they destroyed me. A problem I couldn't solve in 3 hours still taught me something. I started writing down every new idea or technique I encountered, keeping a personal "patterns notebook."
The 500th problem specifically was a DP problem involving interval states. I spent two days on it. I drew out the state transitions on paper four or five times before they clicked. When I finally submitted and saw Accepted, I didn't feel triumphant — I felt tired and grateful. Which is, I think, what real learning feels like.
What Actually Matters After 300 Problems
Looking back, here's what I actually learned — not about algorithms, but about learning itself:
Consistency beats intensity. Solving 2 problems a day for a year beats cramming 20 problems in a weekend and burning out. My Codeforces streak was never perfect, but it was consistent enough.
Struggle is the curriculum. The problems I gave up on after 20 minutes taught me nothing. The ones I sat with for 2 hours, even without solving them, rewired how I think.
Community accelerates growth. Reading other people's solutions — especially ones that were shorter and smarter than mine — was one of the highest-leverage things I did. Codeforces has a culture of clean, clever code. I learned to want that too.
Rating is a lagging indicator. There were stretches where I solved a lot but my rating barely moved. It felt discouraging. But the skills were compounding quietly — and they showed up eventually in contests.
What's Next
300 is a milestone, but it's not a destination. I'm still a mid-level solver on a good day. There are people on Codeforces who've solved 3,000+ problems and can see the solution to things I'd struggle with for days.
But that's what I love about competitive programming. There's always more to understand. The ceiling keeps moving.
If you're somewhere in your first 100 problems and it feels slow — it's supposed to feel slow. You're building a mental model that will pay off later. Keep going.
Thanks for reading. If you want to follow along with my CP journey, my Codeforces handle is animesh_sarker.
Top comments (0)