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.

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.

Self-check

quizCheck yourself

1. A road network has distances on edges. Which should you reach for, not plain BFS?

   AUnion-findBDFSCDijkstra, or 0-1 BFS when weights are 0 or 1DBinary search
   Show answer

   C — Dijkstra, or 0-1 BFS when weights are 0 or 1 — BFS only gives shortest paths in unweighted graphs.

2. A scenario problem arrives phrased as riders and drivers. What is the first step?

   AAsk for the answer formatBPick a data structureCStart codingDName the nodes, edges or state out loud before solving
   Show answer

   D — Name the nodes, edges or state out loud before solving — Turning the scenario into a model is what is being tested.

3. For a rate limiter design question, what distinguishes a strong answer?

   AIt is correct with bounded memory, for example bucketed windows, and names failure modesBIt uses a databaseCIt avoids threadsDIt is correct
   Show answer

   A — It is correct with bounded memory, for example bucketed windows, and names failure modes — Uber interviewers are systems people, so volunteer spikes, retry storms and disconnections.