Five things I have learned after solving 500 Leetcode questions

Everyone looking for a job in software development is likely to know Leetcode, which is a website that collects questions and answers from technical interviews at companies like Google, Facebook, and Microsoft. Leetcode also gives advice on how to answer these types of questions and what to do instead.

These kinds of questions about data structures and algorithms are becoming more and more common even at small businesses, which frustrates people who say their "leetcoding" skills don't show how well they can do the job.

However, even though I agree that not knowing how to work with Leetcode isn't a bad thing, there are many things that grinding Leetcode can teach you that will help you in the long run.

1) The importance of Data Structures & Algorithms

Leetcode is not a DSA course, and if you don't already know how to use the platform, you should take a course that will teach you how to use it effectively. Leetcode is great at helping you understand how and why they work and what they are best at.

Let's be honest: Every developer needs a solid foundation in data structure. I recently came across the story of how a simple algorithm change was able to cut 70% of the loading screen time for GTA V, and I know from experience how efficient implementation can allow an application to run smoothly even when it's under a lot of stress.

2) There is always someone more knowledgeable than you

As soon as I figure out a way to solve a problem, I usually feel pretty good about my code. That usually changes when I read through the comments, where you can sometimes find solutions that are better than even the official one.

Leetcode has taught me a lot, but a lot of what I've learned has come from carefully reading other people's code and trying to follow their advice myself.

The idea that there is always more to learn is even more true in my job because I have a lot of very experienced seniors who have helped me a lot. This mindset of learning from others has allowed me to take in as much of their knowledge as I can.

3) An edge case can ruin your day

The stakes were low before I started working, so if I made a mistake in my code, it would be easy to forget about it.

Now that I'm working on a real project, I know that any bug, even one that only affects a very small part of the code, could cause problems for our clients.
Fortunately, Leetcode is a great place to learn how to write code. Every problem has hundreds of test cases, and many of them include every situation that would break the code if it wasn't thought of.

When I recently had to work with a database that didn't have the right constraints and had a lot of rows with weird values in them, I realised how important this was. Fortunately, I was able to fix these problems in my code before they became a problem in production.

4) Hard work beats talent…

If you work hard, you can beat talent even if you have a lot of good skills. "I love this quote from Tim Notke, and it's very relevant to Leetcode." From my own experience, I know a lot of great and talented developers who can't solve most medium-sized problems because they don't know the patterns and tools to use and haven't built the right structure to solve these kinds of problems.

I was even worse than that when I first started. I had trouble with almost any easy question. After taking a few DS&A courses and working on a lot of easy questions, I was able to get to the point where I could solve most mediums in a reasonable amount of time and even difficult ones half of the time.

Another example of the importance of practise came when I recently switched from Python to Java to solve questions. Even though I use Java every day at work, it doesn't feel natural in this setting and I have to go online to find out how to solve most questions, just like when I was a beginner.

In the end, this didn't bother me. I now know that with enough practise, I'll be as good at Java as I am at Python, too.

5) Planning is an important part of making software.

Coding is only a small part of the whole process, and writing a solution right away after reading the question is the worst thing you can do.

Code interviews try to make it like software development by asking questions that aren't clear or aren't complete. It's your job, though, to communicate with your interviewer to get clarifications and see if there are any limitations.

Before you write the code, you should come up with a solution, look at its strengths and weaknesses, and only start coding when everyone agrees that what you came up with is acceptable. If you start coding something that doesn't meet the time and space requirements, you won't have time to change it and you won't be able to do anything else.

This is just as important in a real job as it is in school. If you start writing code without analysing the needs and carefully thinking about your options, you are very likely to have to refactor most of your work.

Conclusion

Honestly, I'm lucky because I like Leetcode and I don't mind practising on it even when I'm not looking for a job. I know a lot of people who don't like it and say that it doesn't teach anything that can be used in a real job.

At least some of you may have learned that it isn't true, and if you have to use Leetcode for interview preparation, at least try to learn something from it. If you don't like it, there are many jobs that won't ask you about it.