Uber Machine Learning Engineer Interview: Questions, Experience & Prep (2026)

Uber is one of the most sought-after destinations for Machine Learning Engineers in India, with engineering hubs in Bangalore and Hyderabad powering global ML systems across ride pricing, matching, fraud detection, and maps. As of July 2026, knok's job radar shows Uber has 8 open ML Engineer roles, out of 803 total ML Engineer openings tracked across India. Bangalore leads with 165 of those openings, reflecting the city's dominance as India's ML hiring hub.

The Uber ML interview process is known to be thorough. Candidates typically face multiple rounds covering ML fundamentals, coding (data structures and algorithms), ML system design at scale, and behavioral questions. Uber values engineers who think end-to-end: from framing the business problem all the way to shipping a model to production and monitoring it.

These questions come up repeatedly in Uber ML Engineer interviews, based on what candidates publicly report:

1. Design a surge pricing model. How would you use real-time demand and supply signals?
2. How would you build a system to detect fraudulent rides or payments at scale?
3. Walk me through how you would design an ETA (estimated time of arrival) prediction system.
4. How do you handle class imbalance in a fraud or anomaly detection model?
5. Explain gradient boosting. How does it differ from random forests?
6. Your production model's performance has degraded over the past month. How do you debug it?
7. How would you design a recommendation system for Uber Eats?
8. What is the difference between online and offline evaluation? How do you decide when a model is ready to ship?
9. Describe a time you improved model performance under tight latency constraints.
10. How would you approach driver-rider matching as an optimization problem?
11. A feature you expected to help the model actually hurt it. What do you do?
12. How do you ensure fairness in a model that affects driver earnings?

Q: Your production model's performance has degraded over the past month. How do you debug it?

*Situation:* At my previous role, a fraud detection model that had been stable for several months suddenly started flagging a much higher share of legitimate transactions.

*Task:* I needed to find the root cause quickly, since false positives were hurting user experience and the business wanted a resolution within a week.

*Action:* I started by checking for data drift, comparing the distribution of current input features against the training data. I found that a key categorical feature, payment method type, had shifted significantly because a new payment option was rolled out after the model was trained. I retrained on a refreshed dataset that included the new payment method, ran offline evaluations, and set up a monitoring alert for feature drift going forward.

*Result:* The false positive rate returned to expected levels after the retrained model was deployed. The drift monitoring alert caught a similar issue early the following quarter, preventing a repeat incident.

---

Q: Describe a time you improved model performance under tight latency constraints.

*Situation:* The team I was on had a real-time recommendation model that was accurate but too slow, causing request timeouts that degraded user experience.

*Task:* My goal was to reduce inference latency without meaningfully hurting recommendation quality, and without a full model rewrite.

*Action:* I profiled the pipeline and found the bottleneck was feature retrieval, not the model itself. I worked with the infrastructure team to move frequently accessed features into an in-memory store. I also quantized the model weights and pruned low-importance features identified through importance scoring. Each change was validated independently in a staging environment before being combined.

*Result:* Inference latency dropped to within the target threshold, and an A/B test confirmed that key engagement metrics held steady. The changes went to production with no rollbacks needed.

---

Q: How do you handle class imbalance in a fraud detection model?

*Situation:* On a previous project, our fraud dataset had a very small share of positive (fraud) examples relative to legitimate transactions, which is typical for fraud problems.

*Task:* I needed to build a model that caught meaningful fraud without generating so many false positives that the operations team could not review them.

*Action:* I evaluated several approaches: oversampling the minority class using SMOTE, undersampling the majority class, adjusting class weights in the loss function, and tuning the decision threshold post-training. I ran cross-validated experiments for each and tracked precision-recall curves rather than accuracy, since accuracy is misleading on imbalanced data. The best result came from combining class weights with threshold tuning calibrated to the ops team's review capacity.

*Result:* The model caught a larger share of fraud cases while keeping false positives at a manageable level. Precision-recall trade-offs were documented so future stakeholders could adjust the threshold based on operational needs.

For ML system design questions (surge pricing, ETA, recommendations): Follow a problem-to-production structure. Start by clarifying the business goal and success metric. Define the ML task (regression, classification, ranking). Describe the data you would need and how you would collect or join it. Walk through feature engineering, model choice, and your reasoning. Cover offline evaluation, then online evaluation via A/B testing. Finish with monitoring and how you would detect drift or degradation. Uber interviewers typically want to see that you think about scale and latency from the start, not as an afterthought.

