105 LeetCode questions in 10 days
I ran medium LeetCode questions - here are my thoughts
LeetCoding is undoubtedly the most important single skill for any software engineer. The reason for this is that it’s basically part of all interview processes out there. Do I necessarily agree with this practice? Maybe.
You probably don’t need to implement the Levenshtein distance between two strings every day. Given that most of the engineering work is CRUD apps that follow a pre-established pattern anyway (especially in more junior ranks and bigger companies), the effectiveness of this interview practice might be debatable. Nevertheless, companies ask these questions for good reasons and it has shown that the process, as cumbersome as it may sometimes be, is working(*). Therefore, we have to face the reality of having to deal with these types of questions. I myself have been on both sides of the screen and want to share my thoughts about going back to the grind.
TLDR;
There is no magic formula or secret trick. In order to become better, nothing beats hard work. No one is going to do it for you.
After some time you will develop a sense / feeling for which classes of Algorithms are viable for which sets of problems. Trust your gut, it will mostly be right.
Timebox solutions
Solving questions can be pretty hard at first, especially when not having been exposed to a variety of different problems and solution approaches.
When starting out, timebox yourself to 15-20 minutes for coming up with a plan / solution. Many problems have multiple solutions. When starting out, come up with a plan and verify that the solution is viable.
If it is, implement it and get it working. Now delete it and implement it again. Repeat this until you understand the approach.
Keep notes
I use Obsidian for my note taking. In there I have a folder called LeetCode. I keep notes for all questions I solve and label them with the difficulty and a “redo” flag.
For all problems, I store the problem statement, solution code and a description in which I explain the solution to myself. Don’t be lazy on that last part, this is the most important one.
Forcing yourself to explain the solution triggers the rubber duck effect and will help you understand and remember it better.
Repetition
On most days, I randomly pick 2-3 problems and just simply redo them. Practice is king and will go long ways.
With enough practice and learning / repeating the optimal solutions to problems, you have no choice but to better understand and remember them.
Algorithms will repeat
The more coding questions you solve, the more often you will remember something similar you’ve done somewhere else.
Most questions are solved using common techniques. This includes dfs and bfs for graph problems (most common asked interview questions), matrix (and array) traversal and manipulation, sorting and dynamic programming (dp).
For example, solve and compare LC-1 and LC-1010. Do you find similarities?
Many times, with practice, you can early identify what solution will be viable just by the feeling you develop for these kinds of problems. Trust your gut instinct and go with it.
I would confidently say that you can solve 80% - 90% of problems with common techniques once you identify what class this problem falls into.
Dynamic Programming sucks
Dynamic Programming problems are notorious for being just a pain. A lot of companies stopped asking these questions. Although I’d still encourage you to learn them, I found that the time required to do so is mostly better invested solving other problems. This, of course, only holds as long as you have relevant other questions on top of the pile.
If not, well… No one’s going to solve the problems for you.
Buy Premium
I know, it costs money. But trust me, just do it. Don’t doubt it, it’s worth it after all.
Alex out