Adventures in Leetcode

Leetcode. Most software engineers have heard of it. I’d never used it, but I decided to check it out because I’ve been so absorbed in work and life recently that I needed something else.

I understand why it’s regarded as it is – both a blessing and a curse. It’s a great source of small but manageable coding problems. Not only that, you can see how others solved the problem. It’s really neat that it shows you how your solution compares to others’ in regards to runtime and memory usage. I’m enjoying these parts a lot.

What I’m not enjoying is how many of these problems rely on algorithms. In real life, the opportunity to use algorithms is so low. I want problems that require me to actually understand what I’m writing, not just regurgitate an algorithm I learned. Maybe this just means I haven’t really learned enough algorithms. I need to work on that.

As I mentioned, it’s awesome that you can see others’ solutions. However, I’ve noticed a theme that people don’t tend to write maintainable code. Or even very readable code, at that. This is also not what I’m looking for. I’m only a few problems in, so I’m not sure if this is a result of the nature of these problems, or the nature of the people solving the problems. Maybe it’s half and half. I do think it’s very common for people, when given a problem, to keep much more of the problem in their head than they need to. They don’t start with OOP. They don’t build objects with reasonable relationships and ownership. They use primitive data objects and maintain that modeling and data ownership in their heads. I do this too… but I want to practice not doing that.

I’m still having fun, and I’m glad I finally checked it out. Like most things, you get what you put in.