Hey, thanks for the book shoutout. I'm glad BeyondCTCI was to your liking, if nothing else. We spent a lot of time on those tips, so I'm glad you thought they were helpful. :)
-Mike Mroczka (author of BCTCI)
155 karma · joined November 3, 2023
-Mike Mroczka (author of BCTCI)
It’s FAR easier for companies to stick with the interview process they’ve used for decades—just mandate in-person interviews again—than to reinvent the wheel with some new, unproven format. Sure, there’s a growing need to assess more than just DS&A in initial screenings, but let’s be honest: those interviews aren’t going anywhere.
The REAL reason to make these resources free? Because it’s not a competitive advantage to offer problems to practice. There are already tons of free problems online. The real value isn’t in giving people a place to do problems—that already exists. The value is in the book. If you already know enough to do well on problems without the book, then you shouldn't have to pay to practice it.
None of us authors are advocating exclusively for this interview type. Designing real-world systems is great, which is why most big tech companies have system design rounds in their processes (except for new grad interviews).
Finally, speaking as someone with diagnosed severe anxiety and a specific disorder that causes frequent panic attacks, I completely empathize with being a “fish out of water” in this process. If it helps, you should know that most big tech companies have accommodations for such things depending on your needs (extra time, allowance of service animals in the interview room, etc). I’m not sure any interview process will be anxiety-free (it isn’t for “normal” people either), but through time and effort I have passed Google, Meta, Amazon, and other big tech interviews that have this process. In my experience, these are hindrances to be addressed but not immovable blockers to passing an interview.
A common misconception is that Gayle's original book put forth the "right" way to do interviews. Gayle neither invented or encouraged the current interview structure. Gayle discusses the timeline in more depth in a Blind AMA thread you can find online. I think a lot of people are under the impression that books like thes somehow steer the interview process toward this style of interview. At this point, all we are doing is looking at the process as it is TODAY, and trying to help provide transparency and equal information to everyone. We spend several chapters in this book talking about how broken the process is and making similar points to you, but we can't write a book on an interview process that doesn't exist and while Gayle's original book is well-circulated, she (or any of the rest of us authors) doesn't have sway over how big tech companies conduct their hiring.
With that said, I think we are seeing companies start to incorporate other interviews precisely for the reasons you've mentioned. It isn't uncommon for smaller tech companies especially to have a DS&A interview, but also include a system design interview, and maybe even a practical "build something simple like a tic-tac-toe game in front of me while I watch" kind of interview. I do believe things are getting better and more fair over time (remember two decades ago Google was literally asking riddles in an attempt to screen people). I don't buy into the narrative that these interviews should go away entirely (and if they did, it would take at least a decade) because they are still a reasonably effective way to interview people at scale. The Pragmatic Programmer guy actually had a great take on this here: https://x.com/GergelyOrosz/status/1891212829346435103
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).
My friend, you've clearly got the wrong book. I think there might be some confusion here. That exact sentence (as you've written it) doesn’t appear in our book—I just double-checked the digital version. None of the phrases “eye for detail,” “solid foundation in computer science,” or “asking this question” show up, either individually or together in our entire book.
If you're saying it is in the original Cracking the Coding Interview... ok? The book is a decade out of date at this point, and the originally linked post makes it clear that this book is very different from that one.
If you needed to completely learn data structures and algorithms from scratch, I would NOT recommend his book, but instead, his FREE COURSE since it is so much more visual (and free): https://www.coursera.org/learn/algorithms-part1
For what it is worth, taking a course on DS&A is very different than getting good at these interviews for most people. The two are closely related but very different.
The book also has a discord server (link in the free PDF!), so if you have other questions, feel free to ping me there with them! We are about to start the weekly leetcode contest, and there will be a write-up after it finishes on which techniques and templates we've used from the book, which might give you more of a sense of how different it is. Hope to see you there, my friend!
That said, I don't think the reasonable conclusion to come to when someone is supportive of a product is that they are invested in it. Sure, suspicion is a healthy thing, but for the record you can look through my comment history and see I recommend LeetCode and a coding book called EPI. No compromising connections—I just like the products and let people know about them when I see people talking about the topics. ¯\_(ツ)_/¯
There’s actually some interesting data on this here: How hard is it to cheat with ChatGPT in technical interviews?
Even AI experts point out that parroting tutorials isn’t real reasoning, and that’s still a tough spot for AI.
All that said, even if AI improves, I still think this book offers a lot of value. It’s packed with new templates and practical strategies to help you get unstuck during interviews—stuff based on data from over 100,000 mock interviews. No pressure if it’s not your thing, but if you’re curious, you can check out some of the technical (and non-technical) chapters at the link below. They cover approaches you definitely won’t see ChatGPT come up with. :)
I'd heartily endorse his book, but they definitely are more different than similar. EPI is also another excellent book with a very different style.
Here is a link to nine chapters of Beyond Cracking the Coding Interview for free in case you're still curious about it: https://bctci.co/free-chapters
When Cracking the Coding Interview was originally written, the intention wasn’t to claim, it as a perfect process and to give ideal questions that should be asked. In fact, there are many questions in the original book that I wouldn’t recommend any interviewer use. The real purpose was to shed light on a process that had been shrouded in secrecy for decades, long before the book existed.
The reality is, like them or not, these types of interviews aren’t going anywhere—whether or not resources like mine are available. So the real question becomes: Should the process remain some insider-only system where only those with well-connected friends know what to expect and how to prepare? Or should we make it more accessible, ensuring that everyone has a fair shot with similar resources?
For me, the answer is clear: transparency and equal access for all. It’s not about endorsing the process—it’s about making sure the playing field is level.
It's called Cracking the *Coding* Interview for a reason. We don't talk about databases or concurrency or system design or meta-programming or any other topics that would take an entire other textbook to cover. It would be impossible to do it justice.
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.
In the current job market, however, lots of places are asking ridiculously hard verbatim leetcode questions in an attempt to filter out "bad candidates." Job seekers feel that too many places ask unfair questions (which is true) and employers feel that there are too many candidates that can't write genuinely simple programs (also true).
While the above sounds sarcastic, honestly, it isn't as ridiculous of a thought as it sounds. I don't think being good at DS&A problems guarantees that you're a good coder, but in general, the people who get good at these problems are also great coders. I can think of less than a handful of people who are good at CS problems but bad at actual coding.
Salesforce had a good interview practice a few years back where they invited you to a meeting. Started a recording, then asked you to keep your microphone and camera on and do several simple programming tasks. It was an "open book," and you could use whatever you wanted, but you just had to show how you got to where you were (and you could only use one monitor so that it was clear what you were looking at at all times). The engineer who met you on the call left after just a couple of minutes, and you could work in peace without having to worry about "entertaining them."
I'm not advocating for spot tests on complex algorithms without context. However, I believe a conversation about fundamental concepts like big-O notation reflects on one's approach to problem-solving and software design. It's not about dismissing anyone's experience or capability but ensuring a solid foundation that benefits all aspects of engineering work.
I understand senior engineers being out of practice and not being able to derive things like topological sort on the fly, but an inability to talk about the basics of big-O or the simplest of data structures is more commonly a red flag than "rust." If they never learned the material, that's a red flag. If they learned the material and they've been building software for the last decade without taking the basics of the material into account while coding, then that is a red flag as well.
Again, happy to admit that this is a flawed approach that will lose some great engineers, but most engineers that have your line of thinking are ones I actively avoid hiring. These concepts are practical, available to learn for free, and easy to understand. If an engineer feels that testing these concepts is beneath them, then they definitely aren't a good fit for any team I'm on. Big-O is to software engineers what Ohm's Law is to electricians. Imagine a world where electricians thought it was demeaning to talk about Ohm's law in an interview. ¯\_(ツ)_/¯
Exactly. That's all a Custom question really is. Questions that are resistant to AI