A driver's delivery app is a safety-critical mobile UI: large touch targets, glanceable info, resilient to flaky network, kind to battery. The interview wants both the architecture and the driver-specific design choices.

1. Top-level layout

A driver doesn't browse; they're on a route. The home screen is:

• Top: map with the route polyline, the driver's current position, the next stop pin.
• Middle: next-stop card — address, customer name, ETA, "Navigate" button.
• Bottom: action button — context-dependent: "Mark Picked Up", "Mark Delivered", "Call Customer".
• Side drawer / tabs: order queue, support, settings.

Everything optimized for glanceable use while stopped (not while driving).

2. Real-time tracking

• GPS via the platform's location API (background-enabled).
• Sampling rate — adaptive: 1Hz while moving, 0.1Hz when stationary; reduces battery drain.
• Send to backend via WebSocket (or HTTPS POST batched if WS unavailable). Backend broadcasts to customers tracking their order.
• Map rendering via Mapbox / Google Maps SDK; render polyline + route + current location marker.

3. ETA

• Compute server-side from current location + route + traffic data (Google Directions / Mapbox Directions API).
• Client refreshes ETA every 30s while en route.
• Show ETA prominently on the next-stop card.

4. Multi-order queue

A driver may have 1–N stops. Model:

Route { id, stops: [{ id, address, lat, lng, customer, status }] }

• Stops have status: pending | en-route | arrived | picked-up | delivered.
• Show the next stop prominently; allow swiping to peek at later stops.
• Re-sequencing requires a confirm (changes route ETA).

5. Status transitions

Buttons reveal state machine:

• Arrived at pickup → "Picked up" button enables.
• Picked up → next stop shown.
• Arrived at delivery → "Delivered" + photo / signature capture.

Each transition:

• Optimistic UI — update the local state immediately.
• Send to backend with idempotency key.
• On failure — queue locally; retry when online; never lose a status transition.

6. Offline resilience

Cellular drops in basements, parking garages, rural areas. The app must function offline:

• Cache route data in IndexedDB.
• Queue mutations (status transitions, location pings) and replay when online.
• Show offline banner + retry indicator.
• Map tiles pre-cached for the route area.

7. Navigation handoff

Don't build a turn-by-turn navigator. Hand off to Google Maps / Apple Maps / Waze via deep links:

google.navigation:q=lat,lng
maps://?daddr=lat,lng

The driver gets best-in-class navigation; your app stays focused on the order.

8. Push notifications

• New order assigned.
• Route changed by dispatcher.
• Customer message.

Background-friendly; cleared once acknowledged.

9. Battery & background

• Adaptive GPS sampling.
• Coalesce network writes (batch location pings every 5–10s, not per sample).
• Use platform background location correctly — request the right permission level; show why.
• Pause non-essential UI updates when screen is off.

10. Safety & UX

• Large touch targets (44pt minimum) — drivers tap with gloves, in cars.
• High contrast — sunlight readability.
• Voice readout for new orders (handsfree).
• Limit while-driving interactions — disable certain buttons above 10 mph, or show a "pull over to complete" prompt.
• Don't show modals while driving — queue for next stop.

11. Telemetry & support

• Crash reporting (Sentry).
• Per-driver location/status history (for dispatcher dashboards).
• In-app support chat / "Call dispatcher" button.
• Customer-facing tracker is a separate web view (driver doesn't see it).

12. Auth & shift state

• Driver logs in at shift start; onShift flag controls notification routing.
• Force re-auth daily or on suspicious activity.
• Clear sensitive data on logout.

Interview framing

"Driver app is mobile, glanceable, offline-resilient, battery-aware. The screen is map + next-stop card + a primary action button — everything else is secondary. Real-time tracking is adaptive GPS sampling sent over a WebSocket (or batched HTTPS), with offline queueing if signal drops. Status transitions (picked, delivered) are optimistic with idempotency keys and a local queue that replays on reconnect — we never lose a transition. Don't build navigation; deep-link to Maps/Waze. Adaptive sampling and batched writes keep battery alive. Large touch targets, high contrast, no modals while driving. Push for new orders. Cache the route + map tiles in IndexedDB for the offline case."