Ask HN: How does one get good at System Design interviews?
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.
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".
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.
Neither of these sound very productive.
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. 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. This can be helpful for LARPing though: https://systemdesignfightclub.com/ Practice. 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. 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. Get to know the building blocks very well. The problem is that for senior+ interviews, you need to know things like cold starts, consistent hashing, dealing with different invalidations techniques for the cache, etc - the combinations seem infinite There's a lot of stuff to know! Senior+ isn't called that because some rando can memorize a couple of things in 5 minutes and ace the interview. It takes years to learn tons everything and get an intuition for things, and even then there's a bunch you still won't know. The systems design interview is in knowing enough of the building blocks and being smart enough to put them together, and being able to discuss why put them together that way. There's no right answer, using a relational database to ingest log messages from a service is an acceptable answer to the right question, but you have to be able to sit there and explain the tradeoffs being made and when you would and wouldn't want to do that. As you've noted, studying the questions won't help unless you memorize enough of the questions and get lucky. So get to know enough of the building blocks well so you can come up with a combination of them that's reasonable. All systems have tradeoffs, what's the optimal, least-bad solution? What are the considerations you're optimizing for. The system you'd build for a FAANG isn't the same system you'd build for a VC-funded company, isn't the same one you'd build for a boot-strapped company.
So it's half hazing, half theatrical performance? "Half of it is regurgitating"
"how you behave as a human being, what happens when I throw in a curve ball."