Dataford
Interview QuestionsInterview GuidesExperiencesCoaching
New
Pricing
Get started
Dataford
Popular roles
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Browse
Browse All RolesEvery role hub, from analyst to MLBrowse All CompaniesCompany-specific interview loopsAll Interview GuidesThe full guide library
Top questions by role
Software EngineerData AnalystData ScientistData EngineerBusiness AnalystAI EngineerMachine Learning EngineerProduct Manager
Top questions by skill
SQLPythonStatisticsMachine LearningA/B TestingSystem DesignGenerative AIProduct SenseMetricsBehavioral
Browse all questions →Try a mock interview
Experiences
Practice
Mock InterviewsTimed interview simulations with feedbackCoaching1:1 coaching with people at your target companiesSuccess PathYour 6-week structured planModulesCurated lessons by topicWebinarsTalks from ex-Big Tech data leadsPlaygroundA free-form scratch editor
Learn
BlogInterview strategy and career adviceTech Job Market ReportHiring trends across data and AI rolesFor UniversitiesDataford for career centersAbout DatafordWho we are and how we build
Pricing
Build my plan

Test Live Dispatch Algorithm

HardA/B Testing & Experimentation00:00
Practice interviewer
In session
5 left
00:00

Your question is Test Live Dispatch Algorithm. Take a moment with it on the right.

Talk me through your thinking if you like. When you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes).

You need to log in / sign up to chat or submit.

Problem

Context

RideNow, a two-sided ride-hailing marketplace, wants to evaluate a new dispatch algorithm that matches riders to drivers using a richer ETA + driver-utilization objective. The team believes it can reduce rider pickup time and cancellations, but a bad rollout could hurt marketplace balance and driver earnings.

Hypothesis Seed

The new algorithm prioritizes lower predicted pickup ETA while smoothing driver idle time across zones. Product expects faster pickups and fewer rider cancellations, but there is concern that local marketplace interactions may create spillovers across drivers and neighborhoods.

Constraints

  • Eligible traffic: 240,000 completed or canceled dispatch requests per day across 12 cities
  • Maximum experiment window: 21 days, after which operations needs a ship / no-ship decision
  • Business requirement: do not increase rider cancellation rate by more than 0.3 percentage points or reduce driver hourly earnings by more than 1%
  • Cost asymmetry: a false positive is expensive because it can degrade marketplace liquidity and trust; a false negative is acceptable if it delays a beneficial launch by a few weeks
  • Engineering constraint: the dispatch service can support a city-by-time-cell experiment, but not rider-level randomization without contamination risk

Tasks

  1. Define the null and alternative hypotheses, the primary metric, at least three guardrails, and a realistic MDE.
  2. Choose the unit of randomization and experiment design, and justify it given marketplace interference and SUTVA concerns.
  3. Calculate the required sample size and expected duration using explicit assumptions, including alpha, power, baseline, and MDE.
  4. Pre-register the analysis plan: statistical test, peeking policy, multiple-comparison treatment, SRM checks, and how you will handle clustering.
  5. State a clear ship / don’t-ship / iterate rule that respects guardrails even if the primary metric improves.