Distilled Prep

Uber

This is a starter brief — expand it as you read their archive.

Uber's engineering culture is shaped by one core problem: running a real-time, two-sided marketplace at global scale. Almost everything they publish traces back to it — forecasting demand, matching supply, moving money, and doing all of it with low latency across hundreds of cities.

For data scientists, expect their interviews to lean on marketplace dynamics (surge, matching, incentives), forecasting, experimentation under network interference, and geospatial thinking. For software engineers, their archive is a masterclass in evolving infrastructure under growth: storage migrations, in-house platforms, and reliability at scale.

Names worth recognizing before an interview: Michelangelo (their ML platform — the blog series that arguably popularized the feature store concept), H3 (open-source hexagonal geospatial index), and Cadence (workflow orchestration, ancestor of Temporal).

Their vocabulary

Michelangelo

Uber's internal ML-as-a-service platform, covering feature management, training, deployment, and monitoring. Its feature store component heavily influenced the open-source ecosystem (Feast and others). If an interviewer asks how you'd "productionize a model at Uber," they are implicitly asking how you'd work within a Michelangelo-shaped platform.

Questions

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.