Delivery Marketplace ML Applications Questions

Machine learning use cases common to on-demand delivery marketplaces, covering demand forecasting, driver/courier dispatch and routing, pricing and revenue optimization, recommendations, fraud detection, and real-time optimization. Includes model development, deployment, monitoring, drift handling, and scalability considerations for ML systems operating in a high-velocity, two-sided marketplace.

HardTechnical

32 practiced

Propose a reinforcement learning formulation to optimize DoorDash driver dispatch with fairness constraints such as equitable earnings and balanced workload. Define the state representation, action space, reward shaping (including fairness penalties), candidate algorithms (centralized RL, multi-agent RL, constrained policy optimization), simulation environment requirements, and how to ensure safe exploration and offline policy evaluation before deployment.

Sample Answer

Requirements & objectives:- Maximize platform-wide metrics (on-time pickups/deliveries, customer satisfaction, GMV) while enforcing fairness: equitable earnings (within-band across drivers), balanced workload, geographic coverage, and no long-term starvation.

State representation:- Driver-level: location (tile/coords), status (idle, enroute, on-trip), time-since-last-dispatch, cumulative earnings in rolling window, recent acceptance rate, vehicle type.- Order-level: pickup/dropoff coords, promised ETA, payout, order size, priority.- Global/context: time-of-day, traffic heatmap, demand forecast, supply distribution, performance KPIs.- Use normalized features and aggregations (e.g., histograms of earnings per region) so state dimensionality remains tractable.

Action space:- Centralized: assign specific driver→order pairings or batch-match a set of drivers to orders (discrete).- Decentralized (multi-agent): per-driver action: accept/decline recommended order, reposition target (continuous/grid).- Hybrid: central policy proposes candidate assignments; local agent accepts/adjusts.

Reward shaping (primary + fairness penalties):- Base reward: weighted sum of successful delivery revenue, on-time indicator, customer satisfaction (e.g., tip, rating), negative travel/time cost.- Fairness penalties (soft constraints): - Earnings variance penalty: -λ1 * Var(earnings_i over window) or hinge penalty if earnings_i below percentile. - Workload imbalance: -λ2 * KL divergence between desired and observed workload distribution. - Long-term starvation: large negative penalty for drivers exceeding threshold idle time or zero earnings.- Use reward discounting that blends short-term efficiency and long-term fairness (different timescales).

Candidate algorithms:- Centralized RL: PPO/DDPG/IMPALA on assignment MDP with action masking and pointer-net style architectures for combinatorial matching.- Multi-Agent RL (MARL): MAPPO, QMIX, or independent PPO with parameter sharing and centralized critic for stability.- Constrained optimization: Constrained Policy Optimization (CPO) or Lagrangian methods (dual ascent) to enforce fairness as constraints rather than penalties; safe RL algorithms (CVaR optimization).- Offline RL: Conservative Q-Learning (CQL) or Batch-Constrained Q to leverage logged data.

Simulation environment requirements:- High-fidelity simulator with realistic driver behaviors (acceptance, repositioning), stochastic travel times/traffic, order arrival processes conditioned on time/area, economic model (payouts, cancellation), and a virtual population of drivers with heterogenous preferences.- Fast parallel simulation, support for counterfactual queries, and hooks to log causal variables for evaluation.

Safe exploration & deployment:- Offline evaluation: policy value estimation via importance sampling, FQE (Fitted Q Evaluation), and doubly-robust estimators; test in logged replay and synthetic stress scenarios.- Constrained training: start with conservative surrogate policies via imitation learning from historical policy; apply CPO or Lagrangian constraints to bound fairness violations during training.- Safe exploration: deploy in shadow mode and staged rollouts (canary regions, time windows) with throttling; use action masking to prevent extreme assignments (e.g., >X extra trips).- Monitoring & rollback: real-time monitors on fairness metrics, ride-quality KPIs, and automated rollback if constraints breached.

Evaluation & metrics:- Track efficiency (on-time %, average wait, platform revenue) and fairness (Gini/variance of earnings, fraction of drivers below threshold, churn proxies) over short and long horizons; use A/B tests with careful allocation and sequential testing.

Trade-offs:- Soft vs hard constraints: penalties are easier but may produce oscillations; constrained RL is more stable but harder to optimize.- Centralized scales better for global optimality; MARL offers robustness and privacy but needs credit assignment work.

This design balances operational efficiency and enforceable fairness using constrained RL methods, rigorous offline validation, and staged safe deployment.

MediumTechnical

28 practiced

Write a PyTorch forward pass snippet that computes attention over a batch of user order sequences to produce a fixed-length user embedding. Inputs: orders_tensor with shape (batch_size, seq_len, feature_dim) and mask with shape (batch_size, seq_len) where mask==0 indicates padding. Show the attention scores, masked softmax, and final weighted sum. Use standard PyTorch APIs; keep to the forward computation (no class boilerplate required).

