8 ms·

System Design Interview book review

160 points by gregdoesit 6y ago

posharma 6y ago
Designing Data Intensive Applications (DDIA) is the best book I’ve come across when it comes to serious system design.
- monster_group 6y ago
  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.
  - q3k 6y ago
    > 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.
    - vsareto 6y ago
      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.
  - decafninja 6y ago
    Sorry if dumb question, but what is "TFA"?
    - daemoncoder 6y ago
      ”The Fine Article” that this discussion is about :-)
    - chrishepner 6y ago
      It stands for "the f-ing article," i.e. the link in the original post. (When you have to explain it, you realize that a lot of common terminology in the "tech community" kind of sucks!)
- jorblumesea 6y ago
  DDIA is an amazing book, but it's way, way too deep for any kind of interview. If you read DDIA cover to cover, you know what I mean. DDIA is to system design, as a computer science textbook is to the algo interview.
fizwhiz 6y ago
This book will at best get you an L5 gig at FAANG; for Staff eng positions (L6+) you need significantly more depth and rigor.
- deleted 6y ago
  [deleted]
- dragontamer 6y ago
  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.
  - phlipski 6y ago
    Can you recommend any good primers/tutorials on "Tee's", sockets or pipes in unix/linux? You know - for us "hardware" guys to brush up on? :)
    - 6y ago
sna1l 6y ago
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. [1] https://www.educative.io/courses/grokking-the-system-design-interview https://www.educative.io/courses/grokking-the-system-design-...
lazyant 6y ago
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).
- jazzkingrt 6y ago
  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.
  - aalhour 6y ago
    Can you share more about what resources did you study to bridge the FAANG L5 gaps in terms of knowledge and interview skills?
- jorblumesea 6y ago
  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.
Crash0v3rid3 6y ago
Does anyone have any resources to practice back of the napkin type of capacity metrics that are often asked in these interviews?
- varunsaini 6y ago
  Simon from Shopify has this awesome newsletter to talk about some of these things. https://sirupsen.com/napkin/problem-14-using-checksums-to-verify/ https://sirupsen.com/napkin/problem-14-using-checksums-to-ve...
  - azemetre 6y ago
    He was also a guest on the changelog podcast where we talks about his process as well, well worth the listen: https://changelog.com/person/sirupsen https://changelog.com/person/sirupsen
vincentmarle 6y ago
> 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.
iooi 6y ago
I can't recommend this YT channel enough: https://www.youtube.com/channel/UC9vLsnF6QPYuH51njmIooCQ https://www.youtube.com/channel/UC9vLsnF6QPYuH51njmIooCQ It's so, so much better than "Grokking the System Design Interview", which I find infantile at best and definitely not worth any amount of money.
- jmoll 6y ago
  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.
- arolihas 6y ago
  It’s a shame they only have 6 videos and haven’t posted in a year.
x87678r 6y ago
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.
game_the0ry 6y ago
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.
- obviouslynotme 6y ago
  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.
finikytou 6y ago
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?
- ivzhh 6y ago
  My guess is DDIA + USENIX/OSDI/... papers.
sul_tasto 6y ago
Is there a way to stay on top of the research that’s referenced in these works?
stevetarzia 6y ago
This looks like a great reference book for the course I teach at Northwestern University (CS-310 Scalable Software Architectures). FWIW, my lecture videos from Spring 2020 are posted on YouTube, and I've heard from students that these are a good study resource for SWE interviews: https://www.youtube.com/playlist?list=PLWl7jvxH18r0u5VRZsOjhghNXc_Ec4dZz https://www.youtube.com/playlist?list=PLWl7jvxH18r0u5VRZsOjh...

160 points by gregdoesit 6y ago

posharma 6y ago

Designing Data Intensive Applications (DDIA) is the best book I’ve come across when it comes to serious system design.

monster_group 6y ago
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.
- q3k 6y ago
  > 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.
  - vsareto 6y ago
    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.
- decafninja 6y ago
  Sorry if dumb question, but what is "TFA"?
  - daemoncoder 6y ago
    ”The Fine Article” that this discussion is about :-)
  - chrishepner 6y ago
    It stands for "the f-ing article," i.e. the link in the original post. (When you have to explain it, you realize that a lot of common terminology in the "tech community" kind of sucks!)
jorblumesea 6y ago
DDIA is an amazing book, but it's way, way too deep for any kind of interview. If you read DDIA cover to cover, you know what I mean. DDIA is to system design, as a computer science textbook is to the algo interview.

fizwhiz 6y ago

This book will at best get you an L5 gig at FAANG; for Staff eng positions (L6+) you need significantly more depth and rigor.

deleted 6y ago
[deleted]
dragontamer 6y ago
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.
- phlipski 6y ago
  Can you recommend any good primers/tutorials on "Tee's", sockets or pipes in unix/linux? You know - for us "hardware" guys to brush up on? :)
  - 6y ago

sna1l 6y ago

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. [1] https://www.educative.io/courses/grokking-the-system-design-interview https://www.educative.io/courses/grokking-the-system-design-...

lazyant 6y ago

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

jazzkingrt 6y ago
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.
- aalhour 6y ago
  Can you share more about what resources did you study to bridge the FAANG L5 gaps in terms of knowledge and interview skills?
jorblumesea 6y ago
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.

Crash0v3rid3 6y ago

Does anyone have any resources to practice back of the napkin type of capacity metrics that are often asked in these interviews?

varunsaini 6y ago
Simon from Shopify has this awesome newsletter to talk about some of these things. https://sirupsen.com/napkin/problem-14-using-checksums-to-verify/ https://sirupsen.com/napkin/problem-14-using-checksums-to-ve...
- azemetre 6y ago
  He was also a guest on the changelog podcast where we talks about his process as well, well worth the listen: https://changelog.com/person/sirupsen https://changelog.com/person/sirupsen

vincentmarle 6y ago

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

iooi 6y ago

I can't recommend this YT channel enough: https://www.youtube.com/channel/UC9vLsnF6QPYuH51njmIooCQ https://www.youtube.com/channel/UC9vLsnF6QPYuH51njmIooCQ It's so, so much better than "Grokking the System Design Interview", which I find infantile at best and definitely not worth any amount of money.

jmoll 6y ago
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.
arolihas 6y ago
It’s a shame they only have 6 videos and haven’t posted in a year.

x87678r 6y ago

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.

game_the0ry 6y ago

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.

obviouslynotme 6y ago
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.

finikytou 6y ago

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?

ivzhh 6y ago
My guess is DDIA + USENIX/OSDI/... papers.

sul_tasto 6y ago

Is there a way to stay on top of the research that’s referenced in these works?

stevetarzia 6y ago

This looks like a great reference book for the course I teach at Northwestern University (CS-310 Scalable Software Architectures). FWIW, my lecture videos from Spring 2020 are posted on YouTube, and I've heard from students that these are a good study resource for SWE interviews: https://www.youtube.com/playlist?list=PLWl7jvxH18r0u5VRZsOjhghNXc_Ec4dZz https://www.youtube.com/playlist?list=PLWl7jvxH18r0u5VRZsOjh...