Site Reliability Engineer Interview Experience at Uber – 2026

This coding screen runs on CodeSignal, matching Uber's standard technical-screen format. The problem asks candidates to design a rate limiter class supporting a sliding-window request count per client ID, exposing an `allow(client_id)` method that returns whether the current request should proceed. A deque of timestamps per client, evicting entries older than the window on each call before checking the count against the limit, is the expected implementation. A common follow-up asks how this would need to change to work correctly across multiple service instances rather than a single process — moving the timestamp tracking into a shared store like Redis using a sorted set keyed by client ID, with the score being the request timestamp, is the strong answer.

This is the hardest round of the loop, consistent with what several candidates separately describe as Uber's most difficult stage. The problem models driver-rider matching within a bounded radius: given a stream of driver location updates and a rider request with a pickup location, find the nearest available driver within a configurable radius, and support drivers going offline mid-stream. Starting with a brute-force distance check against all known drivers, then optimizing to a geohash-based bucketing approach once scale to a full city's worth of drivers comes up, is the expected progression — narrowing the search to nearby buckets before computing exact distances only on that smaller candidate set. A common pitfall is missing correct handling of a driver going offline (stale entries left in the bucket structure), which requires explicit removal logic once flagged with a specific test case.

Candidates are asked to design the infrastructure for surge pricing calculation across city zones in near real time. Dividing each city into a grid of zones, computing a demand-to-supply ratio per zone on a short rolling window using a stream processing layer, and pushing updated multipliers to a fast in-memory store that pricing services read from directly rather than recomputing per request, is a strong direction. A common mid-round twist introduces a new constraint: what happens during a major event (a large concert letting out) causing an extreme, highly localized demand spike in one small zone — a dampening mechanism that caps how fast the multiplier can rise within a short window is the right adaptation, avoiding a runaway feedback loop where a price spike itself gets misread as sustained demand.

The bar raiser round focuses specifically on a past decision defended under real follow-up pressure, matching what candidates describe as this round's real purpose — testing decision-making reasoning, not just project outcomes. A common prompt covers choosing to roll back a deployment rather than forward-fix during an active incident, with the interviewer pushing repeatedly on why a forward patch wasn't used given the fix was reportedly small, expecting the actual risk difference between the two options to be quantified rather than 'rollback is safer' accepted as a given answer.