System Architect Breaks Down System Design Interview [ex Google/Microsoft]
Вставка
- Опубліковано 24 лип 2024
- In this video, Dima Korolev, a system architect at Miro and senior engineer (previously at Google and Microsoft), uses his extensive experience to break down a mock Systems Design interview.
This is the second installment of Inspect Element, an interviewing.io series where senior software engineers from top tech companies review mock interviews conducted on the interviewing.io platform. Through these videos, you'll learn the ins and outs of algorithmic/data structure & system design interviews directly from the people responsible for conducting them.
Dima has 15+ years of experience interviewing candidates for major tech companies. In this video he provides his perspective on what the candidate is doing right, and what they could improve on. Among the things he covers in this video are:
● Time management in the context of interviews
● Important, but commonly missed factors in solutions
● Improvements on the proposed solution
Excalidraw from video: excalidraw.com/#room=ea8411a0...
👉 Original Video: • System Design Intervie...
👉 Sign up to book a mock interview just like this one or to watch more interviews in our showcase: www.interviewing.io
❗❗ Disclaimer: All interviews are shared with explicit permission from the interviewer and the interviewee, and all interviews are anonymous. interviewing.io has the sole right to distribute this content.
Timestamps
00:00 - Introduction
03:09 - Interview starts
03:36 - E4/E5/E6
06:50 - Using cheat sheets
08:16 - Making the interviewer go off script
09:59 - When asking backfires
11:18 - Who you're dealing with
13:58 - Why bring in the browser
16:17 - Template to their disadvantage
20:09 - Asking too early
22:41 - Asking too much
23:50 - Online Judge Problem Explained
25:11 - Capacity estimates start
27:24 - I don't recommend capacity estimates
28:35 - Scalability/Availability
36:15 - WordPress/Code exec
40:20 - Beating nervousness
45:27 - Speaking too fast
49:01 - Time management
53:25 - What is manageable?
54:25 - Know your interviewer
55:13 - Focus on original question
59:50 - Storage Data Model
1:06:10 - Don't ask about cloud
1:08:04 - API gateways
1:12:21 - Functional requirements
1:14:04 - He talk's like an L4
1:27:22 - Boilerplate answers sync/async
1:33:10 - Right words but no structure
1:39:50 - Schema
1:46:02 - Frame of mind
1:50:21 - Recap
1:55:48 - Feedback for interviewer
1:59:17 - Did candidate pass?
2:00:57 - Stay away from templates
2:04:33 - Feedback on the feedback - Наука та технологія
![Two Ex-Google System Design Experts Compete: Who will design the better system? [Part 1]](http://i.ytimg.com/vi/Zi0pPkiFemE/mqdefault.jpg)
![Two Ex-Google System Design Experts Compete: Who will design the better system? [Part 1]](/img/tr.png)
Dimas analysis actually sobered me up a bit and now I am not obsessing over the templates as an SDE2 candidate, and will instead try to be true and honest during my sys design interview. I'm an SDE2, my system design skills are supposed to be pretty novice - I can do well by having good communication skills and reasonable judgements.
This is superbly useful content! Thank you for your time and efforts.
Thanks Dima for your valuable timing
Great interview break down, thanks a lot for sharing.
Interesting enough - I had the 'hearing a knock on my door' trick and to even admit nerves when needed written in my self notes before I watched this video. I get so absolutely anxious over my interviews, and it's comforting to hear that people can relate
Thanks Dima for sharing this helpful content
On of the best content. Thanks 👍
Good job. Keep this kind of more videos.
Thanks for your feedback
This very helpful one. Probably I want this kind of videos
I like this kind of videos. Thanks for sharing with us.
I love these types of videos! Definitely should do more of them! We really need to see the excalidraw in real time though.
Small criticisms regarding the person breaking down the interview:
1) A little too nit-picky, the candidate clarifying it would be browser based is perfectly fine. Gathering this requirement could potentially change the implementation slightly in certain cases (e.g. the discussion later regarding on how to return the submission result to the user, does the client support web sockets, etc..).
2) Overly focused on side details (Coding problems where the solution isn't deterministic, buy & run our own servers to save cost, etc..). If prompted by the interviewer then you can absolutely go into this, but otherwise with limited time you don't want to go on unnecessary tangents that the interview likely doesn't care about. He wants L6+ candidates to mention these types of things which you can do, but should be done quickly unless the interviews wants to pry more. Personally I feel its more important for L6+ candidates to identify architecture based issues around real world usage patterns (E.G. we're probably going to want competitions, this is going to cause extremely heavy load of 100k+ submissions especially in the final moments of the deadline, we need to make sure we are able to handle this scale without delays and make sure it doesn't cause additional bottlenecks)
3) You should have spoken more about the high level details that were missed (What is replicated, where/how are health checks performed, fault tolerance, how exactly does the system perform the actions described, the important parts of the schema, etc...)
Good things:
1) The person judging suggests not doing capacity estimates, finally something I agree with strongly! Asking 1-2 questions to get an idea of scale is fine, but as the interviewer mentions the exact details are usually irrelevant. When doing the overall architecture if you identify a component that can't scale horizontally indefinitely, at that point you can identify the bottleneck and dive into those types of details further.
2) This interview was strange, the person being interviewed seemed to have a really strong technical knowledge base (L5+) and didn't make critical pitfalls that a lot of other candidates tend to make. The time usage, delivery, and explanations were all over the place (L4 or below...). Usually you find the opposite where the candidate is very well put together, but it becomes readily apparent they haven't designed enough real world systems and you can still weed out that they only have book knowledge & are not a true senior. Getting rid of the template, using time better, and slowing down a bit will easily get this candidate to an L5 level.
Good analysis and response. I'd add that some/most interviews should be framed such that soft skills can be analyzed through direct inquiry or related exposition of past experience (though maybe that could fit in Q&A).
Hi, thank you!
Good point about replication. I did clarify that it's important for the candidate to speak about persistence of data (as part of the life cycle of the elements of the data model, such as submission, judgement result, etc.) Replication (fault tolerance / high availability in general) was sort of implied there, good call that it should be more verbose in the cover.
Also, from my comment below about using the browser: I've used online judges that are desktop Java applications. You literally "Upload a file..." with a solution. So, browser is not strictly necessary to build the online judge, although, in 2022, it's relatively safe to expect the users to access it from their browsers.
It actually took quite some time to prepare and record this cover, so I join Kevin at encouraging you / you guys to do so as well. We need more of this content online, this I'm certain about!
Yea, overall great job! Loved the video.
It’s understandable that you might want different clients, but the more jarring part of your commentary is you made it seem like a big negative having the candidate clarify that. It felt like a very neutral clarification. I wouldn’t make any assumptions about the candidates competency from that. You seemed a bit picky about small details that I would have let slide as I felt there were more important things to critique on.
That being said, most of the things you said were spot on, glad to see someone else agree that capacity requirements tend to be overdone and are seldom relevant. It was a really solid breakdown and everything else you mentioned was insightful.
@@christophergregorio9602 I just want someone who knows why back-filling data is important, how to do it decently, and where it's needed/not-needed (back-fill everything, it takes less than a week, it will save you months, I will die on this hill hahaha).
I'd also like to hear something about system alarms, even if half a sentence, from candidates at this level.
"Getting rid of the template" - Could you please clarify what you mean by this?
Highly informative!
This is very helpful content. Thanks
Thanks for your surprising video
Thank you Dima
Definitely helpful for everyone
Great stuff!
Great job. Keep it
Great one!
Very good contet. I think you will share more videos with us
Excellent interview 😍
Good job. Keep it up ☺️
Great interview
Perfect interview
I honestly like this one.
Great videos
101:26 "probabilistic problems" that part completely confuses me and why running results on multiple machines
Very helpful one
Great video, I particularly appreciated the distinction between L4 vs L5 answers. One nit, the excalidraw link doesn't take us to the candidate drawing.
We're glad you enjoyed it! Sorry about the excalidraw link, one limitation is that old designs seem to be overwritten/changed. We'll work to ensure future videos have designs saved elsewhere.
Good interview
This problem feels like the distributed cron job problem but with potentially more security implications since you're involving arbitrary code execution. What does the Internet think?
The commenter was really good. I also did not believe OJ uses queues in the real world either. I mean you can, but to make sure users get the judge status and result ASAP, one way to wait the results synchronized, and the other is, as most of the "answers" online out there, using a message queue. While using a message queue would free the resources from the backend, in order to push the updates to users, you would still have to maintain a long open connection while users are waiting for the results. One saves some resources for maintaining the connection, while the other saves resources on maintaining the queue. Apparently maintaining the queue is a much higher level of effort and does not bring any performance gain.
Thanks...
I more prefer this kind of video 👍
Also please increase the volume.
I think probably you should more explain about this.
Avoiding specifics around back of the napkin math / scaling estimates and instead smoothing over them with broad strokes is a very unique approach ua-cam.com/video/IJSVmyhq2i0/v-deo.html. Let's say you have the distributed cron, how would you talk yourself out of capacity estimation there?
Keep it up
Best one
48:31
talking to strengths instead of asking "if this the right idea"
contradicts the earlier point about checking with interviewer we are on right path instead of talking endlessly
Him This services isn;t available in India. It would be super great if you guys can do a L7 kindof role. There is a demo video, but it doesn't talk about the expectations. For example, one of the videos, ua-cam.com/video/NWRqJFZ0rbY/v-deo.html (47:00) where the feedback is to be more and more explicit, trying to bias the system more towards the capacity estimation. But doesn't talk a lot about the L7.
1:17:47
The candidate wasn't amazing and the template is thoroughly dumb, but...
If you mention CDNs on a system design question before you even have a basic rudimentary, synchronous, optimistic, and borderline half-stupid definition & solution to a single base case, I would be concerned (and yes, if the business cannot answer a single question when the candidate asks 'what is important?', the candidate's job role is now much of management's if the interview reflects reality).
You're not senior enough for asking what the business thinks is required? I have no response to this matte machine perspective.
Why bring in the browser? Because it's the primary client and upstream dependency of most actions. If you think someone is dumb for saying so, I don't know that you're a good interviewer.
With that said, I can't agree more on viewing interviews as a collaborative process where the interviewer and candidate are in a simulated team effort.
Yeah, we could bring in the CDN topic in a more gentle way.
The main point is that mixing the traffic (QPS) of serving static problem statements with the traffic (QPS) of sending in submissions and receiving their results in some form (result, leaderboard update, email, etc.) is a blunder.
Also, for the record, I have used online judges that are desktop Java applications. You literally "Upload a file..." with a solution. So, browser is not strictly necessary to build the online judge, although, in 2022, it's relatively safe to expect the users to access it from their browsers.
The best solution to this problem is getting management drunk and convincing them that only the top 100 scores belong on the leader board. Honestly in real life I've escalated requests up the entire leadership chain until I got a sensible answer (which they honestly appreciate if you're not being a dick or pointing fingers), but I get that this is a hypothetical thought experiment.
My interview style is more focused on mental gear changes on problems starting from an empty context, to defining the minimal problem, establishing minimal requirements, identifying system defects, violations, and bottlenecks -- this can be done in ~5 minutes for qualified people on a good day. Then run other defined request types through the system to see if the system breaks or gets overwhelmed. Abstract if required and iterate to complete.
I wouldn't expect much about custom hardware unless you work at a low language level or work some place where nanoseconds matter like at a HFT firm building some special DB with an FPGA board.
Side note: this interviewer was not professional in my opinion, especially towards the end. They way he said "it's more important than you fucking up" in that dismissive tone to the guy that's already anxious and actually fucking up. Just end the interview at that point or talk about the weather if the "no" has been decided.
@@countofmontecristo8369 Yeah, without opening any cans of worms, I'd be the first to admit that part of the objective of this video -- and of Interviewing.io, to be completely honest -- is to maximize the candidate's chances of receiving an offer.
My preference is to balance on the edge of making the candidates -- as well as the audience of this video -- both learn how to be better engineers and maximize their chances to pass interviews.
In other words, I sincerely don't pay much attention to whether the interviewer could have presented themselves differently. It's just not worth our emotions -- neither while we interview, nor when we work together.
For the record, I do like this particular interviewer, and do not think he comes out as unprofessional. It's a mock interview, after all; I pretty much tell you guys explicitly that certain feedback is best to be interpreted as "you suck" =)
There's just not much demand, it seems, to train professional interviewers beyond certain point. This interviewer is far above the bar to my taste. In a company where I'm interviewing people now, I'd certainly want him to interview "real" candidates. But again, I'm known for not paying too much attention to this aspect of conversations, as my personal motto is that substance is far more important than form.
Thanks again for your feedback!
PS: FPGA boards are fun indeed.
@@dimakorolev4740 Appreciate your thoughtful response. I'm sure I'd have the alternate-universe version of me equally, if not more so, questioning things I said in an interview analysis. I do wish we all could spend more time on optimizing the silly interview process, corporate culture, and larger societal goals without gaming the meta, but it is what it is I guess.
For now...
Note to self - if you put "expert" in the title people will go out of their way to debunk the "expert"
For anyone who critiques in the comments...
Why don't you make a long form video analyzing an interview ?
I'd love to see you try actually we' re looking for content creators
I hope you're not expected to check work comments at such an hour. Also, unless this was just edited, 'expert' only appears in your comment. Also, critique is good, my guy. I appreciate all thought invoking critique of my own work from anyone (even if it's called a mess). The present two comments here can only help your business (seriously I don't know if I would hire or be hired/work under this interviewer, but the other design fellow from another video conducted a better analysis).
You guys should take these comments and write medium articles expanding on these comments in a positive "thanks for your thoughts, let us expand on our POV or revise and add additional information" or at least be passive aggressive under sock puppet accounts. Utilizing articles as content from and for users would increase user engagement and likely play well with the algo.
But what do I know :)
Nobody is “debunking” anything lol. Overall the guy did a great job at breaking things down, just a few odd points here and there. The reddit guy in your other system design interview was absolutely incredible!
It’s just a little bit of constructive criticism as he had a tendency to over focus a bit on minor details and not address some bigger concerns. Overall it was a great breakdown though and will be helpful to most people watching.
You definitely need to be a little bit less defensive lol.
@@christophergregorio9602 Could you link that Reddit guy here pls? Gotta learn from the best.
Yea, it’s this video: m.ua-cam.com/video/oHyaRvnX2G8/v-deo.html
His communication is outstanding more than anything else.
@@dimakorolev4740 The video is called "Senior Engineer Breaks Down Systems Design Interview" from this same UA-cam channel