For debugging and degradation questions: Use a systematic top-down approach. Check data first: has input distribution shifted? Are there missing or corrupted features? Then check the model: is the same artifact deployed? Then check the environment: did upstream pipelines change? Candidates report that interviewers at companies like Uber value structured thinking over jumping straight to conclusions.

For behavioral questions (STAR format): Keep the Situation and Task brief, one to two sentences each. Spend most of your time on Action, making clear what you personally did versus what the team did. In Result, be specific about what changed. If exact numbers are available, use them; if not, describe the direction and the business impact clearly.

For algorithms and fundamentals questions: State your approach out loud before coding. Call out time and space complexity. If you see a trade-off, name it. Uber ML roles sit at the intersection of software engineering and ML, so clean, correct code matters as much as ML knowledge.

Uber ML Engineers work on systems that affect millions of rides and deliveries every day. Interviewers are looking for a few things in particular.

End-to-end thinking. Can you go from a vague business problem ('reduce cancellations') to a concrete ML formulation, a data plan, and a production deployment strategy? Candidates who answer system design questions only at the modeling layer, without thinking about data pipelines, feature stores, monitoring, or latency, typically do not clear this round.

Comfort with scale. Uber's systems handle large volumes of real-time data. Interviewers expect you to raise latency budgets, batching, caching, and approximate methods (like approximate nearest-neighbor search) without being prompted.

Ownership and judgment. Behavioral questions at Uber are meant to reveal whether you identify problems and drive them to resolution, or wait for direction. Use the STAR format and make your personal contribution clear.

Technical depth without hand-waving. If you mention a technique like gradient boosting or attention mechanisms, be ready to explain how it works, not just what it does. Interviewers follow up on anything that sounds rehearsed but shallow.

Communication. ML at Uber involves working with product, operations, and data engineering teams. Interviewers notice whether you can explain a technical decision in plain terms.

Week 1: ML fundamentals and coding. Review core supervised and unsupervised learning concepts: how gradient boosting works, bias-variance trade-off, regularization, evaluation metrics (precision, recall, AUC-ROC, NDCG). Practice coding problems on arrays, trees, graphs, and dynamic programming. Focus on problems common in ML pipelines: sorting, hashing, sliding windows.

Week 2: ML system design. Practice designing end-to-end systems for problems similar to Uber's domain: ETA prediction, dynamic pricing, fraud detection, food recommendations. For each, follow the framework: business goal, ML task, data, features, model, evaluation, production, monitoring. Read publicly available engineering blogs from companies in ride-sharing and delivery ML to understand real-world constraints.

Week 3: Behavioral and domain-specific prep. Write out four to six work stories in STAR format. Make sure each story shows a clear technical challenge, your specific actions, and a measurable outcome. Practice explaining your past projects out loud, as if talking to a non-technical stakeholder. Review Uber-specific ML domains: maps and routing, marketplace matching, personalization.

Week 4: Mock interviews and review. Do at least two timed mock interviews with a peer or on a practice platform. Review any gaps that come up. Go through the questions list above and make sure you have a clear, structured answer for each. Check Glassdoor and levels.fyi for recent candidate experiences to see if the process has changed.

As you search, tools like knok check 150+ job sites nightly, apply to matching roles, and message HR contacts on your behalf, keeping your pipeline moving while you focus on interview prep.

Jumping to models before framing the problem. Many candidates start naming algorithms before establishing what they are trying to predict and how they will measure success. Interviewers at Uber, candidates report, often stop and ask 'what is the ML task here?' if you skip this step.

Ignoring production concerns. A design that works offline but cannot serve predictions within latency constraints will not impress an Uber interviewer. Always address how the model will be deployed, how features will be retrieved in real time, and what monitoring will look like.

Vague STAR answers. Saying 'we improved the model' without specifying what you personally did or what changed is a common miss. Be precise about your role and the outcome, using real numbers where you have them.

Over-indexing on deep learning. Uber uses a range of ML approaches. Defaulting to a neural network for every problem without justifying the choice can signal shallow judgment. Sometimes a gradient-boosted tree or a simple logistic model is the right call for a given latency or data constraint.

Not asking clarifying questions in system design. Jumping into a design without asking about traffic volume, latency requirements, or data availability wastes time and signals poor engineering judgment. Interviewers typically want to see you clarify scope before building.

Weak monitoring and retraining plans. Many candidates design a great model but forget to address what happens after launch: how you detect drift, how often you retrain, and who owns the pipeline. This is part of the design, not a bonus.