I think a lot of it comes down to the resources everyone uses to prepare for such interviews. Most YT videos are hand-wavy and give a decent intro but fail to talk about nuances. I've recently started reading ByteByteGo's articles, they are very good, but still not many of the constraints that you mention I should talk about are actually mentioned in there.
If I wasn't aware of the depth I may need to go into (I guess this also varies by level of role you are interviewing for), how would I prepare for it? Is there a really good one-stop for reading about all possible things to discuss? Genuine question.
That is a very fair question. A few others have brought this up in my probono mentorship sessions. I don't have a single resource to point to hence I even wrote this article. Otherwise, I don't write on interviews.
Also it takes a lot of effort for seasoned interviewers to write articles like this (it took me a long time).
> If I wasn't aware of the depth I may need to go into, how would I prepare for it?
My answer: Ask why's. Push the boundaries of what you take for granted. While preparing, record yourself and observe what you are taking for granted. Practicing this outside of the real interviews sort of prepare you for the day.
This sounds very hand wavy too :) That coz that is a lot of depth of the answer that I am not getting into.
Eg: When an API needs to be async and you need to use kafka or SQS. Next time, understand what queue guarantees are, when does a queue fail, when is there data loss, what are the guarantees of a queue exactly once, at least once, are you storing the whole object in the queue, how are you tracking status of requests in the queue - do you need another entry in the database, etc
So what I tried to show here, a lot of thinking happens during your preparation. In my case, my experience makes a bit easier to ask these but I believe if folks ask these "whys" they can start learning it as well.
Have a follow up? I am open for a chat, may be I will learn more about your struggle.
This is one of the best set of tips I’ve seen for system design interviews. I’ve probably read hundreds of comments online (like on Hacker News) with system design interview tips and this covers all the points really well!
Thank you so much for the article! I'm a university student who just started learning system design because I have a system design interview coming up for an internship. Unfortunately, since I don't have any experience, I've been studying by watching youtube videos and trying to memorize the solutions. Do you have any tips for how I can start learning system design in a better way?
FAANG companies (and other similar companies) have a low bar for new grads when it comes to system design interviews. In fact, some even skip it. So, don't stress too much.
Ensure you know the design of your past project well and the trade offs in those. This article is focused on industry hires who will have a higher bar.
This is so useful and well crafted. I will definitely use it as a guide for my next system design interview.
I used to not go into the required level of details in my first system design interviews.
My most successful system design interview was when I engaged in the problem itself, not trying to remember the hot terms and just throwing them out there so the interviewer knows I know the concepts.
Really useful guide that I'd recommend to anyone I know who's going to do system design interviews soon!
The post is full of good insights to prepare properly for the interviews. Great one, Raviraj!
> “requirements, calculations, data schema, load balancers, and API design“
My 2 cents about this one: I think having a structure will help on tackling the problem. Otherwise, the interviewee may end up with the same fear as writers with the blank page.
I can't think of a problem that doesn't benefit from asking the requirements and clarifying questions first, doing a high-level and then diving into a lower-level design
But I get your point of mechanically going and putting a LB with stateless API servers, a distributed database, and some cache and that's the design for everything.
May be I should have clarified it better. Thanks for bringing it up.
The post should not say 'have no structure'. In fact, the message is dig into the requirements and also prioritize them. Take the time to align with the interviewer.
Also higher level design is a necessary step but not enough. Candidates stop at that and that is a mistake.
I think a lot of it comes down to the resources everyone uses to prepare for such interviews. Most YT videos are hand-wavy and give a decent intro but fail to talk about nuances. I've recently started reading ByteByteGo's articles, they are very good, but still not many of the constraints that you mention I should talk about are actually mentioned in there.
If I wasn't aware of the depth I may need to go into (I guess this also varies by level of role you are interviewing for), how would I prepare for it? Is there a really good one-stop for reading about all possible things to discuss? Genuine question.
That is a very fair question. A few others have brought this up in my probono mentorship sessions. I don't have a single resource to point to hence I even wrote this article. Otherwise, I don't write on interviews.
Also it takes a lot of effort for seasoned interviewers to write articles like this (it took me a long time).
> If I wasn't aware of the depth I may need to go into, how would I prepare for it?
My answer: Ask why's. Push the boundaries of what you take for granted. While preparing, record yourself and observe what you are taking for granted. Practicing this outside of the real interviews sort of prepare you for the day.
This sounds very hand wavy too :) That coz that is a lot of depth of the answer that I am not getting into.
Eg: When an API needs to be async and you need to use kafka or SQS. Next time, understand what queue guarantees are, when does a queue fail, when is there data loss, what are the guarantees of a queue exactly once, at least once, are you storing the whole object in the queue, how are you tracking status of requests in the queue - do you need another entry in the database, etc
So what I tried to show here, a lot of thinking happens during your preparation. In my case, my experience makes a bit easier to ask these but I believe if folks ask these "whys" they can start learning it as well.
Have a follow up? I am open for a chat, may be I will learn more about your struggle.
This is one of the best set of tips I’ve seen for system design interviews. I’ve probably read hundreds of comments online (like on Hacker News) with system design interview tips and this covers all the points really well!
Oh thank you!
Thank you so much for the article! I'm a university student who just started learning system design because I have a system design interview coming up for an internship. Unfortunately, since I don't have any experience, I've been studying by watching youtube videos and trying to memorize the solutions. Do you have any tips for how I can start learning system design in a better way?
FAANG companies (and other similar companies) have a low bar for new grads when it comes to system design interviews. In fact, some even skip it. So, don't stress too much.
Ensure you know the design of your past project well and the trade offs in those. This article is focused on industry hires who will have a higher bar.
This is so useful and well crafted. I will definitely use it as a guide for my next system design interview.
I used to not go into the required level of details in my first system design interviews.
My most successful system design interview was when I engaged in the problem itself, not trying to remember the hot terms and just throwing them out there so the interviewer knows I know the concepts.
Really useful guide that I'd recommend to anyone I know who's going to do system design interviews soon!
So happy for this article, Raviraj.
I've been the interviewer for too many system design interviews where the process seems way too formulaic and just trying to use buzzwords.
Honestly, this is why I get so bothered sometimes watching replays of system design interviews.
People talking in way too high level: "Here we prefer availability and fault tolerance." OK. Where and what specifically?
Btw, sincerely appreciate the course mention 🙏 we're already at 23 enrollments so that's crazy 🤯 🙇♂️
Glad the article resonated with you.
23! nice. It's gonna keep growing!
I remember in my first interviews, how I spent ton of time trying to come up with all those advanced use cases to seem smart 😅
Great tips
Haha, me too. I am too ashamed to even talk about my first one.
The post is full of good insights to prepare properly for the interviews. Great one, Raviraj!
> “requirements, calculations, data schema, load balancers, and API design“
My 2 cents about this one: I think having a structure will help on tackling the problem. Otherwise, the interviewee may end up with the same fear as writers with the blank page.
I can't think of a problem that doesn't benefit from asking the requirements and clarifying questions first, doing a high-level and then diving into a lower-level design
But I get your point of mechanically going and putting a LB with stateless API servers, a distributed database, and some cache and that's the design for everything.
Glad you liked it!
May be I should have clarified it better. Thanks for bringing it up.
The post should not say 'have no structure'. In fact, the message is dig into the requirements and also prioritize them. Take the time to align with the interviewer.
Also higher level design is a necessary step but not enough. Candidates stop at that and that is a mistake.
I really like this article 🔝
Glad you loved it!