Uber Machine Learning Engineer Interview Guide

From hundreds of mock interviews, one pattern keeps showing up: candidates prep for Uber's MLE loop like it's a data science interview with some coding on the side. It's not. The onsite packs 4 to 5 rounds that test software engineering just as hard as ML, and the people who underestimate the coding bar are the ones who don't make it through.

Uber Machine Learning Engineer Role

Your first year looks like this: you write the Flink job that computes real-time supply-demand features per geo-hex, deploy the model through Uber's Michelangelo platform, and monitor prediction drift on Monday morning dashboards. Success means you've shipped a model improvement that moved a business metric like ETA accuracy or rider cancellation rate, and you can navigate the internal infra stack without hand-holding.

A Typical Week

Most of your week isn't modeling. You're debugging Cassandra timeouts in the feature hydration step, migrating batch Spark jobs to streaming Flink, updating Airflow DAGs for staged rollouts. If you want to spend 80% of your time on model experimentation, this role will frustrate you.

Projects & Impact Areas

Marketplace optimization is the beating heart of Uber's ML work: surge pricing, ETA prediction, and driver-rider matching all run on models where a 1% accuracy improvement in ETAs cascades into lower cancellation rates and better driver utilization. Restaurant and courier ranking on the Eats side feeds a recommendation system that directly drives order volume. The GenAI push is newer but growing fast, with Uber's AI platform team deploying fine-tuned LLMs for customer support ticket classification, and LLM topics like RAG and embeddings are showing up in interviews with increasing frequency.

Skills & What's Expected

Uber treats MLEs as engineers who happen to know ML, not the other way around. The skill profile the widget shows tells the story: the expert-level dimensions cluster around engineering (distributed systems, pipeline architecture, infrastructure, model serving) while statistics and business acumen sit a tier below. If you're choosing where to spend your last week of prep, spend it on systems and production code, not on memorizing ML paper abstracts.

Levels & Career Growth

The L5a to L5b (Senior to Staff) jump is where careers stall. At L5a you can be a brilliant contributor who ships great models for your pod. L5b requires you to set technical direction for a domain like marketplace pricing, mentor engineers on adjacent teams, and lead initiatives that span multiple product areas, and Uber's ladder rewards a model that measurably improves dispatch efficiency over a conference publication.

Work Culture

For the San Francisco office, Uber's current policy requires Tuesday through Thursday in-person, with Monday and Friday flexible. Many MLEs come in a fourth day because cross-functional syncs with marketplace, maps, and safety teams happen face-to-face. The pace is intense and metrics-driven: teams run weekly experiment reviews, and there's an expectation you ship model iterations quickly rather than polish them in isolation. Uber has invested meaningfully in cultural norms around inclusion since the 2017 controversies, and from what candidates report, the environment has genuinely improved, but ownership here means you're on-call for your models and a Kafka lag spike on Thursday afternoon is yours to solve.

Uber Machine Learning Engineer Compensation

Uber's initial stock grants can follow a front-loaded vesting schedule (the widget notes an example of 35/30/20/15 over four years). If your offer uses that structure, your effective comp drops in Years 3 and 4 unless new equity fills the gap. When comparing against a company with equal annual vesting, model the four-year cumulative, not just the Year 1 headline.

The source data is clear that base salary and RSUs are the most negotiable components of an Uber MLE offer. Since base bands tend to leave less room, focus your negotiation energy on the initial RSU grant size, which is where the real variance lives. Anchor your ask to the overall package value rather than any single line item, and tie your case to specific skills Uber's ML teams need, like experience with real-time serving systems or marketplace optimization at scale.

Uber Machine Learning Engineer Interview Process

What catches most candidates off guard is the sheer density of this loop. Two coding rounds plus two ML/Modeling rounds in a single onsite means you can't afford to treat algorithms as an afterthought while cramming ML theory. From what candidates report, weak algorithmic performance is one of the most common rejection reasons, but lack of ML depth and poor system design thinking sink just as many people. Prep coding and ML as two completely separate tracks with equal time allocation.

