Seriously, LeetCode in 2026? Everyone is saying HackerRank just killed LeetCode, and yet here I am, still trying to debug my way through LeetCode problems.
Well, I always wanted to smash LeetCode like a absolute pro, but I thought I just didn’t have that "push" in me. But after reading Hadil’s article on her LeetCode journey, the passion finally ignited. I started solving problems on my own, but honestly, it felt like total deja vu. I always start LeetCode thinking “this is easy,” but somewhere along the line of medium and hard questions, I get completely lost.
I wanted to share my honest, unfiltered journey of trying to master LeetCode, hitting massive roadblocks, and finally finding the spark to face my coding fears. It hasn't been a straight line, but if you're trying to find your footing in tech right now, I hope my story makes you feel a little less alone in the grind.
The Backstory: That "We Need to Grind DSA" Conversation
The story goes back to 2024. I was at my job, talking to a few developers about getting a new role in tech. We all agreed on the golden rule: we need to get better at DSA and solve LeetCode problems.
The fire burnt out quickly after it ignited. I had the passion to start things, so I jumped right into solving questions, only to hit an immediate dead end. Every single question felt brand new and completely alien. It was like the problem was speaking the answer in Parseltongue, and here I am, sitting like Harry Potter's cousin Dudley, just wondering: “What is he saying?”
I tried a few questions, solved them, and wanted to keep up a streak. But I couldn’t sometimes due to time constraints, other times because the logic just wouldn’t come. Now, looking for new jobs, I knew I wanted to solve LeetCode problems, but I carried this deep fear inside me. I waited for a spark.
Then I recently came across Hadil’s article. I was amazed and inspired by her dedication and hard work. Since I am no longer that same 2024 me, I felt it was finally time to give it a fresh start.
The Mental Battle: Convincing Myself to Hit 'Start' Again
The journey of a thousand miles begins with a single step, right?
No. The journey actually begins with convincing myself to make a fresh start while fighting unknown fears. What if I can’t produce good code? What if the time complexity is way too much? What if I just write brute-force code and can’t solve other questions? What if I fail the interviews?
How do you deal with these questions? By making your fundamentals strong. Giving it a fresh start meant learning from scratch, revising everything, and actually trying out the code.
I am a big believer in the Pareto Principle (the 80/20 rule), so I knew I had to master the core fundamentals that count majorly toward solving questions. I write my code in C++, so for solving LeetCode problems, you must know STL (Standard Template Library). It always felt like the missing tool back when I was coding in C.
Moving Beyond Loops: Spotting the Patterns
Now that I have learned the basics and STL, I should just start grinding questions and participating in weekly challenges, right?
No. The real next step is learning the patterns that help you identify how to approach a LeetCode problem. For example:
- Two Pointer Approach: The two pointers advance towards opposite ends of the data structure with a fixed increment.
- Fast and Slow Pointers: This technique involves using two pointers moving at different speeds—a slow pointer moving one step at a time, and a fast pointer moving two steps at a time.
- Sliding Window: A window is used to traverse an array. To keep it moving, the previous element is removed and the next element is added. The size depends entirely on the problem.
Learning these and many more like these helps you remember the proper patterns and data structures to use. But after learning all this, did I finally start solving?
Reality Check: Over-Engineering vs. Over-Simplifying
I thought I was fully prepared for everything. I was ready to solve problems and become a Grandmaster. But the path isn’t as easy as it looks.
There were many problems where I over-engineered the answers showing off my knowledge of complex data structures when the solution could have simply been solved using a basic array. Other times, I produced under-engineered answers, where I didn’t think about the results and just coded blindly.
But with each LeetCode problem I tackle, I am keeping myself open-minded. I am learning from my mistakes so I can code better on the next question.
Real Talk: My Playbook for Surviving LeetCode
- Don’t start coding right away. Take your time to think through the solution and time complexities. Think in terms of brute force, better, and optimal solutions first.
- Read your code before submitting. Check for basic mistakes, like a missing semicolon or silly syntax errors.
- Think about the edge cases. Sometimes LeetCode examples don’t provide the edge cases, and you will hit a wall during submission if you don't think of them early.
- Use pen and paper first. Understand the problem on paper, solve it there, and verify your logic before you type a single line.
- Think in terms of time complexity. Understand the comparisons and know exactly when and why your code should be O(n) versus O(log n).
- Document your journey. You won’t recall what solution you wrote 2 months ago. If you document it, you can easily recall and revise it later.
To be completely honest, I am still figuring it out day by day, but shifting from mindless grinding to actually understanding the patterns has changed everything for me. It’s a process, and I’m finally okay with making mistakes as long as I’m moving forward.
If you are currently on your own LeetCode journey, or if you have some solid tips that helped you crack the DSA code, I would love to learn from you in the comments! What is that one favorite question the one that made you genuinely happy after you finally saw that green "Accepted" screen?
Let's share our learnings and get better together. Feel free to connect with me on LinkedIn to discuss more about LeetCode!
Top comments (31)
I use LeetCode just to practice my programming skills on learning a new language. It's also a good idea to build projects while learning a new language.
Feel free to follow me Konark! leetcode.com/u/FrancisTRdev/
Wow, so cool. What's your current favorite language?
Sure, I will follow you. Senior developer hahaha.
Python is the way to go, but learning Ruby and slowly felling in love with it. wbu?
Wow python and ruby that seems nice. I'm more of a cpp guy but I wanna get my hands on Go. I have used it learn the basic but apart from all the languages it stick with me and got me an urge to explore it.
I can definitely relate to this. Every time I think I'll finally get consistent with LeetCode, life gets in the way or I end up stuck on a problem 😅
I like your approach of focusing on patterns first instead of just grinding questions. All the best with the journey!
same here, I finally decided to try again yesterday, installed a pretty cool app and ofc that ended with hyperventilation, overthinking, and self criticism . If I miss one thing, I end up downloading 20 maths books I will never get to... Nightmare
Haha, I can relate 😅 It's so easy to fall into the "I need to learn everything first" mindset instead of just solving the next problem.
Hopefully this time we both manage to stay consistent. Good luck 💪
"I need to learn everything first" mindset - our worst enemy xD. Good luck as well, hope we both stick to it. I feel like I will have to try pen and paper method to last this time, and limit it to 1h a day max.
All the best to you both. I know natasha leetcode can become hard at times but yeah I know you have the ability to solve everything. You got this. This time you will be consistent and a leetcode grandmaster.
You and @hemapriya_kanagala can be accountability partners and help each other accountable for solving problems. All the best to you both. If there's anyway I could help feel free to reach out.
Thank you so much, that would really be amazing. Sure, let's check in next week and see where we are at :)
ofc I end up here leetcode4kids.com/parents LOL
Wow, sounds good. You are planning for yourself and your kids.😆
How's the site? It teaches awesome stuff? I didn't knew about this. Leetcode for kids damn am I too late or too old 😅?
I saw a tons of video before getting started and everyone suggested patterns. So, this time I tried them and learned a few of them and that helped me in solving problems so why not share it with others. You can also try patterns and maybe they might help you be consistent.
Thank you so Hemapriya for your message. All the best to you as well. I know this time you will perform awesomely. Feel free to reach out to discuss leetcode problems or solutions. Maybe, I could help you a little.
I really liked that you focused on patterns instead of memorization. I think that's where a lot of people get stuck, they try to remember hundreds of solutions instead of understanding why a certain approach works.
Something I've also realized is that LeetCode and building projects develop very different muscles. Building projects teaches you how to design systems and ship things, while DSA teaches you how to reason under constraints. Neither really replaces the other, especially for interviews.
The part about over-engineering also made me smile because I've definitely been guilty of trying to use a fancy data structure when a simple array would've done the job. 😅
Wishing you the best on the journey! Looking forward to seeing the progress updates.
Thank you so much Aryan. I'm glad my article resonated with you. Yeah both of them have their own advantages like you mentioned. So, they both are required to learn these lessons and also DSA helps you notice patterns that could be useful in your development journey. You start observing patterns, issues, edge-cases and many more subtle things that otherwise are missed.
Thank you for the wishes. All the best on your journey as well. Hope to see you grow to 100k asap.
Exactly! That's something I didn't appreciate until I started solving more problems myself. The biggest takeaway isn't memorizing solutions, it's training yourself to notice patterns and think through edge cases before they become production bugs.
Thanks for the kind wishes, Konark! Looking forward to seeing both of us keep growing. 😄
I relate to this a lot. The hardest part isn't solving the problems, it's starting again after losing momentum. Learning patterns instead of memorizing solutions made a much bigger difference for me too. Good luck with your journey, and I hope you stick with documenting your progress. Looking forward to seeing your "Accepted" streak grow. 💪
Thank you so much for your kind words. I'm glad you found it relatable.
Patterns do help if you know where to find and apply them. Thank you so much and you too have an awesome journey. Sure, I will try my best though I'm afraid of losing it rn but even if I lose it I will continue to solve leetcode problems and become a problem solver.
Sliding window is really just the two pointer idea wearing a different hat, and once that clicked for me a whole pile of "hard" problems stopped feeling like separate tricks. Your definition of two pointers moving toward opposite ends covers one flavor, but the same technique also shows up with both pointers going the same direction at different speeds, which is exactly what sliding window is doing under the hood. Treating them as one family instead of three names is probably the single thing that shrinks the pattern list the most. The pen and paper rule in your playbook is underrated too, that's where most of my wrong approaches die before I waste time typing them out.
Yes, exactly they might be same under the hood. Thanks for pointing them out. I was the eager one before not solving the questions on pen and paper. Just reading and solving them asap that resulted me in not understanding problems or not having clear solutions so this time I have started with understanding the problem first using pen and paper and then coding them. This has resulted me in understanding and finding patterns or mathematical solution faster.
Great perspective. The biggest shift is moving from memorizing solutions to recognizing patterns. Once you understand techniques like sliding windows, two pointers, and graph traversal, new problems become much easier to approach.
I'm glad you think this is a great perspective. After basics patterns are a must and every should know it. The ability to use these comes with more questions you solve.
One thing that quietly wrecks pattern-based prep: you learn to recognize "this is a sliding window problem" but never build the muscle to notice when a problem looks like a known pattern and isn't. The trap in your playbook step 1 — think brute/better/optimal — is that once you've memorized 15 patterns, your brain jumps straight to "which bucket does this fit" instead of actually reasoning about the constraints. That's how people who've done 500 problems still freeze on a slightly-twisted medium in an interview.
Small fix that helped a lot of people I've talked to: before you match a pattern, write down the invariant you're maintaining, not the technique. For sliding window it's "everything inside the window satisfies X." If you can't state the invariant in one sentence, you don't understand the problem yet — and that's independent of whether you've seen the pattern. It also directly kills your over/under-engineering problem, because the invariant tells you exactly how much machinery you need and no more.
One correction while I'm here: your two-pointer description says the pointers "advance towards opposite ends with a fixed increment" — that's actually the converging variant (start at both ends, move inward). Fixed-increment same-direction is a different flavor. Worth getting straight since mislabeling the variant is exactly how you reach for the wrong one under pressure.
Thank you so much for this pattern based problem. The problem that you have mentioned is a real problem, thank you for sharing your perspective on it.
The small fix that you have mentioned is a big savior. I understood it and would keep it in mind the next time I solve problems. Thanks for the help for the over/under-engineering problem.
Got it. That must have been my mistake of learning the two-pointer approach. Thanks for clarifying and correcting me. I'll keep this in mind and correct my explanation.
Thank you for correcting and giving me feedback on my way of learning. I will surely use your provided method and improve solving the problems.
No problem at all. I'm glad I could help!!
The phase where you read hadil's article and decided to take action is truly the turning point
Most people get inspired and do nothing , but you took action , which eventually gave the results You were looking for
Also I find Pareto principle very effective as you mentioned.
Thanks for sharing the playbook
I haven't still got the results but yes the practice have made it easy for me to solve atleast the easy problems on LeetCode. I'm still learning and getting better everyday.
Thank you so much for your words. I hope you also grind and shine.😊
Really enjoyed reading this. The shift from "solving more problems" to "understanding patterns" is something many developers realize only after struggling for a while. Thanks for sharing your honest journey—it was both relatable and motivating
Thank you for such a nice comment. I'm really happy to see that you find it relatable and motivating. Keep growing and shine even brighter than the brightest star.
Which is better: building and shipping, or wasting a bunch of time on "LeetCode"? That's a no-brainer.