← Back to Directory

Uber interview notes, page 51 of 61

Large Enterprises

Most of these Uber write-ups come from Software Engineers (407), then Data Scientists (78) and Machine Learning Engineers (65). The most reported rounds are the technical phone screen (387), the system design round (95), the product sense round (46) and the onsite coding round (23).

609 interview notes · updated Aug 2026

Uber·Software Engineer·Technical Phone Screen

Jun 2026
Uber SWE interview with a recursive equality problem. Nothing flashy, just a clean algorithmic question that required careful handling of type semantics and nested structures.
  • Given two JSON-like records that can contain scalars, lists, and nested objects, write a function to determine if they are deeply equal. Scalar equality must be type-strict (so 1 and "1" are not equal), list equality is order-sensitive, and object equality ignores key order.

“Recursion was the obvious move and I got there quickly, but I fumbled the scalar type-checking part at first.”

View Post

Uber·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Uber system design round for a software engineer role, one big question that expanded in every direction the longer we talked. The scope kept growing and I'm not sure I covered everything they wanted.
  • Design a real-time driver heatmap for Uber that shows drivers where rider demand is concentrated. Walk through event ingestion, geospatial aggregation, pipeline architecture, how updates get pushed to driver apps, data retention, and how it scales to millions of drivers globally.

“This one sprawled.”

View Post

Uber·Software Engineer·Technical Phone Screen

Jun 2026
Uber SWE coding round, one sliding window problem that looks easy until you actually sit down and think about the edge cases.
  • Given an integer array and an integer k, find the length of the shortest contiguous subarray that contains at least k distinct integers. Return -1 if none exists.

“My first instinct was sliding window and that was right, but I fumbled the shrinking logic.”

View Post

Uber·Software Engineer·Technical Phone Screen

Jun 2026
Phone screen for a backend SWE role at Uber. One coding problem the whole time, but the follow-up caught me more off guard than the main question did.
  • Given a matrix containing only letters and dash characters, replace each dash with the nearest orthogonally adjacent letter. Follow-up: if a dash is equidistant from multiple letters, use the alphabetically smallest one.

“I recognized the multi-source BFS angle pretty quickly, seeding from all letter cells at once and letting the wave fill in the dashes.”

View Post

Uber·Data Scientist·Technical Phone Screen

Jun 2026
Uber DS interview focused on a pretty specific airport ETA modeling scenario. One question but it had a lot of layers, metric design plus experiment design plus causal inference all bundled together. Felt like a case study more than a standard interview question.
  • You have a new model that predicts walk-time from a rider's order location to the airport pickup zone, meant to replace the current ETA model. What metrics would you use to evaluate its impact on both riders and drivers? How would you design an experiment to compare the two models? And since riders might change their walking speed based on what the app shows them, how do you separate that behavioral effect from whether the model itself is actually more accurate?

“The metrics part felt manageable.”

View Post

Uber·Software Engineer·Technical Phone Screen

Jun 2026
Uber SWE interview with a graph problem that looks straightforward but has a few subtle edges (pun intended). The offline DSU approach is the key insight and they did push on complexity and online query variants.
  • Given an undirected weighted graph and a list of queries of the form (p, q, k), determine for each query whether a path exists from p to q where every edge along the path has weight strictly greater than (or at least) k. Return a boolean per query.

“The tricky part is the wording.”

View Post

Uber·Software Engineer·Technical Phone Screen

Jun 2026
Uber SWE coding round with a discount pricing problem that's basically a monotonic stack question in disguise. Not a bad problem once you see it, but if you go in thinking brute force is fine you'll get stuck on the follow-up.
  • You're given a price list. For each item, find the first item to its right with a price less than or equal to it and subtract that from the original price. Output the total sum of all final prices, plus the indices of any items that had no discount applied.

“The two-part output is what trips you up if you're not paying attention.”

View Post

Uber·Software Engineer·Onsite - Coding / Algorithms

Jun 2026
Uber SWE interview that was basically one big scheduling problem dressed up in five different costumes. The core question was approachable but the follow-ups kept coming and by the end I was just trying to hold it together on concurrency.
  • Given N attendees with busy calendars and individual working-hour windows, find the earliest time slot of at least d minutes where everyone is free simultaneously. Return the start time or -1 if none exists.
  • How does your algorithm generalize from 2 to N attendees, and what changes in time and space complexity?
  • Attendees are in different time zones with different working hours per local day. How do you normalize times correctly, including handling daylight saving time transitions?
  • Schedules can have up to around a million total intervals across all attendees. How do you keep the solution efficient when inputs are this large and highly fragmented?
  • Redesign the function so it only considers slots after the current time, without accepting 'now' as a direct parameter. How do you handle testability and determinism?
  • Calendars can be updated concurrently while a meeting-finder call is running. How do you keep reads consistent and writes safe? Walk through your choice of locking strategy, data structures, and how you avoid starvation.

“I went with a merge-intervals approach: combine all busy intervals across attendees, sort them, then scan the gaps.”

View Post

Uber·Software Engineer·Onsite - System Design / Architecture

Jun 2026
Uber system design round for a software engineer role. The whole interview was basically one big open-ended problem about room booking and ranking, which sounds deceptively simple until you're actually in it trying to justify every design choice on the fly.
  • Design a ranking system that assigns meeting rooms to booking requests. Walk through what factors you'd prioritize (like room usage frequency, how well the room's historical meeting durations match the request, capacity fit, available equipment, and physical proximity), how you'd combine them into a scoring function, how you'd handle cold-start problems and ties, and how you'd run an experiment to validate and tune the weights.

“This question has a lot of surface area and I underestimated it early on.”

View Post

Uber·Data Scientist·Technical Phone Screen

Jun 2026
Uber data science interview with a meaty marketplace experiment design question. The whole session basically revolved around one scenario but it went pretty deep pretty fast.
  • A ride-hailing company just rolled out a new ETA prediction model for riders. How would you design an experiment to measure its impact on the marketplace?
  • What primary metrics would you track on both the demand side (riders) and supply side (drivers) to evaluate the new ETA model?
  • What intermediate or leading indicators would you monitor during the experiment before final results are available?
  • Would you go with a classic A/B test or a synthetic control approach for this experiment? Walk through your reasoning on randomization unit, duration, and how you'd interpret the results.

“This is where I spent most of my time and also where I stumbled.”

View Post