Uber system design mock interview walk-through with Dima Korolev ex-Google

Show video

hello thanks for joining us for another system  design mock interview uh first just a quick   reminder if you are preparing for an interview  then do check out our platform IGotAnOffer.com   where you can find prep materials and you can also  get onetoone coaching with ex-FAANG interviewers   to help you nail the interview and get that job  uh okay my candidate today was hired by Google   after he was top coder of the month on algorithm  track of top coder he also scored in the top 50   in the final round of Google code Jam um and  since then he's done all sorts of things he's   become one of the most interesting people online  talking about system design and related topics um   he's also a host of the YouTube channel SysDesign  Meetup which you are welcome to get involved in   yourself um let's bring him on Dima, thank you  so much for doing this interview with us today   good to be here thank you Tom I'll do a lot and  I do have tons of pleasure and satisfaction from   having people become better engineers and pass  interviews with my callers so let's record this   yeah great thanks for doing this and uh yeah demr  is going to um play the role of the candidate but   um he he loves kind of helping people get  better interviews and get better at system   design first and foremost um so he will kind of  step out of character at some points during the   interview and to give you tips on on what kind  of considerations you should be you should be   making um okay that sound about right anything you  want to add or should we crack straight on excited   let's do it okay well dimma um the question I  wanted to ask you today is how would you design Uber all righty well we start from certain  requirements to make sure we're solving the same problem um usually in an interview  there's a section called f FRS and   nfrs functional nonfunctional requirements  personally I don't necessarily like these   terms that much but they do help so let's  let's talk about what we need to solve for let's first not forget that Uber is a  decided Marketplace so we have uh writers   they B wres um basically if I'm a rer I  am at Point a or I plan to be at Point a   right now sometime soon maybe in the future  and what I do is I use the app to call a cap   to call a car call a taxi call an Uber to  get from certain point B from A to B now or later um there also are the drivers which is  a totally different part of a conversation   because Uber again is a two-sided Marketplace  so there no let's put aside the conversation   about contractors versus full-time employees  basically we we're going to like not touch   regulation we got a bunch of people who have  signed up for the platform so that they can   be given rights I assume they pass all the  background checks and they are allowed to   do so and they also have the app open they  do drive people from A to B um and uh so to   me the most interesting part of uber is how  to how to connect these two because solving   for only only this only writers or only  drivers is not as fun as doing the whole   thing as closing the loop but for the sake of  completen let's talk about what the writers can do um well book a right from us a GPS of  course from the way so that I can book the   right from where I am right now or from  a given point provided Point uh I can uh   set custom time I can change the right  Midway I can cancel it before or Midway   there are tons of issues to worry about  when it comes to like if it's an airport   transfer pickup certain pickup points proper  terminal locations if there is a parking lot   to enter uh that's a big problem itself  uh I'm not sure we need to go there but   I need to I need to put it here pick up  drop of points Al to be honest this would be shared requirements and also the important  thing here is that we have ratings um and when I provide right so the way it works I think is uh when  I'm the WR when I'm the driver I start my day   I start my shift or what not I I'm back  in business after lunch and uh I open the   app and I Mark myself as as available which  which is kind of my first requirement right out of business one hold and then what  needs to happen is Uber is a company   doesn't request rights other writers  do so what happens when I'm marking   myself as as available U I'm going to  start with s I'm going to call them bids the requests to be the request  from particular writer to be taken   from point A to point B I should also  add here that uh we have different car types x black uh large and pets or whatnot  children and I should also add that uh number of people can be different so as a as a writer of  course I I Mark myself available in a particular   car the system knows that the system  knows I'm driving like a Mercedes-Benz   E-class which means I can take let's say up  to four people as a driver you mean all yeah   as a apologist as a driver as a driver yeah  you need to just change that it says Rider   just for oh thank you just not to confuse  the viewers yeah you're absolutely right so do not confuse the viewers writers drivers so what happens with there's a  there's a separate conversation behind   the scenes that has to do with with  the price uh price creation uh we   need need to talk about this eventually  I don't think it's the time is right now   but there is a there's a price it's in  the shareed requirements price setting engine plus search pricing search pricing is  a very clever idea it's that if we have a hot   Marketplace if if it's Christmas or if it's some  I don't know large sport sport event uh because   we have so many so much more writers than drivers  the price gets higher so that the the drivers make   extra money and the market works out this thing  but from what I understand from what I know Uber   by Design does not let people bid on prices Uber  says the price itself so it's other platforms   other platforms probably let you like put the  amount as the as the writer and potential as   a driver until the orders match like in the order  book but with Uber it's it's fixed price computed   by the platform given the current conditions  uh what's important here is that when I am the   driver and and I receive the bid I'm not entirely  positive I've not it's been a while since I've   seen this interface from the inside but I don't  think the driver knows a lot about the right   because I think from the product perspective there  used to be uh there was a failure mode when if you   want to go to a certain region where drivers  don't want to go to you cannot order a order   a car there order a uber there there so I think  what they would tell you as a driver is you need   to pick up somebody at a certain point it's going  to be on the map on your phone so I know how far   how far it is chances are it's going to be sent to  me while I'm driving a current passenger so that   Uber is a platform really wants their drivers to  be driving full-time so when I'm completing the   ride my phone will start buzzing me with potential  options and I think I don't think it's going to   tell me where or is the next potential writer  going but it's going to tell me if it's a short   ride or a long ride and I also think there's a big  important feature which was ultimately introduced   and people loved it drivers loved it when they  can Mark themselves as going home so that on the   one hand you cannot I'm sort of making this up but  it's fine on the one hand I mean I I I have some I   have some knowledge but I'm also making indicated  guesses the way it works is on the one hand you   don't want to penalize the writers who go to to  the area where drivers don't want to go they would   be embarrassing and insane so the way works is we  the platform Uber the platform does not tell that   driver that this potential customer potential  Rider wants to go to certain region they don't   want to go to but at the same time when it's like  late in my shift and I probably plan to be going   home I can hit the platform that hey I would much  rather be going towards that direction so if I'm   living in a town and I'm like north of it because  that's where the airport is I can probably start   marking myself as please take me to the rights  home but not Vice person so on heading help mode yeah so receive pickup location time most  often now um how long the right is PL to be how far and uh yeah I guess that's  it how many people maybe doesn't matter but not too much all right so now if this makes  sense I think it mostly does so far   um let's talk about what we're  actually optimizing for these   for function requirements um I think  the way I would put it nonfunctional requirements my goal the objective  is to keep the writers the drivers   busy oh I think I think there also would also be a rating my goal is to get the driver Vis that's  the number one priority from what I understand   about the right share in business it's always  the provider of the of the service the drivers   who are in shot Supply so whatever I  can do algorithmically design wise um   financially whatever I can do to keep them more  engaged especially when it's most needed by the   writers I should be doing that in terms of  CIS design for from the algorithm setpoint   the most interesting part I think would be  to to improve the algorithms of suggesting   which drivers get get routed to which  writers because that's my bur and but   that's my algorithm so I'm thinking out loud  here how to how to approach the problem of logistics so like let's let's  focus on the on the on the mention problem uh write driver full disclosure I have no idea how it works  I'm going to be making guesses which is probably   what you guys should be doing in an interview  so let's let's start to postulate it from first   principles um when I don't know what to say I  will start saying the most obvious things and   go with the flow the most obvious thing is that  imagine I'm the writer I'm taking my phone I'm   going to call they up I expect some nearby who  are either Idol or are about to complete their   trip I'm expecting them to be notified of my  request of my right yeah request um in practice   I'm almost positive the way it's going to work  internally it's that my write request is not   sent to all the drivers in the area at the same  time I don't really want my drivers to feel like   like they had to compete for the right I don't  feel like I don't want to design the system so   that that from the product standpoint from the  ux standpoint if I'm the driver who wants to   make money I'm distracted and frantically Ty  in yes yes accept the right once uh once I'm   about to drop off this particular passenger  and I'm looking for the next one in fact now   that I think about it one obvious thing would  be maybe a lot of drivers would actually enter   this automatically accept rise mode I'm not  sure if Uber works this way it might even be   against certain regulations but if I'm the  assistant designer I would argue that let's   extend this also consider some automatically  accept rights until I don't know t plus 2 hours 5m. so obviously if I'm the driver I have  a good rating I have a good car everything   fits U the platform if the platform knows  my default is to accept the right it's like   with Airbnb if you have instant look if  this driver yeah I could I could put this here if it's a platform I know that the writer  has request at the right and there is a driver   available in in their vicinity who's idle or  about to be idle soon and who has this instant   book feature on I will just send this writer  the this request and assume that the request   is taken at the start of the interview you want  to clarify the scope of the question with the   interviewer as DEA probably should have done  here before jumping in for example did we want   to focus on just the ride Hing app or include  Uber Eats Etc are we trying to design Uber as   it is now or a new improved version if you're  going to make assumptions clarify them with   the interviewer Dema covers the functional  and nonfunctional requirements in a lot of   detail if he was interviewing at Uber this would  probably be the right way to go because it's a   very product first company and an Uber interview  viwer will want to see that you're capable of   anticipating specific product needs and adapting  accordingly if you are interviewing at another   company such as Google you'd probably want to  be a bit quicker on the requirements to give   yourself more time on your design I think QX WIS  I would say I would do it like this like this so   we're going to be talking about the algorithm  plus ux and then we'll start drawing stuff uh um so from the the way I usually  do it is I would say like life of a right what what what happens to the  right as it progresses through the system first of all it's requested by  writer then the system starts looking for a driver um let's design so the main idea here is  that I don't really want to be sent in the same   R to multiple drivers currently simultaneously  because I don't want them to be distracted   so even if even if uh let's say there are no  instantly bookable drivers and there are five   drivers around me I would still not want to send  a request to all of them simultaneously because   as a driver once I'm seeing the invitation  to accept the right let's say I want this   driver to have 10 15 seconds well 5 10 seconds to  accept this right and they don't need to compete   with each other so like if I'm the driver I'm  dropping you off and someone else is about to   take a ride from from near where I am and I'm  seeing the notification hey there's a there's   a person next to us Mark who needs a write as a I  would like to design the ux and the flow so that   once as a driver I see this notification I have  the next let's say 7even seconds to decide if I   accept this right or no for the next 7 seconds  once it was sent to me this request this request   is potentially mine it's not being routed to  any other driver so either I accept it within   let's say 7 seconds or I don't in which case the  system finds the next potential driver so let's   say we're going to have a two two State two- tier  process if instant book not available Pi a driver nearby M AI for selection send them the request wait I don't know 7 Seconds  go to up find driver and be nerdy here if a driver is found If a driver who accept it is found go to peov so imagine there are no instantly  bookable drivers yet I pick a driver   I send in this D request wait for 7  seconds if if no confirmation within   this 7 seconds I'm going back to here  in which case I'm looking for the next   driver and instant book gets priority  if an instant book driver is a varable nearby I would say same thing but I give them like four seconds  that up seven if no explicit rejection is this   idea clear I just made this up it could be totally  off but my point is that if you have people who   who are who are in this hot standby mode and  they they committed to accept every right I   give them like four seconds to say no and if  those guys aren't available I book a person   who is not autoc confirming and I give them  7 Seconds to confirm now we get to the pickup mode um so to be honest in terms of sis  design our job is mostly done here pickup   is pretty much Google Maps navigations or  ways or Apple Maps I don't think we need   to design this we can use a third party  app of course if we're a company such as   Uber we have our own mapping technology  and and uh driving skilles what I serving   capacities what I think we should mention here  explicitly is the location is shared in real time moreover maybe tweaked to allow for uh  traffic lights uh curb site pickup details   Etc because I can totally imagine the first  version of uber to be using let's say some   standard Google Maps application and then I can  totally imagine some standard is failure modes   when let's say tiny road is one way and you  probably want to be picking up the the writer   like 10 meters to the north because that's  where it's easy to pick up this this person   so it's it's a separate conversation I don't  think we should go there it's it's a bit too   low level but fundamentally in the pickup mode  until until the match has been confirmed until   we know both of the GPS uh coordinates  of both people of both phones and until   we know that the the driver has started the  right we're still on the pickup mode pickup   mode pickup mode uh can still cancel  from either side might be for a Fe and U we in in this case if it cancel go back to   the starting point once approved once  the right is confirmed go to INR note confirmed includes but is not limited  to GPS manual confirmation by the driver perhaps driver perhaps a code I know there's a feature when oh uh there's  a feature when uh in certain locations in certain   jurisdictions you don't really trust people  people to trust each other so the platform   need to confirm that it's it's actually the the  correct Rider got into the correct car and the   way Uber solves for this is they have a code like  a four-digit code or QR code so the the writer   needs to share this with the driver and only once  that is confirmed the WR can start um yeah I think   I think this is mostly taken care of I could go I  could go on with the part where you like Liberty   or something but I think we're good enough what  do you say what would you say shall we shall we   get to shall we get to Dr let's start designing  yeah I think I think we we've covered enough there um do I have oh these are apps do I have  pictures okay fine I have a rectangle you   work at mirror so you should have everything  right I know right well it's a personal account   it's it's a free version I have a lot more  okay Labs enabled so um I'm going to start   from the writer which is the user because I  think it's it's where the flow mostly it's   it's where the more most intense flow  happens all right s design diagrams and boxes there are many ways to approach this and  honestly I it's been a while since I was doing   this as a candidate but a lot of times so the the  first high level question to ask is are we are we   using any cloud provider like Amazon a US Google  Cloud Microsoft Azure something else or are we   are we totally bare metal like our own Hardware a  good design is of course agnostic to this but it's   worth mentioning that so I'm going to I'm going  to do something like this I'm going to have a dashed angle should be far thicker  by the way yeah that's like my cloud misclick uh the way it always happens  the first box inside this thinky is a low balancer a lot people a lot of people Miss  what low balancers actually do so it's a   it's a cluster which is traditionally denoted  by having a couple of them yeah lb cluster I   think I can s it back uh the way it works is my  request hits one of the instances of this loow balancer can make it thicker um in the case  of uber it's not that important because extra   let's say 2300 millisecond latency extra like  3 seconds would not make things very different   but realistically what you want to do is you  want the request from the user to enter your   private Network as soon as possible so lot  balances not are not only used to to sh your   your backend servers so that you can you  can add more of them they also serve to   to make sure that they ENT use your device  the request from there enters my system as   soon as possible and whatever Network calls  happen behind the scenes they happen with my   own network which is controlled by me which  is low which is low latency High throughput   far more reliable that's what w balancer  does here then it would fundamentally uh there's a big thing to say to be  said here about uh G sharding I'll   get there in a moment so fundamentally I  would say like hypothetically this could   this could literally be something like uh  you can do it text this could literally be api. uber.com hypothetically that's that's the  resource where the request comes to if if if it's   HTTP is of course hgps to be safe and secure  to be not interceptable at least not easily   interceptable now behind the scenes internally  it should still be next to the arrow behind the   scenes internally what happens is I would argue  uh for many reasons low balancing and regulation   different cities have their different have their  own uh shs have their own specific sets of sets   of servers to serve the cities so it's like a  per location Uber server what I'm doing here   is I'm starting to get some work of routing the  traffic done on the low balancer level because   once you once the writer once once my phone talks  to law balancer first of all the phone knows where   I am I assume there are some GPS coordinates  I so if I'm in Austin it knows I'm in Austin   if I'm in Singapore it knows I'm in Singapore  so the request of the law balancer even even if   it hits the same end point the same high level  top level end point there's enough metadata for   the law balancer to already decide that I'm  drawing multiple of these because they also shed they know that the request would go to let's  say um Austin I'm not sure Austin has Uber by the   way so we can say it's there wasn't there was a  new article a couple years ago that that wasn't   that is it doesn't so let's say it's New York New  York and let's say keep keep waging this thingy   and let's say there is something else which is  San Francisco why not let's say it's let's say   it's Brin because we're International so the  lot balancer at the moment it needs to make   a decision where to where to pass this request  to it can decide which which which Uber location   it goes to and there could be like in Europe  there could be gdpr rules so for example per   location data for burden cannot leave burden not  leave Germany um I cannot comment on this right   now I what so far the only thing I'm saying  is that the moment the like my my request my   tab gets to the actual backend service here  it's already tied to a particular location I   think it's fine now this this is a tricky part  when people draw multiple things multiple boxes   like like I did here it means a couple things  one thing it means is that if one of them dies   the system is still up and running that's called  high availability that's called resiliency that's   called durability well durability is mostly about  not losing the data but still we need multiple of   this that one of them can die and then once  once we commit to having multiple notes um   it's a very it's a very delicate conversation  how to how to proceed here because in terms   of the system design architecture logically we  can treat this as a single box and then decide   how to best make sure it runs in a way that is  highly available so nodes can die but it's still   functional and durable so that once no once nodes  die they don't lose any data so let's pretend for   a moment logically that the whole Burly is  served by a single by a single instance of   an Uber server for buring uh as a high-profile  engineer I would actually go as far as saying   that it's not impossible because the total  amount of traffic to This Server when it comes to okay that's this this deserves this warrant's   drawing you have the so-called Riot  path which are the mutations State changes and you have the read path that's immutable request for example when I'm just opening the  app I really I literally want to see how many   cars are there available I don't need to go  to the right path I can go to the read path   and read path is super easy to scale because  that's what that's where strong versus vention   consistency comes them to play read path can  be eventually consistent if I if I literally   open the Uber app to see how many cars are there  around me if my data if the data I'm seeing is 3   five seconds behind heck even 30 seconds behind  the product still doesn't suck it still fulfills   all the requirements so the truth is that this  is super easy to scale because it can can be   eventually consistent where as the right path  can be eventually consistent the right path is   where potential data races collisions happen on  the on the r path if if both of us open the app   in the same location and we see slightly different  pictures that's okay on the right path if both of   us order right we get to different servers here  you get to server a I get to server B and somehow   these servers are not in line with what's going  on and the same driver accepts AR rise from both   of us that's a disaster that's a catastrophe  that's what should be prevented so logically   the right path is where this single source of  Truth sing singular like mut slog so to speak   synchronized section that's where it happens uh  so I'm going to put it here and say should be synchronized single source of Truth and so one of the most difficult problems of  system design is how to how to build synchronized   s of Truth systems that are distributed but  logically for now we can we can pretend there's   a single machine and again as a high performance  person I know it's possible if you if you take   all the read path ques this these guys if you take  them out of scope for now if you if if you pretend   there is enough machines that are only eventually  consistent they can be behind the world time they   cannot be up to date they might be like 5 Seconds  10 seconds 15 seconds behind the actual state of   the fleet uh we ignore them for now they just work  that's not difficult for the right path I'm going   to claim that the total number of requests for  new rights per second within the whole city of   burlin is going to be quite small if you look  back into all the state transitions so you go   to we have pickup mode find the driver mode then  we get the INRI mode etc etc then you can have to   confirm the right and you may like leave a tip  if you look at all the state transitions that   needs to be correctly synchronized with with  one another that needs to be that need to be   respected the invariance such as no writer can  no driver can accept two writers at the same   time I'm going to claim that for a single C of  Burling the number of mutating cures per second   is actually quite small it is certainly way under  one way under 1,000 I just cannot possibly imagine   that on the right path in terms of synchronizing  drivers and Riders you order more than one 1,000   rids per second so that's actually something  one machine can handle uh in practice there will   be more complexities here let me try to explain  this in this limited amount of time we have left   in practice is so the r path is a picture of all  the cars available so to speak the right path is the right wrer to driver matching State machine synchronization we also have something  in the middle which is synchronizing specific data uh the data specifically particular right let me explain that's important uh I believe  Uber has this feature share my right so I can as a   writer I can request a WR get matched to a driver  get matched with the driver get into the car is   a right to the airport and I want my peers my  wife or what not to do not be worried so I can   share them I can send the link with them right  through the Uber app so that they can watch in in   real time where my where my location is of course  internally even if you don't share your right Uber   backend Services absolutely do know where every  driver Rider pair is the point is this potential   component this guy sees a lot more traffic if if  the state changes such as right requested right   canceled Right started right ended for these I  believe the traffic would be quite small for the   whole city in New York it's likely under three  digits maybe maybe low four digits for this the   for the data specific to individual rights the  QPS is far larger because like in a perfect in a   simple terms you can imagine that let's say every  five or 10 seconds the car the driver uh updates   their position their coordinates connecting to  the server in deck so the traffic here this is   the most the most important part thing to keep  right this is where conf can have this is where   we need to maintain the invariant when the  same driver cannot pick up two Riders this   here the traffic is manageable by even a single  machine here we have a lot more traffic even if   it's let's say every 5 Seconds there's a beacon  from every single uh driver currently driving   for Uber or waiting to pick up someone and for  every single Rider who is at least waiting for   the right or in the right that can easily be  thousands of this driving life so you you can   easily get tens of thousands of requests per  second here but the trick is for this part you   don't you cannot potentially have the data from  one right colliding the data from from the other   right there's no conflict there's no there's no  path there's no room for for conflicts there's no   confusion you can break your your your logical in  variance here but not here so this basically what   I'm drawing right now would be logically speaking  a different subcomponents of uh of this per location of this per location Uber server so this  is a fleet of servers I've I've ploted a couple   of them I would argue that in practice for this  logic but let's actually let's start from let's   start botom up for the for the read path you  can add as many machines as you want they just   subscribe the feed feed of internal updates and  uh it's like a CDN more or less to get to get   snapshot of of which cars are currently available  in in berl you get to one of many of these notes   and you get the data that is somewhat accurate  you just scale this as necessary I would argue   there could be dozens of them maybe five five  to 10 for Bry maybe 15 for New York maybe 50   or 100 if you don't write your code correctly but  that's that's a large number for these things you   need as a large number of them too but each so  these notes are all identical in logic they all   interchangeable they're all funable if one of them  dies you just replace it by a new one uh they they   all serve the same purpose and have the same data  for these logic um if one node dies what happens   is you start the traffic from your writers drivers  and active rights you sh this traffic so that a   particular data point in a particular time goes to  a particular server you can use consistent hashen   to send send it to two or three machines just to  make sure if one dies they is lost but honestly   that's not important because if if a machine dies  well what's the worst that can happen for the next   I would say half a minute you lose track of this  big and keep alive messages of where the driver   is no big deal on a company scale so this is also  straightforward although you need to work on your   sharting properly for this part you need to be  super careful if you're a ninja engineer if if   your Uber is a startup that just need needs  to launch somehow I would sincerely suggest   that we just have a single machine for the whole  buring that that handles this if it dies until   it TR starts or until a new machine starts on  a backup for a couple seconds no new rights can   be requested no new rights can be confirmed or  canceled or whatnot but in practice if you're if   you are the big Uber itself you don't do it on a  single machine that's too dangerous you have a few   of them the standard technique is to use data  rections have a have an odd number of machines   stand traditionally would be three or five so  that they always are in touch with each other   they always know which one is the is the main  one who whose word matters most in a democratic   setum so that if one of these machines dies if  it's not the leader that's okay it's it's it's   replaced and kept up to date if the leader dies  within a split second another leader is elected   and they guarantee that all the invariant we  need to we need to respect are being respected   that's my high level diagram DEA has laid out a  very convincing highle design and explained his   thinking clearly throughout one potential area  of improvement is at senior level a lot of focus   is put onto protocols dimma mentioned https in  relation to the connection from the user's phone   to the load balancer and Beyond but he didn't  mention web sockets he would have done well   to mention there should have been a persistent  connection opened from the driver's phone and   the rider's phone sharing the location coordinates  using a single API call to achieve this would have   been wasteful yeah that's uh that's interesting  I wanted to uh ask you what metrics are you going   to be tracking here like how are you going to  know if the system is behaving as it should do oh that's a big question there are there are tons  of directions there are tons of ways to postulate   the question actually so like bottom up as an  engineer I want to make sure that my system is up   and running so I would look at I would look at the  traffic numbers everywhere traffic numbers here   traffic numbers to every single location traffic  numbers from within internal systems to all these   components all these three if any of them drop  something something is wrong that's something   I can totally totally monitor myself as a as a  higher level C designer I would also argue we   need to track user facing metrics I want to know  how many rides are currently taking place I would   imagine the the office like imagine berlan has has  an Uber office I don't think it's the case but it   doesn't matter I would imagine there's going to be  a large screen to monitor real-time metrics with   tons of charts it will be like active real-time  number of number of riots happening right now   there will be like this daily sine wave because  there is more at night than in the afternoon and   if suddenly it goes below what you would expect  or above you what you would expect this should   trigger an alarm an alert somebody should look  into this I would look into the length of the   rights if the traffic pattern has changed I  would look into the ratings of drivers and   writers are we are we clearly like I will not  deteriorate in performance for the end users I   would absolutely look at more fine grain metrics  such as like average distance from the rider to a   driver average pickup time because in practice  this is a very high level picture in practice   there's going to be tons of a testing behind the  scenes if my engineering team has designed a new   meion algorithm that is presumably making pickups  faster chances far is being a tested for parts of   drivers and I want to see how how it performs  how it behaves so they can make a decisions on   how to roll it out and went so yeah tons of cool  stuff thank you for a good question yeah thanks   for the answer um also yeah just before we wind  this up um are there any other kind of features   that that you think might be interesting to  add and and how how would they affect your design um yeah let me reflect let me look  back at this as as I slowly exit the mode   of someone who was interviewed and I enter the  mode of the like in hiring Committee Member um   I think I've I've tried to give your listeners  the best possible experience of seeing how how   the real interview looks like in practice if I'm  being an interviewed like this I would absolutely   ask what are we designing for real because nobody  designs Ubers these days from scratch either it's   a smaller startup so that it's it's not a dup a  replica of uber but rather some some more targeted   news product I don't know maybe it's a maybe  it's a Richa pickup maybe they are allowed to   use pedestrian roads maybe they have drones maybe  they have extra regulations on what what business   Advantage they have compared to the Uber itself  in which case the design should absolutely be   focused on this particular tailored like tailored  own mode on the other hand if you really need to   design Uber well I can I can guarantee you as  someone who's in the industry for a long time   this is not how Uber looks like on a high level  yes but as we all know from Twitter and Elon   Musk high level whiteboard designs have little  to do with what systems look like behind the   scenes so for the for the interview conversation  I think that's approximately what I would imagine   candidates should draw when ask this question  but if I'm interviewing given I'm a couple levels   above the senior staff level I will probably be  having a more product first conversation I think   I managed to strike the balance and actually  talk about consistency about data flows about   databases somehow but yeah it's it's a really  big can of worms and if I can leave you with one   thing here you got to read your interview you  got to figure out what this particular compan   is looking for Uber in particular is well known  Uber is a company is well known for looking for   product first Engineers if you actually talk  to the to your interviewer about hey I need   to optimize like curbside pickup I need to suggest  pickup spots because that's where writers are more   happy to be picked up compared to other pickup  spots where they complain like they were they   were honked at this is super useful this gives you  tons of bonus points for Uber for other companies   do your homework but yeah tons of ways to go  from here Dema gives some very useful advice and   insight here for those of you with interviews  coming up so let's recap quickly be sure to   clarify at the beginning what problem you're  trying to solve in this case are we designing   Uber or a new improved Uber for example generally  the more senior your level the more product first   your approach should be but try to figure out what  your target company is looking for Uber is known   for hiring product first Engineers but that's not  the case at every company this is where doing mock   interviews with ex interviewers from your target  company can be very helpful you can do that with   our coaches at IGotAnOffer.com Dima yeah I think  we can we can finish it there unless uh there's   anything else you want to you want to comment on  or any other advice that you want to give to the viewers um well I'm still in the in the excited  mode so I I would say one thing I did not do and   you guys should is talking about databases  I've deliberately voted the topic because   the high level the high level picture trumps uh  the choice of like S no SQL and stuff like that   but fundamentally yeah I do hope it's helpful  please spend your time with you Tom and all the   best hello really hope you found that useful  if you did you can like And subscribe and why   not come visit us at IGotAnoffer.com there  you can find more videos useful Frameworks  

and question guides all completely free  and you can also book expert feedback   one to one with our coaches from Google meta  Amazon Etc thank you and good luck with your interview

2023-10-29

Show video