Please read the new rule regarding the restriction on the use of AI tools. ×

KimberlyBruh's blog

By KimberlyBruh, history, 5 hours ago, In English

Hey, Codeforces community!

After years of competitive programming, including participation in international junior olympiads, I recently crossed the 1400 rating mark on Codeforces. For someone who’s been in the game for six years, this might sound like a modest achievement, but this milestone reflects the unique challenges that I’ve faced along the way. In this post, I’d like to share some thoughts, a few hard-earned lessons, and advice for those who, like me, have significant experience but find themselves struggling to break through certain plateaus.


The Struggle: Stagnation Despite Experience

With a background in competitive programming that goes back several years, and having worked on problems for an average of three hours a day, I used to wonder why my rating wasn't higher. It’s easy to assume that years of experience should naturally translate to rapid progression, but in reality, this experience can sometimes work against you. Here are a few insights I’ve gathered:

  • Over-reliance on Old Methods: After competing in various contests and solving hundreds of problems, I noticed that I had a tendency to rely on familiar approaches, even when they weren’t optimal. While it's tempting to fall back on what you know works, competitive programming often requires thinking outside the box and exploring new techniques.

  • Plateauing at the Intermediate Level: Breaking into 1400 isn’t about solving more problems, but rather solving the right problems. For a while, I was stuck solving problems at or below my comfort zone (~1200-1300 level). This gave me a false sense of progress but wasn’t pushing me toward improvement.


The Path to Progress: Structured Learning and Problem Selection

To push past this plateau, I had to re-evaluate how I approached my training. Here are a few adjustments I made that significantly helped me improve:

1. Diverse Problem Solving

  • Challenge yourself with higher-rated problems: I started dedicating more time to solving problems in the 1400-1600 range, even if it meant taking longer to understand them. These problems forced me to step out of my comfort zone and encounter new patterns.
  • Mix problem types: It’s easy to get stuck in a groove with certain problem types (e.g., greedy, graphs). I made a conscious effort to diversify the types of problems I tackled—such as geometry, combinatorics, and non-classical DP problems. This variety sharpened my problem-solving skills across the board.

2. In-depth Focus on Weak Areas

  • Algorithmic precision: Despite years of experience, I found myself overlooking certain classic algorithms or applying them inefficiently. I revisited some core algorithms with the goal of improving my understanding of the nuances. For example, exploring advanced uses of segment trees or nuanced graph algorithms like Dijkstra’s with priority queues made a big difference.
  • Mastering non-intuitive concepts: Some concepts, like dynamic programming (DP) optimizations or advanced combinatorial problems, always seemed daunting. But investing time in mastering these “gaps” was essential to unlocking higher-level problem-solving techniques.

3. Effective Contest Strategy

  • Time Management: Contest strategy became crucial. Early on, I focused too much on solving problems quickly rather than accurately. Now, I focus on getting the first two problems right before moving on. For tougher problems, I prioritize breaking them down logically and make sure I’m not bogged down by low-value attempts.
  • Strategic skipping: Another key improvement was the ability to strategically skip problems when I hit a wall. I used to lose time stubbornly sticking with unsolved problems. Now, if I’m not making headway within a reasonable time, I move on and revisit later.

What Really Mattered: Reflection and Efficient Training

With experience comes the danger of complacency. For a long time, I was solving problems just to solve them, without reflecting on my performance or pushing myself beyond my usual tactics. To push past 1400, here’s what made the real difference:

1. Analyzing My Weaknesses

  • After each contest or practice session, I carefully reviewed the problems I struggled with. Instead of just reading editorials, I spent time recreating the solutions from scratch to deeply understand the thought process.
  • I also started comparing my performance with top solvers to see where I was falling short. This gave me insight into how quickly I needed to solve early problems and how efficiently others managed the harder ones.

2. Implementing Timed Practice

  • One thing I incorporated into my routine was timed problem-solving. I found that recreating contest conditions in my practice sessions helped me adjust to the pressure and speed needed for real contests. For instance, I’d give myself 90 minutes to work through a set of problems instead of spending an indefinite amount of time on each one.

3. Reframing Success

  • I learned to stop fixating on rating jumps after each contest. Instead, I started focusing on my long-term improvement. Some contests would boost my rating, others would knock it back down, but what mattered most was my overall trend of improvement over months.

Advice for Fellow Experienced Coders

If you’ve been in competitive programming for a while and feel like you should be performing better, here’s my advice:

  • Avoid auto-piloting through practice: Just solving problems isn’t enough. You need to engage critically with each one, understanding the problem fully and reviewing alternative approaches.

  • Break old habits: After several years, it's easy to fall into patterns that limit your growth. If you’ve been working a certain way without results, shake things up. Try a new training method, explore new problem types, or study an unfamiliar algorithm.

  • Learn from the community: Even after all this time, I learned so much by diving into the solutions of top coders on Codeforces. Analyzing their code gave me insight into better techniques and more efficient implementations.


Final Thoughts

