me too. I said "I haven't thought about this before" when the guy asked me about how to scale up database reads on my app, and he immediately moved on. I've since read about scaling up database reads and it's all very basic, common sense stuff that I had in fact kinda thought about before. Oops
This is probably the most "mature" systems design video I ever watched. No specifics, just handling different aspects and focusing on what's important for the outcome. Thanks for posting!
Motivating to say the least: "If you get rejected it means you were at least at the front door of that place. Just keep going." After getting rejected at 3 out of top 4 tech companies, feeling devastated. Thanks for this nice video.
Watched this a couple years ago when I switched jobs and marked it "Good" and now stumbled upon it again. Still feel that the content is awesome. Great technical details, good suggestions of strategies / approaches, and the explanations on the mindset one should have going into these interviews / prepping for these interviews are absolutely on point as well. Respect for putting out such good content,
I wish you were still making videos. These have honestly been the most helpful and realistic explanations I have found to date. Well done. I'd love to see more about when you are working to actually level up your career. For example: devops (probably using AWS as an example since that seems to be what most use), a datawarehouse video on scalability, maybe even a video on choosing architectures themselves?
Thank you Jack for the awesome video. I would say that this is one hell of video that mentions a lot of quality content about the interviews, architecture design and how to prepare them. Some best things discussed in the video were : 1) The person had 8 years of experience and still he was low on architecture design. May be you are not pushing yourself harder. 2) We all might not be working in the company that works on scaling the application. But we can still know what the company is doing by reading their engineering blogs. 3) You must be driving the interview and not the interviewer should be pushing every time. I was not pushing myself harder and it's better that I start pushing myself harder and start reading the blogs of big tech companies.
This is just an awesome video! It really resonates with what I tell potential candidates and friends who ask me about how to tackle a design interview. Stuff that I liked about the video: 1. Why a design interview is conducted 2. What is the interviewer looking for 3. Whats the worst thing a candidate can do. 4. Breaking apart an example problem -> mentioning the caveats that you were pulling numbers out of thin air (sorta) 5. How to get good at this (not just for the purposes of passing an interview) So pretty much the entire 50 mins. Please continue to post!
Great advice, great outlook, and great positivity. The only comment I would make is for the engineer with 8 years of experience -- I'm also self taught, and have been a SWE for 4 years: the first 2 of that was barely trying to stay afloat, and the last 2 were finally building cool things. Still not that good at architecture, but sometimes number of years alone don't tell the whole story
I have watched and read almost every major video and written source on system design and this is by far the best I've seen. What you do better than the others is address the meta issues around the fact that you are making estimations and might not know everything but that the point is to keep going and keep exploring even though you don't know everything.
Thanks Jackson, I'm an incoming graduate looking at entry level positions with very limited industry experience, and I find your videos really helpful and lighthearted. Thank you very much for taking the time to make these!
Thank you Jackson for this amazing video. Being a noob at system design, this video really helped me to boost my confidence to drive the interview rather than being driven.
Jackson Gabbard, Incredibly amazing content. When I just started this video i thought you would be giving some generic tips and tricks to crack the interview - but you went in breadth and depth at some places and covered end to end. It gives a clear picture of what happens in a system design interview. At the end summarizing, with haystack story and how to build or interact with the community who builds architecture that impacts large scale is simply superb. Thanks a lot for such wonderful content :)
Great video about general system design process. The concurrent connection analysis could go into some details on how you get concurrent users from throughput (68K user per sec). If every user stays for 1 sec and leaves, sure. You would have 68K concurrent users at any given point of time. But if visitors stay for 10 seconds on avg, then you would probably need to accommodate 680K concurrent connections (68K/sec * 10 secs) in total.
Great video, it was so interesting that after a while I stopped noticing the background music which was little distracting in the beginning. Thanks for such inflammatory film
I have an interview tomorrow (which I have a hunch will be on system design), and I gotta say you really helped out my confidence. Thanks. Fingers crossed for tomorrow 🤞🤞
thanks for sharing. architecture is way less discussed since it's more open ended but imo shows a developer's experience much more. the bass line of the background track is also very funky
I was able to understand you properly but decided to read the comments halfway through and saw a bunch of people complaining about the background music and then couldn't watch it anymore haha
Excellent, I watched till the end. Amazon is flying me for an on-site interview in 3 days ( 8 dec ). I'm a mobile developer . I failed at a similar company on the scalability interview but aced the coding. Your video helped to get the right attitude. I'm talking with the SREs and they are happy to share how they solved the black Friday issue. I will post how it went.
OMG, what an awesome video. I wished I watched it long time ago. There is so much to learn. This must be shared again and again. @Jackson you are so awesome in explaining things. Thank you so much.
Thank You! Great piece of advice. I urge you to continue doing this. And that you walked through a problem and ways to approach it in a real world-> that was the most useful part!
that was awesome jackson. happy I found this piece of valuable video. nothing helped me more than this to know what a intrviewer wants me in a system design interview.
Thanks Jackson, it is a great video! Could you try to share some video about how to approach a detail system design question with drawing something, from frontend to backend, distribution system etc?
Thanks Jackson, great video! However, the music was as loud as your voice and it made me drift away from what you were saying at times. Maybe lower the musci volume next time? Best of luck in the future!
for the question about how much data is acceptable to use? should we think about if it's appropriate to use mobile data at all? Why can't the phone store the data on the phone and upload it only when the phone is connected to wifi? Yes, there are some people who we may never get data from in that model but how many people is that? Is the loss of collecting that data worth the trade-off for a better user experience where we aren't using our users' expensive mobile data?
I like you. Please make more videos. I also really liked your behavioral interview video. I'll definitely be using your advice, and recommend you to tech friends who are interviewing. Thank you so much!
Hey Jackson, thanks for the cool video. I still have a bunch of questions: - Is the top-down method a good way to attack those problems? I think one of my weaknesses was that I almost always chose the bottom-up approach (started from data structure, algorithm, etc.) - It is true that there is no right and correct answer to many of the system design problems, however, how can I check the correctness of my design? I mean, in order to practice for the coding interviews, I can simply code my solution and try to compile and run it! But how I can make sure that I ask good questions, come up with good solutions, and not bull shit during the system design interview!! - You mentioned that the architecture and systems design questions are usually not for recent grads, and those questions typically wouldn't result in rejections. However, as a recent grad that faced a few rejections, I am pretty sure that the system design interviews caused me to get the rejection letter! Well, I didn't have any issue in the coding interviews, and I assume the behavioral interviews went okay (didn't act like a psycho or weirdo, I hope!), so the only interviews that might have gone wrong were the systems designs. Would you also tell me why companies choose the zero feedback policy, which can be extremely helpful for candidates like me to find their weaknesses?
Let me see if I can do these questions justice in a RUclips comment reply: - Is the top-down method a good way to attack those problems? There are many acceptable ways to solve a problem like this and bottom up is fine, too. I once interviewed a graphics specialist with experience in high-performance video game programming who used his knowledge of kD trees to guide his decision making about a big systems problem. He worked his way up from the core algorithm that would enable efficient computation of the thing that the problem needed to compute and then figured out much traffic one server instance could handle and from there figured out how many servers he would need. Super strong performance. Honestly, I think either approach could work as long as the reasoning is sound. - It is true that there is no right and correct answer to many of the system design problems, however, how can I check the correctness of my design? Something I've told people in the past about architecture interviews is that you can't really "prep" for them. You can only sharpen your overall knowledge and intuition about large scale systems and do you best to bring that knowledge and intuition to bear in the interview. That said, most of the challenge of an architecture interview is purely reasoning, judgement, and complex reduction. I think an excellent way to prepare for this is to think about real-world systems and to try to estimate how they would have to work. Especially if there's an open discussion about them somewhere. For instance, Square has a great engineering blog where they give away lots of juicy details about their systems. Let's say you were asked a question about how to host many diverse datasets in a highly available away. Maybe the use case is a system like Parse where people define a schema and your awesome systems figures out how to store it. You would probably have the intuition that there would be many backing databases (because the alternative is the insane table denormalization pattern that every n00b dreams up and eventually realizes is a bad idea). If you did figure there would be many different databases, you might wonder how many you could host on a single machine. You'd need some real-world context for this. Well, reading over Square's engineering blog posts, I get at least one useful data point: corner.squareup.com/2016/04/shift.html. The explain how many database schemas there were on individual hosts, what the upsides were, and what the downsides were. To me, this is delightful, amazing detail that helps me be a better engineer. Props to Square for putting it out there. AirBnB also does a great job of showcasing the cool stuff they're up to. Stripe also. So, you can definitely gut check your intuitions about how a system might work by finding existing companies that are talking about how their actual systems work. There are also some great mental checks you can do. Once you have an idea of how to solve a problem, try to imagine one or two real-world costs associated with it. For instance, "If I did with my system, how much would it cost to run it?" Often, a bad design will immediately show as being either impossibly cheap or impossibly expensive. You might also ask, "If I used to solve this problem, what aspects of the problem might make that decision a bad one?" An example of this could be in a problem like deciding between a load-balanced, multiple server solution or a single, powerful server. I've seen this over and over again in systems design interviews. Often people who don't have a strong systems background will assume that any problem needs a) load balancers, b) multiple servers, c) backup servers, and d) some sort of complicated way of coordinating these two things. However, often the people who are making these assertions haven't looked closely enough at the core of the problem. They jump straight to some big sounding system architecture without justifying the need for it. You should ask really basic sounding questions like "Can I run the entire system on one machine?" "If not, why not?" "What are the specific things that make this a system that *needs* more than one machine?" If you build up from a place of deep scepticism about how much hardware to throw at a problem, you'll stand a better chance. - Would you also tell me why companies choose the zero feedback policy, which can be extremely helpful for candidates like me to find their weaknesses? Honestly, I find this super, duper frustrating. I've led *so* many interviews where I was dying to give the candidate specific feedback about their performance in order to help them grow. Everything from telling the smart-but-too-aggressive candidate to ease up to having a sit-down session with a candidate who was obviously so burned by their last position that they were showing up to the interview with venom in their voice such that no company would ever hire them. Sometimes it's as simple as telling someone "Hey, it's really clear you are missing this specific piece of background that is preventing you from succeeding." It sucks not giving that feedback. I think the reasons are a few. For one, the more information you give someone you don't hire, the more easily they can sue you. Consider the language many companies use in evaluating someone. Maybe Awesome Company decided to give every interviewee a digest of the interview feedback. Maybe Candidate Casey gets the feedback and sees a line like, "While we loved your passion and your technical skills, we felt that you wouldn't be a good cultural fit for the team we're trying to create. Awesome Company prizes its culture of and felt that you might struggle to acclimate to that environment based on your time in companies embrace different cultures." It's extremely common to refer to someone's "culture" and whether or not they would be a "good culture fit." This is completely benign language in-context, but if someone felt discriminated against in not getting hired and wanted to sue the company who gave them feedback like this. It's very easy for an antagonistic lawyer to say Awesome Company was discriminating against Casey's religious or ethnic or social or vim-over-emacs or whatever culture. It could end up being a very expensive bit of benevolence for Awesome Company. Next, there's just a practical matter of time. Recruiters have numbers to hit. Companies are optimising for finding awesome people to help them achieve their goals. They're not optimizing for helping the entire tech community grow one interview at a time. If they did, they would burn hundreds of hours every month collating and summarising interview feedback. What's worse, recruiters are not a technical as the interviewers, so it's totally likely that if the recruiter did give you a summary of your feedback, it would be much, much lower resolution than the actual feedback. Maybe the interviewer would say, "His alogrithmic abilities were great, but I found his approach to debugging his code naive and half-hearted." The recruiter might summarise this as "Your coding ability didn't meet Awesome Company's bar." In that case, the feedback is useless to you because you still don't know how to improve. Lastly, there's the exploitive case. If Awesome Company gave everyone feedback, Awesome Company would be the go-to place for getting the feedback, even for people who don't care about working at Awesome Company. Facebook saw a lot of this when it became common practice for Google to retain good people by throwing piles of money at them if they tried to quit while holding a competing offer from Facebook. People would interview at FB just to get the offer and go back to renegotiate their salaries. Brutal. In cases like that, giving the feedback makes Awesome Company exploitable. I'm stoked that you've received rejections and you're still pushing forward. That makes it much more likely that you'll succeed long-term.
Wow! I didn't expect you to put this much time answering my questions. Really, appreciate it. One thing about my last question: I understand that giving feedback my cause issues for companies, but usually, all I needed as feedback was something like this: "Out of the seven rounds, your score in the interview# 5 did not meet the bar!" and you can imagine, how much this sentence is valuable to a guy like me without any industry experience. Another thing that I forgot to ask is about networking! I've heard a lot that networking is one the most important factors in job hunting! is that true? Actually, I had to apply for well over 200 positions (all related to my resume) to get less than 10 interviews! The amount of stress that accumulates over time is so high that a shy person like me would be super stress out in the next interview (mostly, because you even don't know when you may get your next interview!). Btw, good job on pronouncing my name! ;-) I know that it's not an easy name to pronounce! Did you get any help? lol
Hi Jack, Good morning and hello from Sydney! This video was amazing and hugely inspirational for me. Nicely done !! Subscribed and looking forward to more amazing videos from you!
Update: please disregard my following comment. I just saw you mentioning level 5 (at Facebook) is a "comfortable" level to stick with. It kind of shocks me when the Facebook director refuses to hire that 8-year experienced person. I was expecting that he would still get hired, but just be offered a lower level of job since he's architecture skill is at that level. I don't know if it's just Facebook or a norm in FANG companies that would harshly expect a person to grow to a certain technical level in a certain amount of time (years). I am under the impression that there's a sweet sport in these large companies. For example, in my company (a well-known Bay Area tech company), it only expects the engineers to progress in a certain timeline for the first to IC levels. But when an engineer reaches level 3, it's at their own discretion whether they want to push themselves forward to the next level (level 4 is probably tech lead kink of role). I am thinking after level 3 (some company would have a different threshold), the company would hire people based on their skills which corresponds to how much value of work they can deliver, regardless of how fast they have been progressing in their career.
I liked the saying "If you are going through hell, keep going!" Although I don't agree to a few things like even if in your current job, you didn't get exposure to architecture etc. but there are so many courses out there and people do really well after taking those courses so then it's not really about your experience because it's something you can learn and ace the interviews. There are blogs of people who did exactly that and after failing initial interview took the courses like grokking the system design, etc and then were hired eventually
Conclusion: 1. There is no correct answer for architecture qs. 2. Performance at system design decides the final ROLE and OFFER 3. Your solution should be BROAD and DETAIL. 4. Practice by solving and thinking about real-life system that we use. 5. Find out the challenges in a given design question. 6. Breakdown the problem into smaller chunks(back of the envelope, capacity estimations etc) 7. Think about implementation details in client/server-side, different devices etc. 8. Don't let FAILURE stop you. 9. Read about tech talks and articles provided by other tech companies.
This was very helpful, thanks. Although it's a very depressing message that people stuck in crappy jobs after school will be unlikely to ever get a chance to join the "A-list" companies.
Hi, just a quick tip from the audience perspective: the music is a bit loud, and I have problems hearing you clearly. I don't know if anyone else experienced it, but I think it could be 75% to 50% lower.
Amazing video! Learnt a lot. I liked the background music it didn't bother me too much. Please do keep up these videos coming in. I just wish you had more videos love it!
Thanks, Jackson for such a nice video and covering all the point as an interviewer, However how or where to get the good understanding of designing such system when you never got such opportunity or you were in support project all the time during your career?
Excellent advice. I have 8 years of exp as a dev. But only worked at startups. Have a lot of wide experience, but nothing deep. Sys design has been the 1 HUGE stumbling block to cracking a big company now. Since they all consider me for Principal Roles which I downgrade to Senior Roles but the expectations are super high for Sys Design and they are all crashing. I have done the thing that was talked about at the end. I have avoided the whole hard interview my entire career. This time I decided to challenge myself. Not going to hit the Uber/Atlassians of the world. But I hope to end up somewhere nice soon. Been 8 months though. Its getting hard to stay motivated.
Hey Jackson, this is the best tip video for the system design interview. Really appreciate it. Would it be even nicer to have the background off 😊 - oh I found your comment about no-music version!
"if you get rejected it means you were at least at the front door of that place. just keep going". this motivates me quite a lot. thanks
me too. I said "I haven't thought about this before" when the guy asked me about how to scale up database reads on my app, and he immediately moved on. I've since read about scaling up database reads and it's all very basic, common sense stuff that I had in fact kinda thought about before. Oops
Jis front door pe aap pahunche ho, use front door ke bahar to hamne apni 20s gujari hai.
Nice video. But the background music is annoying. It keeps interrupting the mind.
There's a link to a no-music version in the description.
+Jackson Gabbard Thank you. Sorry, I saw it later.
+Sohail Siadat Really useful video for me.
The background music is actually helping me to concentrate on his words. Maybe it's a matter of taste. :)
Danm I thought that was just me and I didn't wanna post a negative comment about it. But yes. So much good information. Such bad distracting music.
This is probably the most "mature" systems design video I ever watched. No specifics, just handling different aspects and focusing on what's important for the outcome. Thanks for posting!
Motivating to say the least: "If you get rejected it means you were at least at the front door of that place. Just keep going." After getting rejected at 3 out of top 4 tech companies, feeling devastated. Thanks for this nice video.
Watched this a couple years ago when I switched jobs and marked it "Good" and now stumbled upon it again. Still feel that the content is awesome. Great technical details, good suggestions of strategies / approaches, and the explanations on the mindset one should have going into these interviews / prepping for these interviews are absolutely on point as well. Respect for putting out such good content,
That really means a lot. Thanks for sharing this. You made my day.
I wish you were still making videos. These have honestly been the most helpful and realistic explanations I have found to date. Well done. I'd love to see more about when you are working to actually level up your career. For example: devops (probably using AWS as an example since that seems to be what most use), a datawarehouse video on scalability, maybe even a video on choosing architectures themselves?
That transition to the squeeky voice was brilliant. It made my day.
Thank you Jack for the awesome video.
I would say that this is one hell of video that mentions a lot of quality content about the interviews, architecture design and how to prepare them. Some best things discussed in the video were :
1) The person had 8 years of experience and still he was low on architecture design. May be you are not pushing yourself harder.
2) We all might not be working in the company that works on scaling the application. But we can still know what the company is doing by reading their engineering blogs.
3) You must be driving the interview and not the interviewer should be pushing every time.
I was not pushing myself harder and it's better that I start pushing myself harder and start reading the blogs of big tech companies.
This is literally the best thing what I've ever seen on youtube regarding the Architecutre Interviews. Thank you for sharing this!
Such a candid and down to earth video. I was not at all disturbed by background music. His voice was crystal clear
Thanks a lot for your awesome video! As a self-taught engineer trying to land a job in big tech company, I find your speech really inspiring!!
One of the best take away "If you are going through hell, keep going."
This is just an awesome video! It really resonates with what I tell potential candidates and friends who ask me about how to tackle a design interview.
Stuff that I liked about the video:
1. Why a design interview is conducted
2. What is the interviewer looking for
3. Whats the worst thing a candidate can do.
4. Breaking apart an example problem -> mentioning the caveats that you were pulling numbers out of thin air (sorta)
5. How to get good at this (not just for the purposes of passing an interview)
So pretty much the entire 50 mins.
Please continue to post!
Great advice, great outlook, and great positivity. The only comment I would make is for the engineer with 8 years of experience -- I'm also self taught, and have been a SWE for 4 years: the first 2 of that was barely trying to stay afloat, and the last 2 were finally building cool things. Still not that good at architecture, but sometimes number of years alone don't tell the whole story
I have watched and read almost every major video and written source on system design and this is by far the best I've seen. What you do better than the others is address the meta issues around the fact that you are making estimations and might not know everything but that the point is to keep going and keep exploring even though you don't know everything.
That actually sounds like an interview that reflects a realistic day to day work :)
This is the true definitive guide to system design interviews. Very informative and really helpful. I wish I saw this much earlier in the process.
Thanks Jackson, I'm an incoming graduate looking at entry level positions with very limited industry experience, and I find your videos really helpful and lighthearted. Thank you very much for taking the time to make these!
Most insightful systems design tutorial yet.
Thank you Jackson for this amazing video.
Being a noob at system design, this video really helped me to boost my confidence to drive the interview rather than being driven.
Watching 28:30 in 2021 from a small town in India on my 300Mbps JioFiber connection which only costs $20 a month :D
phew.. time flies.
Haha! Indeed -- that part of the video definitely did not age well. 🤦🏻♂️
Jackson Gabbard, Incredibly amazing content. When I just started this video i thought you would be giving some generic tips and tricks to crack the interview - but you went in breadth and depth at some places and covered end to end.
It gives a clear picture of what happens in a system design interview. At the end summarizing, with haystack story and how to build or interact with the community who builds architecture that impacts large scale is simply superb.
Thanks a lot for such wonderful content :)
Great video, but this background music really is too loud.
Great video about general system design process. The concurrent connection analysis could go into some details on how you get concurrent users from throughput (68K user per sec). If every user stays for 1 sec and leaves, sure. You would have 68K concurrent users at any given point of time. But if visitors stay for 10 seconds on avg, then you would probably need to accommodate 680K concurrent connections (68K/sec * 10 secs) in total.
Thanks I was confused about this.
This is a fantastic video that inspired and also terrified me. I'm going to be as animated and hungry for knowledge as I can be in this interview.
Great video, it was so interesting that after a while I stopped noticing the background music which was little distracting in the beginning. Thanks for such inflammatory film
Can't thank you enough for making this, found it extremely helpful. Shame you stopped making videos!
I have an interview tomorrow (which I have a hunch will be on system design), and I gotta say you really helped out my confidence. Thanks. Fingers crossed for tomorrow 🤞🤞
success?))
Great content thank you! Wish there was a way to remove the music track.
Loved the video, you've earned my subscription. Super helpful as someone getting ready to leave their first job. MOAR!
Very helpful! Study vidoes like this and then practice at Meetapro with mock interviews will help you land multiple offers.
thanks for sharing. architecture is way less discussed since it's more open ended but imo shows a developer's experience much more. the bass line of the background track is also very funky
I was able to understand you properly but decided to read the comments halfway through and saw a bunch of people complaining about the background music and then couldn't watch it anymore haha
Excellent, I watched till the end.
Amazon is flying me for an on-site interview in 3 days ( 8 dec ). I'm a mobile developer . I failed at a similar company on the scalability interview but aced the coding.
Your video helped to get the right attitude. I'm talking with the SREs and they are happy to share how they solved the black Friday issue. I will post how it went.
Hi Raymond,
If you don't mind, Can you please share your interview experience?
OMG, what an awesome video. I wished I watched it long time ago. There is so much to learn. This must be shared again and again. @Jackson you are so awesome in explaining things. Thank you so much.
Thank You! Great piece of advice. I urge you to continue doing this. And that you walked through a problem and ways to approach it in a real world-> that was the most useful part!
I really love your intuitive way of explaining stuff! Thanks very much!!
In contrast to what everyone else is saying about the background music, I thought it made the entire talk easier to listen to than without
I was already watching this at 1:25X and you went flash at 32:00
Super good tips and mindset for approaching such interviews. Thanks!
Too good and you are a great communicator of your ideas. Just loved it.
Your video made me understand that I am never going to make it into a top-tier software company.
Not with that attitude
Please repost without the background noise a.k.a (music) ..this is a gold mine :)
Thanks for sharing the knowledge with us.I think i need to watch twice to understand
eyy you're still with us! please don't leave.
Laf. Had me there for a minute with the pitch correction. Was thinking "wtf is wrong with this guys balls" 😂 Thanks for the videos, man!
that was awesome jackson. happy I found this piece of valuable video. nothing helped me more than this to know what a intrviewer wants me in a system design interview.
I am going to interview with facebook. The system design interview advices you gave are very helpful! Thank you vm for the fantastic video!
This is a great video and I am seeing this in 2020. Why have you stopped?
At 31:50 talking about PII & GDPR was awesome ;)
I have a systems design interview for my first software engineering internship... Wish me luck. Ill try my best!
Hey, Jackson, it was a great video! Why did you stop do more like this?
Remove music please!!!
I can’t agree enough on this!
Such a good talk.. cheers. I have an interview tomorrow so this has helped.
one of the best videos on system design interview
Nice video. I made the playback speed as 2X as I usually do to understand any videos and it was such an amazing rap with music.
Thanks Jackson, it is a great video! Could you try to share some video about how to approach a detail system design question with drawing something, from frontend to backend, distribution system etc?
Amazing Video! Thanks Jackson. Gonna interview at FB next week, wish me good luck. : )
Thanks Jackson, great video!
However, the music was as loud as your voice and it made me drift away from what you were saying at times. Maybe lower the musci volume next time?
Best of luck in the future!
If you look in the description, there's a link to a version of the video with no music.
+Jackson Gabbard thanks
Awesome. That's what I need:)
for the question about how much data is acceptable to use? should we think about if it's appropriate to use mobile data at all? Why can't the phone store the data on the phone and upload it only when the phone is connected to wifi? Yes, there are some people who we may never get data from in that model but how many people is that? Is the loss of collecting that data worth the trade-off for a better user experience where we aren't using our users' expensive mobile data?
Thanks Jackson for valuable suggestions through your episodes.
I like you. Please make more videos. I also really liked your behavioral interview video. I'll definitely be using your advice, and recommend you to tech friends who are interviewing. Thank you so much!
What's with that speedup section? I kept messing with my video speed setting thinking there was a bug on youtube.
It took me whole two minutes to see you implemented a recursion into your video. hilarious!
The cup moves at 6:47. Magic happened!
Hey Jackson, thanks for the cool video.
I still have a bunch of questions:
- Is the top-down method a good way to attack those problems? I think one of my weaknesses was that I almost always chose the bottom-up approach (started from data structure, algorithm, etc.)
- It is true that there is no right and correct answer to many of the system design problems, however, how can I check the correctness of my design? I mean, in order to practice for the coding interviews, I can simply code my solution and try to compile and run it! But how I can make sure that I ask good questions, come up with good solutions, and not bull shit during the system design interview!!
- You mentioned that the architecture and systems design questions are usually not for recent grads, and those questions typically wouldn't result in rejections. However, as a recent grad that faced a few rejections, I am pretty sure that the system design interviews caused me to get the rejection letter! Well, I didn't have any issue in the coding interviews, and I assume the behavioral interviews went okay (didn't act like a psycho or weirdo, I hope!), so the only interviews that might have gone wrong were the systems designs. Would you also tell me why companies choose the zero feedback policy, which can be extremely helpful for candidates like me to find their weaknesses?
Let me see if I can do these questions justice in a RUclips comment reply:
- Is the top-down method a good way to attack those problems?
There are many acceptable ways to solve a problem like this and bottom up is fine, too. I once interviewed a graphics specialist with experience in high-performance video game programming who used his knowledge of kD trees to guide his decision making about a big systems problem. He worked his way up from the core algorithm that would enable efficient computation of the thing that the problem needed to compute and then figured out much traffic one server instance could handle and from there figured out how many servers he would need. Super strong performance. Honestly, I think either approach could work as long as the reasoning is sound.
- It is true that there is no right and correct answer to many of the system design problems, however, how can I check the correctness of my design?
Something I've told people in the past about architecture interviews is that you can't really "prep" for them. You can only sharpen your overall knowledge and intuition about large scale systems and do you best to bring that knowledge and intuition to bear in the interview. That said, most of the challenge of an architecture interview is purely reasoning, judgement, and complex reduction. I think an excellent way to prepare for this is to think about real-world systems and to try to estimate how they would have to work. Especially if there's an open discussion about them somewhere.
For instance, Square has a great engineering blog where they give away lots of juicy details about their systems. Let's say you were asked a question about how to host many diverse datasets in a highly available away. Maybe the use case is a system like Parse where people define a schema and your awesome systems figures out how to store it. You would probably have the intuition that there would be many backing databases (because the alternative is the insane table denormalization pattern that every n00b dreams up and eventually realizes is a bad idea). If you did figure there would be many different databases, you might wonder how many you could host on a single machine. You'd need some real-world context for this. Well, reading over Square's engineering blog posts, I get at least one useful data point: corner.squareup.com/2016/04/shift.html. The explain how many database schemas there were on individual hosts, what the upsides were, and what the downsides were. To me, this is delightful, amazing detail that helps me be a better engineer. Props to Square for putting it out there. AirBnB also does a great job of showcasing the cool stuff they're up to. Stripe also. So, you can definitely gut check your intuitions about how a system might work by finding existing companies that are talking about how their actual systems work.
There are also some great mental checks you can do. Once you have an idea of how to solve a problem, try to imagine one or two real-world costs associated with it. For instance, "If I did with my system, how much would it cost to run it?" Often, a bad design will immediately show as being either impossibly cheap or impossibly expensive. You might also ask, "If I used to solve this problem, what aspects of the problem might make that decision a bad one?" An example of this could be in a problem like deciding between a load-balanced, multiple server solution or a single, powerful server. I've seen this over and over again in systems design interviews. Often people who don't have a strong systems background will assume that any problem needs a) load balancers, b) multiple servers, c) backup servers, and d) some sort of complicated way of coordinating these two things. However, often the people who are making these assertions haven't looked closely enough at the core of the problem. They jump straight to some big sounding system architecture without justifying the need for it. You should ask really basic sounding questions like "Can I run the entire system on one machine?" "If not, why not?" "What are the specific things that make this a system that *needs* more than one machine?" If you build up from a place of deep scepticism about how much hardware to throw at a problem, you'll stand a better chance.
- Would you also tell me why companies choose the zero feedback policy, which can be extremely helpful for candidates like me to find their weaknesses?
Honestly, I find this super, duper frustrating. I've led *so* many interviews where I was dying to give the candidate specific feedback about their performance in order to help them grow. Everything from telling the smart-but-too-aggressive candidate to ease up to having a sit-down session with a candidate who was obviously so burned by their last position that they were showing up to the interview with venom in their voice such that no company would ever hire them. Sometimes it's as simple as telling someone "Hey, it's really clear you are missing this specific piece of background that is preventing you from succeeding." It sucks not giving that feedback.
I think the reasons are a few. For one, the more information you give someone you don't hire, the more easily they can sue you. Consider the language many companies use in evaluating someone. Maybe Awesome Company decided to give every interviewee a digest of the interview feedback. Maybe Candidate Casey gets the feedback and sees a line like, "While we loved your passion and your technical skills, we felt that you wouldn't be a good cultural fit for the team we're trying to create. Awesome Company prizes its culture of and felt that you might struggle to acclimate to that environment based on your time in companies embrace different cultures." It's extremely common to refer to someone's "culture" and whether or not they would be a "good culture fit." This is completely benign language in-context, but if someone felt discriminated against in not getting hired and wanted to sue the company who gave them feedback like this. It's very easy for an antagonistic lawyer to say Awesome Company was discriminating against Casey's religious or ethnic or social or vim-over-emacs or whatever culture. It could end up being a very expensive bit of benevolence for Awesome Company.
Next, there's just a practical matter of time. Recruiters have numbers to hit. Companies are optimising for finding awesome people to help them achieve their goals. They're not optimizing for helping the entire tech community grow one interview at a time. If they did, they would burn hundreds of hours every month collating and summarising interview feedback. What's worse, recruiters are not a technical as the interviewers, so it's totally likely that if the recruiter did give you a summary of your feedback, it would be much, much lower resolution than the actual feedback. Maybe the interviewer would say, "His alogrithmic abilities were great, but I found his approach to debugging his code naive and half-hearted." The recruiter might summarise this as "Your coding ability didn't meet Awesome Company's bar." In that case, the feedback is useless to you because you still don't know how to improve.
Lastly, there's the exploitive case. If Awesome Company gave everyone feedback, Awesome Company would be the go-to place for getting the feedback, even for people who don't care about working at Awesome Company. Facebook saw a lot of this when it became common practice for Google to retain good people by throwing piles of money at them if they tried to quit while holding a competing offer from Facebook. People would interview at FB just to get the offer and go back to renegotiate their salaries. Brutal. In cases like that, giving the feedback makes Awesome Company exploitable.
I'm stoked that you've received rejections and you're still pushing forward. That makes it much more likely that you'll succeed long-term.
Wow! I didn't expect you to put this much time answering my questions. Really, appreciate it.
One thing about my last question: I understand that giving feedback my cause issues for companies, but usually, all I needed as feedback was something like this: "Out of the seven rounds, your score in the interview# 5 did not meet the bar!" and you can imagine, how much this sentence is valuable to a guy like me without any industry experience.
Another thing that I forgot to ask is about networking! I've heard a lot that networking is one the most important factors in job hunting! is that true? Actually, I had to apply for well over 200 positions (all related to my resume) to get less than 10 interviews! The amount of stress that accumulates over time is so high that a shy person like me would be super stress out in the next interview (mostly, because you even don't know when you may get your next interview!).
Btw, good job on pronouncing my name! ;-) I know that it's not an easy name to pronounce! Did you get any help? lol
Hi Jack, Good morning and hello from Sydney! This video was amazing and hugely inspirational for me. Nicely done !! Subscribed and looking forward to more amazing videos from you!
Update: please disregard my following comment. I just saw you mentioning level 5 (at Facebook) is a "comfortable" level to stick with.
It kind of shocks me when the Facebook director refuses to hire that 8-year experienced person. I was expecting that he would still get hired, but just be offered a lower level of job since he's architecture skill is at that level. I don't know if it's just Facebook or a norm in FANG companies that would harshly expect a person to grow to a certain technical level in a certain amount of time (years). I am under the impression that there's a sweet sport in these large companies. For example, in my company (a well-known Bay Area tech company), it only expects the engineers to progress in a certain timeline for the first to IC levels. But when an engineer reaches level 3, it's at their own discretion whether they want to push themselves forward to the next level (level 4 is probably tech lead kink of role). I am thinking after level 3 (some company would have a different threshold), the company would hire people based on their skills which corresponds to how much value of work they can deliver, regardless of how fast they have been progressing in their career.
I liked the saying "If you are going through hell, keep going!"
Although I don't agree to a few things like even if in your current job, you didn't get exposure to architecture etc. but there are so many courses out there and people do really well after taking those courses so then it's not really about your experience because it's something you can learn and ace the interviews. There are blogs of people who did exactly that and after failing initial interview took the courses like grokking the system design, etc and then were hired eventually
Hi, Could you please make a video on System Design for ios applications as there is really a dearth of those online. Thanks!
This is actually great content. Thanks alot. Please do you know of any resource to learn more on mobile Architecture and Systems Design
Thanks, very helpful video! I really like the logging service example in the video, very thought-invoking
Hi what's the BGM? That sounds so good!
Conclusion:
1. There is no correct answer for architecture qs.
2. Performance at system design decides the final ROLE and OFFER
3. Your solution should be BROAD and DETAIL.
4. Practice by solving and thinking about real-life system that we use.
5. Find out the challenges in a given design question.
6. Breakdown the problem into smaller chunks(back of the envelope, capacity estimations etc)
7. Think about implementation details in client/server-side, different devices etc.
8. Don't let FAILURE stop you.
9. Read about tech talks and articles provided by other tech companies.
This was very helpful, thanks. Although it's a very depressing message that people stuck in crappy jobs after school will be unlikely to ever get a chance to join the "A-list" companies.
"If you are going through hell, keep going. That's a lot like architecture interview" - Nice
Jackson, thank you for such an amazing video advice. It's super motivating.
that is some solid advice right there. You’ve gained a new subscriber :)
Thanks for the information you provided in your video, but the music in the background was load a little bit and keeped distracting me :(
I have an interview at Facebook on Monday. I'm terrified.
How was it?
same
you passed?
I´m about to interview at Facebook for a rol in Android, which kind of questions did you did when you interviewed people for Android roles?
This is awesome, man. I'm totally into it and didn't notice the music at all. :)
Hi, just a quick tip from the audience perspective: the music is a bit loud, and I have problems hearing you clearly. I don't know if anyone else experienced it, but I think it could be 75% to 50% lower.
Good video, it would help if there is a way to turn off background music
Heck, you nailed it dude! What killer video it is... Great enlightenment... Keep rocking!
Another fan in your funnel :)
This is phenomenal, thanks for making this video
This is probably the most impactful video I've ever seen about interviews and tech
The user facing questions seems to be more a Product system design, than backend architecture design?
Really enjoy the way you talk. So COHERENT! 🤑🤑
Amazing video! Learnt a lot. I liked the background music it didn't bother me too much. Please do keep up these videos coming in. I just wish you had more videos love it!
thanks for the version without background music , it was driving me insane, how did you know? 😅👍🏻
Can you please do a video on whiteboarding a session where you go through a question of designing a service?
Very motivating. Love your videos. You're great at this. Why'd you stop?
Man, this video is so motivating. Big thumbs up
I was going to add a comment about the background music, but then i see a bunch of those already here. No more music please and thank you!
Thanks, Jackson for such a nice video and covering all the point as an interviewer, However how or where to get the good understanding of designing such system when you never got such opportunity or you were in support project all the time during your career?
Does a system design interview of this sort - which is really super-focused on backend design - really make sense to hire a front-end / client dev?
DItto the music comments, turn music off or lower it quite a bit. Thanks for taking the time to put this together.
Excellent advice. I have 8 years of exp as a dev. But only worked at startups. Have a lot of wide experience, but nothing deep. Sys design has been the 1 HUGE stumbling block to cracking a big company now. Since they all consider me for Principal Roles which I downgrade to Senior Roles but the expectations are super high for Sys Design and they are all crashing.
I have done the thing that was talked about at the end. I have avoided the whole hard interview my entire career. This time I decided to challenge myself. Not going to hit the Uber/Atlassians of the world. But I hope to end up somewhere nice soon. Been 8 months though. Its getting hard to stay motivated.
Hey Jackson, this is the best tip video for the system design interview. Really appreciate it. Would it be even nicer to have the background off 😊 - oh I found your comment about no-music version!