I can say with confidence that I understand most of the technical knowledge needed to succeed in these interviews, albeit it's not coming from personal experience building such systems but rather from reading books & blogs.<p>With that being said - when it comes to tackling these interviews - it seems that most of the time I am trying to regurgitate information rather than actually doing some kind of "problem solving".<p>The other end of this would be to read many System Design Interview Answers and learning those - and then knocking on wood and praying that you're going to get one of those questions.<p>Neither of these sound very productive.<p>How would one be able to answer such questions with confidence if they have never build out those systems? And what would be the preparation needed to be able to do that?
Answering "Design Uber" questions is like playing a weird charade game in a LARP camp. It is very convenient for the interviewer because they set the rules and can change them anytime. They only prepare their question once and apply it it all candidates. What type of signal these are supposed to generate? Are these some sort of behavioral/hazing rituals? Why all the smoke and mirrors? If these are testing System Design skills, why not ask a specific System Design question? Why not ask about tradeoffs between single vs multi leader vs leaderless? Why not ask specifically about document vs relational.<p>Better yet, why not look at the person experience and ask them how would they scale a system they actually worked on before? And what were the tradeoffs.<p>This can be helpful for LARPing though: <a href="https://systemdesignfightclub.com/" rel="nofollow">https://systemdesignfightclub.com/</a>
Practice.<p>The interviewer knows you don't have personal experience building Dropbox, but a systems design interview question might be help me build Dropbox, for cats. Half of it is regurgitating information - what database would you use, Redis vs Mongodb vs Dynamodb vs Postgresql vs Spanner vs BigQuery vs BigTable vs Firebase, but more importantly, you need to show that you know the bigger concepts; relational vs key-value vs document store, and their trade-offs.<p>The interview is 45 minutes to see how you think, how you react to questions, how you behave as a human being, what happens when I throw in a curve ball. If I say your design is stupid, do you get mad and start yelling at me and call me names, or can you incorporate that feedback and adjust your design to accommodate a change in behavior.<p>Get to know the building blocks very well.