Sample Answer

Approach: compute scalar attention logits per order using a learnable query vector, apply mask-aware softmax to ignore padding, then compute weighted sum across the sequence to produce a fixed-length user embedding (batch_size, feature_dim).

python

import torch
import torch.nn.functional as F

# inputs (example shapes)
# orders_tensor: (batch_size, seq_len, feature_dim)
# mask: (batch_size, seq_len) with 1 for real tokens, 0 for padding
orders_tensor = torch.randn(32, 20, 128)
mask = torch.randint(0, 2, (32, 20)).float()

# learnable query vector (usually defined as nn.Parameter in a module)
query = torch.randn(128)  # shape: (feature_dim,)

# 1) compute raw attention scores via dot product between each order and query
# result shape: (batch_size, seq_len)
scores = torch.einsum("bse,e->bs", orders_tensor, query)

# 2) apply mask: set logits for padding positions to a large negative value before softmax
# convert mask to boolean where True = valid
mask_bool = mask.to(torch.bool)
neg_inf = -1e9
scores_masked = scores.masked_fill(~mask_bool, neg_inf)

# 3) masked softmax across seq_len to get attention weights
attn_weights = F.softmax(scores_masked, dim=1)  # shape: (batch_size, seq_len)
# optional numeric stability: ensure weights for padding are exactly zero
attn_weights = attn_weights * mask  # zeros out paddings (mask is 0/1 float)
attn_weights = attn_weights / (attn_weights.sum(dim=1, keepdim=True) + 1e-12)

# 4) weighted sum to get fixed-length user embedding
# expand weights to multiply with features, then sum over seq_len
user_embedding = torch.einsum("bs,bse->be", attn_weights, orders_tensor)  # (batch_size, feature_dim)

Key points:- Dot-product with a learnable query produces per-item relevance; query usually declared as nn.Parameter(feature_dim).- Masked softmax uses large negative logits to exclude padding; we also zero and renormalize weights for robustness.- Final embedding is a weighted sum over sequence dimension.

Time/space:- Time: O(batch * seq_len * feature_dim) dominated by dot-products and weighted sum.- Space: O(batch * seq_len * feature_dim) for input; attention arrays O(batch * seq_len).

Edge cases:- All-pad sequence: sum of weights could be zero — handled by adding small epsilon during renormalization or falling back to zeros/learned default embedding.- Very long seq_len: consider sparse/causal attention or chunking.- Use float mask type compatibility on different devices/dtypes.

Alternatives:- Use a learned projection + tanh + scalar projection (add nonlinearity).- Multi-head attention for richer interactions.- Use scaled dot-product with per-feature scaling (like transformer) for stability.

HardTechnical

28 practiced

During a major holiday, a predictive model for delivery times and demand drops its accuracy by 40% compared to baseline. As the ML lead, propose an investigation and remediation plan that covers immediate mitigation steps, root-cause analysis (data quality, covariate drift, distributional shifts in user behavior, labeling issues), retraining and validation strategy, rollback criteria, stakeholder communication, and a post-mortem prevention plan.

Sample Answer

Immediate mitigation (first 0–4 hours)- Fail-open to a conservative baseline: route predictions to the previously validated baseline model or fallback heuristic to avoid bad decisions.- Throttle automated actions that depend on model confidence; surface confidence to downstream teams.- Enable enhanced logging (inputs, preds, confidences, feature snapshots) and sampling for replay.

Triage & root-cause analysis (4–48 hours)- Data quality: check ingestion pipelines, missing fields, timestamp alignment, duplicate or delayed batches.- Covariate drift: run feature distribution comparisons (KS/Chi-square, Population Stability Index) vs. baseline window and recent pre-event window.- Labeling issues: verify ground-truth arrival times; check for systemic delays in labeling pipeline during holiday.- Behavior shifts: examine user / driver patterns (demand spike shapes, geography, time-of-day) and external signals (weather, promotions).- Model health metrics: calibration, confidence histogram, per-segment accuracy, and error decomposition by cohort.- Hypothesis prioritization: rank likely causes by impact and ease of test (e.g., data lag vs. distributional shift).

Remediation & retraining strategy (48–96 hours)- Short-term: apply feature transforms robust to shifts (clipping, winsorizing), recalibrate probabilities (Platt/isotonic) and reweight/augment recent holiday data for fine-tuning.- If labels are delayed/corrupt: use semi-supervised or weak-supervision with flagged low-confidence examples excluded.- Retraining: create a time-aware training split (rolling-window CV), include holiday-like samples via upsampling or synthetic augmentation, and track per-segment metrics.- Validation: use holdout from same holiday period if available, stress-test on simulated extreme scenarios, and run canary deployment on small traffic with A/B metrics (accuracy, business KPI impact).

