53 ms·

A senior engineer's guide to the system design interview

909 points by leeny 4y ago

carabiner 4y ago
Bug: The YouTube video link at the top just takes you to youtube.com and not a specific video.
annshress 4y ago
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!
chrisabrams 4y ago
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!
Samit5174 4y ago
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!
Ozzie_osman 4y ago
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.
eternalban 4y ago
"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." 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!"
- rednerrus 4y ago
  It's kind of true if you just think about the beginning of the long tail as the end point.
- reactordev 4y ago
  The reality is you can become an engineer with no degree whilst you can’t become a surgeon with no degree. The criticism of the writing is dismissing that a lot of people want to go for that promotion or higher tier but due to imposter syndrome or lack of confidence, abstain. This guide is to help them overcome those fears and level up. If you have an issue with people leveling up, good luck to you.
  - eternalban 4y ago
    That trivializes our profession and hard earned experience simply because a degree is not a requirement. It is ridiculous to say drag'n'droping something is halfway to being a systems designer. And the anecdote about "experience at facebook" was such nonsense. "I worked at facebook doing something other than distributed systems, and geez, I learned nothing about distributed systems". "QED!" p.s. I missed this ad hom bit (no, not the issue here) > If you have an issue with people leveling up, good luck to you.
    - 4y ago
shahsyed 4y ago
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. Highly recommend. Interviewing.io is one of the best resources for those doing prep today and the team behind it is awesome.
rednerrus 4y ago
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.
- mdm12 4y ago
  I have seen this process described elsewhere as 'reverse system design', and it is my preferred approach to evaluating senior candidates as well.
- jstx1 4y ago
  Still sounds like a system design interview to me, just a bit less structured.
  - deleted 4y ago
    [deleted]
  - rednerrus 4y ago
    We've found that candidates who better understand how things are connected make better candidates and operators. We need some way to gauge how well they understand how things are connected. This is as fair of way as we've come up with.
    - zekrioca 4y ago
      I totally relate to that. In the university setting, I see many students more interested in learning keywords instead of “key concepts” behind such keywords. Think of preferring to learn “k8s” instead of “resource manager”. Today, very few of them knows that etcd is one of the key components in “k8s”. I guess this behavior is similar to the transformation that happened in other non-CS fields.
debacle 4y ago
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." 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. 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. 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.
- nfw2 4y ago
  I’ve got an interview coming up for a senior role on a UX engineering team (design system, component libraries, etc). The interview is just the standard set of backend system design and leetcode problems. It’s a pretty big red flag to me that the skills being evaluated are so tangential to the actual job. It doesn’t give me any confidence that the people I will be working with have the skillset I consider important, or that the team and I will approach problems in a compatible way.
  - jahewson 4y ago
    I suspect your fears are well-placed. Whoever is hiring this team has no idea how to hire for those roles and that suggests that those roles might not be valued within the larger company. Though sometimes the hiring manager has just lucked out and hired a great team so far. Still, will that team be listened to? Will that team be respected?
  - hot_gril 4y ago
    They always tell us, when you're interviewing candidates, they're also interviewing you. Show them why they should work here.
- 4y ago
omniglottal 4y ago
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.
- modzu 4y ago
  its an ad, and they nailed the seo
  - leeny 4y ago
    Hey, founder of interviewing.io here. We actually did zero thinking about SEO. We had someone look at this guide at the end through an SEO lens, but then we decided that that would make the content not as good and would make the guide less readable. (As an aside, I think in recent years, the spirit of SEO has become more about just making good stuff and less about hacking...) Anyway, it wasn't for SEO. It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass.
    - LastTrain 4y ago
      > It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass. No way, I’m dying here. “… and my main weakness is probably that I care too much…”
      - morgannewman 4y ago
        [dead]
      - arolihas 4y ago
        These people don’t have to think about SEO because it’s already been embedded into them. BS corporatespeak at their very core, the perfect type to sell interview gaming.
