How to Prepare For a Technical Interview
Table of Contents
- How Long Do I Need?
- Best Materials to Prep
- What Should I Know? Give Me a Checklist!
- How to Use Sample Coding Problems
- More Advanced Prep and Materials
- Mock Interviews Are Key
- How Do I Actually Approach the Problem?
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.
How Long Do I Need?
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.
Best Materials to Prep
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:
- https://leetcode.com - You've probably heard of these guys. Tons of questions, community-driven. Decent IDE, well known.
- https://hackerrank.com - More for recruiting purposes nowadays, but same idea.
- https://topcoder.com - Known for competitive programming, but same idea as well.
- https://geeksforgeeks.org - Tons of questions, explanations are hit or miss though.
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:
- Grokking Algorithms - good basic primer and introduction. Great graphs.
- Cracking the Coding Interview by Gayle Laakmann McDowell - this is the O.G. of technical interview prep books. Extremely comprehensive, highly recommended.
- Introduction to Algorithms by Cormen, Leiserson, Rivest, Stein - another classic in academia.
- Elements of Programming Interviews - harder problems than CTCI.
- Programming Interviews Exposed: Secrets to Landing Your Next Job
What Should I Know? Give Me a Checklist!
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.
Data structures
- Hashtables - Arguably the single most important data structure known to mankind. Make sure you can implement one from scratch.
- Stacks/Queues are essential, know what FILO and FIFO are.
- Linked Lists - Know about singly linked lists, doubly linked lists, circular.
- Trees - Get to know basic tree/node construction, traversal and manipulation algorithms. Learn about the subsets-- binary trees, n-ary trees, and trie-trees. Lower-level or senior programmers should know about balanced binary trees and their implementation.
- Graphs - Get to know all implementations (objects and pointers, matrix, and adjacency list) and their pros and cons.
Algorithms
- Sorting - get to know the details of at least two n*log(n) sorting algorithm, I recommend Quicksort and Mergesort.
- Binary Search
- Tree/Graph traversal algorithms: Breadth-first Search and Depth-first Search are musts. Also know inorder, postorder, preorder.
- Advanced - for the most part optional, but if you wanted to go beyond the basics, I'd recommend Dijkstra, A*, Traveling Salesman, Knapsack Problem.
Math (rare)
- Basic discrete math (logic, set theory, etc.)
- Counting problems
- Probability (permutations vs. combinations)
Programming Languages
- Know the ins-and-outs of your language (I'm fond of JS). The language you choose should be one that you have mastered, or know best. The interview is not the time to be figuring out how to write a for-loop or what is truthy.
- Don't worry about choice of language. There is some controversy around this point-- if you're going for a Frontend role, perhaps Javascript is a better language than Python (and vice-versa for a backend role). But for the most part, the interviewer is conducting the interview because they are looking for your algorithmic reasoning skills and thought process. I've had interviewers not know the ins-and-outs of ES6 JS, and I just kindly explained parts that were unintuitive to them (like why you don't need return statements in certain arrow functions).
- Helps a lot to know one of Python, C++, Java
OOP Design
- Polymorphism
- Abstraction
- Encapsulation/Inheritance
Systems Design
- Scoping/User Cases/Constraints
- Component Design
- OOP Design
- Database Schema Design
- Vertical Scaling
- Horizontal Scaling
- Caching
- Load Balancing
- Database Replication
- Database Partitioning
- Map-Reduce
- Microservices
- Concurrency
- Networking
- Abstraction
- Estimation
Note: Systems Design is a huge interview topic in itself. I highly recommend the System Design Cheatsheet and reading Designing Data-Intensive Applications.
How to Use Sample Coding Problems
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 2 or 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:
- What have I learned thus far? Is there anything I should know for next time?
- What pattern or technique did the solution derive from?
- What hint did I need? How far was I from solving it myself?
- If asked this same question tomorrow, can I readily solve it without any assistance?
More Advanced Prep and Materials
At startups and smaller companies, or for specialized roles or research positions,you may get more specific questions. As an example, for a Javascript Engineer role, you may be asked: What is hoisting in Javascript?
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:
Mock Interviews Are Key
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.
How Do I Actually Approach the Problem?
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.
Back