What topics are tested in Uber SDE-2 interviews?

Uber SDE-2 interviews test: Arrays, Trees, Two Pointers, Sliding Window, Graphs, Dynamic Programming, Hash Maps, Sorting.

Does Uber SDE-2 have a system design round?

Yes, Uber SDE-2 includes a system design round.

Uber

Q: How many rounds are there in Uber SDE-2 interviews?

Uber SDE-2 typically has 5 rounds. Uber SDE-2 (L4) interviews include a Design and Architecture round — not a generic system design exercise. Uber's interviewers expect you to know their actual domain: hexagonal geo-indexing (H3), real-time driver location pipelines, surge pricing engines, and ride-matching latency constraints. The coding bar is hard — two onsite rounds at Hard difficulty, the second of which (Depth in Specialization) tests production-code quality and OOP, not just algorithmic correctness. No online assessment for experienced hires. Expect 5 rounds over 2–4 weeks.

Mobility / Tech · San Francisco, CA

Uber's real-time dispatch platform connects riders, drivers, and couriers across 70+ countries at massive scale.

Related Companies

Rounds: 5 rounds
Focus: DSA + Architecture Design
System Design: Yes
Timeline: 2–4 weeks to offer

Role:

Rounds 1–2 are fully visible · Round 3+ unlocked with a free account

Technical Phone Screen

Round 1 of 5DSA / Coding

60 min

ArraysTreesTwo PointersSliding Window

Live coding from the start. One medium-hard problem with approach discussion before coding. Uber interviewers at SDE-2 level will ask about complexity guarantees at scale — e.g., 'how does this hold up across 10M active drivers?' — before you finish the implementation.

Medium–Hard

What to expect

1 medium-hard problem, often involving frequency counting, interval manipulation, or graph traversal framed around Uber's operational data
e.g., 'Given a stream of driver GPS pings, return the top K most-active driver zones in the last 5 minutes' (sliding window + heap or min-heap eviction)
Explain your approach and complexity before coding — interviewers note when candidates code first and explain later
A short follow-up variant testing whether the solution degrades gracefully with a different constraint (e.g., memory-bounded)

Practice on KnowEase.AI

DSA Practice — Two Pointers →

On-site: Algorithms & Data Structures

Round 2 of 5DSA / Coding

60 min

GraphsDynamic ProgrammingHash MapsSorting

Hard problem with real-world framing from Uber's domain. The problem will look like standard LeetCode Hard but be wrapped in ride-hailing context. Brute force → optimal progression is expected; the interviewer is watching whether you identify the bottleneck and fix it without being told.

Hard

What to expect

e.g., 'Given N drivers and M ride requests with (lat, lon) coordinates, find assignments minimizing total pickup distance' — expected to identify this as a weighted bipartite matching or greedy-with-heap problem
e.g., 'Given a real-time stream of trip events, detect when a driver has been stationary for more than K minutes across overlapping geo-zones' (interval + spatial reasoning)
Brute force stated upfront is fine; staying on brute force when asked to optimize is not
Clean, modular code — SDE-2 candidates who write spaghetti code with no separation of concerns are down-leveled to SDE-1

Practice on KnowEase.AI

DSA Practice — Graphs →DSA Practice — 1D DP →

On-site: Depth in Specialization

Round 3 of 5LLD / OOD

60 min

HeapsGraphsConcurrencyOOP

Hard problem evaluated as a code review, not just a solution. Interviewers explicitly assess whether the code is production-quality: class responsibilities, error handling, naming, and extensibility. At SDE-2 level, Uber expects heaps, graphs, or concurrency patterns used correctly with no hand-holding.

What to expect

e.g., 'Implement a real-time top-K ranking system for Uber Eats restaurants by order velocity' — expected to use a heap with expiry, not just sort the full list
e.g., 'Build a thread-safe token-bucket rate limiter for Uber's driver onboarding API' — concurrency bugs (unsynchronized shared state) are a common rejection trigger here
Interviewer will ask: 'Walk me through this as if you're doing a code review with your team' — candidates who can't narrate their own design choices fail this round
Follow-up: 'How would this perform at 10M requests/second? What breaks first?'

Full details unlocked with a free account

Design and Architecture

Round 4 of 5System Design

60 min

Real-time SystemsGeo-indexingKafkaRedisDistributed Databases

Design a real-time, geo-distributed system at Uber's actual scale. This is not 'design Twitter' — the interviewer will frame the problem in Uber's domain and expects you to reason about supply-demand dynamics, geospatial indexing, and sub-second matching latency. Candidates who design for a single city when Uber operates across dozens of countries with wildly different density profiles are explicitly called out.

What to expect

e.g., 'Design the surge pricing engine: how do GPS pings from 5M active drivers become per-zone surge multipliers in under 60 seconds?' — expected to discuss H3 hexagonal geo-indexing, rolling 5-minute supply/demand windows, and Redis-backed zone multiplier cache
e.g., 'Design the driver-rider matching service: how do you find the nearest available driver for a request in under 200ms?' — expected to use Redis GEOSEARCH/GEORADIUS for proximity lookup, not a full DB scan
Designing the location update pipeline at scale: drivers ping GPS every 4 seconds; how do you ingest, store, and query 5M+ concurrent location streams without a hot shard?
Not knowing the difference between geohash and H3 hexagons is a yellow flag — H3's equidistant hexagons avoid the edge-distortion problem of square geohash cells, which matters for zone boundary accuracy in surge pricing
Generic CAP theorem discussion without anchoring to Uber's actual consistency tradeoffs (e.g., eventual consistency is fine for surge display, not for payment authorization) signals a surface-level answer

Full details unlocked with a free account

Collaboration & Leadership

Round 5 of 5Behavioral / HM

45 min

BehavioralTechnical LeadershipOwnership

Run by the hiring manager or another senior manager in the org. This is partly behavioral and partly a technical retrospective — they will ask you to walk through your most impactful project in detail and then probe the decisions you made. At SDE-2, Uber is evaluating whether you operate with ownership, not just execution.

What to expect

Walk me through the most impactful thing you shipped — they want your specific decisions and their measurable outcomes, not team outcomes
Tell me about a production incident you were involved in and how it resolved — they want your role specifically, including if you made the mistake
How did you handle a disagreement with a cross-functional partner (PM, data scientist, another team)?
Candidates who treat this as a soft round and don't prepare structured project narratives are regularly surprised by the depth of follow-up questioning

Full details unlocked with a free account

Questions — coming soon.

Company Guide — coming soon.

About Uber SDE-2 Interviews

Uber SDE-2 (L4) interviews include a Design and Architecture round — not a generic system design exercise. Uber's interviewers expect you to know their actual domain: hexagonal geo-indexing (H3), real-time driver location pipelines, surge pricing engines, and ride-matching latency constraints. The coding bar is hard — two onsite rounds at Hard difficulty, the second of which (Depth in Specialization) tests production-code quality and OOP, not just algorithmic correctness. No online assessment for experienced hires. Expect 5 rounds over 2–4 weeks.

See interview loops for other companies:

Microsoft Amazon Flipkart Razorpay Walmart Coupang Rippling Rubrik Target

Start your Uber SDE-2 prep plan

Practice the exact topics tested in each round — DSA, system design, SQL, and LLD.

Start free →