That this book and the very similar "Grokking the System Design Interview" (I went through both) get accolades just shows the poor resources we have.
What we need is more "Designing Data Intensive Applications", adapted to interviews.
Just as a couple quick comments, the "web crawler" scenario suggest a breadth-first search, which is OK (as in compared to depth-first search) but not good enough; web links in general is not a DAG and you can get into a loop. As another comment, in none of these two resources there's a single estimate that I can remember about how many servers you need as per requests/bandwidth etc, only calculations are about data amount. They also assume collaborative interviewer, which has never happened in my experience. I think none of these two resources by themselves would get you a L5 or even do well as L4 at FAANG (please somebody correct me), they are very basic (maybe I'm "too advanced" heh).
Yeah, SDI doesn't do a very good job of actually solving that chicken and egg problem. It tends to give a "solution" without motivating the design decisions.
After reading about 80% of SDI and not much else, I failed a system design interview when I provided the "right" answer of putting an async task on a messaging queue, but couldn't explain how at-least-once delivery could be used to deal with a flaky task.
I think I've filled a lot of these gaps now (passed L5 system design at Google for example) but there wasn't really a single efficient resource that helped me do so. DDIA is awesome though.
Most system design resources are either too shallow (Grokking, system design primer, etc) or fairly deep (DDIA). There's not a good middle ground.
> would get you a L5 or even do well as L4 at FAANG
Imo, the system design interview is actually about communication and not purely about design. Explaining your thought process, how you work with others, how you identify bottlenecks, how you think about the problem space.
There's a difference between being able to interview and actual system design in the real world. You'd be surprised at how surface level system design interviews are. Often people with real world experience do poorly because they dive too deep or know too much and the interviews are generally short (45 min). There are also no real set standards, unlike algo problems where there is a fair amount of theory around time complexity.
My amazon interview was mostly cribbed off grokking uber design and I passed.
The fact that you passed Amz sys design simply tells me that you are good at studying and absorbing existing knowledge however shitty or flaky it might be. I think its an important skill to have and I guess thats also whats tested in interviews. Its like "this is the syllabus how much of it do you know".
> They also assume collaborative interviewer, which has never happened in my experience.
As a FAANG interviewer myself, this is very sad to me. System design interviews are inherently collaborative and they can provide a pretty good signal on "do I want to work with this person". I thoroughly enjoy conducting system design interviews -- It's always a joy to talk through the problem with the candidate and sometimes I even get to learn something new myself!
In my personal opinion the biggest trap I see is other interviewers falling into a rut: they've asked their question hundreds of time and already know what they want, robbing it of that vital collaborative aspect.
Make sure to cycle what you ask, so that you can continue to be pleasantly surprised in interviews and remember that it's a 2-way street.
Design interviews are so much more pleasant (and imo higher signal) than coding interviews. I remember the sobering moment I interviewed with another company and was asked a question I myself had asked before 60 times before, having believed it falsely to be unique and clever. It's turtles all the way down.
>I thoroughly enjoy conducting system design interviews
As a seasoned vet in the area, I thoroughly enjoy participating in system design interviews. In 2019, I interviewed at Google, FB, and Microsoft. Each featured multiple System Design rounds and only one of two at FB was not very good. While the others were very interesting and interactive, the not so good one at FB was run by someone fairly junior who clearly didn't have much practical experience in designing complete systems, so it felt very one-sided and me constantly feeling like I was being patronizing since the lack of feedback really felt like lack of understanding.
What we need is more "Designing Data Intensive Applications", adapted to interviews.
Just as a couple quick comments, the "web crawler" scenario suggest a breadth-first search, which is OK (as in compared to depth-first search) but not good enough; web links in general is not a DAG and you can get into a loop. As another comment, in none of these two resources there's a single estimate that I can remember about how many servers you need as per requests/bandwidth etc, only calculations are about data amount. They also assume collaborative interviewer, which has never happened in my experience. I think none of these two resources by themselves would get you a L5 or even do well as L4 at FAANG (please somebody correct me), they are very basic (maybe I'm "too advanced" heh).