In the world of programming, especially competitive coding or technical interviews, there's always one big question: Should I solve hundreds of problems, or focus on fewer but more insightful ones?
Quantity Teaches Patterns Solving a lot of problems exposes you to a variety of problem types, tricks, and edge cases. It builds intuition over time. You start recognizing patterns faster, and brute force becomes your debugging tool rather than your go-to strategy.
But here's the catch: if you’re solving 50 easy problems the same way without understanding why the solution works or fails, you’re just spinning your wheels.
Quality Builds Depth On the other hand, solving fewer but quality problems forces you to go deep. These are the problems that make you think, get stuck, revisit your approach, and finally understand the core concept behind them. One well-understood dynamic programming or graph problem can teach you more than 20 surface-level ones.
This is the type of learning that sticks and scales — the kind that makes the difference in a real interview or a timed contest.
The Ideal Strategy? Start with quantity, especially when you're a beginner. Get your hands dirty, get used to problem statements, and build your stamina. But once you're comfortable with the basics:
Switch to quality. Choose problems that challenge you, break your mental model, and leave you with “Aha!” moments.
And always reflect after solving:
Could you optimize it?
Did you find multiple approaches?
What did you learn that can be reused?
The oversimplified models always missed lots of nuances and pretend that you have a complete model, a few things that you didn’t model:
Speed: If you learn the same amount of things in a 800 and in a 1700, you can do the first one upto 20 times faster, then it is a strong argument for doing the 800. If you can learn at least 1/20 of things, you should do the 800. Trust me, no one can perfectly solve a 800, I also can’t (the ideal goal is 30 seconds per solve at 100wpm).
Energy: it simply takes lots of energy to do high difficulty problem. It doesn’t drain much to do low or mid problem. If you want to train for a whole day for many days, there is a natural cap of the amount of hard problems.
Development: you cannot get all skills from problem solving efficiently. You need to set aside time for learning DS etc. If you do this effectively, you rely less on solving difficult problems. At early levels, most of the ways you get stuck is not knowing some idea. At late levels, most of the way is you cannot think fast and exhaustive and consistent enough — this last thing is solvable with mid level problems, not necessarily hard ones.
It comes down to a very complicated calculations that is constantly adjusting of which one is more useful in the current situation.
Fun fact, I think I get saturated from improvement from either type of problem solving and now I need some substantially new ideas.
Thanks a lot for taking the time to share these insights — I really appreciate your experience and perspective.
What you said about energy, speed, and development really makes sense. I now understand why grinding only high-difficulty problems isn’t always optimal and why building consistency with mid-level problems has long-term benefits.
That said, if you don’t mind, could you suggest a bit more concretely what I should focus on next to reach Candidate Master? For example, how should I balance problem difficulty, topics, and contests? Any patterns or habits that helped you cross that gap?
I don’t think I can say much because it is really upto personal understandings of what benefit you the most. However, I think it is very useful to not miss options.
Easy problems: 800-1300 in your case, med:1400-1700 and hard:1800-2000 all serve some roles. speed and difficulty are rewarded almost equally in CF. Speed gives you time to solve the next problem and can compensate for idea. So you have to probably decide which one you can improve more effectively first.
DS: learn them if you haven’t (you should only need upto lazy segment tree for next few hundred ratings), it is relatively quick compared to solving problems.
Contest: contest serves as a sanity check/ validation test for me, I know that I won’t learn as much as other options but it is a great way to have fun and check your skills didn’t deteriorate noticeably (especially after a period of rest)
Thanks.
I also agree. Contrary to popular (is it? maybe just in my community) beliefs, I think CF is a pretty solid metric, not in comparing people with people, but in comparing yourself with yourself from the past. For example: me. My rating didn't improve for the entire year despite me grinding like crazy, so I knew something went wrong and fixed it. Any thought that is not "I plateau-ed, I need to fix my training" is just pure cope and mental m*sturbation.
how was your progress sooooooo high at the beginning? currently yes you've solved 6k problems no wonder ur at the top,but back when you started how were you so good? or did u actually start out in a a different platform?
what do you think a normal graph for no. of pbs solved vs rating is?
is it even corelated?
also do you have anything more to say about burnout(not just short term,long term too)? really wanna know your views..
I started high mainly because I studied theory so much, have prior coding experience for games, and have decent math Olympiad successes. This was enough for 2000 rating out of the gate, but it was some climb to stabilize at orange, then at red etc. I didn’t start at another platform, codeforces is the first.
Many of my solves are actually low difficulty, there are decent mid or high level but they probably make up only 1000. The entire >3200 section is almost untouched.
I think generally, if you are really capable of learning fast+ lucky, you can get one rating equivalent per problem solved. If you are not focusing , I feel the efficiency can be 1/10 or so. Generally I think the rule to break is amount of time spent per rating. I am thinking for most people, 6 hours per rating is enough, but it could get as great as 1-2 hours at some point. the 6 hours estimate gives 5-20 problems of similar difficulty, or 50 problems in speed per rating point.
Given my solve counts, it looks like 1 problem per rating though (excluding easy speed problems).
it is somewhat correlated, if you don’t go out of your way to improve quickly, it will fall to a general estimate, but you can beat this rate substantially if you discover what works for you.
For burnout, yes, there are plenty of times that I feel like I am not improving, or some strategies did not pay off. There are a few things to do: try new things (such as me investing a bit into solving problems fast), work on other stuff and come back (I also have to deal with academics and jobs related stuff)
Scroll down here to see the rating vs problems solved chart.
This is how we should think when we are receiving advices.
A lot of people says "To achieve $$$X$$$ just do $$$A, B, C$$$", but in reality it's much more than $$$A, B, C$$$.
It's also dependent on an exact time / situation.
Moderately hard problems work best for me. I'm not a big fan of solving a lot of
800problems (unless you are a beginner and need to get used to coding), nor a big fan of solving problems way out of my skill range (solving3000s while I am a solid GM at best), since it takes way too much energy.Ad-hoc problems are something to keep in mind too. I find acquiring coding skills quite easy, but the same cannot be said with thinking skill, so lately I only do problems with minimal implementation. Yeah, my coding skill got slightly worse, but I can do twice, or thrice as much problems in the same time frame, which is cool.
Start by solving a lot of problems. You will know it's time to move on to harder ones when the problems start to feel easy. You might spend a lot of time solving a problem, but in a contest, you don't have much time. So you can always find some problems to practice with and improve your speed