Distilled Prep

Interview prep, distilled from
engineering blogs.

Engineering blogs of major tech companies, distilled into interview preparation. Every question links back to the post that inspired it, and teaches the reasoning — not the trivia.

Meta
8 questions
Google
7 questions
Airbnb
5 questions
Stripe
5 questions
Uber
5 questions
DoorDash
5 questions
Netflix
7 questions

Recently added

difficulty 4/5 Systems designSoftware engstream-processingdistributed-systemsreliabilitygeospatialJul 2026

A concert ends and demand in a few city blocks jumps 20x in minutes. Design the platform that keeps pricing, ETAs, and trip requests reliable through spikes like this.

Practice against the follow-up probes
  • Where exactly does 20x-in-one-neighborhood stress a system that handles the whole city fine?
  • What must stay strongly consistent during a surge, and what can be seconds stale?
  • Thundering herd: every app in the venue refreshes at once. What absorbs it?
  • How do you prevent duplicate trip creation when users rage-tap through timeouts?
  • What load do you shed first, and how do users experience degradation?
Show answer guide

What the interviewer is probing

Hot-partition reasoning: geographic sharding concentrates a local spike onto a handful of shards/keys, so the answer is absorbing structures — caching with request coalescing, aggregation before fan-in, backpressure, and tiered shedding — plus consistency judgment (prices shown can be stale-bounded; the price committed to a trip must be exact) and idempotency under retry storms.

Strong answer outline

  • Identify the hot spots: the venue's geo-cells become hot keys in every layer — location ingestion, demand aggregation, pricing reads, matching. City-scale capacity doesn't help; per-key throughput does.
  • Ingestion/aggregation: driver/rider events flow through a partitioned log keyed by cell; pre-aggregate demand/supply counts at the edge of the pipeline (windowed counts, not raw events, cross the network); pricing recomputes per cell on a short cadence — by design a rate-limited consumer, immune to input spikes.
  • Read path: surge multipliers and ETAs served from replicated caches with short TTLs and request coalescing (one recompute per cell per tick, thousands of readers share it); app refresh jitter and client-side backoff flatten the herd; static fallbacks (last-known multiplier with staleness cap) if the pricing service lags.
  • Consistency split: displayed price/ETA — bounded staleness (seconds) is fine; committed trip price — locked at request time: the trip creation transaction snapshots the quote (signed/versioned), so a surge tick between tap and commit never surprises the rider or the ledger.
  • Duplicate protection: trip creation is idempotent (client-generated request key, atomic check-and-create); rage-taps and retries collapse to one trip; offers to drivers similarly idempotent.
  • Shedding order and UX: drop analytics/telemetry first, widen ETA refresh intervals, coarsen pricing granularity (cell → zone), queue match requests with honest wait messaging — never drop committed trips or corrupt pricing; capacity signals (queue depth, cache hit-rate, per-cell RPS) drive automation and dashboards.

The underlying concept

Geographic load is power-law bursty, and sharding by geography converts a citywide non-event into a per-key crisis — so spike architecture is about absorption: aggregate early (turn N events into one count), coalesce reads (turn N queries into one compute), backpressure producers, and shed along an explicit value ladder. The consistency principle is asymmetric like every marketplace's: advertisements may be stale within bounds, commitments must be exact and idempotent — and the commit point is where the system snapshots truth. Graceful degradation is designed, not discovered: decide in peacetime what fails first.

Source

Distilled Prep canon — curated from Uber's public work on surge infrastructure and real-time marketplace reliability.

difficulty 4/5 ML system designML engSoftware enggeospatialml-platformlogistics-optimizationscalabilityJul 2026

Design the real-time dispatch and matching system that pairs riders with drivers in a dense city — from request to accepted match in under a few seconds.

Practice against the follow-up probes
  • What are you optimizing, exactly? Nearest driver is the naive answer — what's wrong with it?
  • Why batch requests into matching windows instead of matching greedily?
  • What does the geospatial layer need to do, and how do you index a world of moving points?
  • Locations are stale and GPS is noisy. Where does that bite, and what absorbs it?
  • How do you evaluate a new matching policy before risking a city on it?
Show answer guide

What the interviewer is probing

Whether the candidate sees dispatch as a global optimization under latency constraints: greedy nearest-match is locally fine and globally wasteful (assigning a driver to rider A can strand rider B), which is why systems batch into short windows and solve assignment problems. Plus the systems substrate — geospatial indexing of moving objects, staleness tolerance, and simulation-first evaluation for changes too risky to A/B naively.