- deleted 4y ago
newaccount2021 4y ago
thought interviewing sucked before? now your resume is in a stack with 300 other dev resumes instead of 3 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
- deleted 4y ago
  [deleted]
groffee 4y ago
There's very little content here, especially nothing that would be considered 'senior'.
- paxys 4y ago
  You'd be surprised
tootie 4y ago
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.
- siva7 4y ago
  You're wondering why you didn't get the job after letting the interviewer feel like their assessment tasks weren't perfectly designed?
  - twelve40 4y ago
    Well, the sad truth is that a lot of _interviewers_ actually suck at interviewing, so sometimes an interview devolves into a bewildering game of what this particular person wants to hear today based on their mood, especially with the open-ended questions. It is not always possible to suffer through this process politely and constructively.
  - ZephyrBlu 4y ago
    If the candidate is exposing flaws in your assessment and making you think that should be a positive signal, not a negative one. Unfortunately people have egos and generally don't take kindly to situations like that.
- alex_sf 4y ago
  > 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. So.. you argued with the interviewer about their question being 'invalid'. That's not going to be a winning strategy. If you have to insist on making comments like these, a better way to express it would be: "Well, I know the context here is that we're designing a new, small-scale system. In cases like these, I think it's normally most helpful to get an MVP out-the-door, and not worry about scalability. However, in a situation where we _were_ concerned about scalability, I'd start by..." > That and I kept trying to extract imaginary requirements. This is more on the interviewer. If you ask for requirements, they should provide them. If they've done it a while, they might have a generic set, but they should at least be willing to make them up on the spot. In lieu of that, there's no rule that says you can't make them up on your own. E.g.: You: "How many concurrent clients do we need to support?" Them: "I dunno, just make it scalable." You: "Ok, let's assume it's 10k and we want to make sure we can scale that horizontally in a roughly linear fashion up to 100k.."
joshSzep 4y ago
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. https://youtu.be/Zi0pPkiFemE https://youtu.be/Zi0pPkiFemE TLDW; they struggle! big time!
FlyingSnake 4y ago
“When a measure becomes a target, it ceases to be a good measure”. The interviewing cottage industry has become a sad joke at this point.
mgraczyk 4y ago
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. Most of the advice here is good, although it could be condensed quite a bit. 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). 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. 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...
- leonidasv 4y ago
  >I feel like I can easily see through interview practice or coaching How do you spot it? I've had candidates with stellar performance on system design interviews, and I've never had any suspect of them (and the resumé also seemed pretty strong in those cases). But now I'm curious if I missed something.
  - moandcompany 4y ago
    One of the "heavy practice/coaching/leetcode grinding" signals is when the interviewee immediately dives into proposing a solution and discusses facets of that solution in great detail without bothering to ask clarifying questions or discussing assumptions and the risks/consequences of those assumptions.
    - 4y ago
agumonkey 4y ago
I struggle to read this. It looks like a self-help ebook.
ed25519FUUU 4y ago
> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt. 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.
- dakiol 4y ago
  Problem is: as candidate you don't know if "engaging in a back-and-forth conversation about problem constraints" is something the interviewers want. Some interviewers want it, but it's not always like that. And, no, usually discarding an entire company just because the interviewer on duty doesn't like "engaging" is BS.
  - hot_gril 4y ago
    They usually want it, or at least it's neutral. Just make sure you have enough time to actually solve the problem and don't ask for ridiculous hints, and nobody is going to fault you for talking.
  - marcosdumay 4y ago
    Well, as the interviewed you must pick one if the two options without any hint.
  - tempest_ 4y ago
    It was some time ago and a limited sample but at one point there a was google recruiting presentation at my school. When asked a reasonably simple question regarding expectations during interviews the google employees that were present each gave a drastically different answer(even after hearing their colleague). The entire group covered the who spectrum of possible responses which lead me to believe that there was definitely a luck of the draw factor in who you get. Perhaps they are more adherent to a rubric in 2023 which leads to these study guide type posts. Large company bullshit has never been my jam though so I never applied to find out myself.
  - 4y ago
