Leetcode.com is a website where people–mostly software engineers–practice their coding skills. It’s pretty similar to sites like HackerRank & Topcoder which will rank your code written for a particular problem against the ones submitted by other users.
Leetcode gets primarily used for two use cases:
I never had a clear understanding when it comes to data structures and algorithms, so being a software engineer for the last 12 years, I thought it’s not a bad idea to at least start now. So as of Dec 2019, I became a premium member in Leetcode and committed myself to get as much value out of $150 that I spent on the membership fees. Leetcode is like an ocean; it has closer to 2000+ questions, which keeps growing day by day.
In fact, this was my exact reaction when I open the website for the first time after looking at the number of questions and categories it had
In this post, let me explain some of the methods I developed over some time, which helped me to understand and learn about these data structures & algorithms.
Most people new to Leetcode directly jump into solving the problems without getting a proper understanding of the underlying data structures like a linked list, stack, queue, tree, etc. Trust me; this is a bad idea.
I would recommend spending some time understanding these data structures, which are the building blocks for solving any problems.
Even if you are not able to go through all the data structures, at least get a strong understanding of the linked list and binary trees. Fortunately, there are some excellent materials created by Stanford, which can help you with this:
Leetcode has many categories and a whole lot of questions in each of them, so it’s essential to come up with a method that could help you to understand these concepts. Learning with Leetcode is a long process, and it will take time, so one thing that I clearly understood is you have to keep the enthusiasm and eagerness to learn high if you want to go through the journey.
If you are a beginner, then use the below flowchart to learn things and gradually increase the complexity of the problems that you solve. It also helps in understanding the concepts well so you can reapply those techniques in the subsequent problems.
Stages are numbers in red circles, and dotted lines are entirely optional for proceeding to the next stage. When you are done with stage 3 depending upon your motivation, you will end up either doing “Monthly coding challenges” or “attending interviews” (both are fun).
It’s essential to define a process, so when you get a problem, you know exactly how to solve it, or else it won’t be easy to organize the information that you have learned so far and use them when required. The most fundamental thing to do before writing code is first to understand the algorithms and various techniques.
I came up with a two-step process which helped me in both learning these techniques and coming up with a solution when presented with a problem.
I would first categorize the problem into one of these buckets:
Assuming you have already categorized the problem, you can now apply various techniques that you learned on each of these categories to come up with an elegant solution. I would say try to come up with a solution first (maybe even a worst-case scenario), don’t need to be the most optimal one. Because based on my experience, if I target the best optimal solution right away, I generally get stuck, and I lose hope of solving the problem.
Tip: A simple way to reduce the time complexity is to use temporary storage in the form of Queue, Stack, List & Map part of your code
Below diagram explains the process that we talked about:
Some things to keep in mind which I learned over some time:
It’s easy to look at the solution, but don’t do it → Even though your algorithm performs the absolute worst, I would recommend you code the whole thing out, see the runtime complexity first before directly looking into the solution. If you start looking at the solution early, you will never learn anything because you will always be inclined to go to the “Solutions” tab if you are not able to solve it for more than 10 mins.
Understand the problem statement properly → Sample output and test cases given in Leetcode problems are only simple ones. If you take that as a source of truth and start designing your algorithm, your code will fail. So I would say try various test cases to make sure you understand all the scenarios then code it out. That way, you will cover all edge calls and learn a lot during the process.
Submitting the code too many times → Since there is no penalty in submitting the code multiple times, I have seen people coding fast (not covering all scenarios, or being impatient) and submitting the code way too many times. Of course, it will fail, and they can keep trying again and again. It is not at all recommended as in case of a coding challenge, you will get negative marks for this, and if you are attending an interview, you may even get rejected for this behavior.
Pay attention to edge cases → Leetcode, on average, runs anywhere between 100 to 250 test cases for a given problem. So make sure to read the “Constraints” section of the problem statement carefully and code all the edge cases, so you don’t need to rewrite the whole code after seeing a failure on a particular test case.
Turn off autocomplete → This is not a big deal. But most coding interviews are conducted on a vi editor or a simple notepad, so practicing code without autocomplete helps in these situations.Learning materials
Here are some youtube channels that helped me to learn things:
Starting from Dec 2019, I have been pushing myself to spend at least 7 to 8 hours a week solving coding problems in Leetcode and trying to learn as much as I can. I would say its worth it.
I thoroughly enjoyed the journey I was not only able to get a strong understanding of these data structures but also developed a habit of learning different algorithms created by various authors to solve the same problems (not just looking at the solution)
I was also able to relate how some of these algorithms get used in the products that we use pretty much every day. Here are some examples:
If you like the writeup and found it helpful, please a clap 👏 or leave a comment in the article.
Also published behind a paywall at: https://medium.com/javarevisited/graduating-from-leetcode-b5da6a786514