Let me be honest with you.
Four months ago, I was that person who Googled "difference between array and list" at 2 AM. I'd panic every time someone mentioned Big O notation. And don't even get me started on dynamic programming (I thought it was some fancy way of writing really flexible code).
Fast forward to today? I just accepted an offer from one of Vietnam's top tech companies. Not because I'm naturally brilliant (trust me, I'm not). But because I stumbled upon a roadmap that actually worked.
This is my story. The messy, caffeinated, sometimes-wanted-to-cry journey of conquering LeetCode. And if I can do it, I promise you can too.
The Wake-Up Call
Picture this: I'm sitting in my first technical interview for a junior developer position. The interviewer smiles and says, "Let's start with something easy. Can you reverse a linked list?"
Easy? EASY?!
I froze. My mind went blank. I think I mumbled something about using a for loop (it made zero sense). That 45-minute interview felt like 45 hours of public humiliation.
The rejection email arrived two days later. But honestly? I knew I'd bombed it the moment I left that Zoom call.
That night, I did what any self-respecting millennial would do: I rage-googled "how to not suck at coding interviews." And that's when I discovered LeetCode.
Why LeetCode? (And Why You Can't Just Wing It)
Here's the brutal truth about landing a job at Google, Meta, Amazon, or even top Vietnamese companies like VNG, Shopee, HBLAB and MoMo: they all use the same playbook.
They test you on Data Structures and Algorithms (DSA). Not because they're sadists (okay, maybe a little). But because DSA problems reveal how you think, how you handle pressure, and whether you can optimize solutions.
Here's why LeetCode became my secret weapon:
It's the Industry Standard
According to research from Hired.com, over 85% of FAANG companies include algorithm challenges in their technical screens. LeetCode problems have become the universal language of tech interviews.
If you can crush LeetCode mediums, you can handle most real interviews. It's like training for a marathon by actually... running marathons.
It's Basically a Giant Cheat Sheet
Data from TeamBlind shows that approximately 70% of interview questions from top tech companies are variations of LeetCode medium problems. Seventy percent!
My Google interview question about finding the longest substring without repeating characters? Yeah, that was basically LeetCode #3. My Shopee interview about validating binary search trees? LeetCode #98.
It Builds Your Problem-Solving Muscles
LeetCode isn't just about memorizing solutions. It teaches you to recognize patterns. After solving enough problems, you start seeing the matrix.
"Oh, this needs two pointers." "Ah, sliding window would work here." "This screams dynamic programming."
It's like learning chess openings. Once you know the patterns, you're not starting from scratch every game.
My 4-Month Roadmap (The One That Actually Worked)
Okay, confession time again: I didn't follow this roadmap perfectly. Some weeks I crushed it. Other weeks I ate instant noodles at midnight while crying over a hard problem.
But overall? This structure saved my life. Here's exactly what I did, week by week.
(Spoiler: Month 1 was rough. Month 2 was when things clicked. Month 3 made me feel like a coding wizard. Month 4 was all about polish and confidence.)
Month 1: Humbling Beginnings (Weeks 1-4)
Goal: Stop feeling like an imposter. Build a solid foundation.
The first month was all about ego destruction and rebuilding. I started with Easy problems, which (surprise!) weren't that easy when you're a beginner.
Week 1: Arrays Are Not as Simple as They Look
I started with the legendary Two Sum problem. You know, the "Hello World" of LeetCode.
My first attempt? A nested for loop that would make any computer science professor weep. O(n²) time complexity. It worked, but it was like using a sledgehammer to crack a walnut.
Then I learned about HashMaps. Mind. Blown. Suddenly, I could solve the same problem in O(n) time. It was like discovering fire.
Problems I tackled:
• #1 Two Sum Taught me the magic of HashMaps
• #217 Contains Duplicate Easy warmup with HashSets
• #53 Maximum Subarray My introduction to Kadane's algorithm (which sounds fancy but is actually elegant)
Week 2: String Problems Made Me Question Everything
Strings. Simple, right? Just text.
WRONG.
String manipulation turned out to be an art form. I spent an embarrassing amount of time trying to solve Valid Anagram before realizing I could just... sort the strings. Or use a HashMap to count character frequencies.
The real kicker was Group Anagrams. This one showed up in my actual interview later. Knowing how to use sorted strings as HashMap keys saved my bacon.
Key problems:
• #242 Valid Anagram Multiple approaches, same destination
• #49 Group Anagrams Showed up in THREE of my interviews
• #128 Longest Consecutive Sequence First medium problem I solved without crying
Week 3: Two Pointers Changed My Life
This was the week everything started to click.
The Two Pointers technique is like a superpower. You've got problems that seem like they need nested loops (O(n²), yikes). But with two pointers moving toward each other or in the same direction? You can solve them in O(n) time.
The iconic 3Sum problem almost broke me. I spent three days on it. THREE DAYS. But when I finally solved it, I felt like I'd just defeated a Dark Souls boss.
Essential problems:
• #15 3Sum The boss battle of Week 3
• #11 Container With Most Water Beautiful demonstration of opposite pointers
• #125 Valid Palindrome Easy warmup that teaches the fundamentals
Week 4: Linked Lists (Or: Pointers Are Evil)
Linked lists taught me humility.
I'd always worked with arrays. Everything had an index. Life made sense. Then linked lists showed up with their cryptic node.next.next.next nonsense.
The fast/slow pointer technique (also called the tortoise and hare algorithm) was a revelation. One pointer moves twice as fast as the other. If there's a cycle, they'll eventually meet. Genius!
Reversing a linked list iteratively took me 47 attempts. Yes, I counted.
Must-solve problems:
• #206 Reverse Linked List Learn both iterative AND recursive solutions
• #141 Linked List Cycle Perfect introduction to fast/slow pointers
• #21 Merge Two Sorted Lists Foundation for harder merge problems
Month 1 Reality Check:
By the end of Month 1, I'd solved about 60 Easy problems. I still felt like a beginner, but at least I wasn't drowning anymore. I could read a problem and think, "Okay, this looks like a HashMap situation" or "Two pointers might work here."
Progress? Yes. Confidence? Getting there.
Month 2: When Things Started to Click (Weeks 5-8)
Goal: Tackle Medium problems like a semi-competent human being.
Month 2 was where I transformed from "panicking beginner" to "cautiously optimistic intermediate." Medium problems became my daily bread, and honestly? They're where the real learning happens.
According to Interviewing.io, 75% of Big Tech interview questions fall into the Medium category. This month was basically boot camp.
Week 5: Sliding Window Blew My Mind
The Sliding Window technique is pure elegance. You maintain a "window" of elements and slide it across an array or string. It's perfect for problems involving consecutive subarrays or substrings.
Longest Substring Without Repeating Characters was my nemesis. It took me two solid evenings to crack. But once I understood how to expand and contract the window while tracking characters with a HashMap? Chef's kiss.
Game-changing problems:
• #3 Longest Substring Without Repeating Characters The quintessential sliding window problem
• #567 Permutation in String Fixed-size window variation
• #76 Minimum Window Substring Hard problem that made me feel like a genius when I finally solved it
Week 6: Stack Problems Are Secretly Fun
Who knew Last In, First Out (LIFO) could be so satisfying?
Stacks are perfect for problems involving matching pairs (like parentheses), tracking history, or finding the next greater/smaller element.
Valid Parentheses is the "Hello World" of stack problems.
Super simple concept, but it teaches you to think in terms of matching and closing.
Then came Monotonic Stack problems like Daily Temperatures. These problems look impossible until you learn the pattern. Then they're... still tricky, but doable.
Stack essentials:
• #20 Valid Parentheses The warmup
• #155 Min Stack Design your own data structure (so cool!)
• #739 Daily Temperatures Monotonic stack magic
Week 7: Trees Made Me Feel Smart (Finally)
Trees! Beautiful, hierarchical, occasionally frustrating trees.
I learned that there are two main ways to traverse a tree:
• BFS (Breadth-First Search) Uses a queue, goes level by level
• DFS (Depth-First Search) Uses recursion or a stack, goes deep before going wide
Binary Tree Level Order Traversal was my first real BFS problem. Watching the queue fill up level by level felt like watching magic happen.
And Validate Binary Search Tree? That one taught me that recursion can be beautiful when done right. (It can also be a nightmare when done wrong, trust me.)
Tree fundamentals:
• #102 Binary Tree Level Order Traversal BFS template problem
• #98 Validate Binary Search Tree Teaches proper BST validation
• #236 Lowest Common Ancestor Classic recursion problem
Week 8: Heaps Are Underrated
If you see the words "Top K" or "Kth largest/smallest" in a problem, your brain should immediately shout "HEAP!"
A heap (or priority queue) maintains the largest or smallest element at the top in O(log n) time. It's like having a bouncer who always knows who the VIP is.
Find Median from Data Stream using two heaps (a max-heap and a min-heap) was one of those problems that makes you feel like you've leveled up as a programmer.
Heap must-knows:
• #215 Kth Largest Element in an Array Perfect heap introduction
• #347 Top K Frequent Elements Combines HashMap + Heap
• #295 Find Median from Data Stream The two-heap masterpiece
Month 2 Milestone:
By the end of Month 2, I'd solved around 80-90 Medium problems. More importantly, I could now look at a problem and recognize patterns within the first minute.
"Oh, this is asking for consecutive elements? Sliding window." "Finding Kth largest? Heap time." "Need to validate something recursively? DFS."
Month 3: Advanced Topics (Or: The Gauntlet) (Weeks 9-12)
Goal: Stop running away from Hard problems. Embrace the pain of graphs and dynamic programming.
Month 3 was the hardest. Not because the problems were impossibly difficult (okay, some were), but because this is where imposter syndrome hit hardest.
But I pushed through. And by the end, I felt like I'd earned my stripes.
Week 9: Graphs (The Final Boss)
If trees made me nervous, graphs made me want to quit coding altogether. But I didn't!
The secret to graphs? They're just trees with attitude. Trees that can have cycles, multiple connections, and no clear root.
Number of Islands was my introduction. It's basically a grid where you flood-fill to find connected components. Once I got the pattern (DFS or BFS to explore, mark visited nodes), everything else became manageable.
*Course Schedule * taught me about topological sorting and cycle detection. This showed up in my actual Google interview (!!!).
Graph essentials:
• #200 Number of Islands The gateway drug to graph problems
• #133 Clone Graph Teaches graph traversal + HashMaps
• #207 Course Schedule Cycle detection and topological sort
Week 10: Backtracking (Choose Your Own Adventure)
Backtracking is like exploring every path in a maze, but being smart enough to turn back when you hit a dead end.
The mantra is simple: Try. Go deeper. Wrong? Backtrack. Try again.
Subsets and Permutations are the foundational problems. Once you understand how to build solutions incrementally and undo choices when needed, backtracking becomes second nature.
Word Search on a grid was satisfying. You try each direction, mark your path, and backtrack if it doesn't work out. It's like being a detective.
Backtracking classics:
• #78 Subsets The simplest backtracking template
• #46 Permutations All possible orderings
• #39 Combination Sum Backtracking with reusable elements
• #79 Word Search Backtracking on a 2D grid
Weeks 11-12: Dynamic Programming (The Final Exam)
Ah yes. Dynamic Programming (DP). The topic that makes grown engineers cry.
I'm not going to lie to you. DP was HARD. Like, "stare at the ceiling at 3 AM questioning your life choices" hard.
But here's the secret: DP is just smart recursion. You solve a big problem by breaking it into smaller subproblems and remembering the answers so you don't recalculate them.
Start with Climbing Stairs. It's the Fibonacci sequence in disguise. Once you see the pattern (dp[i] = dp[i-1] + dp[i-2]), the lightbulb goes on.
Then tackle House Robber. Then Coin Change. Each problem builds on the last.
By the time I got to Longest Common Subsequence (a 2D DP problem), I felt like I'd climbed Everest.
Pro tip: Use this DP patterns guide. It saved my sanity.
DP progression (easy to hard):
• #70 Climbing Stairs Your DP "Hello World"
• #198 House Robber Teaches the "skip or take" pattern
• #322 Coin Change Unbounded knapsack introduction
• #300 Longest Increasing Subsequence Classic DP with binary search optimization
• #1143 Longest Common Subsequence 2D DP masterclass
Month 3 Reality Check:
I won't sugarcoat it. Month 3 was exhausting. But by the end, I'd solved around 15-20 Hard problems and felt confident tackling any topic.
Graphs? Bring it. DP? I'm ready. Backtracking? Let's go.
Month 4: Polish & Interview Prep (Weeks 13-16)
Goal: Stop learning new stuff. Start performing like you're already in an interview.
Month 4 was about transformation. I went from "person who solves LeetCode problems" to "person who can nail technical interviews."
Big difference.
Week 13: Filling in the Gaps
I spent this week covering topics I'd avoided:
• Trie For prefix-based string problems
• Bit Manipulation For those weird XOR problems
These topics don't show up often in interviews, but when they do, you'll be glad you prepared.
Weeks 14-15: Mock Interviews & Contests
This is where the magic happened.
I did mock interviews on Pramp and Interviewing.io. Talking through my solutions out loud felt awkward at first. But it's essential.
In real interviews, communication matters as much as correctness. You need to explain your thought process, discuss tradeoffs, and handle hints gracefully.
I also joined LeetCode Weekly Contests. The time pressure is intense. You get 90 minutes for 4 problems. It's stressful, but it trains you to think fast and handle nerves.
My first contest? I solved 1 problem. My last contest before interviews? I solved 3. Progress.
Week 16: Rest & Review
In the final week, I did something radical: I stopped grinding.
Instead, I reviewed my notes.
I re-solved 10 of my favorite problems (one from each major topic).
I made sure I could still code Two Sum, Reverse Linked List, and Validate BST in my sleep.
Most importantly? I slept. A well-rested brain crushes interviews. A burned-out brain makes silly mistakes.
The Mistakes I Made (So You Don't Have To)
Let's talk about my failures. Because trust me, there were many.
Mistake #1: Grinding Quantity Over Quality
**
Early on, I had this toxic mindset: "If I solve 500 problems, I'll be ready!"
**Wrong.
Solving one problem deeply, understanding three different approaches (brute force, better, optimal), and analyzing time/space complexity is worth more than speed-running ten problems by peeking at solutions.
Research from MIT's learning science department shows that deep understanding leads to 3x better retention than surface-level practice.
Quality beats quantity. Every. Single. Time.
Mistake #2: Looking at Solutions Too Soon
I used to give up after 10 minutes and check the discussion section.
This was sabotage. The struggle is where learning happens.
When you finally crack a problem after 45 minutes of thinking, that "Aha!" moment cements the solution in your brain.
Rule of thumb: Spend at least 30-45 minutes wrestling with a problem before looking at hints.
Mistake #3: Ignoring Time/Space Complexity
Getting an "Accepted" verdict felt great.
But if I didn't analyze why my solution worked and whether I could optimize it, I missed the entire point.
After every solution, ask yourself:
• What's the time complexity? (How does it scale with input size?)
• What's the space complexity? (How much extra memory am I using?)
• Can I do better?
Learn Big O notation inside out using Big O Cheat Sheet. Interviewers will ask about complexity.
Mistake #4: Coding in Silence
When I practiced alone, I coded quietly. Just me, my editor, and the blinking cursor.
Then I did my first mock interview. The interviewer asked, "Can you walk me through your approach?" I fumbled. Badly.
In real interviews, you must communicate. Even when practicing solo, talk out loud. Explain your thinking as if someone's listening.
"I'm using a HashMap here because I need O(1) lookup..." "Let me try two pointers since the array is sorted..."
"This looks like a DP problem because we have overlapping subproblems..."
The Result (And Why You Can Do This Too)
After 4 months, I interviewed at:
• VNG Made it to final round
• Shopee Got an offer!
• Google Passed phone screen (didn't continue due to Shopee offer)
• MoMo Got an offer!
I accepted the Shopee offer. The salary was great. The team seemed amazing. And honestly? I was exhausted from interviewing.
But here's the most important part:
I'm not special.
I don't have a PhD.
I didn't go to Stanford.
Four months ago, I couldn't explain what a linked list was.
According to Levels.fyi data, engineers who followed a structured 3-6 month LeetCode plan had a 73% success rate landing Big Tech offers.
Compare that to just 31% for those who practiced sporadically.
The roadmap works. You just have to commit.
The Resources That Saved My Life
You don't need to figure everything out alone. Here are the resources that helped me most:
Practice Platforms:
• LeetCode The main battleground
• NeetCode Video explanations that actually make sense
• AlgoExpert Structured curriculum (paid but worth it)
Learning Resources:
• Tech Interview Handbook Free, comprehensive, gold mine
• Grind 75 The ultimate curated problem list
• GeeksforGeeks Great for theory and explanations
• Cracking the Coding Interview (book) The Bible of technical interviews
Mock Interview Platforms:
• Pramp Free peer-to-peer practice
• Interviewing.io Practice with real engineers
Your Turn (Start Today, Not Tomorrow)
Look, I'm not going to tell you this journey is easy. It's not.
There will be days when you want to quit. Days when you'll stare at a problem for an hour and feel like an absolute fraud. Days when you'll wonder if you're cut out for this.
But here's what I learned: Everyone feels that way. The people crushing interviews at Google? They felt that way too. The difference is they kept going.
Your Action Plan (Do This Right Now):
• Create your LeetCode account (takes 2 minutes)
• Solve Two Sum right now (seriously, close this article and do it)
• Commit to 2-3 problems per day for the next 4 months
• Join the LeetCode Discord for community support
• Track your progress in a spreadsheet and celebrate small wins
The dream job you want? It's 4 months away. Not 4 years. Not when you're "ready." Four. Months.
I'll see you on the other side. And when you land that offer at VNG, Shopee, Google, or wherever your dream takes you, come back and tell me about it.
You've got this. Now go solve Two Sum.
🚀
Top comments (0)