Design Uber
Match riders with nearby drivers in seconds, track trips live, and price them, for millions of concurrent users worldwide.
2 questions on this site are reported in Grab software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: geospatial, matching, streaming, marketplace, real-time, pub-sub, fan-out, privacy.
Run an AI mock Grab interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from Grab. It indicates where a question has been asked, nothing more.
Match riders with nearby drivers in seconds, track trips live, and price them, for millions of concurrent users worldwide.
Show each user which friends are within 5 miles, refreshed every 30 s, for 10 M concurrent users, without leaking anyone’s location.
A brainstorming or whiteboarding discussion in which you justify each design decision. Grab says the round covers architecture, security and monitoring, not only the diagram.
Reciting a memorised design. Interviewers are reported to ask why each decision was made and then change the constraints, and Grab says it values how you solve a problem as much as the solution.
From public interview guides and candidate reports, and Grab’s own interview guidance where it publishes any. Not endorsed by Grab. Formats change; treat it as a prior, not a promise.
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in Grab interviews under different names.
Questions reported in Grab system design interviews include Uber and Nearby Friends. Between them they test geospatial, matching, streaming, marketplace, real time and pub sub. The reports come from public interview guides and candidate accounts, not from Grab, so practise the patterns rather than memorising one list.
A brainstorming or whiteboarding discussion in which you justify each design decision. Grab says the round covers architecture, security and monitoring, not only the diagram.
Reports say the Grab round weighs 4 things. 1. Assumptions stated up front, and a reason for every choice. 2. Follow-ups that add a new constraint, to see whether the design still holds. 3. Scalability, reliability and maintainability, the principles Grab points candidates to. 4. Security and monitoring designed in, not added at the end. Reciting a memorised design. Interviewers are reported to ask why each decision was made and then change the constraints, and Grab says it values how you solve a problem as much as the solution.
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Uber: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (geospatial, matching, streaming and marketplace) with one more question each.