What to Expect in the Grab System Design Interview

Expect one design round of about 45 to 60 minutes, built on Grab's own product problems. Grab is the Southeast Asian superapp company headquartered in Singapore, and it runs ride hailing, delivery, and payments. Grab's careers site says the functional interviews run up to four rounds, and candidates report that one of those rounds is system design.

Candidates also report questions about scaling a service for a large regional market, including one reported question about scaling an API to meet market demands. Grab publishes detailed engineering articles, so the real systems are available to study before the round. Product judgment is graded here together with the architecture.

The Question Types

Real time matching. Grab's core problem is connecting a passenger to a nearby driver within seconds, and Grab's engineering posts describe a service that searches for those drivers along the road network. That service ranks drivers by routing distance rather than straight line distance, and it first matches each driver's reported position to the nearest road segment, a step Grab calls snapping. A separate Grab explainer covers geohashes, which are short codes that divide the map into small labeled squares so that a nearby search checks only a few squares.

Allocation rules. Grab states publicly that it does not always assign the nearest driver, and its published description lists estimated arrival time, driver preferences, fraud checks, vehicle suitability, and order batching. Expect follow-up questions about the ranking rules, not only about the search itself.

Delivery and logistics. GrabFood, GrabMart, and GrabExpress add restaurants, merchants, and couriers to the same problem, and the hard parts are preparation time, batching several orders into one trip, and late cancellations.

Payments and ledgers. GrabPay and Grab's digital banks move money in several countries, so expect questions about exact balances, retries that must not charge twice, and rules that differ per country. Idempotency, meaning that a repeated request has the effect of one request, is a common follow-up.

Streaming and scale. Grab's engineering posts describe an event streaming platform built on Apache Kafka, which is a system that stores streams of events so that many services can read them in order. Booking, payment, and analytics events all pass through that platform.

Weak network conditions. Because Grab's markets include places with slow mobile data and inaccurate location readings, a design that assumes a fast network and perfect location data is incomplete, and the interviewer will ask what happens when both fail.

A Walkthrough: Design Driver Matching for One City

1. Requirements (5 minutes). Many drivers report location about once per second, and passenger requests arrive in bursts at peak hours. The target is a match within a few seconds, and a defensible choice of driver.

2. Location ingestion. Drivers send location updates to a write-heavy service, which keeps the latest position per driver in memory and publishes each update to an event stream for other services.

3. The index. Store drivers by map square, using a geohash grid or a similar scheme, so that a search reads only the requester's square plus its neighbors. Say clearly that a driver just across a square boundary must still be found.

4. Ranking. Compute routing distance or estimated arrival time for the candidate drivers, then rank them by the business rules: arrival time, driver preferences, fraud signals, and vehicle type.

5. Assignment. Offer the trip to the top driver with a short timeout, and move to the next driver if that one declines. One driver must never receive two offers at once, so take a lock per driver during the offer.

6. Failures and scale. Shard by region, because traffic is local to each city, and reduce service in steps when load is high: allow more time per match, shrink the search radius, then queue requests. Keep every assignment decision in the event stream so that it can be reviewed later.

What the Interviewer Grades

State the requirements and the scale first, then draw the parts, and name a trade-off for each choice by saying what you give up. Connect each decision to users, because a slow match makes the passenger cancel and a wrong match wastes a driver's time. Candidates report deep follow-up questions, so defend every part of the diagram with a reason, and bring rough numbers such as updates per second and the size of one location record.

Common Mistakes in This Round

• Searching by straight line distance only. Grab's own posts explain that road distance decides the better driver, so mention routing early.
• Ignoring the ranking rules. The search is the easy half of the question, because most of the grading happens in how you choose among the nearby drivers.
• Assuming a perfect network. Location updates will arrive late, missing, or wrong, and the design must say what happens then.
• One global cluster. Traffic is regional and rules differ per country, so shard by region and keep each market's data close to it.
• No measurement. Say which numbers you would watch: time to match, cancellation rate, and driver idle time.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the queues, caches, sharding, and indexes that every matching design uses.
• Go deeper on the hard cases. Advanced System Design Interview, Volume II covers replication, consistency, and failure handling for payment style problems.
• Rehearse the walkthrough. Practice the six steps above out loud, in under 40 minutes, with a timer running.
• Study the other rounds too. The design round is one part of the Grab interview process. The other parts include the motivation question and the reported waits in how long it takes to hear back.