cabin

Source code for personal website
git clone git://git.dimitrijedobrota.com/cabin.git
Log | Files | Refs | README | LICENSE

Leetcode.md (6890B)


0 @title: Leetcode, an honest review
1 @date: 2025-01-01
2 @language: en
3 @categories: general, leetcode
5 # Leetcode an honest review
7 ## Overview
9 My [leetcode journey](https://leetcode.com/u/dimitrijed/) has started on Nov 5, 2022 as a way to prepare for
10 algorithms class. As I've done more and more problems it slowly turned into an
11 obsession. I was doing problem after problem, from many different categories.
12 For the duration of 2023 and 2024, every single day, I've been doing at least
13 one problem - a Daily problem if it hasn't already been solved, or a random
14 problem if it has. Usually, that was all I did, but when I was bored, I
15 would do 5, 10 or even 20 problems.
17 The summary is as follows (at the time of writing):
18 * Streak: 737/789 days
19 * Rank: 3,601/~5mil people
20 * Easy: 350/846 problems
21 * Medium: 968/1775 problems
22 * Hard: 182/785 problems
23 * Total: 1500 problems
24 * Badges: 44
27 ## Routine
29 During the day, when I found the time, I sat down ready to tackle one
30 problem. I would do my best to solve it without looking at hints and solutions.
31 Goal was to find the best possible algorithm, which in practice means beating
32 85% submissions or more. Based on the problem, this would take anywhere between
33 5 and 20 minutes, and then I would try to utilize a hint, in case there was
34 something I'd missed.
36 If that didn't help, I would turn to the official or community solution, in
37 order to understand what I'd missed and how exactly does the algorithm need to
38 work, then I would try to implement it myself, often more clearly and
39 concisely. Even if I've managed to solve a problem in the satisfactory
40 complexity, I would still take a look at the solutions just to see whether
41 there is something worth remembering. I've picked up a lot of great trick
42 this way.
45 ## Learning
47 Because of my competitive programming background from middle school and high
48 school, I was already quite familiar with the format as well as logical
49 thinking, which has kick-started the beginning.
51 At that time, I've been writing a lot of C, but I wanted to get good at C++.
52 I'd seen STL before, but I lacked deep understanding of it all. I've started
53 with some introductory problems, that mostly tested logic, but soon enough I
54 started dabbling with more advanced topics like Trees and Graphs. That is where
55 the real fun began. I was aware of the few algorithms from the class, but when
56 it came time to actually implement them I was thunder struck. It was a crucial
57 step at the time to take a look at other people's solutions and see how exactly
58 are the data structures represented in C++ code, and how to interact with them.
60 As my knowledge of algorithms grew, so did my understanding of C++, although
61 I've spent an additional time learning about it's inner workings. It came to
62 the point where language was not an issue anymore. That's when I've started
63 thinking beyond the problem at hand, and more about the codding style, as
64 well as the best utilization of processor and memory.
67 ## Problems
69 There are many different kinds of problems, regardless of their difficulty:
70 * Brain testers - usually math related and require logical thinking
71 * Strictly math problems - based on advanced math knowledge
72 * Little problems - not necessarily hard, but can be tricky to implement elegantly
73 * Straight foreword problems - one you've seen the underlying idea, they are
74 not that difficult
75 * Problems that require a well-known algorithm in order to be solved. I don't
76 think any mortal can come up with them in any reasonable amount of time.
78 Most of the problems require a specific technique to be solved, such as sliding
79 window, two pointer, binary search... The more problems you do, the easier it
80 will be to spot these patterns quickly, and implement the adequate solution.
81 The issue may arise, when a few of these techniques are required simultaneously.
84 ## Difficulty.
86 Easy problems are easy mainly because of the restrictions. Any valid solution,
87 regardless of the complexity, will work. Most of them are trivial, but there
88 are a few hidden gems that serve as an introduction to a well-known algorithms
89 to be used in harder problems. This is a good reason to look at other solutions
90 even if running time is satisfactory - inefficiency is masked by small constants.
92 Medium problems vary drastically. There are some trivial ones, some that are
93 just tedious to code, some that require solid understanding of common
94 algorithms and data structures, while some require specific algorithm that is
95 worth remembering. Due to the wide array of possibilities, there are some
96 medium problems that I've solved in under a minute, while even after I've done
97 so many of them, from time to time, I come across one that I have no idea where
98 to even start. This is a fact of life, and there is no point in beating your
99 head about it.
101 Hard problems are weird. There are some that require ultra specific algorithms,
102 some that require outstanding out the box thinking, while still being possible
103 to come up with. My favorite ones are those that require perfect
104 understanding of the common algorithms and data structures, then adding some
105 twist to it, whether it's a combination or transformation that is needed in
106 order for it to work. Some are just impossible to understand, even with a
107 solution...
110 ## Advice
112 Doing 1500 problems is really unnecessary if your main focus are interviews.
113 Focusing on [neetcode](https://neetcode.io/) will be enough for most people.
116 There are a few things worth remembering:
118 * Code, Code, Code! Every single solution needs to be actually coded,
119 tested and run. There are no too easy problems. Everything counts.
120 * You need to be aware of your weaknesses, whether it's the understanding
121 of the language that is holding you back, or it's some algorithm or a
122 data structure.
123 * Once you've learned a new concept, you should drill it until it becomes
124 second nature. There should be no rush between problems, unless everything
125 is crystal clear. Otherwise you will waste a lot of time reviewing concepts
126 that should have been mastered a long time ago.
127 * Not everything is in the algorithms and data structures. Clean and concise
128 code also matters a lot
129 * Copying the solution to the paper by hand really helps internalize the ideas.
130 Do this only for a small number of special problems, as not to waste too much
131 time.
134 ## Conclusion
136 I'll be taking a break, possibly forever, form leetcode. It's been fun, but
137 I've passed the point of diminishing returns for where I want to be, so it's
138 better for me to focus my energy elsewhere. The lesions I've learned will
139 continue to serve me in the future, both the algorithms and data structures, as
140 well as the logic and general practice of coding.
142 I haven't given competitions an honest shot, mostly due to the incontinent time
143 at which they are held. Although, they might be a new step forward, to keep me
144 from getting rusty.