Guide

So I've seen a lot of posts recently asking how to get good at leetcode. I see countless posts from beginners who don't know how to start and panic at not being able to solve easies despite taking a ds&a course. I see posts from those who have done 200+ questions but still can't reliably solve mediums on their own. As someone who recently went through the journey of going from zero DS&A knowledge to interview-ready in 4 months. I figured I'd write a step-by-step guide of what I did to help everyone out. This post is not intended to be a philosophical discussion on whether leetcode is appropriate for interviews, this will be an actionable guide with concrete steps that you can follow. Who am I and why you should listen to me: I have to preface this guide with my background so you can trust that I know what I'm talking about. I'm a recent mechanical engineering graduate from a Canadian university who self-studied computer science and web development and landed a software engineer role. Part of this self-study process involved learning DS&A and leetcode which took 4 months by studying 3-4 hours a day, 6 days a week. At the start of my journey, I couldn't even solve easies. After these 4 months, I'm now able to consistently (90% of problems) solve mediums in ~20 minutes and hards in ~35 minutes on my own. I also usually solve OAs (tiktok, SIG, IMC, blackrock, pure storage, c3 ai, cisco, tower research) with 100% test cases, and scored 822 on my one codesignal gca attempt (not the best, ran out of time debugging q3 lol). I've done 6 leetcode questions during onsite interviews and have optimally solved all of them. I'm not trying to flex, just trying to show that what I'm saying is credible. My overall strategy: As a preface, the goal of this guide is to deeply understand the techniques needed to solve LC problems at an abstract level and implement your abstract solution quickly. My approach is based off how technical material is taught in university courses. What they do is teach a strategy/technique at an abstract level, walk through solving guided example problems using that strategy, have students practice through assignments and practice finals, then apply what you've learned on the actual exams. My overall approach to learning is breadth -> depth -> breadth. First learning what you’ll be learning (breadth), learning those specific topics with a full and deep understanding (depth), then tying the specific topics back into the big picture and how they relate to each other (breadth). I also write summary notes after I read through a topic, I find this lets me take all the information and form a generalized abstraction of the topic along with critical specifics, and if I’m able to write a page of well-structured notes using my own understanding of what I just learned then that means I understand the topic deeply. I also re-read these notes at the end of each of the 4 steps for spaced-repetition effects or when I need to jog my memory since re-reading my own written notes takes me back to the mental state I was in when I first wrote them. Step 1: Learn Python (or Java or C++): The first step is to get familiar with your programming language of choice. I chose Python and recommend you do the same if you have time, but if you’re in a rush then just use whatever you’re familiar with as long as it’s acceptable in coding interviews (Python, Java, C++). Python is the least verbose language and most similar to plain pseudo code, and in a timed test every minute counts. It lets you spend less time on implementation and more time on figuring out the abstract algorithm which is where the bottleneck is for coding interviews. You need to be familiar with a language before you can learn DS&A so you can concurrently learn the language implementations of data structures and algorithms. To learn Python I just went through the W3 Schools’ guide on syntax and overall language specs (dynamic typing, garbage collection, etc.). The official docs are good as well but they have a lot of stuff that you don’t need for coding interviews. I also took notes on the syntax (6 pages). This step took me 10 hours split across 3 days. Step 2: Learn DS&A: With DS&A you need to learn how each data structure and algorithm works deeply at an abstract level. For me this meant visualizing a gif of the algorithm in my head, learning the time space complexities of operations the DS/A supports and why they are what they are, learning how the DS/A handles edge cases, and writing an implementation in Python. The resource I used was the interactive ebook PythonDS3 by Runestone Academy. It’s full of word explanations, diagrams, and live code in an editor that you can play around with. It first explains each DS/A at an abstract level, then shows you the Python implementation. I would go through a page/sub-section, think about the concepts deeply and piece everything together in my head, then write a page of notes on that topic. As a preface, I used Tech Interview Handbook’s study plan to figure out which topics are important and I need to take notes on, and which are not which I would only read. I also used Tech Interview Handbook’s topic-by-topic cheatsheet to confirm time and space complexities and how the DS/A is used in problems. This step took me 6 weeks, and I tried to finish 1 subsection per day. Each subsection only takes 30 minutes to read, but I would reread, think deeply about what I read, google stuff I didn’t understand, sometimes watch a youtube video if I still didn’t understand it fully, and write my summary notes which all took about 3 hours per subsection. Step 3: Learn Leetcode techniques/strategies (patterns): So here is the most important step that I see a lot of people get wrong. People tend to jump straight into practicing leetcode problems and end up having to do 300+ problems to get interview-ready. The issue with this is that LC problems are designed with particular established strategy in mind, and if you’re trying to learn the strategy from particular problems then that’s very inefficient. This would be like in calculus, trying to learn the chain rule, fundamental theorem, monotonic convergence by jumping into doing calculus practice finals, or in linear algebra, trying to learn matrix operations, finding eigenvalues, or SVD decomposition by jumping into doing linear algebra finals. You can clearly see how inefficient this approach is. Furthermore, many of these strategies came from breakthrough papers in computer science that took PhDs to come up with and have many pages of rigorous proof. Trying to come up with these strategies from scratch or induction from LC problems would require you to be a genius. Now you see why so many people get stuck at this step, they’re doing it completely wrong. The resource I used for this is Grokking the Coding Interview and Grokking Dynamic Programming by Design Gurus and Educative.io (no affiliations). These courses are paid but the information is truly worth the money, as it’s by far the best resource I’ve found for this step and the time and energy you’ll save compared to using other resources is well-worth it. If you really can’t afford it then I’ve heard good things about Leetcode Explore cards. There’s also a Hackernoon article on coding interview patterns that summarizes the patterns taught in Grokking, but they’re pretty succinct and don’t offer the depth of information that I think you need. You could pair that with the CSES Competitive Programmer's Handbook to pick out and learn the specific strategies covered by Grokking. I basically used this the same way as with DS&A. For each pattern, I read the primer, read the solutions to the first few problems, tried to solve a few of the later problems in my head abstractly (5-10 minutes of thinking) using the strategy taught in the first few problems, then read the remaining problems (each pattern has 5-14 example problems). Once I finished a pattern, I would piece together the information into an abstract strategy, the situations in which that strategy can be used, what makes the strategy more/less efficient compared to other options, common characteristics in problems where I should consider this strategy, along with its edge cases and time/space complexity, and write down my page of notes. This is probably the most difficult step of the whole plan as you’ll be flexing your brain for abstract thinking and logical reasoning. It'll likely be very difficult to think that hard but you’ll develop a very strong foundation for solving LC problems later so it’s well-worth the mental pain. I would try to aim for fully learning 1 strategy per day which took anywhere from 3-5 hours and there’s around 24 strategies total (Grokking the Coding Interview + Grokking Dynamic Programming). For dynamic programming, there’s a section in Grokking the Coding Interview but I found it confusing and it only contains 1 DP strategy, so I recommend skipping that one and once you’re done GTCI start Grokking Dynamic Programming which explains that strategy better and also has 5 more strategies. Step 4: Practice At this step, you should know your Python syntax, understand DS&A, understand the ins and outs of each strategy and should be able to come up with the solution in your head to most LC easy’s in 5 minutes and mediums in 10 minutes. The point of this stage is to actually practice the full problem from prompt to code and practice talking out loud (or whisper if you need to be quiet) like you would in an interview. The resource I recommend is Grind 75 grouped by weeks with 70-100 questions total. Go through each question and try to solve it on leetcode. Don’t look at the solution until you’re stuck for 30 minutes, meaning you haven’t made any progress in your logic for 30 minutes, making logical reasoning steps in your head doesn’t count as being stuck. To actually solve a problem, read the prompt, visuals, examples, and input ranges. Start with a brute force and solve how you would do it intuitively, typically this means start on element 0 and perform steps until you reach a solution. Then make logical deductions based on what you’ve been given in the prompt and how your brute force looks (careful, the brute force might be a red herring to the actual optimized solution). Use your logical deductions and match onto a few potential strategies that you think have a high chance of working and investigate how each of those strategies could be used to solve the problem. Sometimes you'll need to combine strategies in series or parallel. If you can’t identify any, just try each of the 24 strategies one by one in your head, even if this fails it’s all good practice for your logical reasoning skills. You can think of the problem solving process as a graph traversal, where you have your starting state as one node and your goal state as another node. You can add strategies as edges onto your starting node to transform the starting state into a new state. Check if the new state is your goal, if not then add another strategy either onto your new state or your original state and repeat until you reach the goal. Once you have the optimal solution in your head, write down your algorithm in comments above the function in 2-4 lines along with the time and space complexity. Writing the algorithm down takes me a minute, but it saves me 5-10 minutes during my implementation as it lets me focus purely on implementing my algorithm into code by referring to the text when I get confused without having to think “what was my algorithm doing at this step again?”. Initially, you’ll probably be slow at implementing the algorithm in code and run into a bunch of Python syntax errors. I’ve spent hours debugging my code in single questions at the start, it’s normal and just use this to learn the quirks of Python. After implementing, I check over my code once for silly mistakes and then run through it with one of the example test cases line-by-line, keeping all the variables in my head (use comments if needed). Then I submit and fix my code if the submission failed. Once the submission passes I go look at the solution (either official or in the comments), try to find “easy-to-understand” and ignore the one liners. If I still don’t understand the algorithm I’ll watch the Neetcode video for it then try to implement it. After around 20 easy’s I started solving them (getting the first optimized code solution which may have syntax bugs) in 15 minutes. After the first 20 mediums I started solving them in 30 minutes. Hards are usually a combination of strategies and some (mostly greedy algorithms) you just need to memorize but there aren't too many and so I can usually solve them in 40 minutes right from my first hard unless I just don’t know the trick. I did 2-4 problems a day (2-5 hours daily) until I hit 50 problems and that was when I felt confident I could solve 80% of the problems on my own in a reasonable time and the remaining problems if I was given a hint or two which is more than interview-ready. Bonus step: Maintain your skills: Given how common switching jobs is in SWE due to either increasing TC or layoffs/pip/firing, and how interviews in SWE are bottlenecked by LC problems, it makes sense to try to retain your knowledge such that you only need a week or two to prep the next time you interview. I’m planning on doing 1-2 LC problems per week on Sundays which I feel like after all this prep to build a strong foundation and deeply understand the material should be enough to retain my knowledge. My solving speed will probably drop, but I estimate next time I prep I’ll only need to review my notes and do 30 LC questions to get me interview-ready. This will probably only take 2 weeks time instead of months. 1-2 questions per week will only take 1-2 hours per week which is nothing for the reward you get by staying near interview-ready. I’ll have to try it out to see if this is enough, but it seems like it should be. And that's the end. If you made it this far, try implementing these steps and let me know how it goes. I hope you find similar success that I have found following these steps. If this guide has helped you in your journey and you want to support me, I'm always taking referrals (DM me). Happy learning!