Being ready for coding interviews is a generally good habit for any Software Engineer. Last year, I was stuck in between feeling terrible about my day-to-day life at work and lethargic enough to not want to interview. I promised to myself to make sure I’d never feel that way again and to prioritize my own health over all else. Luckily (or unluckily, depending on how you view it), I was laid off in around April of last year. I had already been very slowly but consistently ramping up interview preparation in hopes of leaving. Here’s what I learned and continue to do to stay ready in case of the worst.
You’ll need to be prepared for technical code-writing interviews, but also system design interviews. In general, there’s almost always some behavioral interviews as well, but I’m not going to focus on those below. Instead, I’ll discuss how to stay sharp for the technical portions.
Leetcode
A lot of people really hate Leetcode, but hear me out — give it a consistent shot, embrace your improvement, and don’t give up. If you’re like me, you’ll eventually start to enjoy the problem-solving aspect of it all.
Problems
There’s a lot of good lists of problems out there. Here are a couple that may be helpful:
The above are already plenty of problems, and if you’re able to get them down and really understand the processes behind them, you’re probably set for 75% of your technical Leetcode style questions. Start with the problems marked as Easy and then make your way up to Mediums, and then eventually Hards.
There’s another really useful resource that Leetcode provides for free. That’s the daily challenge problemthat you can find at the top of the problem list with a calendar icon next to it. The difficulty ranges — some days it’ll be an Easy and some days it’ll be a Hard. Furthermore, the topic is usually the same throughout the week (examples: BFS, Strings, Hash-Maps, etc.) I love this as a form of preparation, because it’s like a built-in rate limiter. Only one problem is chosen per day, and it’s pretty easy to just sign in and check out the problem every now and then.
Videos
This, for the most part, should be all you need: NeetCode IO’s youtube channel
Neetcode is excellent at describing problems for visual learners like me. He walks through the problem, what he identifies as key information, and goes through a whiteboard solution before implementing. You’ll start to realize that these problems aren’t too tough to write in code. The thinking happens at the whiteboarding step, and these videos will help you build up that intuition.
Readings
I’m not a big reader when it comes to LC questions, but I’m a big fan of editorials and discussion sections within Leetcode itself. Make sure to actually read through them and understand the optimal solutions. There’s many times when a problem is marked as Easy, but that’s just for the base problem. Optimizing the solution, may result in a problem that’s more at a Medium level and is more likely to come up in an interview setting.
While you may not learn the best code syntax guidelines by reading these solutions, I guarantee you’ll learn something new about the language you code in by seeing how others answer the same problem. If you use Python and you see a solution that’s written out as a one-liner, I highly suggest reading through it to get a grasp of what the built-ins in Python are capable of doing.
System Design
There’s so many system design resources out there, it’s just a matter of hunting to find the best ones. Here are some that I like to use:
Newsletters
Newsletters are great, in particular, because they usually come out at a regular frequency and allow you to get consistent learning. Here’s a list of a couple that I subscribe to in order to stay up-to-date:
- Quastor
- A widely recommended blog that provides summaries of many large company blog/learning posts, usually in system design.
- ByteByteGo(Youtube)
- A classic resource from Alex Xu, complete with articles and youtube videos with amazing visualizations.
- Company pages
- Companies often publish articles that dive into architectural decisions that could help you make design decisions in your own work:
Books and Courses
I’m not a huge book reader, but if there’s one book that you should read to get good at System Design, let it be this one:
I haven’t fully completed it, but it’s so far, it’s knowledge-packed and will introduce you to so many concepts, enabling you to dive deeper into whatever sounds interesting. In other words, if you “don’t know what you don’t know,” this book will help you get your feet in the ground.
There are a few other courses/e-books that are useful as supplements to the above, and that may be more targeted towards the interview environment rather than just topical introductions:
- Grokking the Modern System Design Interview
- Alex Xu’s System Design Interview
- Note: there are multiple volumes
Conclusion
The one thing that’s worth taking away from this article is actually really simple: stay consistent. Consistency will allow you to get a fuller understanding over time rather than forcing stuff into your brain. Don’t be afraid to be bad at these at first (Leetcode Easy problems can still be tough!), but just understand that over time you’ll see improvement bit by bit. The longer you can stick to it, the more prepared you’ll be, and the more you’ll start to like the process (positive feedback).