Distilled Prep

Build a prep sheet

Filter to your target company and role, then print this page — it's print-styled as a clean one-pager.

difficulty 4/5 Data scienceML engforecastingmarketplace-dynamics

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.

difficulty 3/5 Software engdistributed-systemsapi-designreliability

A customer taps "Place order" and their app times out waiting for your response, so it retries. Meanwhile your first attempt actually succeeded — the order reached the kitchen. Walk me through how you design the order placement API so retries are safe, and then tell me what happens when the deduplication store itself is briefly unavailable.

Show answer guide

What the interviewer is probing

Whether the candidate reaches for idempotency keys as a design principle rather than a buzzword: where the key is generated, what gets stored, the atomicity requirement between "check" and "act", and TTL trade-offs. The second part tests degraded-mode reasoning — do they fail open (risk duplicates) or fail closed (risk lost orders), and can they connect that choice to the business cost of each failure?

Strong answer outline

  • Client generates the idempotency key (per logical order attempt, not per HTTP request) so all retries of one intent share a key.
  • Server: atomic check-and-set (e.g. unique constraint or conditional write), not read-then-write — the race between two concurrent retries is the classic bug.
  • Store the response with the key so retries return the original result, not just a "duplicate" error.
  • TTL discussion: too short re-enables duplicates, too long bloats storage; tie it to realistic client retry windows.
  • Degraded mode: articulate fail-open vs fail-closed and pick using domain cost — a duplicate food order costs a refund; a dropped one costs a customer. Reasonable answers differ; unreasoned answers don't.

The underlying concept

Exactly-once delivery doesn't exist between distributed parties; what systems actually implement is at-least-once delivery plus idempotent processing, which is indistinguishable from exactly-once from the caller's perspective. The idempotency key turns a side-effecting operation into something safely retryable by giving the server a durable memory of intents it has already honored. Every payment and ordering system you've used is built on this pattern.

Source

Hand-written seed example in the style of DoorDash's platform reliability posts.