deleted 4y ago
[deleted]
John23832 4y ago
I think to be frank, this gamification of interviews is BS. 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.
- blue039 4y ago
  Yeah, I don't think I want a job that asks such questions. I've done the webscale BS. I've done actual architecture that exists in reality. At this stage in my career there's nothing an interviewer can do but insult me. You might say that this is hubris about my own skill but it has nothing to do with how good I am. My resume has a LOOONG track record of consistent work in the industry. Call my references, do some actual DD on me, then ask me real questions related to actual things. If leetcode and all these other service went straight to hell tomorrow the world would be a better place. This entire "interview" industry is propped up by a bunch of leeches capitalizing on a recently extremely popular field. Then, injecting their BS to make the process harder thereby earning them dollars. The linked article is a perfect example. It's actually an advertisement if you look close enough designed by these exact leeches. This is just a reimagining of the bloodsuckers who run SAT/GRE/GMAT prep services and "ex-ivy-league recruiter consultant" bullshit. They are the same people and the only place they belong is all the way at the back of the breadline. That may be too generous for them anyway. There are better people that deserve the bread. There's a good chance at my career phase I have more experience than the interviewer. They "level the playing field" by asking me these stupid things. That is why it is insulting. I almost want to leave the industry entirely than have to do the process one more time. I don't need a 7 phase 360 interview with everyone including the CEO's cousin to insure I am a "culture fit". It was never like this before. It needs to stop.
  - hot_gril 4y ago
    Companies already look at resumes, and the interview is a good way to double check things in a pass/fail manner. It's not like the SAT where you take a single test that sorta determines where you go, but even that is useful as a broad measure. Like if I'm in a top school's admissions and see 1800/2400 (idk the new scoring), there'd better be an explanation. If Amazon saw my resume and I couldn't explain to them generally how I'd architect the backend for their lockers, something would be wrong. And sometimes something is wrong; I interview someone who clearly doesn't know how to code and must've lied on the resume. I don't know how else you're supposed to do it. At the higher levels, they're also testing for humility.
jefQuery 4y ago
I read all 4 parts in the pre-released version on the interviewing.io discord. Here's my feedback: 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. 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. 3.5/4 stars; would read again
- hot_gril 4y ago
  https://github.com/dcramer/mangodb https://github.com/dcramer/mangodb
rickreynoldssf 4y ago
First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies. ...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. 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 const a = [1,2,3,4,5,6,7,8,9]; const b = a.filter(x=>1); if(!!1 && b.some(e=>e>6)){ foo(); } 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. I'm known for hiring the best engineers.
- xapata 4y ago
  > best engineers Precision is different from recall. You're asking trivia. I'd rather ask questions that can't be studied for, only practiced through years of experience. I also sometimes hire people who don't know JavaScript, yet.
  - meese712 4y ago
    Don't see how you could consider the question they posed to be trivia for someone who knows javascript? Abuse of truthy evaluation is very rampant. All the JS codebases I've worked on are filled with `if (!myArray.length)` and etc. I would be very sad if anyone with a year of JS experience couldn't get this problem.
    - xapata 4y ago
      By trivia, I mean it can be thoroughly explained in a paragraph or two. Separately, if it's the kind of thing that can be learned in less than a year of experience, it's not helpful for determining whether someone should be hired as a senior engineer.
