We've gone away from system design interview questions on my team. We ask people to diagram something technical they understand well and the team digs in and asks questions to understand depth and breadth of the candidates understanding. For us it works much better. It's a chance to see how well candidates do in following instructions. It gives you a chance to explore depth and breadth of their knowledge on something technical that they claim to understand. Our philosophy is how well you understand something you claim to know well is indicative of the depth and breadth of your technical knowledge in general. There are plenty of opportunities in this to ask about design and get to know how people think when it comes to design. I think it helps to eliminate false negatives and false positives.
I am on the interviewer side of ~1 system design interview per week and have done probably around 100 of them at Google and other companies.<p>Most of the advice here is good, although it could be condensed quite a bit.<p>The biggest red flag for me as an interviewer is when candidates list off concepts or technologies they don't understand. DO NOT say things like "we can't do this because of the CAP theorem" or "we should add a cache to reduce latency" unless what you are saying is true and you can explain why this is true (the guide mentions this).<p>The biggest green flag is when the candidate obviously has thought deeply about related problems and made design decisions based on real world constraints and requirements. If you bring up a lot of related things you have worked on, explain why you made the decisions you did in those scenarios, if its obviously related to the question, and if you don't spend too much doing it, then you will definitely get a positive recommendation from me.<p>The purpose of the system design interview is to convince me that you could build, or lead a team to build, the thing that we are discussing at a company like the one where you are interviewing. I feel like I can easily see through interview practice or coaching, so I don't recommend spending more than an hour or so "preparing" for system design interviews. Unless you are interviewing somewhere with very inexperienced interviewers...
I got such fatigue from scrolling through so very much prologue, introduction, expectation-setting, and general "here is what we are going to say and here is how you may expect we will say it" fluff that I gave up, pages in, before getting to any apparent content.
I will read this as it seems really good.
However, it always feels like a catch-22 problem to me, in the sense that, if you've never worked at a large company before, you can't claim to have truly used or understood large scale systems properly to work on them or design them in production.<p>I got rejected from a large tech company after failing system design and this was exactly their reasoning: "you seem to know the concepts and the theory really well, but, it was obvious to the interviewers that you lack the real world experience and hiring you would be a risk".<p>Obviously I... knew or at least tried to know the theory because I PREPARED. I read books, articles, practiced mock problems, watched YouTube for a few weeks, etc, etc. I just tried to "drill" the knowledge that was not there into my brain for the purpose of passing the interview. I guess that's what a lot of people do.<p>So yeah, it left me really down for a few months and feeling bad about myself and like the world sucks. So, how are you all out there "faking it till you make it" in a convincing way?<p>Because I bet that no engineers at a FAANG will alone design a full scale system on their own ever, so I doubt the usefulness of the "signal" these interviews give, but, ofc, that's just me, someone who prepared for months and failed
I think to be frank, this gamification of interviews is BS.<p>I’ve built actual production systems at scale. The fact that I need to follow a guide to “demonstrate” my ability to someone who 9/10 hasn’t built (or couldn’t build) anything at scale in production shows where we are in the absurdity matrix.
<i>"You can pass system design interviews even if you’ve never designed distributed systems before. If you have copied files between machines with drag-and-drop, you are halfway there. If you implemented clients or servers or have opened network connections, you’ve got this. This guide will teach you the most important 20% of information that will appear 80% of the time in system design interviews. By the end of this guide you won’t be an expert, but you’ll be well on your way to being a better engineer and a much better interview candidate."</i><p>A better engineer, no less! Wow, this must be some magical guide. I have to read it now. Also what does this say about our industry. "You want to be a surgeon but don't have the experience? Ever cut a tomato? You're halfway there. If you've ever made a sandwich, you've got this. Nurse!"
A senior interviewer's guide to the system design interview*.<p>I've speed read over the existing two sections and while it's informative, I'd argue that the maybe 10+/12 of the core design concepts are things that someone with a formal CS education should have picked up - you don't need to be a senior software engineer.<p>The barrier is knowing how these things can be pieced together to make a system from scratch which is the more difficult part as it is a much rarer occurrence in most people's experiences. Even seniors may not have much experience in setting up large scale systems (depending on your definition of senior), so at the end of the day anyone that studied or memorized the material is good enough to pass - practical experience or not.<p>I'd much rather have a high level view of an existing or theoretical system, be provided with some issue that occurs, and be asked for ways to diagnose and remediate said issue. Forget the dance around setting the system up. This is similar to the practice of providing existing code in an interview, describing a bug with the code, and watching the interviewee debug and fix it - but with systems. It mirrors actual work more closely.
I remember once I was interviewing for a senior position where the ask was something like "design a general purpose system for a REST layer on top of an ORM."<p>I had just finished implementing an OSS solution that did exactly that, including some upstream changes we made to improve the system, so I walked through exactly what we did, challenges we faced, etc.<p>I walked out of the interview feeling as though the interviewers and I didn't speak the same language; they might've said the same. Not only did I not get the job, I never got another communication from the company.<p>To me, senior level interviewing, especially at smaller companies, is fraught. A full 1/3rd of the companies I've interviewed at would not have been a good "culture fit," and I'm a picky interviewer. I expect, like coding tests etc, these interviews are not aligned with the real travails of the position - growing talent, managing time, triaging, and ensuring stability/capability.
Issue with system design is that our industry is so highly opinionated about things. You design something to the best of your abilities, it works (though may have its pros and cons) and then you go present it to a crowd of engineers (HN, say) ... and you get destroyed. There will always be people telling you that these were dumb choices and that that's obvious. And if you go and do what they say is the obviously better solution, then the exact same thing will happen with another crowd.<p>Our field is too immature to actually agree on things being good or bad.
> <i>Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt.</i><p>As someone who has conducted countless interviews at a FANG, I can not stress this point enough. The ability to just talk about a problem makes a big difference between a mediocre interview and a great interview. Besides, it's what makes an interview fun or lame.
Are these interviews turning into a "can you regurgitate some memorized information" formality?<p>As an interviewer: This is always a red flag to me, because being a successful software engineer is much more than memorizing common truisms. (I spend a lot of time cleaning up misinterpreted "truisms.")<p>As a candidate: If I'm expected to regurgitate truisms, it's a flag that trying to do things "right" will be opposed by people who don't understand how computers / information work; and a lot of friction will come from trying to make something work versus make something fit an inappropriate ideal.
I do believe this is probably useful for people interviewing, but on the other hand it reads like mostly complete bullshit and largely social signalling rather than measuring any sort of skills.<p>The fact that you can be coached to pass these interviews with zero practical experience designing systems (Even toy ones or hobby projects) shows that there is very little technical skill involved.<p>Someone who has designed a real production system is still likely to fail these interviews unless they understand the social nuances that interviewers are looking for in a system design round.
This is, unfortunately, painting an overly rosy view of the interviewer.<p>A lot of the time your interviewer is just going to be some senior person with an interview guide. They'll be asking you to design Netflix, without any experience with video or streaming themselves.<p>Rather than "trying crazy stuff", I've found that an important step is asking a few questions early in the interview to see if they understand relevant concepts. You can't take it for granted.
I think it's funny how they say you don't need experience to pass one of the interviews. Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. That and I kept trying to extract imaginary requirements. I still have no idea what they wanted to hear so I just name-dropped architecture paradigms. Didn't get the job.
I read all 4 parts in the pre-released version on the interviewing.io discord. Here's my feedback:<p>Loved how much they go into the actual interview dynamics and phrases to say, where as other resources wave away interacting with the interviewer as an implementation detail. Haven't seen that anywhere else on the web and it's super helpful. The framework is also much more fleshed out than, for instance, the HiredInTech system design guide.<p>However, the 12 tech ideas section was a little too dumbed down for me, though it might be helpful for someone with less experience. I also noticed a few typos (MangoDB, cache vs hash) and told them, and they said they'll fix it in the next version of the guide.<p>3.5/4 stars; would read again
Quick thoughts:<p><pre><code> - System design interview changes depending on the company. At Facebook the interviewer said one sentence in the whole interview to me, no feedback or anything, so be prepared for nasty ones. At Google they hate if you use a particular product to solve your problem and everything needs to be backed up by numbers; they'll ask you how many servers you'd need for your solution ("bill of materials").
- Expanding on last comment, it's common to see in books and courses a basic math of number users -> estimate usage -> requests per second and storage needs but I've never seen anyone take one estimates about servers by computing processing (CPU/RAM) needed.
- This guide, like almost all resources in particular takes on the most common case of web design: client-server request/response (plus queuing). There are other completely different paradigms that show up less frequently and are harder to have experience on, like streaming and batch processing.
- As all guides given space/time limitations, some key concepts are hand-waved with a recipe-based approach.</code></pre>
I develop desktop and embedded applications, so do a different work than distributed systems engineers, but I wonder - do you often build systems from scratch and therefore need to have all this knowledge?<p>Because in every job I've worked in the past 10 years, I landed in an established project, that was developed years ago, and my work was to maintanace and add new features. Most of these projects were too big and complicated for one person to know how they work in every detail - even the ones that were there for the very beginning always said something like "after all these years I don't know how half of the things are implemented".<p>So, from my perspective, an interview question where someone asks me to design a complex system entirely on my own, in details, is just stupid, as I am pretty sure I will never do anything like that in my life. But maybe webdev is a different story?
I've only read up to Part Two so far but find the guide is extremely helpful and resonates with other resources (i.e Grokking the System Design Interview) and with my own experiences for what I believe is the very broken interview process that we face today.<p>Highly recommend. Interviewing.io is one of the best resources for those doing prep today and the team behind it is awesome.
I love the content that interviewing.io puts in this category on their YouTube channel. What was especially eye opening is seeing two senior engineers that normally conduct systems design interviews taking the driver's seat. <a href="https://youtu.be/Zi0pPkiFemE" rel="nofollow">https://youtu.be/Zi0pPkiFemE</a><p>TLDW; they struggle! big time!
I think there may be an error in part 2 of this guide where it talks about ACID.<p>To my understanding, the C (Consistency) in ACID is referring to the structure of the database. In other words, a SQL table can't be updated in such a way that violates the column definitions and constraints defined by the table.<p>In this guide, it seems to be talking about strong consistency vs eventual consistency when discussing ACID, which, to my understanding, is a different topic entirely, and refers to the timeliness of accurate reads.
As someone that is still in undergrad but will be entering the labor market in a few years, this entire process makes me incredibly anxious to think about. Reading what some people go through to find decent jobs has been a huge stressor throughout my undergrad career. I was lucky enough to secure a good internship this summer (which took months of searching and getting ghosted). I’m not excited to run the rat race again once I graduate—that’s for sure!
A lot of system design guides do enunciate on the fundamental concepts of system design such as scaling, design patterns etc. But explaining how to actually approach the problem before the interviewer and explaining what they're looking for and not looking for is what makes this guide unique. Otherwise, by the time the candidate gets to the meat of the problem, the interviewer might have already lost interest in them. So great job guys!
First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies.<p>...that said. This kind of thing annoys me. You shouldn't have to study for an interview. Either you meet the requirement and have the experience or you don't. Reading books and stuff like this is really a cheat by the person being interviewed. You many have studied enough to "pass the test" but you really don't have a deep usable knowledge of the material and will likely forget much of what was studied.<p>When I do interviews I make sure the candidate is aware that studying will be a pointless endeavor and if I can tell your answers come from one of the interview prep books I'll end the interview early. My interviews ask questions that will tell me if you REALLY know the subject. For example if JavaScript is a requirement I'll throw this at you<p>const a = [1,2,3,4,5,6,7,8,9];<p>const b = a.filter(x=>1);<p>if(!!1 && b.some(e=>e>6)){<p>foo();<p>}<p>and ask you to tell me what it does. Its totally weird code and seeing that in actual code is highly unacceptable BUT if you really know JavaScript you will be able to tell me what this does in less than 30 seconds. Immediately if you're going for a Senior position.<p>I'm known for hiring the best engineers.
I'm very excited to see a guide that focuses on the process of the interview itself related to system design. There are plenty of "how to design twitter" resources out there, but for many of us, we really need to better understand the system design interview process itself. Thanks so much for putting this together, can't wait to see parts 3 & 4!
I love a few things about this guide. Firstly, that is acknowledges the fact that interviewing for a thing is different than actually doing the thing. Secondly, that it takes the position that system design interviews are (or should be) more about _how_ you approach a problem than about knowing the details of distributed systems.
This generally seems like good advice, but it does veer occasionally towards suggesting ways to <i>appear good at system design</i> when actually the point of a system design interview is to <i>show the interviewer how good at system design you actually are</i>.<p>This is an important distinction because it is not necessarily the case that the only way to pass a system design interview is to come across as being brilliant at it. I will happily take on a developer who shows that they have some good system design instincts but lacks a mature approach to engineering decisionmaking (assuming their other interviews show that they seem teachable and they have the other prerequisite skills). Not every developer is going to be a lead system designer. The interview is to help us figure out what kind of developer you <i>are</i>.
The repetition of "this is different from code" strikes me as odd.<p>The way I see it, it's identical to code, it just involves more moving parts.<p>> If two experts designed the same system, you would see two different designs, beautiful and aesthetic in their own way and both as “correct” as the other (and with the accompanying justifications to support them).<p>That is nonsense. Systems can be optimally designed too, just like code. Even if you have two systems that both meet the requirements for features, performance, reliability, and cost, one is usually objectively better by surpassing the requirements more than the other.<p>Would you like solution A that is identical to solution B in every way, but can be run with half the hardware, or do you want solution B? Of course you would want solution A.
Interviewing (especially system design) is a skill you have to learn these days. It's also a performance. You can complain about how flawed it is all day, and believe me I do (I'm a staff FAANG swe), but you gotta play the game. Knowing how to methodically break down the problem into smaller components and be able to confidently present the information in a manner that's easy to follow/collaborate is actually a real on-the-job skill of any experienced engineer. You have to be able to demonstrate this in an interview. The people at interviewing.io are legit and this guide is a great prep tool
I really like how the guide is still being worked on, and it has left some breadcrumbs for the readers regarding "what to expect in the future?". I am prepping for interviews and really like how this guide is structured!
Since we’re talking systems here and reasoning from some provided constraints:<p>> We began by listening to 30+ hours of system design interviews and system design lessons. We then performed data analysis to identify 50+ of our highest rated interviewers.<p>At an average 30 mins an interview, that’s 60 interviews in the data set this is based on. That seems like a disproportionate sample to form general advice. That doesn’t mean it’s bad, but does likely bias heavily to a subset of system/interview styles.
Can we stop saying that the 'over engineering interview' is a 'system design interview'?<p>Most real life problems don't get solved by adding queues and moving to an event driven architecture with thousands of micro-services.<p>What I'd expect from a senior engineer is deep technical understanding of how a queue works (epoll, poll, io multiplexing, io non blocking, readiness) for example.
Why would a senior engineer do a system design? Isn't that a role of architect?<p>For me that questions are in line with the "how much tennis balls would fit in an airlplane?" - fun, but are orthogonal to the SWE roles.<p>How often SWE does a system design? Maybe in small startups.
best system design interview advice i got (and put to successful use in loops with goog and fb) was to not try to give the "right" answer -- it's like a professor grading papers on a topic they've taught countless times, you have more of an opportunity to fail than you do to succeed. instead, be decisive and give answers or approximations for any questions that arise, and bring your unique perspective to the problem -- in my case i have a background in mobile app development, so i spent a lot of time speaking to those use-cases.<p>if you try to cover every base and fret about everything being optimal, you're going to barely have time to get started.
It is like asking who watched most YT-vids. Seriously, I think you need to do both.<p>A question suggestion: Show a medium-sized system design and ask which resources that should be removed.
Performative interviews are bullshit. I’ve been working as an Engineer for 20 years - successfully. But you want me to “whiteboard” like a trained monkey?
i am having a problem understanding why FAANG is gatekeeping system design<p>google - search is broke, youtube doesnt make money and is a hotbed of predators<p>facebook - should basically be in prison for aiding war crimes and child suicides<p>netflix - is quickly circling the drain because you can't algorithm creativity<p>amazon - almost all of their products and services lose money<p>apple - siri is slightly better than stubbing your toe on a sharp metal object
thought interviewing sucked before?<p>now your resume is in a stack with 300 other dev resumes instead of 3<p>honestly I may just make my current tech job my last, its increasingly not worth it to get waterboarded like this just to write unit tests