The behavioral round deserves real preparation, not a night-before skim of STAR stories. Cultural mismatch (failing to demonstrate ownership, collaboration, and adaptability) is explicitly called out as a rejection signal at Uber. Candidates who cruise through six technical rounds and then give vague, unstructured answers about cross-functional disagreements or ambiguous project ownership put their entire packet at risk. Have three to four concrete stories ready that show you driving outcomes on a team, not just building models in isolation.

Uber Machine Learning Engineer Interview Questions

import bisect

def max_fare(rides):
    """
    Calculates the maximum fare a driver can earn from a list of non-overlapping rides.

    Args:
        rides: A list of tuples, where each tuple represents a ride as
               (start_time, end_time, fare).

    Returns:
        The maximum possible fare.
    """
    if not rides:
        return 0

    # Sort rides by their end time
    # This is crucial for the DP approach
    sorted_rides = sorted(rides, key=lambda x: x[1])

    n = len(sorted_rides)
    # dp[i] will store the maximum fare considering rides up to index i
    dp = [0] * n
    dp[0] = sorted_rides[0][2]  # Base case: max fare for the first ride is its own fare

    for i in range(1, n):
        current_start, current_end, current_fare = sorted_rides[i]

        # Option 1: Don't take the current ride.
        # The profit is the same as the max profit from the previous ride.
        profit_without_current = dp[i-1]

        # Option 2: Take the current ride.
        # The profit is the current ride's fare plus the max profit from
        # all non-overlapping previous rides.
        profit_with_current = current_fare

        # Find the latest non-overlapping ride using binary search.
        # We need a ride that ends before the current one starts.
        # `bisect_right` helps find the insertion point for current_start in the sorted end times.
        end_times = [ride[1] for ride in sorted_rides[:i]]
        # The index of the last ride that ends before or at current_start begins.
        j = bisect.bisect_right(end_times, current_start) - 1

        if j >= 0:
            profit_with_current += dp[j]

        # The max profit at step i is the max of the two options.
        dp[i] = max(profit_with_current, profit_without_current)

    return dp[n-1]

import heapq

def find_k_closest_locations(graph, start_node, k):
    """
    Finds the K closest locations to a start node in a weighted graph.

    Args:
        graph: An adjacency list representation of the city map.
               e.g., {'A': [('B', 5), ('C', 10)], 'B': [('A', 5)]}
        start_node: The starting location.
        k: The number of closest locations to find.

    Returns:
        A list of the K closest locations (nodes), excluding the start_node.
    """
    if start_node not in graph:
        return []

    # Min-heap stores tuples of (travel_time, location)
    # This allows us to always explore the closest unvisited location.
    pq = [(0, start_node)]
    
    # Keep track of the shortest distance found so far to each location
    distances = {node: float('inf') for node in graph}
    distances[start_node] = 0
    
    closest_locations = []
    visited = set()

    while pq and len(closest_locations) < k:
        current_dist, current_node = heapq.heappop(pq)

        if current_node in visited:
            continue
        
        visited.add(current_node)

        # Add to our result list, but don't add the start node itself
        if current_node != start_node:
            closest_locations.append(current_node)

        # Explore neighbors
        for neighbor, weight in graph.get(current_node, []):
            if neighbor not in visited:
                new_dist = current_dist + weight
                # If we found a shorter path to the neighbor, update it
                if new_dist < distances[neighbor]:
                    distances[neighbor] = new_dist
                    heapq.heappush(pq, (new_dist, neighbor))
    
    return closest_locations

Uber's loop leans heavily toward design and applied reasoning over pure theory, which means you're judged more on whether you can wire together a fraud detection pipeline or a driver support chatbot than on reciting textbook definitions of gradient descent. The experimentation slice is small but deceptively hard because Uber's two-sided marketplace creates interference effects (a new driver incentive in Chicago changes rider behavior too), so even a 10% weight area can sink you if you've never thought about switchback designs. The biggest prep mistake is treating the coding portion as an afterthought, since those problems are pure algorithms with zero ML flavor, and a weak performance there vetoes an otherwise strong showing on the design-heavy rounds.

Practice with real interview questions at datainterview.com/questions.

How to Prepare for Uber Machine Learning Engineer Interviews

