A reasonable Leetcode guide to prep you for a fun Software Engineering career

Paul Maltsev
4 min readFeb 25, 2021

--

I am a software engineer at Ravacan where we build tools to automate supply chains and sourcing. The advantage of working at early stage startups is that you get to build unique tools. These tools often require concepts from Computer Science like Graph algorithms, a solid understanding of time complexity etc…

If you don’t want to spend your life just fixing API endpoints, you must invest time in learning CS fundamentals.

Recently I wrote a Leetcode “curriculum” for my friends and I’m sharing it here as it may be useful to others.

What

Pick difficulty Easy and solve problems from these tags in that order: Array, Hash table, Two pointer, String, Binary search, Linked-list, Tree, DFS, BFS, Topological sort*, Trie*, Sliding window, (optional: Dynamic Programming & Bit Manipulation — if this is your first time, skip these two).

I call that a horizontal pass (through the tags).

Then do the same for Medium difficulty.

I call that a vertical pass (through difficulties).

Once you’re done with Easy and Medium problems, you can do the top 10–15 Hard problems.

* means tag doesn’t have that many problems. Just do a few.

How

For each tag, sort by highest Acceptance and solve the top 10 problems. Then sort by lowest Acceptance and solve the top 10. Lastly, pick the “Top 100 liked questions” list and make sure you do problems in there for that tag.

Before doing each tag, I recommend reading the corresponding CLRS chapter and understanding all the theory behind it. Watching these lectures helps a lot! MIT follows CLRS, so it’s a good combination.

Also, these channels are great resources for difficult concepts: this for most problems, this for good explanations, this to see how a competitive programmer solves, this for graph theory, this for harder problems. And of course any other videos you find when searching for a specific problem.

I recommend spending 30min-2h per problem such that you can think deeply. That’s why doing more than 4 problems/day is too much to handle.

At first (especially with arrays, strings and trees) you will be looking at solutions often to get familiar with the concepts. Gradually, you want to read solutions less and less, while spending more time thinking.

Classic Problems

These are some problems you must do. They are not intuitive and you will need to invest some time to learn them, but they are very important concepts and building blocks for other problems. Do not solve them separately. Solve them when you stumble upon them.

Array: 1, 15, 560, 48, 46, 78, 215 (quick select is massive. Used in quick-sort too!).

LinkedLists: everything you’ll see under “Top 100 liked questions” & 141.

String: 20, 22, 227.

Binary Search: 33, 34 (Erichto has a good video on this one).

Tree: 104, 102 and most Easy & Medium problems from the “Top 100 liked questions” list. Trees are a great topic to master recursion! Do many tree problems.

Graphs: 207 (watch this video for a great explanation), 200. DFS & BFS are very important! You should be able to create a graph and perform iterative/recursive DFS or BFS (BFS is iterative only) comfortably.

Trie: Do all easy problems & 208.

Stack: 232, 155, 716.

Time & Space Complexity

Read this and the CLRS chapter on Big Oh notation. Understanding this concept is crucial!

As a rule of thumb, most problems above have a linear time complexity solution. A few have quadratic and a handful exponential. Space compl. is also very important and most problems have constant or linear space compl.

You should know the best time & space complexity for every problem. An interviewer will ask you for it.

When solving a problem, first come up with a naive solution (we call that brute-force). The brute-force solution will usually be quadratic (or worse) in time.

Always ask yourself what the time & space complexity of your solution is. Next, try to optimize it. Finally, compare it with the solution and make sure you understand and internalize it. Write it yourself (never copy!) and come back to that problem in a week. See if you remember how to do it. In fact, that is a general strategy for all problems. Every 1–2 weeks, do a review by revisiting some problems that challenged you. Try to solve them again and again.

Conclusion

That’s a lot of work and it takes time to gain momentum. It gets easier though. It’s very important to do a solid work with easy problems, that’s the foundation for all other problems. There are about 8–9 big categories, doing 15 easy problems per category, yields ~120 problems. Then 100 more medium. In total about 200 problems is plenty for a good understanding of all the topics.

Follow me on Twitter for more Software Engineering and Blockchain content.

--

--