A senior engineer's guide to the system design interview
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&#x27;t understand. DO NOT say things like &quot;we can&#x27;t do this because of the CAP theorem&quot; or &quot;we should add a cache to reduce latency&quot; 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&#x27;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&#x27;t recommend spending more than an hour or so &quot;preparing&quot; for system design interviews. Unless you are interviewing somewhere with very inexperienced interviewers...