Uber posted $52 billion in revenue for 2025 with 20.1% year-over-year growth, and the company's north-star bets tell you exactly where ML headcount is going. The Nuro robotaxi partnership aims to bring autonomous rides to the SF Bay Area in 2026, while the WeRide deal targets 1,200 robotaxis in the Middle East by 2027. For MLEs, that means the work splits between optimizing the existing marketplace (pricing, matching, ETAs across a two-sided network) and building the ML routing and integration layer that decides when a trip goes to a human driver versus an autonomous vehicle.

Most candidates fumble the "why Uber" question by talking about scale in the abstract. Interviewers want to hear that you understand Uber's two-sided marketplace creates feedback loops that make ML uniquely hard here: a pricing model changes rider demand, which shifts driver supply, which changes the training distribution for the next model iteration. Name a concrete system like surge pricing or driver-rider matching and explain why those marketplace dynamics make it a harder problem than a similar system at a single-sided platform.

Try a Real Interview Question

import numpy as np

class SemanticCache:
    """A cache for LLM prompts based on semantic similarity."""

    def __init__(self):
        """Initializes the SemanticCache."""
        pass

    def add_entry(self, prompt: str, embedding: np.ndarray, response: str):
        """
        Adds a new prompt, its embedding, and its response to the cache.

        Args:
            prompt (str): The prompt text.
            embedding (np.ndarray): A 1D numpy array representing the vector embedding of the prompt.
            response (str): The LLM's response to the prompt.
        """
        pass

    def get_response(self, query_embedding: np.ndarray, threshold: float) -> str | None:
        """
        Finds a response from the cache if a similar prompt exists.

        Args:
            query_embedding (np.ndarray): The embedding of the new prompt.
            threshold (float): The cosine similarity threshold to consider a match.

        Returns:
            Optional[str]: The cached response of the most similar prompt if its
                           similarity is above the threshold, otherwise None.
        """
        pass

import numpy as np

class SemanticCache:
    """A cache for LLM prompts based on semantic similarity."""

    def __init__(self):
        """Initializes the SemanticCache."""
        self.cache = []

    def _cosine_similarity(self, vec1: np.ndarray, vec2: np.ndarray) -> float:
        """Calculates the cosine similarity between two vectors."""
        dot_product = np.dot(vec1, vec2)
        norm_vec1 = np.linalg.norm(vec1)
        norm_vec2 = np.linalg.norm(vec2)

        if norm_vec1 == 0 or norm_vec2 == 0:
            return 0.0

        return dot_product / (norm_vec1 * norm_vec2)

    def add_entry(self, prompt: str, embedding: np.ndarray, response: str):
        """
        Adds a new prompt, its embedding, and its response to the cache.

        Args:
            prompt (str): The prompt text.
            embedding (np.ndarray): A 1D numpy array representing the vector embedding of the prompt.
            response (str): The LLM's response to the prompt.
        """
        # In a production system, you might use a more complex data structure
        # or check for duplicate prompts, but a simple list is fine for this problem.
        self.cache.append({
            "prompt": prompt,
            "embedding": embedding,
            "response": response
        })

    def get_response(self, query_embedding: np.ndarray, threshold: float) -> str | None:
        """
        Finds a response from the cache if a similar prompt exists.

        Args:
            query_embedding (np.ndarray): The embedding of the new prompt.
            threshold (float): The cosine similarity threshold to consider a match.

        Returns:
            Optional[str]: The cached response of the most similar prompt if its
                           similarity is above the threshold, otherwise None.
        """
        if not self.cache:
            return None

        best_similarity = -1.0
        best_response = None

        for entry in self.cache:
            cached_embedding = entry["embedding"]
            similarity = self._cosine_similarity(query_embedding, cached_embedding)

            if similarity > best_similarity:
                best_similarity = similarity
                best_response = entry["response"]

        if best_similarity >= threshold:
            return best_response
        
        return None

Graph problems map naturally to Uber's domain because the core product is a matching and routing network. Think about how rider-driver assignment resembles bipartite matching, or how delivery sequencing on Eats is a variant of shortest-path optimization. Practice problems like these at datainterview.com/coding, and when you solve them, ask yourself how the constraints would change if supply and demand were shifting in real time.

Test Your Readiness

Uber's marketplace creates interference effects that break naive A/B testing assumptions, so pay special attention to questions about switchback experiments and network-effect bias. Sharpen those areas at datainterview.com/questions.