[michael_mroczka]

Hey, I'm one of the main authors of the book. Feel free to ask any questions if you have them. :)

There are many great resources that have come out since the original CtCI, but we waited to release this until we had substantially new advice to give that is different from other options.

TL;DR This book teaches you how to think, not memorize questions. And how to reason about your job search and handle recruiters

Here are nine chapters from the book that you can read so you can make your own decisions. They include:

- Seven non-technical chapters that walk you through important topics such as why technical interviews are broken, what recruiters won't tell you, why you should not spend a lot of time on resumes, and how to get in the door at companies without a referral.

- Two technical chapters covering the two easiest-to-mess-up-in-an-interview topics. Binary search & Sliding Windows. Our new take on Binary Search teaches one template that works for every binary search problem on Leetcode, with only a single-line change you need to remember. The Sliding Windows chapter features 6 unique sliding window templates that make off-by-one errors a thing of the past.

https://bctci.co/free-chapters

[harimau777]

I used interviewing.io's resources for my most recent job search; however:

1. Even once I studied enough to know how to use the more challenging algorithm techniques (dynamic programming, graphs, the more esoteric versions of sliding window, etc.) that still wasn't enough to pass interviews. The time I was given to solve the problems was so short that it would take me at least a month of practice to get fast enough at just one of the techniques.

2. It's difficult to predict what interviewers will ask. In a six month interviewing period I might only get asked a given advanced topic once.

I eventually gave up on becoming sufficiently proficient in more than the basic algorithm techniques. I couldn't realistically prepare for each of the algorithm techniques on interviewing.io and I couldn't predict which I was likely to be asked. It was just luck.

So I found that the best strategy was just apply to as many jobs as I could and hope that I didn't get asked one of the more advanced topics. In effect, if I'm reliant on luck either way, then I may as well rely on the approach that gives me more time to put in applications rather than studying.

I guess my question is what the intended use of this sort of book is considering the world we find ourselves in? That is to say: In an ideal world where interviewers care about demonstrating competency, then taking your approach of learning to understand the basic patterns that make up these questions makes a lot of sense (and would probably make people better programmings). However, in our current world where interviewers demand raw speed, that doesn't seem viable.

[leeny]

Shoot me an email at [e-mail] if you'd like some mock interviews on us. I'm sorry we didn't get you there... but if it's a matter of more reps to get your speed up, happy to get you those for free.

I hope Mike jumps in to answer your question about where the book fits in, in a world where speed matters more than it used to.

[michael_mroczka]

I added my response in this thread! :)

[michael_mroczka]

Hey, thanks for the thoughtful question! You’re absolutely right to point out something that a lot of coding interview experts don’t like to admit: interviews aren’t always predictable. In fact, one of the first sections in the book has each of us sharing a story about an interview we totally bombed. We also spend several chapters breaking down how flawed technical interviews can be.

The reality is, there’s no “interview police” making sure interviewers are asking great questions or grading on the right things. Speed, for example, is often overrated—it usually comes at the expense of correctness. While the interviewing.io learning center covers general patterns, our book takes things further by organizing topics based on dependencies, likelihood of being asked, and difficulty. We believe that the order in which you learn these topics really matters. Of course, most people won’t aim to learn everything—the focus should be on what’s most relevant given the time before an interview.

To answer your specific question, the book assumes you’ll typically have around 20–35 minutes to solve a problem completely. Some companies approach things differently—Meta, for instance, often asks two questions per interview and places a bigger emphasis on speed. That said, Meta interviews tend to be more straightforward these days, with a common study strategy being to sort tagged Meta-questions on LeetCode and work through the top 100. This is literally the process they encourage.

The good news? We’ve got solid data showing that most big tech interviews (outside of Meta) don’t put nearly as much pressure on speed. Of course, statistically, there will be other people expecting two questions per interview, but this isn't as common as the average Blind post would you have think.

We discuss speed in the book and how to get better, but it is similar to the old Marksman adage, "Slow is smooth, Smooth is fast." Speed comes with time, and without knowing how much time you already put in (or how you've been practicing), it is difficult to say a lot more beyond that. Feel free to ping me on the interviewing.io server if you want to discuss this further and I might be able to help.

EDIT: One extra thought. The resources you used to prepare on interviewing.io are very different from what is in this book (and the book content I'll say with humility is much better—and I wrote a lot of both). Don't take our word for it. You can check out the binary search topic in the interviewing.io Learning Center (which you can see I wrote) and then check out our binary search chapter at the link below for free (which I almost mainly wrote). You'll find the book materials are highly divergent (for the better).

https://bctci.co/free-chapters