I recently started applying to Big Tech companies, and as a result, I ended up solving a lot of LeetCode problems (284 problems at the time of writing this blog post). During the preparation process, it became clear to me why so many developers argue about the broken state of the tech interviewing process. Solving LeetCode problems takes a significant amount of time and energy that could otherwise be spent on building projects. However, I believe that the main issue lies not with the tech interviews themselves, but rather with the preparation process.

You have probably already chosen a list of LeetCode problems that you need to solve. If you haven’t, fortunately, there are good lists available online, such as the Blind 75 or Neetcode 150. Each list usually covers multiple topics, including arrays, string manipulation, hashmaps, backtracking, dynamic programming, graph algorithms, etc. So, you start solving these problems one by one. If you have a good understanding of each of these topics, solving LeetCode problems becomes almost a mechanical process of sharpening your skills, becoming faster, and getting more accustomed to the coding interview process in general. However, if you lack a solid understanding of any of these areas, that’s where the problem arises.

Let’s say you struggle with backtracking algorithms. You have never implemented one before, and you are not sure how they work in general. In that case, there are multiple strategies you can follow:

  • Spend hours trying to solve the problem by yourself.
  • Look up the solution on LeetCode.
  • Find a step-by-step guide on solving the problem (e.g., the Neetcode YouTube channel).

The first approach is not ideal, especially if you have an ego like myself (I’m working on it). You can spend a lot of hours trying hard, but if you are not familiar with the concepts, those hours will likely be wasted. The second and third approaches are much better. You read or watch the solution, understanding the thought process behind it, and then try to replicate it yourself. However, the problem with this approach is that it’s still just a single problem out of the 75 or 150 (or however many problems you plan to solve), and you treat it as such. In my experience, this approach does not allow you to fully understand the concept and build a long-term memory of it.

So, what can we do better to fully grasp the concept? I am a strong advocate of the “learning-by-doing” technique, and I suggest utilizing it here. The idea is to build a small or medium-sized project in your programming language of choice where a certain concept is applied. For example, if we are talking about backtracking algorithms, you can build a fully functional Sudoku game.

Why is this approach better?

  • You can see how the concept you are exploring can be applied to solve a real problem.
  • Spending a significant amount of time on a single LeetCode problem can be really tedious. In contrast, building a project should give you much more motivation to stay focused. And it’s completely okay to spend multiple days or weeks working on it.
  • You are much more likely to return to your project later to polish things than returning to your solved LeetCode problems.
  • It should be enough to build a single project for each topic to gain an understanding. After that, you can return to solving LeetCode problems in that topic, and it should be much easier and more fun now.