Reaching 1400 wasn’t an overnight success, and it shouldn’t be for anyone. It’s about consistent, mindful effort—leveraging your experience while also being willing to adapt and improve. My next goal is to push toward 1600 and beyond, but I’m approaching it with patience and a focus on continuous learning.

If you’ve been at this for a while and are feeling stuck, don’t be discouraged. The grind is part of the process, and with the right mindset and strategy, you’ll break through those plateaus.

Good luck to everyone in their journey. Keep improving!


TL;DR:
- Years of experience doesn’t automatically translate to higher ratings—don’t rely too much on old methods. - Focus on diverse, higher-rated problems to challenge yourself. - Implement contest-like timed practice sessions. - Reflect on each contest and pinpoint your weaknesses to continue improving.

Happy coding!

  • Vote: I like it
  • +20
  • Vote: I do not like it

»
5 hours ago, # |
  Vote: I like it 0 Vote: I do not like it

Auto comment: topic has been updated by KimberlyBruh (previous revision, new revision, compare).

»
4 hours ago, # |
  Vote: I like it +1 Vote: I do not like it

hey can I get your discord? I sometimes struggle to understand something and I need help ... you might assist me

  • »
    »
    3 hours ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    I will DM you while there are no running contests. (This account has less than 10 contests so I can't send you <>). Happy coding as always!

»
4 hours ago, # |
Rev. 3   Vote: I like it 0 Vote: I do not like it

can someone please share some tips to become expert? i have practices aprroximately 1200 problems and 50 1700 rated problems. but during contest i always do the problems very late .

»
3 hours ago, # |
  Vote: I like it 0 Vote: I do not like it

12 tags yet you forgot to add the “AI generated” one

  • »
    »
    109 minutes ago, # ^ |
      Vote: I like it +1 Vote: I do not like it

    Instagram comment section

  • »
    »
    103 minutes ago, # ^ |
      Vote: I like it +1 Vote: I do not like it

    this doesn’t read like gpt

    • »
      »
      »
      88 minutes ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      The text's fancy way of saying nothing made me suspicious so i passed the text through GPTZero and QuillBot and the AI coincidence was 85% and 89% respectively

      • »
        »
        »
        »
        85 minutes ago, # ^ |
          Vote: I like it 0 Vote: I do not like it

        AI detectors are not reliable. They give way too many false positives

      • »
        »
        »
        »
        51 minute(s) ago, # ^ |
          Vote: I like it +2 Vote: I do not like it

        In my opinion the blog says everything. On the points that are bolded:

        • Over-reliance on Old Method. Read the blog about "not forcing solution onto a problem". Most people in div2 that I talk to are victims of trying to force something onto a problem then not being able to answer me when I ask then "but why are you trying to solve the problem like that?"

        • Plateauing at the Intermediate Level. This doesn't say much other than pointing out that if you solve only the problem that you're suposed to solved you won't get better, which is true. One of my mottos is "contest is when you solve the problem you can solve and practice is when you solve the problems you couldn't solve".

        • Challenge yourself with higher-rated problems. I agree almost completely, the only part that I disagree is that you can shoot even higher, like aiming for 2000+ problems while being cyan. If you're able to understand the solution you'll benefit a lot from it.

        • Mix problem types. I'd suggest that instead of picking different problem types, you solve problem without knowing its type at all. I see solving similar problems as a possible cause for forcing solutions onto problems.

        • Algorithmic precision. Ties back into "forcing solutions onto problems". Ideally you first understand what you need to do to solve the problem and then think of which algorithm/data structure you'll use. What I see the most in div2 is the exact opposite: read the problem and try to guess a solution without knowing what you have to do to solve it. Deeper understanding of algorithms and the situations that they can be useful is very helpful in these cases.

        • Mastering non-intuitive concepts. Same as the previous point but the effect is even worse. In most cases it's better to know nothing at all instead of trying to use something that you don't understand.

        • Time Management, Strategic skipping. Strategy and time pressure are real things. Strategic skipping during contests is about accepting that difficulty is relative and taking a break to reset your mindset can be helpful. During practice, strategic skipping is about not using "not being able to solve a problem" as an excuse to do sit doing nothing.

        The other points are all good points as well. The point that I stress the most is reflection, but that requires you to face your bad points which is more than many people are willing to do. I'll give you an example: my reflection for last div1. I took too much time to AC D because I misunderstood the problem so I must be more careful when reading in the future. Also I didn't look at samples until I finished coding, when I looked at sample explanations then it was clear that I misunderstood the problem, so I should read sample explanations in the future when they're available. I already upsolved E2, there was nothing much to do during the contest since the solution was the same but faster (I still think going for F instead of E2 during the contest was a good idea) but from upsolving the problem now I have a good vEB implementation and there's the DSU solution to learn from still. For F, it depended on having a certain understanding of B and my B solution didn't translate well into a good solution for F. That highlights that sometimes it's important to take a step back and approach the problem from scratch even after having some (slow) solution to it, because not every solution to the simplified problem is helpful when you try a harder version.