Strong answer outline

  • Objective: multi-term — rider wait (ETA to pickup), completion probability (acceptance/cancel behavior), driver utilization and earnings fairness, and system efficiency; nearest-driver ignores future demand, driver heading, acceptance likelihood, and the opportunity cost of assignments.
  • Batched matching: accumulate requests/supply over a short window (seconds) per area, then solve a bipartite assignment (Hungarian- style or min-cost flow with predicted-ETA edge weights and behavior- adjusted scores); batching converts myopic greed into near-global optima at negligible added wait.
  • Candidate generation + scoring: geospatial index (hexagonal grid cells) maintains driver presence per cell with in-memory, sharded state; candidates from expanding cell rings; scores from real-time features (road-network ETA, driver state, acceptance model) served within tight budgets.
  • Noise and staleness: map-match GPS to the road network; treat locations as estimates with age — score with uncertainty, re-check on offer; retries/declines re-enter the next window; idempotent offer protocol so network flakiness never double-books a driver.
  • Reliability: shard matching by geography (city/region cells) for blast-radius containment; degraded mode falls back to simpler greedy matching locally rather than failing requests; surge events handled by backpressure on window size.
  • Evaluation ladder: offline simulation replaying historical supply/demand under the new policy (the workhorse — marketplace interference makes naive A/B misleading); then switchback experiments in live cities; guardrailed rollout with automatic rollback on wait/cancel regressions.

The underlying concept

Matching markets punish myopia: each assignment consumes shared supply, so sequential greedy decisions compound into global waste — batching into windows recreates a small assignment problem where optimization is tractable, trading milliseconds of wait for system-wide efficiency. The engineering mirror: moving-object geospatial state wants cell-sharded in-memory indexes, and every distributed step must tolerate stale inputs and retries by design. Evaluation completes the lesson — when treatment units share a marketplace, simulation and switchbacks replace unit-level A/B as the honest instruments.

Source

Distilled Prep canon — curated from Uber's public work on dispatch, matching, and marketplace systems.

difficulty 3/5 Product caseData sciencemarketplace-dynamicsexperimentationforecastingJul 2026

Uber Eats' estimated delivery times got more accurate and slightly faster on average — yet order conversion and repeat ordering declined. Diagnose the apparent contradiction.

Practice against the follow-up probes
  • What's the difference between an estimate being accurate and being attractive?
  • Build the metric tree from browse to reorder. Where could the decline enter?
  • How would you distinguish a selection effect from a true regression?
  • Which segments would you cut, and what would each tell you?
  • What experiment settles it?
Show answer guide

What the interviewer is probing

Whether the candidate spots that displayed ETAs are simultaneously a prediction and a promise that shapes demand: honest (longer-tail) estimates can be more accurate yet less attractive, suppressing conversion among time-sensitive customers — a selection effect that also changes who orders and thus measured satisfaction. Metric-tree discipline plus mechanism thinking, in Uber's marketplace flavor.

Strong answer outline

  • Core hypothesis: accuracy improved partly by raising displayed estimates that were previously optimistic — customers see honest 40-minute quotes instead of hopeful 30s; conversion drops among the time-sensitive; the remaining orders skew less time-sensitive, changing repeat-rate composition.
  • Metric tree: browse → restaurant view → cart → checkout (conversion); delivered experience (quoted vs. actual, lateness) → satisfaction proxies (ratings, support contacts) → reorder. Localize which edge declined and when relative to the ETA rollout.
  • Distinguish mechanisms: (a) display effect — check conversion as a function of displayed ETA, holding merchant/distance constant, pre/post; (b) actual-experience effect — did realized lateness or delivery times worsen for any segment despite average gains?; (c) measurement/selection — reorder rates computed on a different ordering population aren't comparable without adjustment.
  • Segment cuts: time-of-day (lunch = time-sensitive), market density, distance bands, new vs. tenured customers, merchant type; the display-effect story predicts the decline concentrates where displayed ETAs rose most.
  • The settling experiment: randomize the display policy (e.g., quantile shown) holding the underlying model constant — separates prediction quality from promise attractiveness; measure conversion, realized lateness against promise, satisfaction, and reorder by cohort.
  • Decision frame: the answer is rarely "revert to optimistic quotes" — it's choosing the displayed quantile that optimizes long-run value: conversions gained by attractive promises vs. trust lost by broken ones.

The underlying concept

A displayed prediction is an intervention: customers act on it, so its optimal presentation is a decision-theory problem distinct from its accuracy. Systems that "improved" a model can regress the business by changing the promise distribution — and the composition of who transacts shifts with it, corrupting naive before/after comparisons of downstream metrics (selection on unobserved time-sensitivity). The durable practice: separate model quality (calibration, error) from display policy (which quantile, how framed), and experiment on them independently.

Source

Distilled Prep canon — curated from Uber's public work on ETA prediction and marketplace conversion.

difficulty 4/5 Product caseData scienceexperimentationcausal-inferencemarketplace-dynamicsJul 2026

A city launches a new driver incentive that guarantees a minimum hourly earning during peak periods. Design the evaluation plan to decide whether the program should be expanded to other cities.

