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
- Accept or decline a ride within seconds
- Navigate to the rider
- Pick up, navigate to destination, drop off
- Track earnings (per ride, per shift, per week)
- Background mode while driving (screen off allowed)
Non-functional
- Battery: 8+ hour shifts without dying (driver typically charges via car)
- Cellular reliability: works in dead zones, recovers from drops
- Latency: dispatch acceptance has a 15–30 second window
Architecture
Two main loops:
- Location loop: always-on GPS while online
- Dispatch loop: receive dispatch, prompt driver, confirm accept/decline
Going online
Driver taps “Go” → app starts:
- Foreground service (Android) or location-always permission (iOS)
- GPS at high accuracy (every 1–4 seconds)
- Persistent connection to dispatch server
- Battery monitoring
Dispatch flow
- Server matches a rider request to a nearby driver
- Push notification + in-app notification + sound + vibration
- Driver has 10–30 seconds to accept
- Accept → app switches to navigation mode; rider info shown
- Decline → driver remains online for next dispatch
- No response → dispatch routes to next driver
Navigation
Two patterns:
- In-app: integrate Mapbox or use platform maps (CarPlay, Android Auto compatible)
- Deep link to external: open Google Maps or Apple Maps with the destination
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
- Surge multipliers
- Tips (added later by rider)
- Bonuses / quests
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
- Allow screen-off operation (audio cues only)
- Use platform-native location APIs (battery-optimized)
- Avoid running heavy ML on-device
- Recommend driver use car charger
Driver safety
- Don’t require typing while driving
- Voice prompts for dispatches and turn-by-turn
- Single-tap accept/decline
- Emergency button (911, in-app safety)
- Periodic break reminders
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.