Cracking the Coding Interview is by far the most popular interview prep book for software engineers. It’s a great book. But it was written for a few years ago, and software engineering interviews seem to have changed in the meantime, at least in the Silicon Valley engineering culture which I’m most involved in.
So I’ve written this guide to the book. It contains notes on things which I think have changed since it was written, and a list of the questions from the book which I think are most relevant to people preparing for software engineering interviews at good companies in the Bay Area.
I was inspired to write this by InterviewCake, which is a competitor to Cracking the Coding Interview. But InterviewCake is much more expensive than CtCI. I think this list of CtCI questions is about as good a list of interview questions as InterviewCake. There, I just saved you $180.
How have things changed? Most obviously, people use more scripting languages here and less C++ and Java. This has some direct effects. For example, there aren’t as many questions about merging arrays given buffer space anymore: that question still makes sense in scripting languages, but it doesn’t come up as much as it does in C. And I think Silicon Valley dislikes what it sees as verbose enterprise trivia bullshit, and purposefully doesn’t talk about such things. I think this is why I don’t hear about people being asked about design patterns.
The 5th edition is somewhat better than the 4th edition, because it has more content at the start of every chapter. I have not seen the 6th edition.
The most relevant questions
Here is a subset of the questions which I think reflects SF software interviews more accurately:
Questions in the 4th edition:
1.1, 1.7, 1.8, 2.1, 3.1, 3.2, 3.3, 3.5, 4.1, 4.2, 4.3, 4.5, 4.8, 7.1, 7.2, 7.4, 8.1, 8.2, 8.3, 8.4, 8.5, 8.6, 8.7, 8.8, 9.2, 9.3, 9.6, 12.1, 12.2, 12.6, 12.7, 15.3, 17.5, 18.1, 18.2, 19.2, 19.7, 19.11, 20.10, 20.11.
Questions in the 5th edition:
1.1, 1.7, 1.8, 2.1, 3.1, 3.2, 3.3, 3.5, 3.7, 4.1, 4.2, 4.3, 4.5, 4.6, 4.8, 5.1, 8.1, 8.2, 8.5, 8.7, 8.9, 8.10, 9.1, 9.2, 9.3, 9.4, 9.5, 10.1, 10.2, 10.5, 10.6, 11.3, 11.6, 11.8, 15.5, 16.1, 17.2, 17.8, 17.12, 18.10, 18.11.
Bryan Sharon was kind enough to map these to the question numbers in the 6th edition:
1.1, 1.8, 1.9, 2.1, 3.1, 3.2, 3.3, 3.4, 3.6, 4.4, 4.1, 4.2, 4.5, 4.6, 4,10, 5.1, 7.1, 7.2, 7.5, 7.7, 7.11, 7.12, 8.1, 8.2, 8.3, 8.4, 8.7, 8.8, 9.1, 9.2, 9.3, 9.4, 10.3, 10.9, 10.10, 14.5, 15.1, 16.4, 16.17, 16.24, 17.22, 17.23
I would recommend giving these questions higher priority in your study.
Many of the questions that I didn’t include there are still good practice. If you want more practise on a particular topic, you should definitely do even the questions I didn’t include.
General notes
Every chapter in the interview questions section of CtCI starts with a short summary of the subject matter for the questions. I think these notes are quite good. It’s well worth reading the notes for chapters even if you don’t do questions from them.
The first 40-ish pages of the book are general advice about software engineering interviews. I agree with all of it except the following points, organized by section:
Before the interview: Companies don’t ask behavioral questions much.
What You Need To Know (page 26): Tries are not absolutely must-have knowledge. I’ve never heard of people being asked to implement quicksort in place. Singleton and Factory design patterns are not crucial knowledge.
At the Interview: You don’t have to use C, C++, or Java. People will possibly be biased against you if you do. Ruby, Python, and Javascript are fine choices. I think it’s fine to do the problem in whatever language you want. You can ask your recruiter about this before the interview.
Comments on individual question chapters (in the 4th edition):
Chapter 1: Arrays and Strings
Companies care less about seeing you edit data in place than they used to. I’d only expect questions on this if you’re applying for a C job. For this reason, questions [1.2, 1.3, 1.5, 1.6, 1.7] are lower priority.
Chapter 2: Linked Lists
All of these questions are less common these days because linked lists come up less, because we don’t use C as much and have more support for generics, leading to us coding our own data structures less often.
2.5 is a common bullshit brainteaser question.
Chapter 3: Queues and stacks
I agree that you’ll look good if you can flawlessly implement a queue and stack.
Chapter 4: Graphs and trees
Study BFS: it’s a really common question. These questions all seem reasonable.
Chapter 5: Bit manipulation
I’ve rarely seen these problems come up, even when I interviewed for a C++ systems job.
I include one question of this type in my list above.
Chapter 6: Brainteasers
These questions are widely reviled, and seem to be getting less common. Maybe memorize the answers in case you run across a bad interviewer.
Chapter 7: OOP
These questions are good. The provided answers are idiomatic Java; if you’re answering in Python you should model your answers after idiomatic Python rather than the answers given.
I don’t hear about people being asked abstract questions like 7.3.
Chapter 8: Recursion
Many of these questions are classics which I’ve been asked many times before.
Chapter 9: Searching and sorting
I think that it’s somewhat less common to be asked to write sorting algorithms these days.
Chapter 10: Math
I don’t hear about math questions being asked, except at extremely math heavy companies to applicants with a hardcore math background.
Chapter 11: Testing
I don’t hear about these questions very much. I’ve never heard questions like “how would you test a pen”.
Chapter 12: System design and memory limits
I don’t hear about memory limit questions very often.
Chapter 13 and 14: C++ and Java
Only relevant if you’re interviewing in C++ or Java, and even then I’d be slightly surprised to get these questions–they seem somewhat like trivia to me. That said, I’ve been asked one of these questions before.
Chapter 15: Databases
The advice given is somewhat out of date. I don’t think that I’ve ever heard about someone being asked to denormalize their SQL database schema for speed in an interview.
I think the “design a database to hold certain data” type questions are more common now. The rise of ORMs has led to SQL being somewhat less important for most developers.
Chapter 16: Low level
These questions are great, but I wouldn’t expect them at most generalist job interviews.
Chapter 17: Networking
This is somewhat more low level than I think most people get asked. It’s worth knowing the answer to the famous “what happens after you type a URL into a browser” question though.
Chapter 18: Threads and Locks
Companies don’t seem to ask about concurrency primitives without warning you beforehand. Some of these questions are Java-specific.
Chapter 19 and 20: Moderate and Hard
All these questions are popular questions. I don’t particularly like them.