Skip to main content
Leetcode Journey

Week 1 of My Leetcode Journey – Lessons Learned

Brad Malgas

Brad Malgas

Author

2 September 20253 min read

A recap of my first five problems on Leetcode. Key lessons included writing algorithms on paper, focusing on edge cases, and learning from failure.

Week 1 of My Leetcode Journey – Lessons Learned cover image

When I started this journey, the idea wasn’t to speedrun Leetcode or brag about the number of problems solved. The point was to slow down, approach each problem methodically, and actually learn. Life happened along the way, but I still managed to get through five problems in what I’m calling my first “week.”

Day 1 – 2239. Find Closest Number to Zero

This one was fairly straightforward. Writing the algorithm on paper first helped me stay structured, and I ended up with an O(N) solution that I later optimized from 6ms to 3ms. Full write-up → Day 1

Day 2 – 1768. Merge Strings Alternately

The key lesson here was about string immutability. My first solution was fine, but I realized appending directly to strings creates unnecessary overhead. Switching to an array was more memory-efficient, though slower in this case, so I reverted to my initial approach. Full write-up → Day 2

Day 3 – 13. Roman to Integer

I had solved this problem before, but redoing it showed me how much I had improved. My 2024 solution took 43ms; this time I got it down to 7ms. The algorithm itself was straightforward, but it was a nice confidence boost to see measurable progress. Full write-up → Day 3

Day 4 – 392. Is Subsequence

On paper, the solution looked obvious, but coding it exposed a blind spot: handling empty strings. Adding a simple early check fixed it. Runtime was 0ms, and although that’s not unique (many submissions share the same runtime), this felt like one of my cleanest solutions. Full write-up → Day 4

Day 5 – 121. Best Time to Buy and Sell Stock

This was the first time I outright failed to solve a problem. My O(N²) brute force solution was far too slow. After an hour of struggling, I had to look at community solutions, which turned out to be simpler than I expected. Frustrating, but an important reminder that failure is part of the process. Full write-up → Day 5

Reflections

A few takeaways from Week 1:

  • Writing algorithms on paper before coding helps.
  • Not every optimization is worth it — sometimes clarity is better.
  • Edge cases (like empty inputs) can easily be overlooked.
  • Struggling or even failing is part of the process, as long as I take the time to learn from it.

Going into Week 2, the goal remains the same: slow, steady problem-solving with an emphasis on learning and retention rather than rushing.

Loading reactions…

Loading comments…