Rollback criteria & deployment controls- Automatic rollback if model increases error >10% vs baseline on canary or key business metrics degrade beyond defined SLOs for sustained 15 minutes.- Progressive rollout with feature flags, circuit breakers, and monitoring alerts tied to both ML and business KPIs.

Stakeholder communication- Immediately notify ops, product, and customer-support with high-level impact, mitigation in place, and ETA for update.- Provide regular briefings (hourly during incident), a short post-incident report within 24–48 hours, and an action plan with owners and timelines.

Post-mortem & prevention- Blameless post-mortem documenting root cause, detection latency, remediation, and lessons.- Preventive measures: expand monitoring (PSI, feature drift, label lag), build holiday-specific training pipelines, create synthetic holiday scenarios in test suites, schedule pre-holiday stress-tests, and run playbooks for similar incidents.- Assign owners for monitoring, runbook maintenance, and quarterly review of model robustness thresholds.

HardTechnical

29 practiced

Fraud labels on DoorDash are often delayed because investigations take time. Propose methods to train and evaluate a fraud detection model when ground truth labels are delayed or missing. Discuss approaches such as delayed feedback modeling, survival analysis, positive-unlabeled learning (PU), use of proxy labels and weak supervision, and practical choices for thresholding and evaluation under label latency.

Sample Answer

Problem framing: label latency means ground-truth fraud flags arrive with delay (or never). Naively training on only confirmed labels biases models toward older examples and increases false negatives. A robust solution mixes modeling label delay, learning from positives+unlabeled data, and careful evaluation.

Key approaches- Delayed-feedback modeling: treat label arrival as a censoring process. Train a model that predicts two things: (a) probability an event is fraudulent, (b) distribution of label delay (or detection probability as function of age). Use importance weighting or inverse-probability-of-censoring to debias supervision: weight examples by 1 / P(label observed by t | features).- Survival analysis / time-to-event: model hazard function h(t|x) = instantaneous probability fraud is detected at time t. Use Cox/proportional hazards or deep survival nets to estimate cumulative incidence F(t|x). For decisioning you can compute P(fraud within decision window).- Positive-Unlabeled (PU) learning: treat confirmed frauds as positives and everything else as unlabeled. Use class-prior estimation (Elkan-Noto, nnPU) or non-negative risk estimators to train classifiers robust to missing negatives. Combine with features indicating time-since-event to capture censoring.- Proxy labels & weak supervision: define short-term proxies (chargebacks, dispute flags, manual-review signals, velocity anomalies) to create weak labels; use label-modeling (Snorkel) to combine sources, estimate accuracies, and produce probabilistic training labels. These proxies reduce latency at the cost of noise—model downstream with noise-aware losses.- Hybrid pipelines: first-stage fast model using proxies/PU for recall; second-stage slower/manual-review model using confirmed labels and survival outputs for precision.

Thresholding & evaluation under latency- Evaluate on time-fixed cohorts: only include examples with sufficient follow-up (e.g., events older than max label delay) to approximate ground truth. Report metrics as function of follow-up time.- Time-aware metrics: compute precision@k / recall at a fixed decision window (e.g., fraud within 30 days). Use CDF estimates from survival model to translate risk scores into probabilities over the window.- Use calibration and cost-aware thresholds: optimize thresholds on expected utility that accounts for delayed detection costs (chargeback cost, customer friction, manual review cost). Use simulated label arrival (backtesting) to validate.- Continuous monitoring: backfill labels as they arrive and run periodic re-training; track label shift and model decay.

Practical choices- Start with PU + proxy labels to get a deployable model quickly; use survival or censoring-aware weighting in subsequent iterations.- Maintain dual metrics: short-horizon proxy performance (fast feedback) and long-horizon validated metrics (ground truth when available).- Instrument pipelines to capture label arrival times, proxy accuracy, and calibration; incorporate human-in-the-loop review for high-impact cases.

Trade-offs- PU/weak labels speed iteration but risk higher false positives.- Survival models handle censoring well but require careful modeling assumptions and more data.- Importance weighting reduces bias but increases variance; balance via regularization and validation on backfilled cohorts.

This combined strategy yields faster iteration, less bias from label latency, and decision thresholds tuned to actual business costs.

EasyTechnical

33 practiced

In the context of DoorDash fraud detection, explain the precision vs recall trade-off for a real-time risk scoring model. Provide guidance on how to choose an operating point given business constraints such as customer friction, investigation capacity, and expected monetary loss from fraud. Describe how you would estimate costs for false positives and false negatives.

Unlock Full Question Bank

Get access to hundreds of Delivery Marketplace ML Applications interview questions and detailed answers.

Join thousands of developers preparing for their dream job.