Uber system design: mock interview walk-through with Dima Korolev (ex-Google)
HTML-код
- Опубликовано: 12 июн 2024
- GET 1-to-1 COACHING for system design interviews: igotanoffer.com/en/interview-...
Today's mock interview: "Design Uber".
Our special guest candidate: Dima Korolev (ex-Google SWE) gives us a walk-through of how we can approach this Uber system design question.
You can see more designs from Dima on his superb channel: / @dimakorolev
Chapters:
00:00 Intro
01:50 Question "Design Uber"
02:02 1. Functional requirements
11:17 2. Non-functional requirements
16:44 3. How a ride progresses through the system
24:18 4. High level design
41:27 5. Metrics
43:44 6. Reflections
Need more help prepping for your system design interview? Use our free guide: igotanoffer.com/blogs/tech/sy...
About us
IGotAnOffer is an interview coaching platform that helps engineers get a job at top companies like Google, Amazon, Meta, etc. Our coaches are all ex-interviewers with first-hand experience of what it takes to get an offer.
- Read what FAANG engineers say about us: igotanoffer.com/en/reviews?ut...
- Get 1-1 interview coaching and land a job at Google, Amazon, Facebook, etc. Browse our coaches: igotanoffer.com/en/interview-...
- Subscribe to this channel for more high quality system design mock interview videos coming soon!
Get 1-on-1 coaching to ace your system design interview: igotanoffer.com/en/interview-coaching/type/system-design-interview?RUclips&
This is not a good example of a System Design Interview. There's way too much detail on requirements thinking, rat-holing on small details, and a complete lack of system design thinking.
100% agree
totally agree. too many functional and non functional requirements. Also failed to include those requirements in the high level design.
This one was confusing. The candidate seemed very nuanced before there was anything close to a working system. He was talking about scaling mutations, different read/write paths, and keeping state consistency before there was a data model, a request flow, or a simple application that matched drivers to riders. He also neglected how state was maintained (A database, perhaps? What kind, and where? What data is stored?). Because there were multiple instances of the API servers, how does this design maintain consistency if a node goes down? So it was a bit difficult to follow.
Exactly, he spent 25min on func req with very small details, some parts are really confusing and it stayed on a quite high level.
Yes, looking back, I should have definitely outlined the DB schema, API specs, relational vs. key-value, entities, domains, etc.
Got too excited to jump straight to what I think is both the bottleneck and the most challenging part.
Thanks for the feedback, folks! Hope it is still useful.
Problem is, the more experience you have, the more likely you will discuss user-facing concerns and high level design concerns before diving into drawing boxes. So a typical 45 min. design interview actually favours mid-level engineers who have enough design experience to draw boxes, but will also not spend more than 20 min. discussing requirements and high-level details.
@dimakorolev4740 do you agree?
@@slover4384hell yeah, zealously +100500
I would note that, with somewhat of a heavy heart, that my performance was sub-par.
The mode I've entered -- something of a "lecturer to the audience the level of which I am not familiar with -- may do well for a video where L6++ people see I can speak their language, but it does not really "check all the boxes".
We've discussed this video with a few friends who know both what I work on and how the interviews are run. The conclusion is that I've bombed this interview =)
But again, on the positive side, interviews suck, SD interviews doubly so (and behavioral interviews triply so!), but nonetheless it's the rules of the game we all play, so no harm in learning the rules of this game and investing a tad into mastering playing by these rules. Because in order to work with great people and build great things one has to first make it there, and, well, the rules are the rules.
Dima is an architect at Miro. Of course, his depth of knowledge and expertise is not represented in a typical system design interview conducted by average engineers. I appreciate having the opportunity to watch his interview. This is another level.
Dima is unconventional in his approach, and appreciated for his deep knowledge of the space and sense of humor!
Aside the preps for interviews, do you have an option to give advice by testing what your client is capable of, and then advice on what kind a jobs the developer to focus on e.g: data science, system design or some other areas?
Hi Damjan, yes absolutely. That would come under our 'career coaching' service. You can book an hour with a coach, they can ask you some questions to see what your capable of and then they'll give you suggestions and ideas of how to focus your job search.
igotanoffer.com/en/career-coaching
Very Nice, now i will create a uber clone :)
I wonder whether Dima is too experienced/algorithm-focused so he jumps into the core matching logic flow and challenges instead of as regular laying out system diagram blocks and explain DB schemas etc. System design interview is vague and open-ended. The interviewer bears the burden/bias to evaluate and differentiate brilliance vs lack of structure.
As of today Austin got Uber service ;)
The diagram didn't have the driver but did have the rider. Seems like a big hole.
It's not a system design interview
I got confused
While he seems knowledgable, this is probably one of the worst system design interviews I've seen so far. He has no sense for high level and deep dive at all. He randomly throws topics around and missed many important topics.
candidate is just doing functional requirements for 25 minutes!. never saw anything so ridiculous before.
More like a product interview than a technical interview. Some direction from the interviewer to keep the candidate on right track would have been nice.