Recent US reports show the same Uber interview process for new grads: a proctored CodeSignal assessment of four problems (two easy, two medium-hard), a one-hour LeetCode-style screen on Zoom, then a final loop of two medium coding interviews and one behavioral interview that digs into your resume. Experienced candidates get a tech screen and four onsite rounds that add system design and low-level design.
The coding is fair but timed tightly, and several reports say the behavioral round goes line by line through your resume. Outcomes and timelines are noted for each report below.
Uber interview process round by round
| Round | Duration | What it tests |
|---|---|---|
| Online assessment (CodeSignal) | 70 min | 4 coding problems, two easy and two medium-hard, proctored |
| Coding screen | 60 min | One LeetCode-style problem on Zoom |
| Final loop - Coding (x2) | 45-60 min each | Medium DSA with current engineers |
| Final loop - Behavioral | 45-60 min | Resume deep dive, ownership, why Uber |
| System design (experienced) | 45-60 min | Marketplace-scale design: dispatch, ETA, surge pricing |
| Bar Raiser (select loops) | 45-60 min | Independent check against Uber’s hiring bar and cultural norms |
Uber interview process in 2025: new grad and intern reports
These show what an interview at Uber looked like for US candidates in 2025. They come from self-reported write-ups on Taro (jointaro.com), and each is one candidate’s account.
- New grad software engineer, United States (early 2025, accepted offer). CodeSignal assessment about 1.5 weeks after applying, completed in December; the interview invite came about a month later. A one-hour LeetCode-style screen on Zoom, then a final loop of three rounds: two medium coding interviews with current engineers and one behavioral interview. One reported prompt was designing a room reservation system. The offer came a little over a week after the final round.
- New grad software engineer, Seattle, WA (May 2025, no offer). CodeSignal General Coding Assessment with four problems, two LeetCode easy and two medium-hard. The candidate called it intense but fair, with real time pressure.
- Software engineer, New York, NY (June 2025, offer declined). Online assessment, one technical screen and four onsite interviews. The questions were LeetCode style, harder than at other companies but fair. The candidate rated the experience negative because several interviewers were dismissive or interrupted often.
- Software engineer intern, United States (February 2025, no offer). Online assessment, technical rounds at LeetCode easy to medium, and a behavioral round that started with tell me about yourself and went deep into the resume.
Uber interview questions that come up often
Coding / technical
- Array/string manipulation and linked-list problems (e.g. find the k-th node from the end)
- Detect cycle in a directed graph - DFS coloring / topological sort
- Process vs thread, TCP vs UDP, and other OS/networking basics
- OOPs concepts explained with a real project example
- Machine coding: design a small object-oriented system (remote control, vending machine) with extensible class boundaries
System design (experienced / some loops)
- Design the rider-driver dispatch/matching system
- Design ETA prediction for a trip in progress
- Design a surge-pricing engine reacting to demand within about a minute
- How would you keep a geospatial driver index fresh as locations update every few seconds?
HR / behavioral
- Tell me about a time you owned a problem nobody assigned to you
- A disagreement with a teammate and how you handled it
- Why Uber, specifically?
- Office preference, start date and work authorization
Uber interview tips from US candidates
- On the CodeSignal assessment, bank the two easy problems quickly; the Seattle new grad said the time pressure was real.
- For the machine-coding round, narrate your class design before typing; interviewers often probe how you’d extend it, not just whether it runs.
- OS, networking, and OOPs fundamentals still open a lot of Uber panels - do not skip them assuming only DSA matters.
- If you reach system design, explain dispatch/ETA/surge pricing in plain language: inputs, outputs, what breaks first at scale.
- Know every line of your resume; the 2025 US intern said the behavioral round went deep into it right after tell me about yourself.
Uber behavioral round in these reports
The early-2025 US new grad’s final loop had one behavioral interview out of three rounds; the 2025 intern’s started with tell me about yourself and went deep into the resume. Stories are checked against Uber’s cultural norms such as ownership and grit, and STAR answers for those are on the Uber behavioral interview questions page.
Sample answers for high-frequency questions
Q. Find the kth node from the end of a singly linked list in one pass.
A. 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?
A. 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. 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 synchronization, which is where races, deadlocks, and lock contention come from.
Q. When would you choose UDP over TCP?
A. 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.
A. 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.
Uber interview tips from these reports
CodeSignal OA
- The new grad assessment is four problems in 70 minutes, proctored, due within 3 days of the email, so take it when you have a clear block of time.
- Two problems are reported as easy and two as medium-hard; banking the easy two quickly leaves time for the heap and greedy problems.
Coding rounds
- One US new grad had a one-hour LeetCode-style screen on Zoom, then two medium coding rounds with current engineers.
- A June 2025 New York candidate called the LeetCode-style questions harder than at other companies but fair.
Behavioral round
- A 2025 US intern said interviewers go deep into your resume after tell me about yourself, so know every project line you list.
- Uber scores stories against its cultural norms such as ownership and grit, so prepare one story each for owning a problem and sticking with a hard one.
Uber India: Software Engineer I campus loop and reported pay
Nearly all of Uber’s India entry-level hiring funnels into a single title - Software Engineer I out of Bengaluru - filled through targeted application windows and referrals, not a blanket walk-in drive across colleges. No fixed CGPA cutoff is published anywhere. Before acting on a forwarded “Uber campus drive” notice, cross-check it against Uber’s careers page.
Community-reported total compensation for a Software Engineer I in India clusters roughly in the ₹20-36 LPA range (Levels.fyi, 2026), skewed by location, stock refresh, and level within the band. For India OA drills, see Uber on placementpapers.app.
Uber India round-wise process
| 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 |
| Hiring Manager / HR | 30-45 min | Behavioral fit, project deep dive, cultural norms |
Real interview experiences from India
Details differ by campus and year.
Experience 1: Summer internship, on-campus (offer)
Source: Uber Interview Experience for Summer Internship (On-Campus) - GeeksforGeeks
Round 1 - Online assessment (CodeSignal, 60 min)
- Three problems: converting a number from base 2 to base 6, a binary-string question about the largest substring length you can flip to make all bits equal, and a modified bowling problem scored with DP.
- The candidate ran out of time on the third, submitted a brute force that earned about half the points, and still cleared. Partial credit does count here.
Round 2 - Technical 1 (Zoom + CodeSignal, 45 min, two interviewers)
- Find the critical and pseudo-critical edges in a minimum spanning tree, a LeetCode Hard. Solved with Kruskal’s plus a hand-written DSU, checking whether the MST weight changes when an edge is excluded.
- The DSU code had bugs that the candidate fixed near the end of the round.
Round 3 - Technical 2 (45 min, two interviewers)
- Explicitly about OOP and coding style, not time complexity: design a restaurant data structure that adds and prints dishes, computes a bill with 18% GST, and lists dishes that do or do not share ingredients with a given list. A follow-up (dishes whose prices sum to a target) was only described as backtracking, not coded.
Round 4 - Hiring manager (30 min)
- Intro, deep dives into two resume projects (one on computer architecture), and a behavioral question about a time you helped someone or asked for help.
Outcome: Offer extended.
Takeaways
- What decided it: Recovering from a buggy DSU implementation while explaining the approach, then clean object-oriented code in the second round
- How to practice: MST and DSU problems, plus one small OOP design coded end to end in 45 minutes
Experience 2: SDE I, on-campus (rejected at round 2)
Source: Uber Interview Experience For SDE I (On-Campus) - GeeksforGeeks
Worth reading precisely because it did not end in an offer.
- Round 1 (HackerRank, 90 min, medium): Burst Balloons (interval DP) and a binary-search-on-answer question over a monotonic equation.
- Round 2 (video call, 60 min, medium): insertion at a given position in a doubly linked list, then a non-standard DP problem.
- Outcome: Not shortlisted after round 2.
Takeaways
- What decided it: This screen leaned on DP, including a problem without a familiar template. The OA platform also varies by drive (CodeSignal and HackerRank both appear in these reports, at 60 to 90 minutes), so confirm the format from your placement email.
- How to practice: Interval DP and binary search on the answer
Experience 3: SDE I, off-campus - LLD decided the outcome
Source: GeeksforGeeks
Round 1 - OA (HackerRank, 75 min): Three medium to hard DSA problems; candidate cleared.
Round 2 - BPS (elimination, 1 hour): 45 minutes of coding on a graph problem similar to Word Ladder (minimum transitions between 4-digit codes that differ by one digit, using only an allowed list), solved with BFS, then 15 minutes of high-level design.
Round 3 - DSA (1 hour): Earliest time when everyone in a network is connected, solved with Union-Find. Rated Strong Hire.
Round 4 - Machine coding / LLD (1 hour): Design a parking lot: classes, interfaces, relationships and OOP questions. The candidate could not finish working code in time. Rated Low Hire.
Round 5 - Hiring manager (45-60 min): Projects, leading a project, handling team conflict, and why Uber. Rated Strong Hire.
Outcome: Not selected. The candidate called it a close call, with the Low Hire in LLD outweighing the two Strong Hire rounds.
Takeaways
- What decided it: For Uber SE I, a weak low-level design round can sink an otherwise strong loop
- How to practice: Time-box one parking-lot style OOD to working code; state class responsibilities before typing
Experience 4: SDE I, February 2026
Source: InterviewExperiences.in, March 2026
Round 1 - Technical assessment (elimination): Given time-sorted shared-ride logs, find the earliest time all users are connected. Follow-up: cancel-ride logs can remove a connection.
Round 2 - DSA coding: Each microservice lists its dependencies; each cycle starts any service whose dependencies are up. Return the minimum number of cycles, or impossible.
Round 3 - LLD: An in-memory file system with mkdir, pwd and cd, absolute and relative paths, and a * wildcard.
Outcome: Not stated in the write-up.
Takeaways
- What decided it: Two of the three rounds were connectivity and dependency-graph problems, and the design round asked for a working API, matching the parking-lot LLD in Experience 3
- How to practice: Union-find, topological ordering, and one file-system or parking-lot design coded end to end
Sources
- Taro: new grad, United States, early 2025
- Taro: new grad, Seattle, May 2025
- Taro: software engineer, New York, June 2025
- Taro: intern, United States, February 2025
- Taro: new grad, Toronto, June 2025
- India experiences: GeeksforGeeks and InterviewExperiences.in write-ups linked in each entry