Blog
How My Way of Thinking Changed with CSES
For a long time, I believed platforms like LeetCode and GeeksforGeeks defined what “good” problem solving looked like. Not rage-baiting — that’s genuinely what I thought.
My typical approach was simple: read the problem carefully, think about possible test cases, recall a similar problem I had solved before, and try to apply the same pattern. In many cases, I relied heavily on unordered_map. In fact, for a lot of problems my first instinct was:
“Can I solve this using a map?”
Surprisingly, this approach worked quite often. Many of my solutions on LeetCode passed comfortably, sometimes even showing the satisfying “Beats 98%” message. Using these techniques, I was also able to clear a couple of DSA interview rounds (though I eventually got rejected for other reasons).
At that time, I genuinely thought my approach to problem solving was solid. Then, out of curiosity, I decided to try the problems on CSES.
And that changed everything.
When I started solving problems there, I quickly noticed something surprising. Solutions that easily passed on LeetCode would often result in Time Limit Exceeded (TLE) on CSES. Even implementations that looked efficient at first glance would fail on stricter constraints.
Initially, this was frustrating.
But over time, something interesting started to happen. Instead of relying on familiar patterns or quick fixes like maps, I began looking deeper into the mathematics and reasoning behind the problems. I started thinking more carefully about time complexity, constraints, and how to design logic that truly scales.
That shift opened up an entirely new way of thinking.
Many elegant CSES solutions look deceptively simple. When you read the final code, even a beginner might understand it quickly. But the thinking process behind that code is far from trivial. It often requires breaking down the problem, identifying the core idea, and designing a solution that is both efficient and clean.
That kind of thinking is what really strengthens problem-solving skills.
Another interesting realization was how much we rely on platform-provided scaffolding. On many coding platforms, the driver code is already written for us. Over time, it’s easy to forget how to structure input handling, program flow, and other basics.
While solving CSES problems, I also started writing my own driver code again. To push myself further, I try solving each problem in three different languages.
You can find my ongoing solutions here:
I haven’t solved every problem yet — I’m still on this journey.
If you’re also exploring CSES or thinking about improving your problem-solving approach, feel free to check out the repository and share your thoughts. I’d be happy to hear how your experience has been.