Uber Interview Guide

Uber’s coding rounds lean practical and systems-flavoured: problems that look like something the company would actually compute — matching riders to drivers, rate limiting, geospatial lookups, routing over a road network. Graph algorithms and design-shaped questions recur more than pure combinatorial puzzles.

The useful preparation shift is to expect problems phrased as a scenario rather than an abstract statement, and to be comfortable turning that scenario into a model before you start solving.

Crowd-reported, not published

No company publishes its question bank. The round structure and the bar below are corroborated by recruiters and candidates; the problem list is crowd-reported, stale, and biased toward whoever posted it. Treat the pattern families as the durable signal — which families a company leans on changes far more slowly than which individual problems it uses.

Strong bias toward problems with a geographic or scheduling flavour — graphs on maps, intervals over time, matching supply to demand.

The loop

Online assessment 1× · 60-90 min 2 auto-graded problems

Technical screen 1× · 45 min One medium

Onsite 3-4× · 45-60 min Coding, plus system design at senior levels

The bar

Model the problem before coding it. Uber's questions often hide a standard algorithm behind a domain story, and naming the algorithm out loud is half the answer.

What they lean on

This is the durable part. Which pattern families a company favours is far more stable than which individual problems it uses, so prepare in this order:

1. shortest-paths-dijkstra-bellman-ford-and-floyd-warshall
2. merge-intervals
3. sweep-line-and-event-counting
4. grid-traversal-islands-and-flood-fill
5. top-k-elements
6. greedy-interval-scheduling

Quirks worth knowing

• Interval and sweep-line problems appear far above their base rate. Drill Phase 07 specifically.
• Expect "now it must run in real time on a million drivers" as a follow-up.

Reported problems

Read this before you trust the list. No company publishes its question bank. Every "asked at Uber" list in circulation — including this one — is aggregated from candidate reports, is months to years out of date, and over-represents whoever bothered to post. Use it to choose an order to practise in. Do not use it as a question bank, and do not assume a problem missing from it is safe to skip. The list below is currently derived from Uber's pattern families rather than from per-problem tags, which is the more honest basis while the tag data is thin.

38 problems

4 easy26 medium8 hard

AllEasyMediumHard

Unsolved onlyExportImportReset

• ○228Summary RangeseasyLeetCode Top Interview 150
• ○252Meeting RoomspremiumeasyNeetCode 150Blind 75
• ○463Island Perimetereasy
• ○733Flood Filleasy
• ○56Merge IntervalsmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○200Number of IslandsmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○347Top K Frequent ElementsmediumNeetCode 150Blind 75
• ○621Task SchedulermediumNeetCode 150
• ○743Network Delay TimemediumNeetCode 150
• ○787Cheapest Flights Within K StopsmediumNeetCode 150
• ○57Insert IntervalmediumNeetCode 150Blind 75LeetCode Top Interview 150
• ○130Surrounded RegionsmediumNeetCode 150LeetCode Top Interview 150
• ○215Kth Largest Element in an ArraymediumNeetCode 150LeetCode Top Interview 150
• ○253Meeting Rooms IIpremiummediumNeetCode 150Blind 75
• ○417Pacific Atlantic Water FlowmediumNeetCode 150Blind 75
• ○435Non-overlapping IntervalsmediumNeetCode 150Blind 75
• ○451Sort Characters By Frequencymedium
• ○452Minimum Number of Arrows to Burst BalloonsmediumLeetCode Top Interview 150
• ○646Maximum Length of Pair Chainmedium
• ○695Max Area of IslandmediumNeetCode 150
• ○731My Calendar IImedium
• ○763Partition LabelsmediumNeetCode 150
• ○846Hand of StraightsmediumNeetCode 150
• ○973K Closest Points to OriginmediumNeetCode 150
• ○1020Number of Enclavesmedium
• ○1024Video Stitchingmedium
• ○1094Car Poolingmedium
• ○1334Find the City With the Smallest Number of Neighbors at a Threshold Distancemedium
• ○1631Path With Minimum Effortmedium
• ○2406Divide Intervals Into Minimum Number of Groupsmedium
• ○218The Skyline Problemhard
• ○329Longest Increasing Path in a MatrixhardNeetCode 150
• ○732My Calendar IIIhard
• ○759Employee Free Timepremiumhard
• ○778Swim in Rising WaterhardNeetCode 150
• ○1368Minimum Cost to Make at Least One Valid Path in a Gridhard
• ○1851Minimum Interval to Include Each QueryhardNeetCode 150
• ○2290Minimum Obstacle Removal to Reach Cornerhard

Pitfalls

• Solving before modelling. These problems arrive as scenarios. Say out loud what the nodes and edges are, or what the state is, before writing anything — getting the model wrong is the expensive failure here.
• Forgetting the graph is weighted. “Fewest steps” cues BFS; road networks have distances. One weighted edge and you need Dijkstra — or 0-1 BFS if the weights are only 0 and 1.
• Ignoring the operational angle. These are systems people. What happens when a driver disconnects, when the request rate spikes, when two matches collide? Naming a failure mode unprompted lands well.
• Treating design questions as pure algorithms. A rate limiter question wants the bucketed, bounded-memory answer, not just a correct one.

Interview follow-ups

They ask	What they’re checking	The answer
“Model this as a graph. What are the nodes?”	Whether you can turn a scenario into a structure	Answer explicitly — intersections as nodes and roads as weighted edges, or riders and drivers as the two sides of a bipartite graph. The model is most of the solution.
“The edges have travel times now.”	BFS’s precondition	BFS is only shortest-path-correct on uniform costs. Switch to Dijkstra at $O(E \log V)$; if the weights are only 0 and 1, 0-1 BFS with a deque keeps it linear.
“What if there are millions of requests per second?”	Bounded memory	Bucket by time: a fixed array of slots keyed by t % window, holding (timestamp, count). $O(1)$ time and $O(1)$ space regardless of traffic — how real rate limiters are built.
“What breaks in production?”	Operational instinct	Name a concrete failure and a mitigation — stale driver locations, a hot partition, a retry storm. Volunteering this is a differentiator.

Recall card

• Problems arrive as scenarios. Model first — name the nodes, edges, or state out loud before solving.
• Weighted graphs, not just BFS. Road networks have distances: Dijkstra, or 0-1 BFS for 0/1 weights.
• Design questions want bounded memory — the bucketed rate limiter, not merely a correct one.
• Volunteer a failure mode. Disconnections, spikes, retry storms. These are systems people.
• Graph and design families dominate the recurring pattern list below.