Design Driver Onboarding

Medium40 min
1 / 30
understanding9 min read

Problem Statement: Trust-Gated Driver Supply

Problem Statement: Trust-Gated Driver Supply — driver onboarding interview depth

Problem Statement: Trust-Gated Driver Supply

Phase understanding — Onboarding design note #1. This section anchors trust-gated supply pipeline for Uber, Lyft, and DoorDash-class marketplaces. Uber/Lyft/DoorDash must vet millions of independent contractors before they touch passengers or food. Onboarding is a compliance workflow—not a signup form.

SignalWhat to measure
Case pipelinetime_to_first_trip_hours
Qualityfalse_positive_rejection_rate vs unsafe_approval_rate
Ops loadmanual_review_queue_depth and reviewer_throughput
Complianceaudit_retention and jurisdiction-specific rule packs

Interviewers probe whether you treat onboarding as a workflow + evidence problem, not CRUD on a user row. Unique key for this section: sec-001-trust-gated supply pipeline-1.

Mechanism

  1. Applicant submits immutable application version.
  2. Workflow fans out vendor checks with correlation IDs.
  3. Evidence vault stores artifacts; OCR feeds structured fields.
  4. Merge gates require all blocking checks PASS.
  5. Ops can override with reason code; activation event is idempotent.

Edge cases

  • Applicant uploads blurry license → manual queue with resubmit link.
  • Vendor webhook arrives before mobile ACK → reconcile by vendor_ref.
  • Duplicate device fingerprint → force manual even if MVR clear.
  • Market rule change mid-flight → version policies; never retroactively fail without notice.

Failure drills

  • Vendor outage: pause auto-approve; extend SLA timers.
  • Double activation event: dedupe on case_id in driver profile service.
  • PII leak attempt: vault denies; break-glass logged.

Checkpoints

  • (sec-001) State machine owned by workflow worker only.
  • (sec-001) Idempotency-Key on create application API.
  • (sec-001) Outbox for driver.activated downstream.
  • (sec-001) CAP: CP for case state; async analytics OK AP.

Code anchors

javaOne Dark Pro
1public record OnboardingCaseId(UUID value, String marketCode) {}
pythonOne Dark Pro
1def is_terminal(state: str) -> bool:
2 return state in {"APPROVED", "REJECTED", "WITHDRAWN"}
typescriptOne Dark Pro
1export type OnboardingState = 'DRAFT' | 'SUBMITTED' | 'IN_REVIEW' | 'APPROVED' | 'REJECTED';

Why interviewers care

Driver Onboarding interviews reward crisp scope, explicit trade-offs, and failure stories—not generic microservice diagrams.

Interview checkpoint

Name one failure story for Problem Statement: Trust-Gated Driver Supply that proves you understand real outages, not happy-path diagrams.

Key Highlights

  • Anchor trust-gated supply pipeline
  • Case workflow owns state transitions
  • Evidence vault with vendor correlation
  • Activation event is idempotent downstream
pro tip
Lead with case state machine and evidence IDs when discussing sec-001.
interviewer loves
Quantify applicant funnel and review SLA before naming cloud SKUs.
common mistake
Mixing trip dispatch or earnings into onboarding scope.
trade off
Buy vendor checks vs build orchestration — orchestration is the moat.

Section Rescue Kit

Buzzwords to use:

Onboarding caseEvidence object

Safe statements:

  • "For Problem Statement: Trust-Gated Driver Supply, I'll separate case workflow from driver activation event."
  • "Let me define check DAG and manual queue SLAs before storage math."
Design Driver Onboarding - System Design | WinJob | WinJob