commit faeee32b8d35d57cfff7d597425b312e81d9010a
parent 45f3fa50b1bdede4c7c7e4ac8fa77829af7bca27
Author: Dimitrije Dobrota <mail@dimitrijedobrota.com>
Date: Wed, 1 Jan 2025 22:38:12 +0100
Leetcode article
Diffstat:
| A | blog/Leetcode.md | | | 145 | +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
1 file changed, 145 insertions(+), 0 deletions(-)
diff --git a/blog/Leetcode.md b/blog/Leetcode.md
@@ -0,0 +1,145 @@
+@title: Leetcode, an honest review
+@date: 2025-01-01
+@language: en
+@categories: general, leetcode
+
+# Leetcode an honest review
+
+## Overview
+
+My [leetcode journey](https://leetcode.com/u/dimitrijed/) has started on Nov 5, 2022 as a way to prepare for
+algorithms class. As I've done more and more problems it slowly turned into an
+obsession. I was doing problem after problem, from many different categories.
+For the duration of 2023 and 2024, every single day, I've been doing at least
+one problem - a Daily problem if it hasn't already been solved, or a random
+problem if it has. Usually, that was all I did, but when I was bored, I
+would do 5, 10 or even 20 problems.
+
+The summary is as follows (at the time of writing):
+* Streak: 737/789 days
+* Rank: 3,601/~5mil people
+* Easy: 350/846 problems
+* Medium: 968/1775 problems
+* Hard: 182/785 problems
+* Total: 1500 problems
+* Badges: 44
+
+
+## Routine
+
+During the day, when I found the time, I sat down ready to tackle one
+problem. I would do my best to solve it without looking at hints and solutions.
+Goal was to find the best possible algorithm, which in practice means beating
+85% submissions or more. Based on the problem, this would take anywhere between
+5 and 20 minutes, and then I would try to utilize a hint, in case there was
+something I'd missed.
+
+If that didn't help, I would turn to the official or community solution, in
+order to understand what I'd missed and how exactly does the algorithm need to
+work, then I would try to implement it myself, often more clearly and
+concisely. Even if I've managed to solve a problem in the satisfactory
+complexity, I would still take a look at the solutions just to see whether
+there is something worth remembering. I've picked up a lot of great trick
+this way.
+
+
+## Learning
+
+Because of my competitive programming background from middle school and high
+school, I was already quite familiar with the format as well as logical
+thinking, which has kick-started the beginning.
+
+At that time, I've been writing a lot of C, but I wanted to get good at C++.
+I'd seen STL before, but I lacked deep understanding of it all. I've started
+with some introductory problems, that mostly tested logic, but soon enough I
+started dabbling with more advanced topics like Trees and Graphs. That is where
+the real fun began. I was aware of the few algorithms from the class, but when
+it came time to actually implement them I was thunder struck. It was a crucial
+step at the time to take a look at other people's solutions and see how exactly
+are the data structures represented in C++ code, and how to interact with them.
+
+As my knowledge of algorithms grew, so did my understanding of C++, although
+I've spent an additional time learning about it's inner workings. It came to
+the point where language was not an issue anymore. That's when I've started
+thinking beyond the problem at hand, and more about the codding style, as
+well as the best utilization of processor and memory.
+
+
+## Problems
+
+There are many different kinds of problems, regardless of their difficulty:
+* Brain testers - usually math related and require logical thinking
+* Strictly math problems - based on advanced math knowledge
+* Little problems - not necessarily hard, but can be tricky to implement elegantly
+* Straight foreword problems - one you've seen the underlying idea, they are
+ not that difficult
+* Problems that require a well-known algorithm in order to be solved. I don't
+ think any mortal can come up with them in any reasonable amount of time.
+
+Most of the problems require a specific technique to be solved, such as sliding
+window, two pointer, binary search... The more problems you do, the easier it
+will be to spot these patterns quickly, and implement the adequate solution.
+The issue may arise, when a few of these techniques are required simultaneously.
+
+
+## Difficulty.
+
+Easy problems are easy mainly because of the restrictions. Any valid solution,
+regardless of the complexity, will work. Most of them are trivial, but there
+are a few hidden gems that serve as an introduction to a well-known algorithms
+to be used in harder problems. This is a good reason to look at other solutions
+even if running time is satisfactory - inefficiency is masked by small constants.
+
+Medium problems vary drastically. There are some trivial ones, some that are
+just tedious to code, some that require solid understanding of common
+algorithms and data structures, while some require specific algorithm that is
+worth remembering. Due to the wide array of possibilities, there are some
+medium problems that I've solved in under a minute, while even after I've done
+so many of them, from time to time, I come across one that I have no idea where
+to even start. This is a fact of life, and there is no point in beating your
+head about it.
+
+Hard problems are weird. There are some that require ultra specific algorithms,
+some that require outstanding out the box thinking, while still being possible
+to come up with. My favorite ones are those that require perfect
+understanding of the common algorithms and data structures, then adding some
+twist to it, whether it's a combination or transformation that is needed in
+order for it to work. Some are just impossible to understand, even with a
+solution...
+
+
+## Advice
+
+Doing 1500 problems is really unnecessary if your main focus are interviews.
+Focusing on [neetcode](https://neetcode.io/) will be enough for most people.
+
+
+There are a few things worth remembering:
+
+* Code, Code, Code! Every single solution needs to be actually coded,
+ tested and run. There are no too easy problems. Everything counts.
+* You need to be aware of your weaknesses, whether it's the understanding
+ of the language that is holding you back, or it's some algorithm or a
+ data structure.
+* Once you've learned a new concept, you should drill it until it becomes
+ second nature. There should be no rush between problems, unless everything
+ is crystal clear. Otherwise you will waste a lot of time reviewing concepts
+ that should have been mastered a long time ago.
+* Not everything is in the algorithms and data structures. Clean and concise
+ code also matters a lot
+* Copying the solution to the paper by hand really helps internalize the ideas.
+ Do this only for a small number of special problems, as not to waste too much
+ time.
+
+
+## Conclusion
+
+I'll be taking a break, possibly forever, form leetcode. It's been fun, but
+I've passed the point of diminishing returns for where I want to be, so it's
+better for me to focus my energy elsewhere. The lesions I've learned will
+continue to serve me in the future, both the algorithms and data structures, as
+well as the logic and general practice of coding.
+
+I haven't given competitions an honest shot, mostly due to the incontinent time
+at which they are held. Although, they might be a new step forward, to keep me
+from getting rusty.
