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.
I think this is a proper one SD. Tease out every piece of requirements at the beginning is vital for later development. However, i understand where your points are coming from. If requirements are not carefully considered, one's design is just a good looking useless picture.
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.
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.
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.
This is an example for how to do the interview as a senior developer. The interviewer could leave the room and Dima could talk with himself forever. I assume the interview session should be a showcase of communicating on unknown to some level ????
Very very detailed, shows how much attention he gives to details, though I think he should've asked about the scope that he's supposed to work on instead of the entire app, or assuming the scope himself. Also, at 24:11 I missed having some numbers before going full diagram to have a notion of the scale we'll be working on. How many drivers "available" concurrently? How many rides a day? How many users (riders and drivers) in total? Number of active users, etc... I also feel like he communicates very well, but leaves the interviewer out of the discussion a lot.
pro tip, never use miro lmao. use excalidraw or any other simpler tool. Avoid figma cuz its heavy and can lag and crash potentally. pick a very lightweight tool that can be customized to your needs or has what you need with a very lightweight proccess
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
Yeah lol, could you get Mark to redo the system designs for Uber, no offense but Mark is way better in explaining and going into detail about the design, detailing the speficing databases needed to be used, what languages are need to script the app, as well as server side langugages needed to handle incoming and outgoing requests from the client.
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.
I had a feeling from the initial few sentences this guy dropped, I knew he is gonna be cooking too much. I call this over cooking in system design interview.
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.
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.
I think this is a proper one SD. Tease out every piece of requirements at the beginning is vital for later development. However, i understand where your points are coming from. If requirements are not carefully considered, one's design is just a good looking useless picture.
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!
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.
This is an example for how to do the interview as a senior developer. The interviewer could leave the room and Dima could talk with himself forever. I assume the interview session should be a showcase of communicating on unknown to some level ????
Very very detailed, shows how much attention he gives to details, though I think he should've asked about the scope that he's supposed to work on instead of the entire app, or assuming the scope himself. Also, at 24:11 I missed having some numbers before going full diagram to have a notion of the scale we'll be working on. How many drivers "available" concurrently? How many rides a day? How many users (riders and drivers) in total? Number of active users, etc... I also feel like he communicates very well, but leaves the interviewer out of the discussion a lot.
pro tip, never use miro lmao. use excalidraw or any other simpler tool. Avoid figma cuz its heavy and can lag and crash potentally. pick a very lightweight tool that can be customized to your needs or has what you need with a very lightweight proccess
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
The diagram didn't have the driver but did have the rider. Seems like a big hole.
Yeah lol, could you get Mark to redo the system designs for Uber, no offense but Mark is way better in explaining and going into detail about the design, detailing the speficing databases needed to be used, what languages are need to script the app, as well as server side langugages needed to handle incoming and outgoing requests from the client.
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.
Very Nice, now i will create a uber clone :)
I had a feeling from the initial few sentences this guy dropped, I knew he is gonna be cooking too much. I call this over cooking in system design interview.
It's not a system design interview
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.
candidate is just doing functional requirements for 25 minutes!. never saw anything so ridiculous before.
I got confused