Cracking the Coding Interview fits some FDE rounds, not all

Your FDE interview is a month away, and on your desk sits a 708-page book. There is no time to read all of it, so the question is which chapters to read.

The answer depends on what kind of coding round you face. At some companies it is the familiar algorithm problem the book teaches so thoroughly. At others it is a production-style build, and then only a few chapters really help.

A book bigger than its title

The author is Gayle Laakmann McDowell. According to the publisher’s listing, the 6th edition was released by CareerCup on 1 July 2015, runs to 708 pages and carries ISBN 978-0-9847828-5-7. The official site still titles this edition “150 Programming Interview Questions and Solutions”, yet inside there are 189 questions, each with hints.

The author’s site says this edition has 70% more content than the previous one. The book has been around for a while, but its core has not aged: how to think when facing an unfamiliar problem in front of an interviewer.

The difficulty is that FDE coding rounds have no common template. Educative’s course on Google FDE interviews describes the coding round as a standard data structures and algorithms interview. It lasts about 45 minutes, with one or two problems, and that is exactly the book’s home ground.

For OpenAI, Exponent’s guide describes the onsite round as a 60-minute production-style build. The problem may be split into several consecutive parts, and new requirements are added once you have a first version. Same book, but each round calls for a different way of reading it.

The valuable part comes before question 1

Before the 189 questions, the book has several opening chapters: the interview process, behavioural preparation, Big O, and a chapter on technical questions with 5 approaches to algorithms. Many readers skip straight to the exercises, and that is a mistake. The opening chapters teach the method; the exercises are just where you practise it.

The Big O chapter covers time and space complexity, amortised time, when log N appears, and how to work out the runtime of recursive functions. The section “Multi-Part Algorithms: Add vs. Multiply” deserves a close read.

Imagine you loop through a list of orders A, then loop through a list of customers B. Two loops in sequence give O(A + B); nest loop B inside loop A and it becomes O(A × B).

With 10,000 orders and 1,000 customers, that is the difference between 11,000 steps and 10,000,000 steps.

Practise saying this calculation out loud before you type any code. A single sentence such as “two loops in sequence, so O(A + B)” is enough to show the interviewer you understand what you are about to write.

Named techniques beat memorised answers

The technique chapter teaches problem-solving methods with their own names, such as BUD, Base Case and Build and Data Structure Brainstorm, along with guidance on what good code looks like. Named techniques are easy to remember. When you are stuck, you have a list to work through rather than sitting in silence.

For OpenAI’s build round, the “good code” part matters even more. When the second requirement arrives at minute 30, code with clear names and sensibly split functions can be changed in a few minutes. Code rushed out just to run may have to be rewritten from scratch.

In what order to read for each type of round?

The 189 questions are grouped by topic: arrays and strings, linked lists, stacks and queues, trees and graphs, recursion and dynamic programming, sorting and searching, object-oriented design, databases, threads and locks, testing, and a few others. So you can choose chapters rather than reading cover to cover.

If the coding round is an algorithm problem of about 45 minutes, read the Big O and technique chapters first. Then work through Arrays and Strings, trees and graphs, sorting and searching, and finally recursion.

If the coding round is a production-style build, move on after the two opening chapters to Object-Oriented Design, Scalability and Memory Limits, and Threads and Locks. These three chapters come closest to the kind of real work this round simulates.

Imagine the task is to write a tool that reads logs and counts errors per service. Then two requirements are added: the log file is larger than memory, and several threads write at the same time. At that point, the chapters on memory limits and locks are exactly what you need.

Turn practice into evidence on your CV

Educative advises asking the recruiter to confirm the interview format, and that should be the first thing you do. One email in advance can save you two weeks of grinding dynamic programming for a round that has no such problems.

Then turn what you have practised into something others can see. A small repo whose commit history shows you extending the code through two or three requirement changes, with notes on complexity, says more about you than a line reading “solved 300 LeetCode problems” on your CV.

Cracking the Coding Interview remains a solid foundation for the coding round. For FDEs, the effective way to read it is to study the two opening chapters closely, then choose the rest according to the format the recruiter confirms.