Everything written here is strictly reflective of my opinion and has not been influenced by any external party. The concepts I refer to are things that I have figured out for myself and may contradict or challenge the things that you have experienced so take everything with a grain of salt.

I've always had a strange relationship with Leetcode. For a good portion of my computer science life, I've avoided anything that had to do with Leetcode including technical interviews and screening. This was for a few factors:

• Fear of testing and defining my own abilities
• Leetcode is tedious and hard
• Preference to work on personal projects

But after a long time of pondering and seeing the mass of people on CS Career Questions encouraging that I at least try, I eventually put my head down and did the work and this article is the result of studying for a month (14 days of solving Leetcode problems).

The simple definition of Leetcode is that it is a platform that allows coders to solve coding problems. This by itself doesn't particularly mean much but with the advent of MANGA (Meta, Amazon, Netflix, Google and Apple), previously FAANG, and big technology companies pushing for Leetcode-style questions in their interviews, Leetcode has become synonymous with technical Interviewing. For one to be successful in pursuing the top Software Engineering jobs, one must be literate in Leetcode.

That being said, this was not the main reason why I chose to start Leetcoding, rather I felt that I had a massive deficiency in my understanding of practical applications of Data Structures and Algorithms. There really is only so much you can do by reading and learning theory and so I went ahead and logged into an account I created a long time ago when a previous motivation tried to kick me into the rabbit hole.

Below are the resources that I have used and will refer to throughout this post.

1. Leetcode Patterns (seanprashad.com)
2. NeetCode.io
3. CRACKING the CODING INTERVIEW

Assuming that you indeed do have a solid understanding of Computer Science fundamentals and have coded before, there are a few steps I would recommend before diving into the deep end.

You can only be as good as your aspirations are. Are you looking to interview for MANGA or big tech? Are you looking to learn more about your language and about coding? Are you trying to get into competitive programming? Or is it for a course that you are taking at University that is known to be difficult?

You need to understand this before even touching Leetcode as your approach and attitude will greatly affect the way the outcome may be.

You don't have to be interviewing to use this book and appreciate the value it brings.

Cracking the Coding Interview by Gayle Laakmann McDowell is an excellent book that teaches about the various aspects of technical interviews. Before diving into Leetcode, I had read the vast majority of this book (but didn't attempt the problems).

I would suggest doing the same and tackling some questions that are available in the book. This book remained an excellent reference throughout my small grind and I referred back to it for every other question.

Much like a math test there really are only so many ways to assess the same set of skills. The more questions you do, the more evident it becomes that there exists "patterns" within the questions you do and thus the variations become more trivial.

In my experience there are a few patterns (not all but the ones I found to be most occurring) that exist within Leetcode and are all explored in Sean Prashad's "Leetcode Patterns" :

• Two Pointer Techniques
• Sliding Window
• Dynamic Programming and Memoization
• Intervals
• Search (BFS, DFS)
• Backtracking

To master a math test means to master the textbook. To master Leetcode means to master its patterns.

Everyone approaches Leetcode differently and should be doing so. Everyone learns differently and the way that I have might not be so suited to you. I knew what I wanted to achieve so I devised a very specific strategy to help get myself to do Leetcode effectively and achieve my goals.

Leetcode is most effective when it is undertaken with an intent to understand not to memorize. Sure some people may prefer to remember hundreds of Leetcode questions in preparation for an interview but I didn't really set out to do that. I wanted to deepen my understanding of the code I write and memorization wasn't an option in that case.

I work full time. There are definitely stories where people have Leetcoded full time but I couldn't afford to do so. The majority of the time I had to Leetcode was after my 9-5 until I went to sleep. Note that I never said when I slept so there were definitely some very early mornings late nights.

I believe that those who are undertaking Leetcode without understanding core CS fundamentals are doing it wrong. You must establish these understandings before diving into the rabbit hole that is Leetcode. Leetcode is not a platform to learn how to code, it really never was and probably never will be.

For those who want to learn more about coding before trying Leetcode, try to undertake a course to learn a language, or start a personal project and get comfortable with coding before trying Leetcode.

"Leetcode should be the whetstone for your coding skills" - me.

Many people think that grinding Leetcode means seeing and completing as many problems as possible in the shortest amount of time. This thinking is mostly synonymous with grinding and studying for interviews but for me, this approach simply doesn't work.

I think that for someone to be most effective on Leetcode, one must pick the right questions. This meaning really varies from individual to individual but for me, I had a criteria in my mind that a question had to pass for me to attempt it.

1. Is the problem actually interesting to me?
2. Is it one that is unique compared to what I have already attempted?
3. Does it seem like a challenging question that I can't just solve in 5 minutes?
4. Does it test something that I want or have to learn?

It might seem pretty logical but asking these questions when reading a Leetcode question filtered a lot of tedious, repetitive and boring questions that I had no interest in solving and thus, ones that wouldn't teach me much over what I already knew.

The way I actually did Leetcode was very structural.

1. Select a problem that I found interesting (refer to "Picking the right questions")
   1. If you don't want to pick or think you are bad at picking, use neetcode.io
2. try to solve it within 30 minutes
   1. If solved, optimize using solutions and analyse time and space complexity
   2. If unsolved then throw new Error('Unable to solve in 30 minutes');
3. catch your failure to solve it optimally and look at solutions
4. Study the solutions (both optimal and non-optimal) and why they work
   1. Understand what pattern is tested and quickly explain what the solution does and why it works
   2. for every line of the code and try to understand and explain out loud what it does
5. while the question is unsolved or the solution is not optimal
   1. Attempt to write a solution or improve the existing solution
   2. Analyse time and space complexity
   3. Propose good test cases and edge cases
   4. Test your code
   5. Submit
6. (Optional) Comment code for future reference
7. Revise and explain the solution out loud to yourself or someone else.

This is how I did Leetcode. It might not be for you but I found it to be very fluid and good for those who need to hustle to get prepared for Interviews and the like. From here, you would begin with Leetcode easy and increase in difficulty as they got easier. To clarify some details, I'll start exploring some interesting things that I've identified throughout this short process.

I never expected to complete questions that I saw for the first time within 30 minutes. In fact, doing so was rare and if It happened consistently, then the questions I was doing were too easy. It is supposed to be hard and the intention is to continually push your own standards higher and learn under high pressure.

Sometimes you are not able to get the optimal answer and that's okay! The idea is for you to understand and learn how to tackle these problems so achieving a non-optimal answer is fine. Though I had a rule in place that I would not leave a problem before I got the optimal solution so try to use your understanding of the non-optimal answer as a ship to take you to the optimal.

This is a massive topic that I won't dive into. To get good at these questions, you need to understand and be able to verbalize test cases and the cases you need to cover. Cracking the Coding Interview has a great section on testing.

After doing quite a few questions, one stood out the most and that was Leetcode #200, Number of Islands.

This problem is a culmination of everything I wanted Leetcode to be for me. It was a very smart and practical problem that fell into the search category of questions. It stood out to me for three reasons.

Not to spoil the solution but the optimal approach to this question is very, very interesting and you would not be able to 'see' the answer by just knowing more algorithms but rather by understanding them and what these algorithms did.

This can really apply to all questions on Leetcode but especially this one. You can look and easily count the islands but to tell code to do that? Not as easy.

All in all, it's a witty question that I recommend anyone try to solve. You may be able to see the solution quickly or go straight to the answers but I would highly recommend an honest challenge at solving it!

A practical question like this always picks at my curiosity. To a certain extent, you can see how this Leetcode problem could be reflected in real coding practice. Just to prove a point, we can reword the question to something like you've built some program that needs to identify the number of mugs in an image represented by a 2d array. The solution to "Number of Islands" would fit snugly as a solution to that problem and this is what made the question even more interesting than it already was.

Some other questions I found very interesting were the classic Two-Sum and its follow-up 3Sum, Jump Game, Pow(x, n) and Unique Paths.

This single blog post is not enough for me to thoroughly explore the rabbit hole that is technical Interviewing and Leetcode.

For many people, Leetcode is a means to an end and that to get their dream job they just need to grind Leetcode problems. I think this shouldn't have to be the case.

Above all, Leetcode showed me a lot of the attributes that I find to be vital in any trade outside of your ability to simply solve a problem such as your thought process, communication skills and attitude.

I think this is for one vital reason: when companies give Leetcode problems, they are not only assessing you on your ability to get the optimal answer but all of those traits I mentioned and more. This idea (and the breakdown of the intention of the technical interview process) is explored extremely insightfully in a video I stumbled upon by A Life Engineered (below).

To be honest, I believe that it is not a good mindset to think that you will pass technical interviews by just solving problems that were similar to what you have seen before because your assessment is going to be much deeper than that.

To be deemed a good problem solver, you have to be able to show that you are a good problem solver and Leetcode is a great medium for enabling that to happen but isn't the only one available.

Then again, this is just me spewing my own opinions and so I highly recommend you go out, do your own research and formulate your own approach to technical Interviews.

In the month that I was studying, including the two weeks that I did Leetcode on and off, I completed 118 questions. This might appear to be a lot but to be honest, is only a chip into how many questions are available on Leetcode.

All in all, my Leetcode experience broke a lot of the earlier assumptions I had about the platform. I started to believe that Leetcode was genuinely a good resource and I think above all, made me a better software engineer and programmer.

It made me apply concepts that I had only studied and challenged the understanding that I had as a Software Engineer. I think a lot is lost when people say just "grind Leetcode" but I genuinely think that if you approach it in a way that resembles a willingness to learn more, you will come out the other side a more resilient and knowledgeable developer.

I know because that's what Leetcode did for me.