Score yourself

Give yourself 0, 1 or 2 points per row.

Area	0 points	1 point	2 points
Requirements	Started drawing	Request and match	Location rate, double assignment, price locking and live tracking agreed
Estimates	None	Numbers, not used later	Location writes vs ride volume drove in-memory index and city sharding
API and data	Skipped	Request endpoint only	Driver socket, quote with lock, idempotent trip events, index vs log vs trips
High-level design	DB query for nearest	Index, no matching flow	Quote, match by ETA, offer, atomic assign and trip states walked
Deep dive	Hand-waved	One topic	Index, ETA matching with atomic assignment, smoothed capped surge or state machine done properly
Trade-offs	None named	Named when asked	Raised unprompted (update rate vs battery, greedy vs batch matching, surge smoothing)
Communication	Long silences	Mostly clear	Thought out loud, checked in, managed time

12 to 14: strong hire signal. 8 to 11: solid, polish the weak rows. Under 8: redo the round in a week, timer on.

The bar: fresher vs SDE-2

	Fresher	SDE-2
Locations	Store in a table	In-memory cell index per city, stale expiry, history to a stream
Matching	Nearest by distance	ETA ranking, sequential offers with timeouts, atomic assignment, batch matching
Surge	Price × demand	Per-cell ratio, smoothing, caps, locked into quotes
Trips	Status column	State machine with idempotent events and timeouts
Scale	One cluster	Sharded by city, stateless matchers, cached ETAs

Common mistakes

Writing every location update to the main database.
Matching by straight-line distance only.
Offering one trip to many drivers at once without atomic assignment, so two accept the same rider, or one driver gets two.
Recalculating price during the trip instead of locking the quote.
Trusting the phone's view of trip state without idempotent events.

Quick check

Five questions on this chapter. Pick an answer, then check it.

quiz

1[
2 {
3  "q": "Drivers send locations every few seconds. How should they be stored?",
4  "options": [
5   "Every point in the trips database",
6   "Latest position in memory (indexed by cell), history to a stream",
7   "Only on the phone",
8   "In object storage per update"
9  ],
10  "answer": 1,
11  "explain": "Latest position in memory, history in a stream, trips in a database."
12 },
13 {
14  "q": "How do you guarantee one driver isn't assigned two trips?",
15  "options": [
16   "Hope",
17   "An atomic conditional update: assign only if the driver has no current trip",
18   "Assign by timestamp",
19   "Let drivers choose"
20  ],
21  "answer": 1,
22  "explain": "Nearest by road, one offer at a time, one driver per trip."
23 },
24 {
25  "q": "What should \"nearest driver\" be measured by?",
26  "options": [
27   "Straight-line distance only",
28   "Estimated time of arrival by road",
29   "Driver rating",
30   "Random"
31  ],
32  "answer": 1,
33  "explain": "Nearest by road: a driver across a river may be close in a line but far by road."
34 },
35 {
36  "q": "How should surge pricing behave?",
37  "options": [
38   "Jump freely every second",
39   "Price the shortage, smooth changes, cap the maximum, and lock the quoted fare",
40   "Never change",
41   "Only go down"
42  ],
43  "answer": 1,
44  "explain": "Price the shortage, smooth the jumps, cap the top, lock the quote."
45 },
46 {
47  "q": "Why model a trip as a state machine?",
48  "options": [
49   "It's trendy",
50   "So each event applies once and only legal moves happen (e.g. no \"completed\" before \"started\")",
51   "For speed",
52   "For maps"
53  ],
54  "answer": 1,
55  "explain": "Every event once, every move legal, every fare from the quote."
56 }
57]

44. Design Ride-Hailing with Surge Pricing (Uber / Rapido)

Score yourself

Score yourself

The bar: fresher vs SDE-2

Common mistakes

Quick check

Platform

Company

Legal