steve76 4y ago
[dead]
brailsafe 4y ago
Super good content. Now for a guide on getting a response back at all for any job application in any industry
ZephyrBlu 4y ago
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. 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. 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.
ghbarton 4y ago
[flagged]
thdc 4y ago
A senior interviewer's guide to the system design interview*. 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. 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. 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.
kimburgess 4y ago
Since we’re talking systems here and reasoning from some provided constraints: > 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. 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.
robbywashere_ 4y ago
The current state of tech interviews is a zero interest rate phenomenon
gwbas1c 4y ago
Are these interviews turning into a "can you regurgitate some memorized information" formality? 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.") 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.
jameshart 4y ago
This generally seems like good advice, but it does veer occasionally towards suggesting ways to appear good at system design when actually the point of a system design interview is to show the interviewer how good at system design you actually are. 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 are.
nfw2 4y ago
I think there may be an error in part 2 of this guide where it talks about ACID. 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. 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.
- layer8 4y ago
  Yes. The Consistency property means that at the end of every transaction, the resulting data state in the DB will be consistent with the schema definition, including any constraints, triggers, etc. In other words, no transaction will result in invalid data with respect to the schema definition. This is similar to soundness in programming languages.
  - layer8 4y ago
    To add: Strong vs. weak/eventual consistency is more related to the Isolation property of ACID.
joshkim81 4y ago
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
fatneckbeard 4y ago
i am having a problem understanding why FAANG is gatekeeping system design google - search is broke, youtube doesnt make money and is a hotbed of predators facebook - should basically be in prison for aiding war crimes and child suicides netflix - is quickly circling the drain because you can't algorithm creativity amazon - almost all of their products and services lose money apple - siri is slightly better than stubbing your toe on a sharp metal object
- shepherdjerred 4y ago
  What are you suggesting? That these companies have poor system design? That they don't need to hire smart technically minded engineers because their problems aren't technical?
  - fatneckbeard 4y ago
    yes.
jdsjdk 4y ago
Very good info!!
jdsjdk 4y ago
Great info, thanks guys!
joe1138 4y ago
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?
- paxys 4y ago
  > But you want me to “whiteboard” like a trained monkey? Well yes, that's the point. You applied to be a Google code monkey and are surprised that they are asking you to do tricks?
nitwit005 4y ago
This is, unfortunately, painting an overly rosy view of the interviewer. 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. 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.
- ldjkfkdsjnv 4y ago
  Yeah they want a canned answer, like they want some standard algorithm for leetcode. You need to be as standard as possible so they can check their boxes
- paxys 4y ago
  Interviewing is a two way street. You can judge the company as much as they judge you. If you find yourself in front of such an interviewer then move on somewhere else.
  - nitwit005 4y ago
    That's entirely valid, but you might have to do a lot of interviewing if you expect every interviewer to be excellent.
brunooliv 4y ago
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. 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". 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. 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? 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
- lampshades 4y ago
  I took a downlevel to get my foot in the door.
jamesdepp 4y ago
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!
- hnfong 4y ago
  Luck plays a huge factor, but generally the crowd on HN are opinionated and bitter. That said, if you're really brilliant and way above your peers, the luck factor drops significantly. Anyway, your experience will likely vary. Don't worry too much.
grufus 4y ago
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. Our field is too immature to actually agree on things being good or bad.
- vasco 4y ago
  That just means there's still space to be creative. If we were printing books or something "mature" we'd be automated away already.
vrnvu 4y ago
Can we stop saying that the 'over engineering interview' is a 'system design interview'? Most real life problems don't get solved by adding queues and moving to an event driven architecture with thousands of micro-services. 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.
Myrmornis 4y ago
This seemed to be paragraphs of preparatory fluff that never got to the core content.
krzyk 4y ago
Why would a senior engineer do a system design? Isn't that a role of architect? 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. How often SWE does a system design? Maybe in small startups.
NorwegianDude 4y ago
The repetition of "this is different from code" strikes me as odd. The way I see it, it's identical to code, it just involves more moving parts. > 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). 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. 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.
mysticllama 4y ago
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. if you try to cover every base and fret about everything being optimal, you're going to barely have time to get started.
AtNightWeCode 4y ago
It is like asking who watched most YT-vids. Seriously, I think you need to do both. A question suggestion: Show a medium-sized system design and ask which resources that should be removed.
strus 4y ago
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? 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". 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?
lazyant 4y ago
Quick thoughts: - 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.

