The Uber driver app is a different beast from the rider app. It runs all day, must survive on cellular, accepts dispatches, navigates, processes payments, and tracks earnings — all while keeping the driver focused on the road. The interview tests whether you understand the unique constraints of an “always-on” mobile app for gig workers.
Functional requirements
- Go online to receive ride dispatches — the app registers the driver’s location and availability with the server and holds a clear online/offline/on-trip state. Interviewers probe how you keep that state consistent if the app restarts or the network drops mid-transition.
- Accept or decline a ride within seconds — the tap must round-trip to the server before the offer expires. Expect questions about idempotent accept requests and what happens when two drivers accept the same request (the server confirms one, tells the other it’s gone).
- Navigate to the rider — the app hands off the pickup coordinates to turn-by-turn guidance and keeps the driver’s live position flowing so the rider sees the car approach.
- Pick up, navigate to destination, drop off — this is a trip state machine (en route → arrived → in progress → complete). A common follow-up is where that state lives: the server is the source of truth, the app is a cache that resyncs on reconnect.
- Track earnings (per ride, per shift, per week) — running totals update as trips complete, and the app rolls them up across time windows the driver cares about.
- Background mode while driving (screen off allowed) — location and dispatch listening continue even when the phone is locked or the driver is in a maps app, so no offers are missed.
Non-functional
- Battery: 8+ hour shifts without dying (driver typically charges via car). The dominant drain is continuous high-accuracy GPS, so most of your design effort goes into throttling location work when the car isn’t moving.
- Cellular reliability: works in dead zones, recovers from drops. Assume the connection will vanish for minutes at a time — buffer location and events locally and reconcile with the server once signal returns.
- Latency: dispatch acceptance has a 15–30 second window. The offer, the driver’s decision, and the confirmation all have to fit inside it, which means the accept request needs a fast, low-overhead path.
Architecture
Two main loops:
- Location loop: always-on GPS while online — samples position on a timer and streams it to the server so matching and the rider’s ETA stay current. This loop dominates battery, so its sampling rate is the main knob you tune.
- Dispatch loop: receive dispatch, prompt driver, confirm accept/decline — listens on a persistent channel, surfaces the offer loudly, and reports the outcome back before the timer runs out.
Going online
Driver taps “Go” → app starts:
- Foreground service (Android) or location-always permission (iOS) — this is what lets the app keep running with the screen off. Interviewers like to check that you know the OS will kill a plain background app, so a foreground service with an ongoing notification is required on Android.
- GPS at high accuracy (every 1–4 seconds) — fine-grained fixes keep the map smooth and matching accurate while the driver is moving; the trade-off is battery, which you claw back when stationary.
- Persistent connection to dispatch server — a long-lived channel (WebSocket or similar) pushes offers instantly instead of relying on polling. This is the same real-time presence problem chat systems solve: heartbeats to detect drops, and fast reconnect with the last known state.
- Battery monitoring — the app watches its own power draw and can warn the driver or shed accuracy when the phone isn’t charging.
Dispatch flow
- Server matches a rider request to a nearby driver — matching runs server-side using live driver positions, so the client just needs to keep its location fresh and stay reachable.
- Push notification + in-app notification + sound + vibration — redundant channels make sure the driver notices even if the app was backgrounded or the phone was in a pocket.
- Driver has 10–30 seconds to accept — a visible countdown creates urgency; the client shows the timer but the server owns the real deadline so a laggy phone can’t game it.
- Accept → app switches to navigation mode; rider info shown — the app transitions the trip state machine and displays pickup location, rider name, and rating.
- Decline → driver remains online for next dispatch — a decline is a normal outcome, not an error; the driver stays in the pool immediately.
- No response → dispatch routes to next driver — the server times out the offer and reassigns, which is why the accept path has to be low-latency and idempotent.
Navigation
Two patterns:
- In-app: integrate Mapbox or use platform maps (CarPlay, Android Auto compatible) — routing lives inside the app so it can sync guidance with ride state (auto-advance from pickup to drop-off) and feed the driver’s position back for the rider’s ETA.
- Deep link to external: open Google Maps or Apple Maps with the destination — cheaper to build and uses maps the driver already trusts, but it hands the screen to another app, so you lose in-context prompts and have to bring the driver back to accept the next leg.
Most apps offer both. In-app navigation provides better integration (turn-by-turn synced with ride state).
Earnings tracking
Each completed ride credits the driver:
- Base fare + distance + time — the core fare computed server-side from trip telemetry; the app displays it but never calculates money on its own.
- Surge multipliers — a factor applied when demand outstrips supply in the area, locked in at request time so the driver sees a stable number.
- Tips (added later by rider) — these arrive asynchronously after drop-off, so the earnings total has to be able to update a ride that already looked final.
- Bonuses / quests — incentive payouts (complete N trips, drive in a zone) that credit on top of fares once conditions are met.
Earnings shown in real time in the app. Cashout (bank transfer) typically weekly or daily via instant cashout (small fee).
Reliability concerns
- App crash mid-ride: server keeps the ride state; on relaunch, app resumes
- Phone dies mid-ride: driver pulls over, plugs in, resumes
- Cellular drop: GPS continues local, queue dispatch responses, sync on reconnect
Battery optimization
The driver app is the worst-case for battery. Mitigations:
- Reduce GPS accuracy when stationary — a parked or idling car doesn’t need 1-second fixes, so drop to coarse, infrequent sampling and ramp back up on movement (detected via the accelerometer or speed).
- Allow screen-off operation (audio cues only) — the display is a major drain, so the driver can lock the phone and still get spoken offer alerts and directions.
- Use platform-native location APIs (battery-optimized) — iOS and Android’s built-in location services batch and fuse sensor data far more efficiently than a hand-rolled GPS polling loop.
- Avoid running heavy ML on-device — push route optimization and matching to the server; on-device inference burns battery you can’t spare on an all-day shift.
- Recommend driver use car charger — the realistic answer for an 8-hour shift is that the phone is plugged in, which frees you to prioritize responsiveness over raw power savings.
Driver safety
- Don’t require typing while driving — any text entry is a hazard; design every in-trip action as a tap or a voice command instead.
- Voice prompts for dispatches and turn-by-turn — spoken offers and directions keep the driver’s eyes on the road, which is the whole point of the interface.
- Single-tap accept/decline — the offer control uses large targets and one gesture so it can be answered at a glance without hunting.
- Emergency button (911, in-app safety) — a reachable panic action that can dial emergency services and share the driver’s live location and trip details.
- Periodic break reminders — the app tracks continuous driving time and nudges the driver to rest, which also helps meet fatigue regulations in some regions.
Frequently Asked Questions
Why is the dispatch acceptance window so short?
If the driver waits, the rider waits. Long acceptance times degrade the entire system. Short windows force engagement.
How does the app handle being killed by iOS?
iOS does not aggressively kill apps with Always-on location during active use. If killed, location updates wake the app via background launch.
How do tips work async?
Rider can tip after the ride. App pushes a notification when tip arrives; earnings update with the new amount.
Keep sharpening your system design:
