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.
I would staunchly second this, as well as Designing Data Intensive Applications.
As this thread is alluding to a lot of system design resourcing is lacking, and IMO is fundamentally misaligned on what is inherently useful for people to learn from.
The majority of the system design resourcing targeted at interview contexts is all extremely contrived; The narrative is usually a paraphrase of a particular blog post about how a particular company solved their particular problem.
Don't get me wrong, this can definitely be useful, case studies can be enlightening, but for practical fundamentals it's misleading as it doesn't actually help someone think along the principal axis' of large-scale system design, or how to construct an organic causal narrative at how to arrive at this seemingly contrived solution. The reader will just come out of the 30 minute read, or 40 minute video, knowing how to implement a very specific system design solution, and would have trouble adapting and wavering away from it in a real world (and that includes interview) context.
The YT channel linked above, and the O'Reilly Designing Data Intensive Applications are so much better than anything else I've seen, and having been on both sides of the interview, it's pretty clear when someone has actually "grokked" system design, vs bullet consumed a bunch of blog posts and videos on "grokking" system design.
Agreed but that is not focused on interview prep. These days to clear tech interviews you have to "study to the test". So if you want to do real system design yeah study DDIA but if you want to clear a system design interview study books like the one in TFA.
> These days to clear tech interviews you have to "study to the test".
It might help, but it's not necessary from my experience. I've gotten into a FAANG company (an SRE position) without 'studying the test', just studying practically applicable materials. And I know plenty of other people who did the same.
This is optimizing for least study time (sometimes from zero knowledge) by studying to the test. If you're saying that studying applicable materials is quicker, then this book is useless. Once you've "made it", you can explore things at a more leisurely pace (notably while gaining experience).
I suspect the next thing to counter too much studying to the test will be to add an additional type of interview round (leetcode/system design/new thing) to the process, further extending it.
I enjoyed the Grokking the System Design Interview resource.[1]
I think what helps the most is not only solving the problems outlined, but adding new constraints and thinking through various failure cases that may be missed by some of the questions. This helps ensure that you understand the material and that you haven't just memorized it.
I have noticed that system design questions are asked in mid-level and even entry-level SWE roles. It's bizarre to me that expecting a fresh grad to build twitter is somehow an accurate assessment of that person's coding skills.
I think hiring managers have run out of hard questions to ask to sufficiently justify gate keeping the high-paying jobs they are dolling out - every grad knows to prep with CTCI, EPI, and leetcode; but what happens when all 10 of the 10 candidates you interview know how to invert a...whatever-tree in optimal O(n) in ~10 mins (bc they all used the same books to prep)? "Well, then you ask harder questions" is the superficial response from hiring managers. And that's how asking hard-level leetcodes in phone interviews becomes the norm.
I am curious to see how far this goes.
Remember the days when FizzBuzz would be sufficient to get a job? I don't, unfortunately, but perhaps some of you do.
We need to think harder about how we hire people. There are better ways.
Off-topic, but the chicken/egg metaphor can be used for any job in America (and probably the rest of the world), not just senior software engineering jobs. I had this problem when I graduated into the great recession in 2008 - every employer wanted 2 years of experience for entry-level jobs, not realizing or caring that you need the job in the first place to get that exp. And that's how you get a skills shortage over many years.
The problem is that the industry has been sold a lie that a magical team of 10X Rockstar 1337 developers can make designing and maintaining large and complex systems easier. Of course, US companies would never purposefully reject qualified candidates in an effort to get more H1B visas either.
In my day-to-day work, I operate at a rather low level. Hardware guys + the occasional assembly code. However, my command of Linux / OS-level stuff is far superior over my peers, and I'm able to occasionally write up a shell-script or two in a few hours that replicates something a peer does over a week at a low-level. (Hardware guys don't necessarily know that "Tee" exists, or how to use Unix Domain Sockets or pipes to their fullest extend)
Becoming the best in one field is almost impossible: there is always someone more studied than you. However, becoming "competent" in two or three different fields can lead to a strong advantage.
Yes, you should reach for depth in your field. But you should also reach for breadth when its easy. There are sometimes easy ways to differentiate yourself over your peers.
----------
I feel like there needs to be a good collection of books that teach the "simplest tricks" of a field.
Ex: Cryptography Engineering is the "simplest" explanation of cryptography. There's not enough math to understand any crypto-algorithm, but by just laying out the names of common algorithms + their common uses, the book teaches the "easiest" bits of crypto to those outside of the field.
Maybe that's the niche for this book? I haven't read it, but if its written clearly enough, it can be used for someone like me to explore a field I don't work in on a day-to-day basis.
--------
Breadth of study vs depth of study are two different styles of study. They're not necessarily more or less important... they're just two different ways of creating your own niche in your organization.
So I'm not a really good systems guy. Its more like, knowing random stuff sometimes comes in handy.
For sockets / pipes / terminal stuff in Unix, I ultimately just had to skim over "Advanced Programming in the UNIX Environment" cover-to-cover.
There's just a lot of things the UNIX dudes have already implemented with regards to inter-process communications, files, threads, processes, signals, and the like.
Once you know what UNIX (and Linux) have to offer, then you can start leveraging it. You don't really need to understand everything, you just need to know things to a level that "I can look it up later when I need it".
Again: you're going for breadth, not depth. Skimming over concepts and "remembering them for later". You'll know when you need it, and can come back to the book for depth later on.
---------
For "Tee", and "Awk", and "expect", and stuff... I followed blogposts at Linode and Slicehost back in the day which covered a lot of interesting sys-admin tricks. I'm pretty sure the Slicehost pages are lost (the company was bought out by Rackspace years ago. I don't know if any of that stuff was archived)
I never was a professional sys-admin. But knowing about Awk, Tee, or various other "standard command-line tools" that web-developers use all the time allows me to script up a lot of things related to testing code, Makefiles, and the like.
I basically got that experience from just messing with servers: trying to run my own mail server or web server on the side. Cronjobs, automation, etc. etc.
At L6+ you also need experience and war stories during the interview process. And a significant number of wins with broad impact that can only happen if you have the soft skills to make large change happen.
Absolutely; my response was more geared towards expectations in a design round. If you have the option to draw from personal experience / war stories then even better.
Can you give more details on how an L6 can pass these interviews? I’m planning a move to SRE sometime this month. I’ve been prepping quite a bit with this book so far.
I'm not an SRE, but for SWEs at that level you may expect a deeper discussion in:
* Addressing scaling bottlenecks with a large focus on reliability and fault-tolerance.
* Concepts orthogonal to the core ask (ex: security, privacy, auth n/z, compliance).
* Cost. Ultimately the most scalable architecture may not be very cost effective; the 2nd best option might be much cheaper and merits discussion.
These are for large scale design questions. Questions to L6 candidates are posed (deliberately) ambiguously to see if they can tease apart the important/finer details.
DDIA is a fantastic 2017 book but a few things went from must-do to avoid or at least think about it before doing it. we ve seen big changes into client side frameworks such as angular/react, nosql is less and less seen as something to look for first, scalability got somehow more complex and more achievable with cloud new features, client server best practices evolved a bit too. things like message queues or kafka are not as sexy
is there a good ressource to add on the top of DDIA that will reflect some recent changes in system design?
> The topic is somewhat a chicken-and-egg one. You'll know how to design a large system after you designed one before.
Yes, but doing a stressful interview is a different beast altogether. "Design YouTube in 45 mins" is something that you have to really practice, regardless of your experience. Glad that this book exists.
Its pretty sad at the end of the page it talks about other resources, the first few are 2008 ish. I'd expect them to be obsolete, but is that just become the industry standard now? FAANG SD interviews are such a mystery and the we never comment response doesn't help.
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).