909 points by leeny 4y ago

Bug: The YouTube video link at the top just takes you to youtube.com and not a specific video.

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!

chrisabrams 4y ago

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!

Samit5174 4y ago

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!

Ozzie_osman 4y ago

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.

eternalban 4y ago

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

rednerrus 4y ago
It's kind of true if you just think about the beginning of the long tail as the end point.
reactordev 4y ago
The reality is you can become an engineer with no degree whilst you can’t become a surgeon with no degree. The criticism of the writing is dismissing that a lot of people want to go for that promotion or higher tier but due to imposter syndrome or lack of confidence, abstain. This guide is to help them overcome those fears and level up. If you have an issue with people leveling up, good luck to you.
- eternalban 4y ago
  That trivializes our profession and hard earned experience simply because a degree is not a requirement. It is ridiculous to say drag'n'droping something is halfway to being a systems designer. And the anecdote about "experience at facebook" was such nonsense. "I worked at facebook doing something other than distributed systems, and geez, I learned nothing about distributed systems". "QED!" p.s. I missed this ad hom bit (no, not the issue here) > If you have an issue with people leveling up, good luck to you.
  - 4y ago

shahsyed 4y ago

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. Highly recommend. Interviewing.io is one of the best resources for those doing prep today and the team behind it is awesome.

rednerrus 4y ago

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.

mdm12 4y ago
I have seen this process described elsewhere as 'reverse system design', and it is my preferred approach to evaluating senior candidates as well.
jstx1 4y ago
Still sounds like a system design interview to me, just a bit less structured.
- deleted 4y ago
  [deleted]
- rednerrus 4y ago
  We've found that candidates who better understand how things are connected make better candidates and operators. We need some way to gauge how well they understand how things are connected. This is as fair of way as we've come up with.
  - zekrioca 4y ago
    I totally relate to that. In the university setting, I see many students more interested in learning keywords instead of “key concepts” behind such keywords. Think of preferring to learn “k8s” instead of “resource manager”. Today, very few of them knows that etcd is one of the key components in “k8s”. I guess this behavior is similar to the transformation that happened in other non-CS fields.

debacle 4y ago

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

nfw2 4y ago
I’ve got an interview coming up for a senior role on a UX engineering team (design system, component libraries, etc). The interview is just the standard set of backend system design and leetcode problems. It’s a pretty big red flag to me that the skills being evaluated are so tangential to the actual job. It doesn’t give me any confidence that the people I will be working with have the skillset I consider important, or that the team and I will approach problems in a compatible way.
- jahewson 4y ago
  I suspect your fears are well-placed. Whoever is hiring this team has no idea how to hire for those roles and that suggests that those roles might not be valued within the larger company. Though sometimes the hiring manager has just lucked out and hired a great team so far. Still, will that team be listened to? Will that team be respected?
- hot_gril 4y ago
  They always tell us, when you're interviewing candidates, they're also interviewing you. Show them why they should work here.
4y ago

omniglottal 4y ago

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.

modzu 4y ago
its an ad, and they nailed the seo
- leeny 4y ago
  Hey, founder of interviewing.io here. We actually did zero thinking about SEO. We had someone look at this guide at the end through an SEO lens, but then we decided that that would make the content not as good and would make the guide less readable. (As an aside, I think in recent years, the spirit of SEO has become more about just making good stuff and less about hacking...) Anyway, it wasn't for SEO. It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass.
  - LastTrain 4y ago
    > It's hard to edit stuff well because we're so passionate about what we wrote here, and we probably should do another pass. No way, I’m dying here. “… and my main weakness is probably that I care too much…”
    - morgannewman 4y ago
      [dead]
    - arolihas 4y ago
      These people don’t have to think about SEO because it’s already been embedded into them. BS corporatespeak at their very core, the perfect type to sell interview gaming.
deleted 4y ago

newaccount2021 4y ago

