5 Mistakes You Will Make as a LeetCode Beginner & How to Fix Them
Using LeetCode Effectively
From 20 July 2021 to 2 April. In the last 8 months, I have solved over 350 interview problems from LeetCode. Here are the 5 mistakes I have made so that you don’t have to.
0. Problem Reading
I don’t know why, but I used to make a lot of mistakes reading the problem statement early on.
It is like you gave a question, and as I quickly read over it, I realize that I have seen this problem before. So now I am excited. I start solving the question, and it feels a little hard, but I fix all issues that come up one by one. I code it up and hit “Run Code”. Only to get a WA on the first — the first test case. Then I’d go over the problem statement again and facepalm. I missed a small yet important detail in the problem statement.
As I have solved more and more questions, however, I have become better at reading the problem statement and extracting all the relevant information before starting with a solution.
One bonus tip: All of the problems require you to use their information fully. So a problem can mention multiple conditions and constraints. And if you are not using all the pieces of information of the question, you probably have an inefficient solution. Make use of *all* of the information in a question to find an optimal solution.
1. Memory
I studied Data Structures and Algorithms in my first year. After one year of gap, when I started off doing my first couple of LC questions, I struggled implementing. I struggled with even implementing binary search — I knew the overview, the basic logic, but I couldn’t implement it for the life of me.
I stressed out about not knowing the implementation for even the basic things, even though I understood their logic.
This is why LC daily worked for me. See, they give you one interview problem to solve each day. And over a period of time, it adds up. You see a lot of questions and a lot of repeated concepts. One interesting consequence that I have observed is — that I don’t even have to think about implementation anymore. It is not a problem for me.
Take, for example, binary search again. In solving 350+ questions, I have come across binary search so so many times that I have the template code in my mind, ready to go. I don’t even have to think about the loop structure, the conditions, or if I should do mid + 1 or mid. I know what to do. And I can do it with my eyes closed.
I follow the official Python3 implementation, which is also the same way its implemented in C++.
2. General Strategy
When I started off, I did not know how to approach the problem. It was a bit of a mess. But over a period of time, I found a strategy. Whenever the question is a bit beyond my reach, I like to do the following:
Step 0: Start with a brute force solution.
This is hitting two birds with one stone. Writing a brute-force solution forces you to think about the important parts of the problem, and how the conditions come together to give the expected result. Then, by formalizing the steps the problem mentions, you can have a brute-force solution in hand.
Step 1: Optimizing
More often than not, a brute-force solution is not enough. Now how do we optimize it? I’ll start writing down test cases — small test cases and try to find if there is some hidden pattern or observation there. Maybe looking in the reversed direction or reframing the problem also helps.
Step 2: Coding the solution
Code! Once you find the solution, it is equally important to be able to code it up. If you have seen the DS/A before it helps a lot.
3. Coding/Debugging
After getting a solution accepted, it feels like you’re done for the day, so you don’t bother anymore.
When it comes to coding and debugging skills, one mistake I made was not looking at other people’s solutions.
In LeetCode, there is a discussion tab where people can post logic, explanations, and code. I have personally learned a lot from reading other people’s solutions. I have learned a lot by looking at other people’s solutions, reading through them, and understanding their thought processes, especially about the language itself.
I don’t have any formal training in Python, but I know special functions used, hacks, the nitty-gritties of the language, and the “Pythonic” way of thinking. Go through my other stuff, on this website 😀
Along with coding, debugging skills come automatically. As I have solved more and more questions, I can more easily spot and solve the bugs. It’s like I know the general places a bug might come up — a variable name messed up or an indexing issue or whatever, giving the same runtime error or time limit error — and I can fix those issues faster.
4. Thinking in terms of code
This is perhaps the biggest hurdle that I faced as a beginner.
It’s sort of like, you look at a question, and it’s hard. You read the problem, and it feels like a proper hard problem. I have noticed that if I am just skimming over the problem, I feel I can’t do it. It’s a bit above me.
At that point, it’s easy to skip the question. But that’s a mistake.
See I have noticed — even if the solution does not strike me at first, as I start working on it, I think my brain shifts gears. I get in the zone. And it is amazing.
I have solved enough problems to read a question and then say, hmm, maybe this is the direction I need to think in. So maybe I’ll look at a graph question and I’ll immediately know, that maybe I need to try out DSU here.
I think it’s because I have built up my intuitions. I can think in terms of Data Structures and Algorithms.
And the thing is, even if that particular chain of reasoning does not work, I think about it a bit more, and I’ll naturally have more and more ideas that come. Ideas start to flow.
#. Final Thoughts
If you look closely, all of the mistakes one can make in solving LeetCode can be fixed by solving more and more questions. Whether it’s a day-by-day grind or a month-long speed run. Practice. Practice and Practice.
Originally published at https://chaudhary1337.com on April 10, 2022.
