As big tech interviews have moved to brain-teaser data structure and algorithm questions, an entire meta-industry has sprung up around teaching people how to answer those questions.
I’ve already talked about the history of data structures, algorithms, and interviews and my opinions on big tech interviews, so I’ll try not to repeat myself.
This guide contains a few links to resources that I’ve used, or that I recommend.
Leetcode is a collection of data structure and algorithm problems that are very commonly used in big tech interviews. Each problem has a set of test cases, and you write code that tries to pass each test case. Working through Leetcode problems is one of the most common ways to prepare for interviews, to the point that it even has a name: grinding Leetcode.
That list of 75 questions was so popular that it spawned its own website: Tech Interview Handbook.
Grinding Leetcode (or other similar sites) is certainly one great way to practice interview questions. It helps to notice patterns across problems, and to become more familiar with the syntax of your coding language. But this should not be the only way you practice!
Interviewing involves much more than writing code. It involves asking questions, thinking out loud, coding without a compiler, and making sure your interviewer is following along. Leetcode doesn’t help with any of that, so don’t make it your only focus.
Cracking the Coding Interview is a big list of data structure and algorithm questions, but in book form. This is one of the go-to resources that everybody preparing for interviewing comes across.
But similar to Leetcode, I think this book sets up the wrong mindset, where each problem takes the format of “take a question, go away by yourself for a while, and come back with an optimal answer”. And that’s not how interviews work at all!
Interviews are a back-and-forth conversation. You’ll be expected to ask questions and think out loud. Working through a bunch of problems by yourself doesn’t give you that practice. So Leetcode and Cracking the Coding Interview are good for some practice, but they shouldn’t be your end-all-be-all.
I’m starting to sound like a broken record, but Interview Cake is another list of data structures and algorithm questions commonly used in tech interviews.
But Interview Cake frames each question as an iterative process, where you solve one part of the problem at a time. This is much closer to how interviews work in real life, which makes it (in my humble opinion) a much better resource.
The big downside is that Interview Cake is pretty expensive, currently $149 for 3 weeks of access or $249 for a year of access. You can also get three weeks of access for free if you’re a student, and you can sign up for one free problem per week.
But Interview Cake is honestly the best resource I personally used when I was studying for the Google interview. I don’t get any kickback for saying that, and honestly I feel a little weird recommending something that costs money, but this is what I personally used the most.
Again, I don’t think you should focus on any single resource as your only source of practice. I think you should do a little bit of everything. Interview Cake provides an excellent framing of problems that you can then bring to questions from Leetcode or Cracking the Coding Interview.
Glassdoor is a website where people post about interviewing and working at various companies, including in big tech. You can hear from other people who have gone through the interview process, or who currently work at the company you’re interviewing for.
Glassdoor has grown since I used it back in 2016, but the core lists of interview questions for particular companies is still there.
One caveat that I’ll give is that there’s a common misconception that different companies ask specific questions. This isn’t true, especially in big tech. So there isn’t much value in digging for Google interview questions over any other list of data structure and algorithm questions. So you should use Glassdoor as a window into the industry, but don’t focus too exclusively on any one post.
Blind is a similar site that lets people post about different companies, including interview questions. Honestly most of the posts on Blind rub me the wrong way so I never look at it, but it’s another site worth checking out. Just keep in mind that the posts here aren’t very representative, to say the least.
The last resource I’ll mention is mock interviews. There are a bunch of websites and programs where you can pay hundreds of dollars for the pleasure of having a fake interview with somebody who works in big tech.
My advice? Save your money.
Mock interviews are the best way to practice for the real thing, but you’re much better off doing mock interviews with your friends, peers, family members, pets, and potted plants.
If you really want to prepare for a big tech interview, my best advice is to pair up with somebody else preparing for interviews, and take turns pretending to be the interviewer and the candidate.
I know that’s counter-intuitive. I know you’re probably saying something like “I can’t pretend to be an interviewer, I haven’t even had an interview yet!” or “My friend can interview me, but are they going to have useful feedback for me?”
I promise that you learn so much from both sides of the mock interview experience: as a candidate, you get to practice talking while you code without a compiler, which is so much harder than it sounds. As an interviewer, you get to see what it feels like when somebody goes silent for a minute, or writes code that you don’t follow, or switches directions without explaining why.
If you don’t know anybody else preparing for a big tech interview, you can ask literally anyone to pretend to interview you. They don’t even need to know coding themselves. Forcing yourself to explain things to somebody with less experience is a great way to make sure you can explain things to a real interviewer.
I’ve listed the above resources because I personally found them useful, but I don’t think you should focus on any single approach. Don’t grind Leetcode without doing mock interviews. Don’t read Cracking the Coding Interview without coding your solutions up. Don’t read a bunch of Glassdoor posts and call it a day.
Mix a little bit from each resource into your preparation. Check out the process outlined in Interview Cake, and then think about how you’d apply that to the problems in Cracking the Coding Interview and on Glassdoor. Bring those questions to mock interviews, and pay attention to what’s hard for both you and your partner.
And don’t limit yourself to what I’ve listed above. If you find something that clicks for you, absolutely integrate that into your practice. And let me know about it!