thought interviewing sucked before? now your resume is in a stack with 300 other dev resumes instead of 3 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

deleted 4y ago
[deleted]

groffee 4y ago

There's very little content here, especially nothing that would be considered 'senior'.

paxys 4y ago
You'd be surprised

tootie 4y ago

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.

siva7 4y ago
You're wondering why you didn't get the job after letting the interviewer feel like their assessment tasks weren't perfectly designed?
- twelve40 4y ago
  Well, the sad truth is that a lot of _interviewers_ actually suck at interviewing, so sometimes an interview devolves into a bewildering game of what this particular person wants to hear today based on their mood, especially with the open-ended questions. It is not always possible to suffer through this process politely and constructively.
- ZephyrBlu 4y ago
  If the candidate is exposing flaws in your assessment and making you think that should be a positive signal, not a negative one. Unfortunately people have egos and generally don't take kindly to situations like that.
alex_sf 4y ago
> 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. So.. you argued with the interviewer about their question being 'invalid'. That's not going to be a winning strategy. If you have to insist on making comments like these, a better way to express it would be: "Well, I know the context here is that we're designing a new, small-scale system. In cases like these, I think it's normally most helpful to get an MVP out-the-door, and not worry about scalability. However, in a situation where we _were_ concerned about scalability, I'd start by..." > That and I kept trying to extract imaginary requirements. This is more on the interviewer. If you ask for requirements, they should provide them. If they've done it a while, they might have a generic set, but they should at least be willing to make them up on the spot. In lieu of that, there's no rule that says you can't make them up on your own. E.g.: You: "How many concurrent clients do we need to support?" Them: "I dunno, just make it scalable." You: "Ok, let's assume it's 10k and we want to make sure we can scale that horizontally in a roughly linear fashion up to 100k.."

joshSzep 4y ago

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. https://youtu.be/Zi0pPkiFemE https://youtu.be/Zi0pPkiFemE TLDW; they struggle! big time!

FlyingSnake 4y ago

“When a measure becomes a target, it ceases to be a good measure”. The interviewing cottage industry has become a sad joke at this point.

mgraczyk 4y ago

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. Most of the advice here is good, although it could be condensed quite a bit. 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). 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. 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...

leonidasv 4y ago
>I feel like I can easily see through interview practice or coaching How do you spot it? I've had candidates with stellar performance on system design interviews, and I've never had any suspect of them (and the resumé also seemed pretty strong in those cases). But now I'm curious if I missed something.
- moandcompany 4y ago
  One of the "heavy practice/coaching/leetcode grinding" signals is when the interviewee immediately dives into proposing a solution and discusses facets of that solution in great detail without bothering to ask clarifying questions or discussing assumptions and the risks/consequences of those assumptions.
  - 4y ago

agumonkey 4y ago

I struggle to read this. It looks like a self-help ebook.

ed25519FUUU 4y ago

> Interviewers want to engage you in a back-and-forth conversation about problem constraints and parameters, so avoid making assumptions about the prompt. 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.

dakiol 4y ago
Problem is: as candidate you don't know if "engaging in a back-and-forth conversation about problem constraints" is something the interviewers want. Some interviewers want it, but it's not always like that. And, no, usually discarding an entire company just because the interviewer on duty doesn't like "engaging" is BS.
- hot_gril 4y ago
  They usually want it, or at least it's neutral. Just make sure you have enough time to actually solve the problem and don't ask for ridiculous hints, and nobody is going to fault you for talking.
- marcosdumay 4y ago
  Well, as the interviewed you must pick one if the two options without any hint.
- tempest_ 4y ago
  It was some time ago and a limited sample but at one point there a was google recruiting presentation at my school. When asked a reasonably simple question regarding expectations during interviews the google employees that were present each gave a drastically different answer(even after hearing their colleague). The entire group covered the who spectrum of possible responses which lead me to believe that there was definitely a luck of the draw factor in who you get. Perhaps they are more adherent to a rubric in 2023 which leads to these study guide type posts. Large company bullshit has never been my jam though so I never applied to find out myself.
