A System for Getting Better at Leetcode#
For the longest time I was in denial about the benefits of studying algorithms and data structures. I wasn’t fascinated by Leetcode or other forms of competitive coding. It felt drab to me. I’d rather build something using programming. That’s more fun. Companies should consider my skills based on Github.
I’ve seen this sentiment around Hacker News and Reddit as well, and I must admit, I was influenced by it. A friend of mine constantly recommended that I learn how to solve DSA problems, but I never got around to it. I tried several times, but I always failed.
Today, I believe that every company should conduct a basic problem solving test for technical roles. You don’t have to use it as a filter, but do the bare minimum, and ask the candidate to actually read a problem that you set them, and attempt to write code in front of you.
What does this exercise do? It shows you not just their coding skills, but also their comprehension skills. It shows you how your potential colleague asks questions, how they think. Take home tests might show you more valid parameters, but as a candidate they tire me out. This sentiment is shared by the community at large.
I’m not saying you should reject candidates on their performance in these rounds. Far from it, you should just use these to weed out really red flags. If someone says they can code but they can’t even write the semblance of placeholder code, then that’s a red flag.
Far too often I spot people in my organizations who struggle to write code. Perhaps they’re good at other things, but coding is definitely not their forte. They could be great sys admins or devops people, sure.
It is not my objective, though, to attempt to convince anyone why you should conduct coding interviews. I’ve made up my mind to not work at places that don’t conduct them anymore. I’d like to know that the company wants to check my skills, and I’d also like to know that everyone I work with has been vetted the same way, so I can hope to expect at least a bare level of coding from them.
So back to my problem. If I think coding interviews are so important, why was I failing at preparing for them? I wanted to crack interviews, so why was I not able to follow what it takes to do well at them?
James Clear - Atomic Habits
Goals can provide direction and even push you forward in the short-term, but eventually a well-designed system will always win. Having a system is what matters. Committing to the process is what makes the difference.
My mistake was that I was not focussing on my system. I was focussing on the outcome of this system. I wanted to crack coding interviews. That is a worthy goal, at this juncture it’s as lofty a goal as any, especially if one sets their eyes on the large tech companies like Google, Apple or Netflix. But one piece of advice I offer anyone trying this is to focus on the system you’re building for yourself.
I’ve been thinking a lot about what sort of system I want to build for studying how to become better at leetcode. I’ve offered segments of this advice to several people. I wanted to take the time to put my thoughts into words so that I can elaborate on my system, and perhaps track its evolution better.
What does it mean to build a system for learning to leetcode better? Well, it means that this system won’t work if you have an interview in X days. That could be a month, 3 months, 6 months or half a year. You might get better at “cracking the coding interview”, perhaps, or you might not. Don’t focus on that.
With that said, let’s begin.
Note
Prerequisites
First, pick a programming language and learn its syntax. You don’t need to know a lot, because you should not be looking at third-party libraries for these problems. Whatever you pick, ensure you learn enough of the syntax to be able to write simple problems with strings, arrays, integers, loops, conditionals, boolean algebra, functions and hashmaps.
If you’ve every taken a class on Algorithms, you can probably skip this step. If you have confidence in being able to remember what you’ve learnt, you should stick to that. However, if you feel you’ve forgotten everything, then you should do one of the following, depending on what sort of learner you are.
Go through the MIT 6.006 Introduction to Algorithms Course
Go through the various sections of data structures and algorithms from Geeks for Geeks.
If you’re really serious about grokking all of this, you should do all three. But these will take time, and they should, since you’re learning a lot of new things at the same time.
Build a Habit, Progressively#
Your first week of leetcoding shouldn’t even be trying to solve a thing. You should focus on logging into the platform, once a day, for 7 days. Turn off your password manager. Type your user name and password. Stay logged in for 15 minutes. Set a timer. Keep looking around the website. When you’re done, log out. I’d recommend using the Private or Incognito mode of your browser to do all leetcoding so you will have to type your user ID and password every time.
Your second week, start reading problems. Just read them. Read them slowly, absorb the language. See what sort of words the questions use. Stay on the website for 30 minutes per day. I’d recommend looking at Easy problems with a high Acceptance Rate. That will give you the truly easy problems.
Warning
Remember that the labels for difficult are quite arbitrary and irrelevant. You should not consider yourself incapable if you do not do the Easy problems. Treat the words Easy, Medium and Hard as words from some other language. They could be gobbledegook for all you care. Use the labels as I recommend, and do not judge your performance on your ability or inability to solve problems of any difficulty. As I will elaborate further, that is not the thing you should measure.
On your third week, you begin trying to solve problems. I say try begrudgingly. Some of you might manage to solve one or two problems, or even more, although not with ease. That’s irrelevant. Don’t congratulate yourself on the number of problems you’re solving. Focus on spending 1 hour on the website. 1 hour. That’s how long you’re going to try to stay logged in. Again, at the end of it, log out and do not store your password on the browser.
From your fourth week, start trying to solve 1 problem a day. Pick the easy ones with a higher acceptance ratio. And time yourself. Don’t spend more than an hour on the website just yet. But keep trying to do this.
Show Up, Consistently#
The first step to “leetcoding” is showing up. You show up, consistently, every, single day. You are sick? Doesn’t matter, log into the platform, read a problem.
Tip
My favorite metaphor for learning to leetcode is to treat it like going to the gym. Your first objective is not to bench 150 KG. Your objective is to not give up in the first few days. You should get up, no matter how bad your day has been, and show up for the workout. It is hard. Don’t let yourself believe that this isn’t. If showing up consistently were easy, everyone would do so. As time passes, it gets easy, but other things influence the difficulty. Good habits are easy to break, unfortunately.
You should consistently show up to the website. Do not break the habit. Do not give up. Try to log in on mobile and read a problem if you’re not near a laptop or a workstation.
This is the first thing you’re going to measure. What is your streak? Not the number of problems you’re doing. How many consecutive days have you been logging in to the platform? Try to get it as close to 90 as possible. Logging in 90 straight days will burn this habit into your routine so you will find it hard to break it.
Measure, Measure, Measure#
You need to measure your progress. What do you measure?
Are you logging in consistently?
How long do you take for an EASY problem on TOPIC with NN% Acceptance?
How long do you manage to stay on the platform until you’re bored or you’re done?
How many problems have you attempted?
How many problems have you solved?
How long has it been since you’ve solved a problem on TOPIC?
What time complexity are you managing for each problem?
What space complexity are you managing for each problem?
What’s the runtime on each solution?
These measurements give you control parameters that you can tweak. You can use these to improve your consistency. You can use them to improve how you learn to leetcode, and how you get better. I’d recommend tracking them however you feel comfortable. I am going to use some tools I’m building myself to achieve this. I’m still not sure, but I have some ideas that I’ll blog about later.
Spaced Repetition#
You shouldn’t keep doing problems in groups of the same topic. Space them out. Return to problems you’ve done before. Return to problems you attempted and perhaps gave up on. Return to problems where you couldn’t manage an optimal solution. Return to problems where you couldn’t manage to improve run time.
Learn from Others#
Read some one else’s solution and try to work through it by hand. Sometimes reading code in another language helps. Remember that most of your job is reading code rather than writing it. But only read others’ solutions once you’ve managed some level of solution by yourself.
Whenever you read their solutions, make sure you rewrite them in your own language. This is why I recommend reading them in some other language. If you code in python, read Javascript solutions. If you code in Java, read solutions in Python. If you code in Javascript, read code in golang.
Keep an eye on the /r/leetcode subreddit. You can also find good solutions on Youtube and Github. The former might be easier to search on.
Challenge Yourself#
Once you manage to consistently show up for 90 days, mix it up. Go on to a platform you haven’t been using. Hackerrank is good, so is Advent of Code. Try to do the problems there. Measure this as well.
Explore uncharted territory. Try problems on Project Euler, while these are not exactly similar to Leetcode, these will help you get more practice in for writing such code.
Do Not Measure the Wrong Things#
When you want to work through an exercise regimen, whether for weight loss or muscle gain, you shouldn’t be measuring how much you are able to do. You should measure the efficiency of your practice. You should be measuring your ability to show up consistently. Do not measure your inability to solve a problem you think you should be able to solve.
Compete#
By this I don’t mean with others, but if you’re into that, you should. I mean compete with yourself. Repeat questions you’ve done before, your system should allow you to do that. Measure your new time. Compare. Try to see if you can gain a 10% improvement in a month. Redo the problem a year later. Are you even faster now?
Note
By repeating problems, your objective should not be to memorize the solution. It’s to look at an older problem with newer experience. You should be able to get better solutions with time. That helps you understand how you’re improving. If you feel that your older solution was the most optimum, then go ahead and retype that. Even retyping an older solution from memory will give you the practice you need. You will gain important muscle memory from it.
Closing Note#
Focussing on a system gives you a process to follow. A routine. You will learn to enjoy the process for itself. And when you’re ready, you should try out mock interviews. Or even better, you should try real interviews, even if you’re not looking for a job.
Note
As an end note, you can replace leetcode in this article with your favorite competitive coding platform. I recommend buying a leetcode premium account when you’re actually interviewing, but you don’t need one to follow along with my system.
Resources#
Here are a few resources I like to rely on when I’m thinking about my system. Note that I’m still early in my methodology, and this is a system that will improve given time.