Introduction

Welcome to my study notes for interviewing, DSA, and programming language quirks! Here, you can find:

• 300+ solutions for LeetCode problems, including multiple possible approaches, time/space complexity, and more
• My written thought processes and failed attempts as I try to work through each problem
• Explanations of what the intuition is behind certain solutions, so you can learn to think different!
• Easy, Medium, and Hard LC Problems
• Problems from the Company Lists of Tesla, Jane Street, Optiver, Robinhood, and more
• Explanations of common algorithms and patterns, such as Brian Kernighan’s Algorithm and Kadane’s Algorithm
• A curated list of my favorite LC problems, that I find extremely interesting, fun, or are great at teaching you a concept
• Documenting the lessons I’ve learned after failing at technical and behavioral interviews

Motivation

In 2nd year, I had hardly done any LeetCode problems. I entered an interview for my 2nd co-op, and it was one of the most embarrassing things I’ve ever done. I did not know syntax, I had to be helped through most problems, and I ended the interview by apologizing. Safe to say, I had to start a study arc after that. I realized that I really needed to practice. Importantly, I needed to learn common patterns and adjust my approaches to problems.

This webpage is a documentation of the journey since. My driving philosophy behind practicing DSA is that the quality of your understanding is far more important than the number of completed problems on your LeetCode profile. Ever since I started to do my first problems, I created a document for each, and began to write notes. I wrote about exactly what I thought when I first read the problem, so I could understand how my brain was wired, and where my intuition leads me. I wrote about common pitfalls I repeatedly ran into, and eventually began associating ways of thinking with problem archetypes. I wrote down my submitted code, including failed attempts. I noted down time/space complexities, since I was poor at identifying those at first.

Eventually, I landed on a template that I really liked for noting down my solutions. This is what you will see throughout each note. Eventually, I learned to find the fun in problems, improved my debugging skills, and found myself doing much better in interviews.

My goal with these notes is not to replace your practice attempts at these problems. Reading code will not teach you how to replicate a solution during an interview. Instead, I hope that these notes encourage you to create your own. Write down your thought processes and your own journey with studying DSA. Even after you spent 30 minutes pulling your hair out, and you reeeeaallly don’t feel like making a note for this problem… make that note. My proudest achievements in my career have come as a result of becoming more technical, and trying to be great at algorithms is a non-trivial part of that. On some days, I spent 2 hours documenting a single LeetCode Medium problem, and that is OK. Because that time you spent pulling apart your code, understanding what that line does, why we did it this way… is priceless for your technical learning.

Above all, remember to never give up on yourself. Some days, you just feel really dumb. I’ve done poorly in more interviews than I have done well. It takes time to get to where you want to be. Being a strong software engineer, and I mean a really strong software engineer, is one of the hardest things humans attempt to do. It takes dedication across a lifetime to get there. And we’re all still trying.

Good luck out there! And be well.

— Justin