- 4y ago

deleted 4y ago

[deleted]

John23832 4y ago

I think to be frank, this gamification of interviews is BS. 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.

blue039 4y ago
Yeah, I don't think I want a job that asks such questions. I've done the webscale BS. I've done actual architecture that exists in reality. At this stage in my career there's nothing an interviewer can do but insult me. You might say that this is hubris about my own skill but it has nothing to do with how good I am. My resume has a LOOONG track record of consistent work in the industry. Call my references, do some actual DD on me, then ask me real questions related to actual things. If leetcode and all these other service went straight to hell tomorrow the world would be a better place. This entire "interview" industry is propped up by a bunch of leeches capitalizing on a recently extremely popular field. Then, injecting their BS to make the process harder thereby earning them dollars. The linked article is a perfect example. It's actually an advertisement if you look close enough designed by these exact leeches. This is just a reimagining of the bloodsuckers who run SAT/GRE/GMAT prep services and "ex-ivy-league recruiter consultant" bullshit. They are the same people and the only place they belong is all the way at the back of the breadline. That may be too generous for them anyway. There are better people that deserve the bread. There's a good chance at my career phase I have more experience than the interviewer. They "level the playing field" by asking me these stupid things. That is why it is insulting. I almost want to leave the industry entirely than have to do the process one more time. I don't need a 7 phase 360 interview with everyone including the CEO's cousin to insure I am a "culture fit". It was never like this before. It needs to stop.
- hot_gril 4y ago
  Companies already look at resumes, and the interview is a good way to double check things in a pass/fail manner. It's not like the SAT where you take a single test that sorta determines where you go, but even that is useful as a broad measure. Like if I'm in a top school's admissions and see 1800/2400 (idk the new scoring), there'd better be an explanation. If Amazon saw my resume and I couldn't explain to them generally how I'd architect the backend for their lockers, something would be wrong. And sometimes something is wrong; I interview someone who clearly doesn't know how to code and must've lied on the resume. I don't know how else you're supposed to do it. At the higher levels, they're also testing for humility.

jefQuery 4y ago

I read all 4 parts in the pre-released version on the interviewing.io discord. Here's my feedback: 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. 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. 3.5/4 stars; would read again

hot_gril 4y ago
https://github.com/dcramer/mangodb https://github.com/dcramer/mangodb

rickreynoldssf 4y ago

First off, I'm not disparaging the content, I'm sure its good and useful in interviewing at most companies. ...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. 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 const a = [1,2,3,4,5,6,7,8,9]; const b = a.filter(x=>1); if(!!1 && b.some(e=>e>6)){ foo(); } 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. I'm known for hiring the best engineers.

xapata 4y ago
> best engineers Precision is different from recall. You're asking trivia. I'd rather ask questions that can't be studied for, only practiced through years of experience. I also sometimes hire people who don't know JavaScript, yet.
- meese712 4y ago
  Don't see how you could consider the question they posed to be trivia for someone who knows javascript? Abuse of truthy evaluation is very rampant. All the JS codebases I've worked on are filled with `if (!myArray.length)` and etc. I would be very sad if anyone with a year of JS experience couldn't get this problem.
  - xapata 4y ago
    By trivia, I mean it can be thoroughly explained in a paragraph or two. Separately, if it's the kind of thing that can be learned in less than a year of experience, it's not helpful for determining whether someone should be hired as a senior engineer.

steve76 4y ago

[dead]

brailsafe 4y ago

Super good content. Now for a guide on getting a response back at all for any job application in any industry

ZephyrBlu 4y ago

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

ghbarton 4y ago

[flagged]

thdc 4y ago

A senior interviewer's guide to the system design interview*. 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. 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. 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.

kimburgess 4y ago

Since we’re talking systems here and reasoning from some provided constraints: > 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. 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.

