Hey Codeforces community,
I’ve been practicing a lot for contests and solving old problems too. I want to share something I noticed: sometimes I make problems harder than they are. Last week, I tried a Div 2B problem—it was about finding a pattern. I spent 30 minutes thinking of a big, complicated solution with DP and other tough ideas. But in the end, it was just a simple sorting trick that took one pass. I lost points because of that!
Now I’m wondering—how do you know when to stop making a problem too hard and look for an easier way? I think the key to getting better at coding is learning when a problem is tricking me into thinking it’s harder than it is. I’m trying to stop after 5 minutes and ask myself: “Is this really a hard problem, or am I just overthinking it?”
What do you think? How do you avoid making problems too complicated? Or do you have funny stories where you realized the answer was easy?
Happy coding, and I hope all your solutions turn green!
Auto comment: topic has been updated by tonmoy197 (previous revision, new revision, compare).
I think this comes from thinking of a solution without having understood the problem in its entirety. The more you think about the problem the simpler it gets but eventually you will start doing observations really quickly.
I try to prove things to myself (but it's actually just to convince myself that something is true, I don't go too deep into proving it) and imagine / guess some things about the problems and seeing if they are true, eventually the truth is revealed to you in this process of finding out what's true and what's not
Also this happens to everyone at a certain extent hahahahahah, it happens to me for some Div2Cs.
Haha, I totally agree—this happens to me too! Starting with a solution before understanding the problem can make it harder, but thinking it through makes it simpler over time. I love your idea of testing guesses to find the truth—great for those tricky Div 2Cs. It happens to us all! Any quick tips for spotting the right path faster?
With experience you'll understand whether a solution is whithin the expected difficulty range for that problem. For example Div2Bs usually just need a simple observation.
For div2 D and simpler problems, I think we should approach them from the perspective of "how to solve the problem" instead of "use what to solve the problem".
This kind of thinking can be divided into the following aspects:
Understand the problem and find the key observation (not all similar problems have the same observation, so this point might be quite important).
Find out what we need to solve for (ex: in an optimization problem, enumerating all solutions is possible, but sometimes we don't care about the optimal solution, so we can consider greedy / dp).
Of course, understanding knowledge is also very important. You can consider training each knowledge point in a specialized way. In this way, for certain problems, you can directly come up with their solutions (if n <= 20, consider dfs; for counting problems, consider using combination numbers; for things with monotonicity, use binary search, etc.). After training on dfs, greedy, binary search and dp, I believe you can quickly solve most of the problems at *1300 and below!
Of course, this kind of thinking logic might lead you into a dead end. ex: when solving CF2069C, my approach was to calculate the contribution of each index, but this method was too complex, and caused me to fail to solve this problem. However, judging from the number of people who passed the problem during the competition, I should have been able to solve it quickly. But by identifying the loopholes in your thinking and mending them, you can make rapid progress!
Hope this content can be helpful. :)