Did the Uber MLE loop for a senior role on the Forecasting team (ETA prediction, rider demand modeling). Eight years in ML, previously did recsys at a mid-size company. Sharing this because the MLE interview is different from the SWE interview and the prep is different.
The process: recruiter screen, two technical phone screens, then a full onsite.
Phone screen 1 (ML depth): 45 minutes on ML concepts. They asked me to design a model to predict whether a user will cancel a ride after requesting it. This is a classic Uber problem and feels too convenient to be a coincidence. They cared less about model choice (I said gradient boosted trees, they nodded, we moved on) and more about feature engineering, class imbalance (cancellations are rare), evaluation metrics, and what happens when the model goes wrong in production.
Phone screen 2 (coding): standard leetcode-style problem. Medium difficulty. They do expect MLE candidates to write clean, working code. If you're weak on coding, fix that before interviewing here.
Onsite ML design round: design a pricing surge system. Familiar Uber domain but they went deep. Real-time latency requirements, model retraining cadence, how you'd detect distribution shift, what happens during peak demand (Super Bowl, NYE) when your training data is thin. I spent about 20 minutes on the ML piece and they kept pulling me toward the systems side.
Onsite systems round: ML systems design. How do you serve a model at 10k QPS with sub-100ms latency? Feature store design. Online vs offline feature serving. Monitoring and alerting on model drift. This is a real systems round, not a soft "talk about your architecture" conversation.
Onsite coding: two problems. One was data manipulation/pandas-style, one was algo (graph). Both were solvable in ~20-25 minutes each.
Onsite behavioral: STAR format, focused on influence without authority and handling ambiguous requirements.
Bottom line: Uber MLE interviews are harder than average. The systems side is real. If you haven't thought about feature stores, model serving infrastructure, or A/B testing ML models in production, that's a gap to fill before you walk in.