robbywashere_ 4y ago

The current state of tech interviews is a zero interest rate phenomenon

gwbas1c 4y ago

Are these interviews turning into a "can you regurgitate some memorized information" formality? 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.") 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.

jameshart 4y ago

This generally seems like good advice, but it does veer occasionally towards suggesting ways to appear good at system design when actually the point of a system design interview is to show the interviewer how good at system design you actually are. 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 are.

nfw2 4y ago

I think there may be an error in part 2 of this guide where it talks about ACID. 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. 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.

layer8 4y ago
Yes. The Consistency property means that at the end of every transaction, the resulting data state in the DB will be consistent with the schema definition, including any constraints, triggers, etc. In other words, no transaction will result in invalid data with respect to the schema definition. This is similar to soundness in programming languages.
- layer8 4y ago
  To add: Strong vs. weak/eventual consistency is more related to the Isolation property of ACID.

joshkim81 4y ago

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

fatneckbeard 4y ago

i am having a problem understanding why FAANG is gatekeeping system design google - search is broke, youtube doesnt make money and is a hotbed of predators facebook - should basically be in prison for aiding war crimes and child suicides netflix - is quickly circling the drain because you can't algorithm creativity amazon - almost all of their products and services lose money apple - siri is slightly better than stubbing your toe on a sharp metal object

shepherdjerred 4y ago
What are you suggesting? That these companies have poor system design? That they don't need to hire smart technically minded engineers because their problems aren't technical?
- fatneckbeard 4y ago
  yes.

jdsjdk 4y ago

Very good info!!

jdsjdk 4y ago

Great info, thanks guys!

joe1138 4y ago

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?

paxys 4y ago
> But you want me to “whiteboard” like a trained monkey? Well yes, that's the point. You applied to be a Google code monkey and are surprised that they are asking you to do tricks?

nitwit005 4y ago

This is, unfortunately, painting an overly rosy view of the interviewer. 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. 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.

ldjkfkdsjnv 4y ago
Yeah they want a canned answer, like they want some standard algorithm for leetcode. You need to be as standard as possible so they can check their boxes
paxys 4y ago
Interviewing is a two way street. You can judge the company as much as they judge you. If you find yourself in front of such an interviewer then move on somewhere else.
- nitwit005 4y ago
  That's entirely valid, but you might have to do a lot of interviewing if you expect every interviewer to be excellent.

brunooliv 4y ago

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

lampshades 4y ago
I took a downlevel to get my foot in the door.

jamesdepp 4y ago

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!

hnfong 4y ago
Luck plays a huge factor, but generally the crowd on HN are opinionated and bitter. That said, if you're really brilliant and way above your peers, the luck factor drops significantly. Anyway, your experience will likely vary. Don't worry too much.

grufus 4y ago

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. Our field is too immature to actually agree on things being good or bad.

vasco 4y ago
That just means there's still space to be creative. If we were printing books or something "mature" we'd be automated away already.

vrnvu 4y ago

Can we stop saying that the 'over engineering interview' is a 'system design interview'? Most real life problems don't get solved by adding queues and moving to an event driven architecture with thousands of micro-services. 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.

Myrmornis 4y ago

This seemed to be paragraphs of preparatory fluff that never got to the core content.

krzyk 4y ago

Why would a senior engineer do a system design? Isn't that a role of architect? 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. How often SWE does a system design? Maybe in small startups.

NorwegianDude 4y ago

The repetition of "this is different from code" strikes me as odd. The way I see it, it's identical to code, it just involves more moving parts. > 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). 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. 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.

mysticllama 4y ago

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. if you try to cover every base and fret about everything being optimal, you're going to barely have time to get started.

AtNightWeCode 4y ago

It is like asking who watched most YT-vids. Seriously, I think you need to do both. A question suggestion: Show a medium-sized system design and ask which resources that should be removed.

strus 4y ago

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

lazyant 4y ago

Quick thoughts: - 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.