System Design Interview book review
blog.pragmaticengineer.com
blog.pragmaticengineer.com
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).
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.
> 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.
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!
We really need to fix the tech interviews.
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.
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.
There are not nearly enough high quality resources on system design.
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.
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.
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.
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.
(When you have to explain it, you realize that a lot of common terminology in the "tech community" kind of sucks!)
DDIA is to system design, as a computer science textbook is to the algo interview.
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-...
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.
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.
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.
It is available on O'Reilly/Safari
* 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.
is there a good ressource to add on the top of DDIA that will reflect some recent changes in system design?
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.
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=PLWl7jvxH18r0u5VRZsOjh...