What 1,200 problems taught me
I solved more than a thousand problems. The useful part was not the algorithms.
The first LeetCode problem I solved took me forty minutes. It was Two Sum. I remember feeling like a genius and an idiot at the same time.
By the time I stopped, I had solved over 1,200 problems. My rating peaked above 2,200. For a while I was in the top 500 in India. None of that is what stayed with me.
Being stuck
What stayed with me is that I learned how to be stuck. I mean sitting with a problem without panicking. That is a skill you can use outside of a contest.
Most problems are not solved by inspiration. They are solved by trying the obvious thing, watching it fail, and noticing what the failure tells you. Competitive programming drills that into you. You get faster at being wrong.
I also learned that reading the problem carefully is usually harder than knowing the algorithm. Half the wrong answers I submitted came from misreading a constraint or assuming something that was not there, not from missing the technique.
One problem I remember was a graph problem I solved three different ways. The first two worked. The third was faster. The lesson was that the first solution is rarely the best one, and that is fine. You need something to improve.
The leaderboard
The other thing it taught me was humility.
There is always someone faster. You can spend a year getting better and still get beaten by a teenager who solves the problem in four minutes. You learn to compare yourself to your past self, because comparing yourself to the leaderboard will make you miserable.
People assume competitive programming is about memorizing algorithms. It is a little about that. Mostly it is about pattern recognition and calm. You see a problem, you have a vague sense of its shape, and you start poking at it. The algorithm comes later.
The limits
The trouble is that contest problems are clean. They have one right answer, a clear input, and a time limit. Real software is not like that. Real software has users who do unexpected things, requirements that change, and bugs that only happen on Tuesdays. Solving 1,200 problems made me better at interviews. It did not make me good at building things.
I learned more about building software from maintaining a small personal site than from any single contest. That is not a knock on competitive programming. It is just a different skill.
Would I do it again? Yes. The rating was never the part that lasted. The habit of sitting with a problem until it makes sense is what stayed.
These days the problems are in a book. The habit is the same. Read carefully, try something, see what breaks, go again.