Longest Continuous Subarray With Absolute Diff Less Than or Equal to Limit (LeetCode 1438) — reported framed as: given an array and a number K, find the length of the longest subarray in which the absolute difference between any two pair of elements is less than or equal to K.

Use a sliding window with two monotonic deques, one tracking the rolling maximum and one tracking the rolling minimum. When max minus min exceeds K, shrink the window from the left. This gives O(N) time and O(N) space. Follow-ups ask about streaming input where you cannot store the whole array, or extending to a 2D grid variant. Recognizing that two deques replace a brute-force O(N^2) scan; clean window management without off-by-one errors; ability to explain the deque invariant clearly.

Insert Delete GetRandom O(1) / RandomizedSet (LeetCode 380) — reported in Uber SDE-2 Backend onsite as: design a data structure like a hashmap supporting get, set, and delete, plus a getRandom function that returns a random key-value pair in O(1). An extension adds concurrency requirements for multiple threads.

Back the structure with a HashMap for O(1) lookup and a dynamic array (list) to enable O(1) random access. On delete, swap the target element with the last element before removing from the list. For the concurrent extension discuss read-write locks or a ConcurrentHashMap variant. Follow-up asks about getRandom with weighted probability. The swap-with-last trick for O(1) delete; recognizing that an array alone gives O(N) delete; awareness of thread safety trade-offs without over-engineering.

LRU Cache (LeetCode 146) — reported multiple times across Glassdoor reviews and LeetCode company tag as a Uber machine-coding and screen staple.

Combine a HashMap (key to node) with a doubly-linked list (ordered by recency) so get and put are both O(1). The dummy head and tail sentinel nodes simplify edge cases. The follow-up typically asks for LFU (LeetCode 460) or a time-based expiry variant relevant to Uber's session or surge-pricing cache. Clean doubly-linked list management without bugs; proper eviction logic on capacity; the ability to articulate why a plain HashMap or a singly-linked list is insufficient.

Design Uber's ride-hailing system — match riders with nearby drivers in real time, handle location tracking, trip lifecycle, and failure modes.

Clarify scale (millions of concurrent GPS pings/second, global cities) then define the core services: Location Service (ingests driver GPS pings into a geospatial index like H3 hexagons or a quadtree), Matching Service (queries nearest available drivers, computes ETAs using a routing graph), Trip Service (state machine: requested, accepted, en-route, completed, cancelled). Use a pub/sub bus (Kafka) to decouple GPS ingestion from matching. Discuss read-heavy vs write-heavy sharding, WebSocket or long-polling for real-time driver tracking on the client, and what happens when a matched driver goes offline before accepting. Interviewers specifically probe cross-region complexity and edge cases such as sparse driver supply. Depth on geospatial indexing strategy, the supply-demand matching algorithm under latency constraints, and realistic failure-mode handling — not just the happy path.

Design a surge pricing engine — calculate dynamic pricing multipliers for each hexagonal zone in a city in near-real time based on supply, demand, and external signals.

Ingest driver GPS pings and ride requests into a streaming pipeline (Kafka). Aggregate supply and demand counts per H3 hex cell on a rolling 30-second window using a stream processor (Flink or Spark Streaming). Compute the multiplier with a configurable function. Persist zone multipliers in a low-latency read store (Redis) that the pricing query service reads. Discuss how to handle uneven load across zones, how to prevent oscillation (multiplier jumping up and down rapidly), and how to propagate the multiplier to rider apps with acceptable staleness. Understanding of streaming windowed aggregation, the latency vs consistency trade-off on multiplier freshness, and realistic discussion of geographic sharding for hot zones like airports.

Design a stock price notification system — ingest price ticks from multiple exchanges and push a notification to subscribed users when a stock price changes by 5 percent relative to a past time window (last minute, last hour, last week).

Reported verbatim in a Uber SDE-2 onsite (LeetCode Discuss thread 7193626). Ingest ticks via a message queue; maintain a time-series store (e.g. TimescaleDB or a Redis sorted set keyed by timestamp) per ticker to answer historical price queries. A Comparator service reads the latest tick and queries the historical baseline for each window; when the threshold is crossed it publishes to a Notification Service. Discuss sharding: stocks with many ticks (AAPL, TSLA) are hot shards — partition by ticker with consistent hashing. For deduplication, use a distributed set with a TTL window to suppress repeated alerts for the same move. Concrete answer on where historical prices live and how to query them efficiently at scale; awareness of hot-ticker sharding; deduplication logic that prevents notification storms.

Tell me about a time you took ownership of a project end to end — from ambiguous requirements through to launch. How did you drive it forward when things were unclear?

Use STAR with emphasis on the actions you personally took to resolve ambiguity: proactively defining scope, aligning stakeholders, and making decisions without waiting for perfect information. Interviewers want specifics — concrete timelines, the decisions you made and why, and measurable outcomes (e.g., reduced latency by 40%, shipped two weeks early). Avoid narratives where the team just rallied around an obvious solution. Alignment with Uber's Go Get It value — bias for action, self-direction, and accountability for outcomes rather than tasks.

Describe a situation where you disagreed with a technical decision made by a senior engineer or manager. How did you handle it, and what was the outcome?

Show that you voiced the disagreement with data or a reasoned argument (not just a preference), then either persuaded the team or committed fully to the chosen path once the decision was made. Avoid stories where you simply deferred or where you were proven obviously right — the interviewer wants to see intellectual honesty and collaborative disagreement. Quantify what changed as a result of your input. Intellectual courage paired with team respect; the ability to separate technical conviction from ego; alignment with See Every Side (Uber's value around diverse perspectives).

Tell me about a time you had to make a significant technical decision under time pressure with incomplete information. What was your decision-making process?

Structure around: what information you quickly gathered, what you deliberately chose not to wait for, the decision itself, how you mitigated the risk of being wrong (rollback plan, feature flag, partial rollout), and what you learned. Quantify the stakes — what would have happened if you waited another day vs decided immediately. Structured risk reasoning under urgency; awareness that some decisions are reversible (two-way doors) vs irreversible; alignment with Go Get It.

Uber Interview Questions

Uber runs a standardized 4-to-6 round onsite loop: two DSA coding rounds, one Low-Level Design (LLD) / machine coding round, one High-Level Design (HLD) system design round, and a Hiring Manager behavioral round. System design is required even at L3 (New Grad), which is unusual compared to other top tech companies. The initial screen uses CodeSignal's General Coding Framework (GCF), with a passing threshold around 700-725. The overall process typically takes around 20 days from application to offer.

16 real questions across 3 rounds

Reported via LeetCode Discuss threads: Uber SDE-2 Bangalore July 2024 (thread 5655907), Uber SDE-2 Backend Interview Exp (thread 7193626) — direct source for LeetCode 380 verbatim framing, Uber SE-2 Bangalore (thread 7300207), Interview Experience SDE2 Uber Nov 2025 (thread 7672800), UBER SDE2 DSA Round (thread 6287791); LeetCode Discuss Uber phone screen thread for LeetCode 1438; Medium write-ups: Uber Interview Experience L4 SDE2-Backend December 2024 by Laxman Kumar Meghwal (train scheduling with min-heap); Glassdoor Uber Software Engineer Interview page (LRU Cache); verified against LeetCode Uber company tag (Merge Intervals).

4 more coding questions Uber actually asks, each with how to approach it and exactly what the interviewer is evaluating. Unlock the full set across every round.

Continue with Google

Or run a Uber mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews