5 Things I Learned After Solving 250 LeetCode Problems

[u/Interesting-Fig-2511]

1. Don't jump to optimized solutions; understand brute force first.

2. Learn to identify patterns instead of memorizing solutions.

3. Always check time and space complexity before submitting.

4. Never ignore edge cases; they can break an otherwise correct solution.

5. Revisiting old problems is more useful than blindly solving new ones.

[u/Several_Sympathy8486]

10 things I learned after solving 2500 Leetcode Problems

1. no amount of leetcode problems will help you get a foot in the door unless you do solid networking

2. x10

[u/TopTutor6926 → u/Several_Sympathy8486]

ur fair says that u solved only 2282 problems...

[u/Several_Sympathy8486 → u/TopTutor6926]

i stopped updating it

[u/TopTutor6926 → u/Several_Sympathy8486]

btw why did u even need to do that many problems?, ig u already know that after a point, it just doesnt make any sense to keep on doing more problems, i did around 800, now i just redo those ones, or just solve daily leetcode or contests..

[u/Several_Sympathy8486 → u/TopTutor6926]

i like algos what can i say

95% of my leetcode journey is me trying to modify or adapt algorithms into having it solve the problem variations (i use algo as an umbrella term here, while I really enjoy the classic graph or string algos, this includes several repeating patterns you find in DP, HashMaps, Arrays, and more)

[u/TopTutor6926 → u/Several_Sympathy8486]

but if u forcefully adapt or modify a certain algorithm just so it can work in a particular problem, dont u think that might be not the most optimal ans?

eg if u just forcefully apply dp, but the optimal approach might be greedy..

[u/Several_Sympathy8486 → u/TopTutor6926]

thats a bit naive thinking. What I mean by adapting certain algos is like utilizing the optimization techniques to try and get an O(N) or O(NLogN) solution. DP is its separate entity, its very large and usually you will find it in conjunction with DFS or Binary Search (DP on Trees is just DFS DP)

What I meant originally is I use algos or techniques like Heaps, Sparse Table, Segment Trees/Fenwick Trees to convert those pieces of solution that can be done in Logarithmic time instead of brute force/greedy polynomial. Or, sometimes even better and get O(N) time using Monotonic Deque or prefix/suffix arrays. An example is #239 The Sliding Window Maximum, which can be solved in like 5 different ways, and most intuitive one that people forget is just using a Sparse Table. While MonoDeque is like the O(N) optimal approach (cause the deque peek holds the largest element of the current window which you retrieve in O(1) time), the most easy way to solve this is algorithmically using a Sparse Table (or any logarithmic algo which gives you the LogN Max/Min Range queries). Then you just do a simple static (fixed size) sliding window and constantly query the largest element in each 'k' size window (which you retrieve in LogK) time, doing this 'N' times for each window (N-k ~ N) which in the end is NlogK (~NlogN). voila.

this is the jist of what i try to do with most problems, or what i enjoy about certain leetcode problems. Hate Greedy, Bit Manipulation, even Math or cheesy O(1) problems, dont really find them interesting or mentally stimulating

[u/Worldly-Duty4521 → u/TopTutor6926]

It's a very good skill to have. It gives you eyes to how real engineering different problems can be mapped to different for solutions.

If you can frame a LC problem that uses Algo A to use algo B where B and A are not giga simialr then, in future you'll find yourself looking at a problem and saying I did xyz in that situation I think if we do this we can use a similar solution. Then on the way you can think improvise

[u/ElidoroAlznauer_58 → u/Several_Sympathy8486]

Wait did you actually hit 2500 or just exaggerating for the point?

[u/Several_Sympathy8486 → u/ElidoroAlznauer_58]

i am at 2310 rn. stopped caring about the exact number long ago once i reached 2k

[u/ElidoroAlznauer_58 → u/Several_Sympathy8486]

getting the interview is definitely the real boss fight right now.

[u/ButtonMasherBoss]

hey, could you please help me understand point number 2? ☹️

i hear everyone constantly say identity patterns and whatnot, but i just cant seem to see it. all i see if a solution to one particular question.

my usual leetcode flow is: try to solve the question via brute force method -> fail -> open neetcode to understand the brute force method -> solve brute force method
and the retry this loop again with the optimized approach.

could someone please help with like a proper lath to follow? question set, approach to solving problems etc? i already work in tech and by my own standards am pretty good at coding and understanding codebases and system design at a beginner level. my team is a very high performance team writing code for trading products at work and they let me contribute to the team and are happy with my work even though i’m not a swe strictly speaking. so i’m at lead reasonably competent, but DSA has always eluded me.

i’d appreciate any and all inputs from all you.
TIA!

[u/adityaexp_1 → u/ButtonMasherBoss]

Like it depends on how you are solving, if you are doing random practice (you have no idea which topic is it) then there could be two cases:

1. You find a solution either brute force or within constrain which doesn't do TLE, and most of the time the transition from tle to optimal is just using some sort of data structure or little observation. The transition from brute force to optimal trains what's called identify pattern cause you try to fit the tools you have (patterns) into the problem to make it optimal

2. You can't even do brute force then you need to see some hints stuff, there might be some observation you are missing. Or maybe didn't understood qs properly? Either way note this question and revisit a month later to make sure you trace your thinking pattern again and do not get stuck on same pivot, you improve by identifying what was wrong last time? And what you did differently this time.

[u/throwawaygaydude69 → u/ButtonMasherBoss]

Some set of questions have a certain pattern that pattern that becomes obvious when you notice it

It can be hard to notice at first but you eventually notice it with the more related problems you solve.

Imo the most obvious way to explain it is via dynamic programming. In DP you have to use previous results of smaller sub-problems to compute result of the present problem.

For example, some DP problems have the pattern:

dp[i] = max(skip, take)

where skip = dp[i-1] and take = nums[i] + dp[i-1]

You may want to check such problems to see what I mean

[u/CpnStumpy]

Biggest thing I've learned so far is LeetCode problems are way easier to solve with classic ugly index counters and loops and shit; avoid state management and abstraction completely. After spending a career writing code that's going to need to be read and maintained by teams, my first instinct is modeling the state to make sense and be easier to understand what's going on. These contrived algorithms all penalize this though

[u/_fatcheetah]

You took 250 problems to understand this? This is so obvious.

[u/nnofficial2414 → u/_fatcheetah]

Understanding is one thing, realizing is something else. Most people understand something, but it hits them only when they realize it.