I'm sure you've heard of Cracking the Coding Interview for Big Tech Interviews. It's one of the best-selling resources that are supposed to help you prepare for coding interviews with big tech companies. But should you actually buy it? In this post, I'll share my thoughts on the book and whether or not I think it's worth your money and time as you study for technical interviews. Spoiler alert: when studying for big tech coding interviews I don't think it is.
My Experience
I’ve conducted over 80 1-1 calls over the last 2 months with people preparing for FAANG interviews, and the vast majority of them have the same flawed training regime. The typical approach is to work through Cracking the Coding Interview and grind leetcode problems until the interview. They spend time trying to develop techniques working through these online courses that end up leaving them frustrated and burnt out.
I spent two years studying for programming interviews. My first interview was just a phone screen and both the interviewer and myself knew once that call was over that I did not get the job. It was a good experience to get familiar with the interview process but I was far from ready to get a job at one of these top tech companies. I then followed the typical approach to prepare for my coding interview. I prioritized Cracking the Coding Interview and doing tons of Leetcode problems. I was a relatively new software engineer and taught myself computer science but I completed hundreds of coding questions as I worked to get my dream job. When I got to the coding interview, I thought I was ready. I was not ready.
After failing the whiteboard interviews, I knew I needed to change my studying habits. The first thing I did was throw out Cracking the Coding Interview and created a coding interview framework to adjust my studying. This framework included studying core computer science concepts, making sure I was prepared for behavioral questions, and approaching coding problems with a different mindset. I also picked up a few different resources (full list of recommended coding interview resources).
Results
I eventually got job offers from top companies like Facebook & Google. I chose Facebook, where I interviewed hundreds of experienced candidates looking to get a job at one of the top companies. I now spend time working with people studying for coding interviews where I share the proven strategies to help you level up your tech career. I, unfortunately, learned these skills the hard way but I now work to make sure no one has to go through what I did.
Why Cracking the Coding Interview sucks
Birds-Eye View
Cracking the Coding Interview gives you a great birds-eye view of the relevant data structures and algorithms, but it doesn’t get deep enough into the fundamentals. When you enter a coding interview, there is a slim chance you are going to get a problem that you have seen before.
The technical questions you are faced with will be abstract and very difficult to work through. Google's hiring committee is expecting you to be able to use your fundamentals to work through the problem with the same details as FAANG level software engineers. These are set up to make it super difficult to pass interviews.
Approachability
The Cracking the Coding Interview approachability is its downfall here. It’s designed to be a great resource for engineers looking to get a job at a mid-size or non-faang company. It’s meant to be a book you can study during your interview preparation, take 30 coding interviews, and eventually, you’ll see something you saw in the book and get a job. Any developer looking to land a non-faang level company should consider using this book.
The problem with Cracking the Coding Interview & FAANG
The problem with FAANG interviews is you don’t have 30 chances and the odds of getting 5 interview questions directly out of the book are slim to none. There will always be a success story about how someone just did Cracking the Coding Interview problems and landed the job. This is the exception to the rule.
With FAANG interviews, you need to prepare for problems you’ve never seen before. During your interview preparation, you should expect the coding interview to be abstract and lack the direction you need when you are writing code.
To do that you need a resource that gets into the thick of it. It takes time to re-learn and walk through the trickiest algorithm problems but these are the expertise you will need when applying to these top tech companies.
Enter the Algorithm Design Manual
My Recommendation
I recommend this book as a starting point to every aspiring FAANG engineer in my study group. It’s a relatively dry book in my opinion, but I haven’t ingested any other resource that has prepared me as well as this book has. If you read carefully and do the problems in each section, you’ll be ready to start learning the techniques needed to solve the more difficult programming interview problems with detailed answers.
You’ll stop feeling stumped during hard problems and you’ll start getting creative.
Getting creative and being able to tackle algorithm questions is what is going to get you across the finish line.
Where did this opinion form?
From experience. As I mentioned, when I was preparing for my Google interview, I did Cracking the Coding Interview front to back. During medium/hard leetcode problems, I would frequently ask myself “How the hell was I supposed to know that trick?”. I showed up to my onsite coding interviews and got my butt kicked.
A year later, after switching to studying the Algorithm Design Manual and adding some more structure to my studying, I got offers from Google & FB. I felt like I was in complete control of my interviews. I would not have gotten to that point if I didn’t nail the core computer science concepts. Understanding the fundamentals and knowing how to use them to decode any problem is what makes a software engineer stand out. The real interview is not just going to give you a leetcode problem to work through. These tech firms are looking for software engineers that not only write flawless code but also have the core algorithms down to solve problems.
To see the stark difference for yourself, compare the chapters on “Big O” in both books.
