michael_mroczka

Hot take from the author: This is a commonly repeated claim, but it’s probably not accurate.

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.

Ok friend. :)

I can see how you’d get to that conclusion, but I don’t agree with this take. “No value” is particularly strong wording. This is a fairly simple, cheap, and fast process for screening people at scale (think “hundreds per week”), I agree that startups mostly shouldn’t rely on this type of interview (and most don’t from what I can gather).

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.

Hey, thanks for the support. You can always reach out to me directly on Discord if you need anything. Nil and I wrote all of the technical content for the book, so we are happy to help in any way we can and do our best to stay available—especially to our supporters! :) I hope to see you there!

Nah, I totally understand where you're coming from and didn't feel attacked. I responded to your reply! :)

I love this comment, and as an author of this book, I don't disagree with a word of it.

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

I added my response in this thread! :)

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

> Asking this question will show an eye for detail and a solid foundation in computer science.

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 it helps, we (the authors) didn't even post this to HN (or ask someone else to). We definitely will answer questions as they come up though. And we were giving away free chapters from the book before today and are just linking to it. I don't see anything we're doing that is breaking the guidelines. Lots of authors chime in when their posts/articles/books are brought up.

Oooh, I'm a BCtCI author, but I admit Sedgewick is the algo expert! His book is more about data structures and algorithms than about coding interviews (related but very different).

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.

Happy to help. :)

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!

If it helps, I (Mike) don't know who @stmw is. I can at least say they aren't one of the four authors of this book.

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. ¯\_(ツ)_/¯

Hey friend, totally okay if we don’t see eye to eye on this. No big deal. But just to share my perspective—if you ask ChatGPT to break down a genuinely hard, new problem (not something that’s been around forever with tons of tutorials and blog posts), the explanations tend to stay pretty surface-level. For example, you might get something like, “We need to use DFS because we need to search the graph.” It doesn’t really get into the deeper reasoning behind why that’s the right approach or what led to this decision when others were possible.

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. :)

https://bctci.co/free-chapters

Hey, I know Shaun personally, and I think his book is excellent. Our books, despite seeming similar, are very different. His is about recognizing preset patterns, and that is about the extent of it. No outreach advice, negotiation strategies, resume opinions, behavioral help, etc. His book also seems to focus heavily on quantity, as he ends up going through 100+ leetcode problems.

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

Hey there, I'm the Mike (an author of BCtCI). I totally get where you’re coming from—there are a lot of flaws in the interview process, no doubt about it.

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.

Appreciate the comment, and you're completely right. Our whole thesis is that doing what everybody else is doing will get you the same results that everybody else is getting. :)

You got me! Hahaha :)

AI can absolutely help you. A lot of the benefits of the book come from the reasoning, though, which AI cannot do. For instance, you might try a question, and the optimal answer uses a heap, but how did we intuit that? What repeatable reasoning steps could we walk through to do that for a different problem? That's what 500 pages in this book is about. XD

> In addition, the book doesn't seem to cover systems design which is an extremely critical part of the interview process for L4 and above.

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.

Agreed. The book talks about niche topics in more depth than most resources online. In addition to all the topics in the book, we're actively releasing free online chapters each month covering more niche topics found in interviews.

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

You're 100% right, but I think your experience is different than recent job seekers. I think this is mostly semantics. You're asking simple problems and are amazed at the number of people that can't do them.

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).

The implied assumption here is that if you can figure out the number of anagrams that can be made from a given string in just 30 minutes, you probably are smart enough to set up a web server in a couple of days with documentation and ChatGPT to guide you.

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.

Your thought is a good one, and I think it is a valid approach. The barrier that comes up when doing this is still going to be cheating. How do you separate the people who are cheating on these at-home tests?

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."

Let's keep it civil, my friend. I totally get the frustration with leetcode-style questions and acknowledge that they aren't perfect. They can indeed overlook the diverse strengths that experienced engineers bring to the table. My perspective is that understanding the basics, like the efficiency of different data structures, is crucial, not just for interviews but for making informed decisions in our work.

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. ¯\_(ツ)_/¯

> We may need to design new kinds of interview questions and methods for humans augmented by AI.

Exactly. That's all a Custom question really is. Questions that are resistant to AI

I can't imagine many companies going back to this. The savings are too shiny to resist

So true!

It's a good question. In short, yes, I believe it is reasonable to assume custom questions will generally perform better than verbatim or modified leetcode questions. In general, while ChatGPT could handle modified questions well enough for interviewees to pass their interviews, it still choked through them and required more coaxing to get an answer than verbatim questions.

Custom questions, by definition, aren't available online, and with no direct tutorials to pull from, the LLM has to make more inferences about the problem and will find the question more challenging.

As for asking ChatGPT novel DS&A questions, I think it is harder than maybe you'd think it is. Any question you'd think to ask likely has a tutorial for it online somewhere, so unless you happen to make up questions like this professionally (I'm paid to do this), or you have a large unique question bank that doesn't exist online (few people have this) then my instinct would be that the questions you're giving it aren't as unique as you think they are.

As a practical example, just give it a log file and tell it to pull out specific pieces of information from it. ChatGPT struggles to write code that can dynamically check obvious boundaries for humans. Recently, I had a list of times in a CSV that I asked it to pull for me ("1pm", "3pm", "9am"), and it wrote code to just grab 3 specific indices from the string. It didn't consider the need to check for 4 indices ("10pm"). It didn't think to start the check based on where commas were in the CSV, and it didn't consider looking for "am" or "pm". It just sliced a specific set of indices in the string. That's mostly because it's used to getting questions working for specific examples, but fails when you ask it to incorporate simple broader tasks into the coding interview question.