[HN Gopher] System Design Interview book review
___________________________________________________________________
System Design Interview book review
Author : gregdoesit
Score : 124 points
Date : 2021-01-05 16:18 UTC (6 hours ago)
(HTM) web link (blog.pragmaticengineer.com)
(TXT) w3m dump (blog.pragmaticengineer.com)
| game_the0ry wrote:
| 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 wrote:
| 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.
| vincentmarle wrote:
| > 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.
| finikytou wrote:
| 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?
| sul_tasto wrote:
| Is there a way to stay on top of the research that's referenced
| in these works?
| x87678r wrote:
| 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.
| fizwhiz wrote:
| This book will _at best_ get you an L5 gig at FAANG; for Staff
| eng positions (L6+) you need significantly more depth and rigor.
| dragontamer wrote:
| 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.
| Crash0v3rid3 wrote:
| 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.
| fizwhiz wrote:
| 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.
| hkarthik wrote:
| 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.
| fizwhiz wrote:
| 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.
| jazzkingrt wrote:
| I completely agree, but that population would be a pretty small
| readership.
| [deleted]
| lazyant wrote:
| 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).
| jorblumesea wrote:
| 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.
| jazzkingrt wrote:
| 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.
| techwizrd wrote:
| I absolutely agree regarding DDIA. I recommend it to all of my
| junior engineers.
|
| There are not nearly enough high quality resources on system
| design.
| posharma wrote:
| Designing Data Intensive Applications (DDIA) is the best book
| I've come across when it comes to serious system design.
| monster_group wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Sorry if dumb question, but what is "TFA"?
| daemoncoder wrote:
| "The Fine Article" that this discussion is about :-)
| chrishepner wrote:
| 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 wrote:
| 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.
| Crash0v3rid3 wrote:
| Does anyone have any resources to practice back of the napkin
| type of capacity metrics that are often asked in these
| interviews?
| varunsaini wrote:
| Simon from Shopify has this awesome newsletter to talk about
| some of these things.
| https://sirupsen.com/napkin/problem-14-using-checksums-to-ve...
| azemetre wrote:
| 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
| iooi wrote:
| I can't recommend this YT channel enough:
| 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 wrote:
| 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 wrote:
| It's a shame they only have 6 videos and haven't posted in a
| year.
| sna1l wrote:
| 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-...
___________________________________________________________________
(page generated 2021-01-05 23:02 UTC)