Technical Interview preparation is hard, and that's why this site exists. However, it's important to know exactly how to prepare. We're talking about the schedule to set, the cadence, what problems and concepts to focus on, and exactly how to actually study.
Most people waste time in their efforts. This article will go through everything you need to read, observe, and do in order to go into your interview with confidence.
This article also assumes that you've already landed the interview and are preparing for on-sites, though the advice here is definitely applicable for technical phone screens as well.
So first, a word on timing.
If given a choice, I’d obviously advocate long-term technical preparation— the longer the better. As a general recommendation, roughly 2-3 months to get fully prepared. This lets you get in around 60-120 challenges, which seems to be the amount you need to do to build the algorithmic intuition.
Obviously this depends on work experience, familiarity with computer science fundamentals, and proximity to interviews themselves.
It may take 3-6 months for a new bootcamp grad with zero exposure to data structures and algorithms to get fully ramped. On the other hand, it could take take 1-2 weeks for a low-level Senior Systems Engineer.
Could you pass a whiteboard technical interview from absolute scratch with a month’s prep? Depends on you, but it's certainly doable-- just be sure you’re applying the 80/20 principle and hitting the major themes.
If there’s only a month left, the recommendation would be to do 1-2 problems a day the right way, and perhaps include some light reading. We'll get to that in how to study individual coding problems.
I think it goes without saying that I'd recommend AlgoDaily, so let's get that out of the way.
Many people swear by our daily newsletter and premium challenges to do well in interviews. I'd recommend trying a problem today and seeing if our walkthroughs, code visualizations, and newsletter are helpful in understanding the more complex algorithms.
For those looking for a little less-hand holding, here's a list of coding interview sites with tons of sample problems:
There's some great Youtube Channels that do a wonderful job of explaining concepts and walking through problems:
Then there are people who will recommend textbooks. I personally think most people struggle with reading huge, academic algorithms textbooks, but the following method has helped in the past:
*1. Set aside a "reading time" every day -- this is important to help make it a habit. Perhaps right before or after work/school.
Decide on a cadence. Similar to how AlgoDaily shines with one problem a day, 10-15 pages per day of the textbook is a good goal.
Scan the headings and summary first, and then read the chapters. This will allow you to have something to hang your knowledge on.
Take light notes in outline form. This could be part of your portfolio or be useful as references for later. More importantly, taking notes encourages active reading.*
With that said, here are some books that have been helpful to myself and others in the past:
The biggest challenge with technical interviews is that almost anything under the sun can fall under the term "technical". If we're specifically talking about software engineering jobs, then the scope shrinks considerably, but it's still not that great. Here's an attempt at all the topics to cover for technical interviews. Be sure to go to the previous section for a guide on how to study these topics.
These lists are prioritized from most important to least important. Ultimately, it's a pretty minor subset of all the algorithms and data structures we know of. The great thing is that this is pretty fixed over time, as the academic underpinnings of Computer Science don't change too much.
Big O notation You must get this part, as it forms the foundation for understanding algorithmic performance and how to choose a data structure.
At least the very least, know the underlying theory and why it's important (hint: scaling, good decision making, trade-offs, etc.). The point here of this is that interviewers want to know you can avoid poor-performing code. Imagine if Facebook took an hour to find your friends, or if Google took a day to display search results.
Refer to the Big O cheatsheet for more.
The way most people study/prepare with coding problems isn't conducive. The average person will go on a site like AlgoDaily or Leetcode, and will look at a problem for 30 seconds to a few minutes.
Often they'll then jump to the solution after getting stuck, read the solution, and call it a day. If this sounds familiar, don't sweat it.
Trying to memorize the solution doesn't really work. Here's a more effective way, and it's why AlgoDaily was designed the way it was:
0. First, choose a cadence. One interview challenge a day seems to be the ideal amount. If you do
3 a day in the manner described, you'll be spending 3-4 hours doing it, which is quite ambitious unless you have all day to spend.
It's also mentally tiring, and you likely won't derive a whole lot of marginal benefits from the 3rd or 4th problem. At a certain point, you'll probably begin to eagerly jump towards obvious solutions, which causes you not to understand where your strengths and weaknesses are. The below process nudges your thought process towards retaining the patterns, and eventually will help you solve problems you've never seen prior.
Commit to about 20-30 minutes of trying to solve it by yourself before going to the solution. Really try to get some semblance of a correct output. Brute force it if you have to - just try to reason about any kind of working solution, no matter how slow. It will help you understand the necessities to optimize later.
If you get stuck, start by look at a hint. Then keep trying to solve it. Repeat until there are no more hints.
No hints? Start going through the walkthrough or solution very slowly. As soon as you get unstuck, STOP READING.
Use the bit of insight to start trying to code again again.
Anytime you get stuck again, repeat step 1. Even though you’ve read a part of the solution, the vast majority of learning comes from the struggle of thinking it through yourself. That is what will help you retain it for next time.
Here's some additional steps that really made the difference in my prep:
Write the solution again in another programming language. This forces you to think through the abstractions again, and helps with retention.
Save the problem, and revisit in increasingly long spurts. So you might do it again in 2 days, then revisit in a week, then a month.
Some questions to ask at each step:
Questions like that rely heavily on experience, and are often harder to
hack or learn in a short period of time. For these,
google.com is key -- it's pretty easy to find a quick and dirty list of
Must Know Data Engineering Interview Questions and to do a few quick passes.
For these lists of questions, since the answers are pretty short, the best way to study might be flash-card style. There are tons of flash-card applications online. Or you could pull in a friend to conduct a mock interview. Speaking of which:
You must do some mock interviews before the actual interview. Ideally it would simulate as much of the real interview as possible. If it's a whiteboard interview, grab a whiteboard and a knowledgable friend, and force yourself to answer random algorithm/data structure questions from them.
If you don't have a friend available, pramp.com is a fantastic resource that I used quite heavily when preparing.
You've made it all this way, and are now ready for the interview! Check out AlgoDaily's guide to approaching the interview problem for a great next step.