Practice against the follow-up probes
  • What are your objectives and guardrails across riders, drivers, and the platform — and which one is the decision metric?
  • Would you randomize at the rider level, driver level, use switchbacks, geo experiments, difference-in-differences, or synthetic control? Why?
  • Drivers can see the incentive and migrate across zones or shift their hours in anticipation. How does that contaminate your design?
  • How do you estimate incrementality — supply that exists because of the program — rather than just measuring that supply went up?
  • The program has a fixed budget. How does that change what "success" means?
Show answer guide

What the interviewer is probing

Whether the candidate recognizes this as an interference problem before choosing a method: driver-level randomization is the intuitive answer and it's wrong here, because treated and control drivers compete in one marketplace and the incentive changes behavior of both. Strong candidates frame the business decision first (expand or not, at what cost per incremental supply hour), pick a design that matches the interference structure, and are honest about what each design cannot identify.

Strong answer outline

  • Frame the decision: expansion is a cost-effectiveness question — dollars per incremental supply-hour during peak, and downstream effects on rider wait times, completed trips, and driver retention. Guardrails: driver earnings dispersion, off-peak supply cannibalization, rider price effects.
  • Rule out naive designs aloud: driver-level randomization suffers spillovers (control drivers face more competition, inflating apparent effects); pre/post comparison confounds seasonality and city trends.
  • Prefer designs matching the interference structure: geo-randomization at the city or zone-cluster level if enough units exist; switchbacks (time-based alternation) if the effect onset/decay is fast; synthetic control or diff-in-diffs against comparable cities when only one launch city exists — which is the realistic case here.
  • Name anticipation and learning effects: announce dates create pre-period contamination; drivers take time to respond, so define a burn-in and an effect window.
  • Incrementality: compare supply-hours against the counterfactual, then decompose — new drivers activated vs. existing drivers shifting hours from off-peak (cannibalization) vs. hours shifted from neighboring zones (displacement). Only the first is cleanly incremental.
  • End with a decision rule: expand if cost per incremental peak supply-hour beats the alternative levers (e.g. surge subsidy) at comparable guardrail impact, validated in 2-3 structurally different cities before general rollout.

The underlying concept

The Stable Unit Treatment Value Assumption (SUTVA) — that one unit's treatment doesn't affect another unit's outcome — fails almost everywhere in a marketplace, because participants compete for shared demand and supply. When SUTVA fails, the choice of randomization unit is the real design decision: you must randomize at the level that contains the interference (zones, cities, time blocks), even though this slashes your sample size and statistical power. That power-vs-validity trade-off, and the discipline of measuring incrementality against a counterfactual rather than a before/after, is the core of applied marketplace causal inference.

Source

Distilled Prep canon — curated from Uber's public work on marketplace experimentation and causally-informed optimization.

difficulty 4/5 Product caseData scienceML engforecastingmarketplace-dynamicsJul 2026

You're forecasting rider demand per city zone in 15-minute intervals to position drivers ahead of demand. A new city launches next month with no historical data. Your global model performs well in mature cities but the launch team needs zone-level forecasts from day one. How do you approach this, and how does your approach change over the city's first 90 days?

Show answer guide

What the interviewer is probing

Whether the candidate can reason about cold-start under real operational pressure: transfer from similar cities, use of covariates that exist before launch (population, POI density, events), honest uncertainty communication, and a plan for graduating from priors to learned patterns. Strong candidates also ask what decision the forecast feeds — positioning tolerance determines how much error is acceptable.

Strong answer outline

  • Clarify the decision consumer first: driver positioning tolerates different error than surge pricing; this sets the accuracy bar and the cost of over- vs under-forecasting (asymmetric loss).
  • Day 0: transfer learning — pool data from demographically/geographically similar cities; features available pre-launch (census, POI, weather, calendar) drive a global model's predictions for the new city.
  • Early weeks: hierarchical/Bayesian shrinkage — city-level estimates borrow strength from the global prior, weight shifting to local data as it accumulates; simple exponential blending is an acceptable pragmatic answer.
  • Instrumentation: define when the city "graduates" (e.g. local-only model beats blended on rolling backtest).
  • Traps to name: launch-period data is unrepresentative (promos, novelty); feedback loops (positioning drivers changes observed demand — you observe fulfilled demand, not true demand).

The underlying concept

Cold-start forecasting is fundamentally a bias-variance trade: with no local data, a global prior is high-bias but low-variance; local data is unbiased but high-variance early on. Hierarchical models formalize the blend, letting the data decide how quickly to trust local signal. The second deep idea is censored demand: a marketplace only observes demand it could serve, so naive training on fulfilled trips systematically underestimates demand exactly where supply was short — the places you most need to forecast well.

Source

Hand-written seed example in the style of Uber's marketplace forecasting posts.