Interview experience
Uber Interview Questions and Answers (2026)
Overview
Section titled “Overview”Uber’s early-career loop runs an online assessment, two technical rounds (fundamentals plus low-level design), and a hiring-manager or HR round - built more around dispatch, ETA, and marketplace problems than mass campus drives.
Uber interview process at a glance
Section titled “Uber interview process at a glance”| Round | Duration | What it tests |
|---|---|---|
| Online Assessment | 60-90 min | 2-3 DSA coding problems |
| Technical Round 1 | 45-60 min | OS/networking/OOPs fundamentals + coding |
| Technical Round 2 | 45-60 min | Machine coding / low-level object-oriented design |
| System design (experienced / some loops) | 45-60 min | Marketplace-scale design: dispatch, ETA, surge pricing |
| Hiring Manager / HR | 30-45 min | Behavioural fit, project deep dive, cultural norms |
| Bar Raiser (select loops) | 45-60 min | Independent check against Uber’s hiring bar and cultural norms |
Online Assessment
Section titled “Online Assessment”A timed round on a platform like HackerRank or CodeSignal: 2-3 DSA problems in 60-90 minutes. Clean, fully-passing solutions beat a partially-optimised clever one - Uber’s screening is largely pass/fail on test cases at this stage.
Common questions
- Array/string manipulation at LeetCode-easy-to-medium difficulty
- Linked list problems (e.g. find the k-th node from the end)
- A graph or tree traversal problem as the harder of the 2-3 questions
Full round-by-round breakdowns are on the Uber interview experience page.
Technical Round 1: fundamentals + coding
Section titled “Technical Round 1: fundamentals + coding”A 45-60 minute round mixing CS fundamentals (operating systems, networking basics, OOPs concepts) with 1-2 live coding problems. Interviewers often follow a working solution with “what if the input were 10x larger” or a memory-vs-speed trade-off question.
Common questions
- Explain process vs thread, or TCP vs UDP, with a concrete example
- OOPs: explain polymorphism/inheritance using a project you built
- Coding: detect a cycle in a directed graph, or a sliding-window string problem
Technical Round 2: machine coding / low-level design
Section titled “Technical Round 2: machine coding / low-level design”A 45-60 minute round where you design and often code a small object-oriented system live - not a distributed system, a clean class model. A recurring theme in candidate reports is a multi-device remote or appliance-control app with a handful of required commands plus device-specific extensions.
Common questions
- Design a small object-oriented system (e.g. a universal remote or vending machine) with generic and device-specific commands
- Justify your class hierarchy and where you’d extend it for a new device type
- Identify and fix a design flaw the interviewer introduces mid-round
See how real candidates handled this stage on the Uber interview experience page.
System design: Uber’s marketplace at scale
Section titled “System design: Uber’s marketplace at scale”Not every fresher loop includes this round, but experienced-hire and many off-campus loops do. Rather than generic system design templates, Uber interviewers lean on problems from its own marketplace: matching millions of riders to a limited, moving supply of drivers in real time.
Common questions
- Design the rider-driver dispatch/matching system - how do you find and rank nearby drivers fast?
- How would you design ETA prediction for a trip in progress?
- Design a surge-pricing engine that reacts to demand within roughly a minute
- How do you keep a geospatial index (e.g. hexagonal grid cells) fresh as drivers move every few seconds?
Hiring Manager / HR round
Section titled “Hiring Manager / HR round”A 30-45 minute closing conversation: project deep dive, motivation for Uber, and 1-2 behavioural stories checked against Uber’s cultural norms (ownership, grit, customer obsession) rather than a generic “tell me about yourself” script.
Common questions
- Walk me through a project you’re proud of - what would you rebuild?
- Tell me about a time you owned a problem nobody assigned to you
- Why Uber, specifically, over other marketplace/consumer tech companies?
- Are you open to relocation, and what’s your notice period?
Sample answer frameworks for each of these are on the Uber HR interview questions page.
Uber’s Bar Raiser round
Section titled “Uber’s Bar Raiser round”This is the most distinctive step in Uber’s broader hiring process, reported mainly for experienced and US-based roles rather than every India fresher loop. A Bar Raiser is an interviewer from outside your hiring team whose only job is to protect Uber’s hiring bar - they carry real veto power even if every other interviewer wants to move forward, precisely so a team under headcount pressure can’t quietly relax its standards. If your loop includes one, expect it to lean harder on Uber’s cultural norms and less on a second helping of DSA.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Find the kth node from the end of a singly linked list in one pass.
Advance a lead pointer k nodes from the head, then move a second pointer from the head in lockstep with the lead until the lead reaches null - the trailing pointer is then at the kth node from the end. It is O(n) time, O(1) space, and needs only one traversal, unlike counting the length first and walking again. Handle the edge cases explicitly: k larger than the list length should return null rather than dereferencing null, and k equal to the length means the head itself. The same two-pointer offset trick underlies deleting the kth-from-end node, where you stop one node earlier to keep the predecessor.
Q: How do you detect a cycle in a directed graph, and where would that matter at Uber?
DFS with three states - unvisited, in-progress on the current recursion stack, and finished - flags a cycle the moment you reach an in-progress node, in O(V + E) time and O(V) space. A plain visited set is not enough, because revisiting a finished node is legal in a DAG. Kahn’s algorithm gives the same answer iteratively by peeling off in-degree-zero nodes and checking whether any remain. This matters in practice for dependency graphs - build pipelines, microservice call chains, or a workflow engine - where a cycle means a deadlock or an infinite retry loop rather than an abstract puzzle.
Q: What is the difference between a process and a thread?
A process has its own virtual address space, page tables, file descriptor table, and heap; a thread lives inside a process and shares all of that while keeping its own stack, registers, and program counter. Context switching between threads of one process is cheaper because the page tables and TLB stay valid, whereas a process switch flushes them. The trade-off is isolation: a segfault or memory corruption in one thread kills the entire process, while separate processes are protected from one another at the cost of IPC through pipes, sockets, or shared memory. Shared mutable state between threads needs synchronisation, which is where races, deadlocks, and lock contention come from.
Q: When would you choose UDP over TCP?
TCP gives a connection-oriented, ordered, reliable byte stream with a three-way handshake, retransmission, flow control, and congestion control - and pays for it in head-of-line blocking, where one lost packet stalls everything behind it. UDP is a connectionless datagram service with no ordering, no retransmission, and no congestion control, so it has lower latency and per-packet overhead. Choose UDP for real-time voice and video, live location pings, DNS, and gaming, where a stale packet is worthless and a missed one is better dropped than resent. For continuous driver-location updates, UDP is the natural fit because the next ping supersedes the lost one - and QUIC shows you can layer reliability and encryption on UDP when you want TCP’s guarantees without its head-of-line blocking.
Q: Design a vending machine as a low-level object-oriented system.
Model the machine as a state machine with an interface VendingState and implementations Idle, HasMoney, Dispensing, and OutOfStock, each deciding what insertCoin, selectProduct, and dispense do - which removes the sprawling switch statement a naive design produces and makes an illegal transition impossible rather than merely rejected. Keep Inventory as a separate collaborator mapping slot to product and quantity, and a CoinManager owning change calculation, so pricing and change logic are independently testable. Expose a narrow facade for the caller, and make dispense atomic with respect to inventory decrement so two concurrent selections cannot oversell the last item. Say which extension points you would keep - adding a card payment should mean adding a PaymentMethod implementation, not editing the state classes.
Q: How would you design the rider-driver dispatch system?
Drivers publish location every few seconds into a geospatial index - Uber uses H3 hexagonal cells - so finding candidates near a pickup point is a lookup of the containing cell plus its ring of neighbours rather than a scan over millions of rows. Keep that index in memory, sharded by region, with the driver state machine (offline, available, en route, on trip) as the source of truth. Ranking candidates on estimated time to pickup rather than straight-line distance matters, because a river or a one-way street makes the nearest driver the wrong one. Assign in short batches rather than greedily, since solving a small bipartite matching every second or two lowers total wait time, and make the assignment an atomic compare-and-swap on driver state so one driver cannot be given two trips.
Q: How would you predict the ETA for a trip in progress?
Split the estimate into route time plus expected delay. The base is a shortest-path computation over a road graph with edge weights that are live speed estimates per segment per time bucket, learned from historical and current GPS traces; contraction hierarchies make repeated queries fast enough at scale. On top of that, a learned residual model corrects the physics estimate using features like time of day, weather, traffic incidents, and the specific driver’s recent speed. Recompute continuously as the trip progresses instead of quoting the original estimate, and predict a distribution so you can quote a conservative percentile - being five minutes late damages trust much more than arriving early. Monitor the error distribution per city and per hour, because a globally good model is often badly biased in one region.
Q: How would a surge-pricing engine work, and what constraints matter?
Compute a supply-demand ratio per geospatial cell over a short sliding window - open requests versus available drivers - and map it through a calibrated multiplier curve, smoothing across neighbouring cells so a rider does not see a price cliff by crossing the street. The loop has to close in around a minute so the multiplier actually attracts drivers into the cell while demand is still there. Key constraints are hysteresis, so the multiplier does not oscillate as the ratio crosses a threshold; caps during emergencies and for regulatory compliance; and price lock, meaning the quote shown to the rider is honoured for the booking even if the multiplier moves. Bad data is the real hazard - a batch of stale driver pings makes supply look higher than it is, so the pipeline needs freshness checks before the ratio is computed.
Frequently asked questions about Uber interviews
Section titled “Frequently asked questions about Uber interviews”What is the Uber interview process for freshers?
Uber’s early-career loop (Software Engineer I) usually runs: 1. Online Assessment (60-90 min) - 2-3 DSA coding problems on a platform like HackerRank or CodeSignal. 2. Technical Round 1 (45-60 min) - OS/networking/OOPs fundamentals plus 1-2 coding problems. 3. Technical Round 2 (45-60 min) - machine coding / low-level object-oriented design. 4. Hiring Manager / HR (30-45 min) - project deep dive and behavioural fit. Timeline is usually 3-6 weeks from application to offer.
What questions are asked in Uber interviews?
Coding rounds cover arrays/strings, linked lists, trees, and graphs, alongside OS and networking basics. The machine-coding round often asks you to design a small object-oriented system - a multi-device remote or vending machine - with clean class boundaries and extensibility. Experienced loops add a system design round built around Uber’s own marketplace problems: rider-driver dispatch, ETA prediction, and surge pricing. Behavioural questions probe ownership, grit, and fit with Uber’s post-2017 cultural norms.
How many rounds are there in the Uber interview?
Fresher / Software Engineer I loops in India typically run 4 stages: Online Assessment, two technical rounds (fundamentals + coding, then machine coding / LLD), and a hiring-manager or HR round. Experienced-hire loops reported on Blind and IGotAnOffer add a system design round, a Collaboration & Leadership behavioural round, and sometimes a Bar Raiser interview, so total touchpoints can run 5-7. Exact composition varies by team and level.
How should I prepare for Uber interviews?
Drill core DSA (arrays, linked lists, trees, graphs) and revise OS, networking, and OOPs, since Uber’s fundamentals round tests both. Practise one clean object-oriented design end to end - class boundaries, extensibility, edge cases. If your loop includes system design, learn the shape of Uber’s own problems: rider-driver matching, ETA prediction, and surge pricing. Prepare 2-3 STAR stories around ownership and grit for the behavioural rounds.
What is Uber’s Bar Raiser round?
Some Uber loops - mainly experienced-hire and US-based roles, per candidate reports on IGotAnOffer and Educative - include a Bar Raiser interview: an interviewer from outside the hiring team who evaluates strictly against Uber’s cultural norms and hiring bar, independent of whether the rest of the panel liked you. It exists so a team under pressure to fill a seat can’t quietly lower its standards. Most India fresher / Software Engineer I loops reported on GeeksforGeeks don’t mention a separate Bar Raiser round, but treat it as a possibility at senior levels.
Is Uber’s India hiring a campus drive or something narrower?
Something narrower. Nearly all of Uber’s India entry-level hiring funnels into one title - Software Engineer I, mostly out of Bengaluru - filled through targeted application windows and referrals in smaller batches, not a walk-in drive across colleges.
What compensation can I expect as an Uber Software Engineer I in India?
Community-reported figures (Levels.fyi, as of 2026) put total compensation for a Software Engineer I in India roughly in the ₹20-36 LPA range depending on location, stock refresh, and negotiation, with Bengaluru offers for new entrants clustering toward the lower-to-mid end of that band. Treat this as a rough signal from self-reported data, not a guarantee - confirm on your own offer letter.