HackTheRounds Interview Experiences

Uber New Grad Full Loop Interview Experience (2026) - CodeSignal OA, Ride Dispatch OOP & Uber Eats Feed Design, Offer

Full Uber 2026 NG loop: CodeSignal OA with Prime Jumps, phone screen on interval concurrency, onsite coding with ride dispatch OOP, Uber Eats home feed system d

By Anonymous · 2026-04-07

Background

Dropping the full walkthrough of my Uber new-grad loop since I just accepted the offer. I was an in-semester senior juggling classes, a part-time research gig, and interview prep all at once. Uber was my top preference because the infra-scale problems (dispatch, pricing, geo-indexing) are genuinely hard. The schedule was tight but manageable if you front-load OA prep and leave onsite drilling for closer to the date.

Timeline

Application via referral: early February
CodeSignal OA link received: 9 days later
OA attempted: 3 days after receiving (70 minute window)
Phone screen invite: 10 days after OA
Phone screen: 1 week after invite
Virtual onsite (3 Coding + 1 BQ): 3 weeks after phone screen, spread across two days
Offer: 8 business days after the final onsite round

Total: about 8 weeks.

OA (CodeSignal, 70 min)

Four problems. One Easy, two Medium, one Hard. CodeSignal's scoring is per-test-case so even a brute force on the Hard problem is worth pursuing after you have locked in the Medium ones.

My actual split:

Q1 Easy: array frequency counting. Done in 6 minutes.
Q2 Medium: interval merging with priority metadata. Done in 18 minutes.
Q3 Medium: graph shortest path with a twist on edge weights. Done in 22 minutes.
Q4 Hard: this was the Prime Jumps variant. I sieved up to `n`, filtered primes by trailing digit, and wrote the DP. Ran out of time to tune but hit most test cases.

Uber's OA in this cycle reused Prime Jumps and Minimum Edge Reversals. These are specific Hard problems that show up repeatedly in Uber OA reports, so if you have 10 hours of OA prep, spend the first two on exactly those two problems.

[[problem/872?company=12|Prime Jumps]]

Phone Screen (45 min, CoderPad)

Problem: A variant of the meeting overlap question. Given intervals, return the time span with the most concurrent intervals. Follow-ups expand toward streaming input.

I used the sweep line pattern: expand each interval into two events, sort, walk with a running count. The interviewer added a wrinkle where intervals could be added over time and asked how my data structure would change. I moved to a TreeMap of timestamps to deltas and walked through the O(log n) insert and O(n) peak query. The last 10 minutes were a whiteboard discussion of how you would do a sub-linear peak query with a segment tree, which I sketched but did not implement.

Clean 35-minute solve, 10 minutes of discussion, and the feedback came back the next day.

[[problem/255?company=12|Meeting Room Scheduler]]

Onsite: 3 Coding + 1 Behavioral

The loop spread across two days. Day one was Coding 1 plus the Behavioral round. Day two was Coding 2 plus System Design. Each coding session was 45 minutes on CoderPad.

Coding Round 1: Algorithm with Streaming Follow-ups

Another interval-flavored problem, this time with a real-world framing. "You have a log of user sessions, each with a start and end timestamp. Return the time of peak concurrent users." I walked through sweep line, coded it, and the interviewer moved to follow-ups.

Follow-up 1 was the streaming version, which I handled with a sorted map. Follow-up 2 was "what if sessions can be deleted," which required me to track delta counts at each event timestamp and allow negative contributions. Follow-up 3 was "what if we want the last 5 peak times, not just the current one?" I sketched this with a bounded priority queue keyed on concurrency count.

The signal Uber is clearly looking for is the ability to extend a LeetCode answer toward production constraints: streaming, deletion, ranked history.

Coding Round 2: Depth in Specialization (OOP Design)

This round was billed as Depth in Specialization but in practice it was an OOP design coding session. The prompt was "design a ride dispatch system that matches drivers and riders."

I started with three classes: Driver , Rider , Trip . The MatchingService held indexes of active drivers by region and an in-flight trip table. The core algorithm was nearest-driver matching via a geohash bucket lookup plus a distance filter. I coded the skeleton with proper type hints and wrote method stubs for each operation.

The interviewer's follow-ups were all "how would you extend this." Carpooling changes the Trip abstraction to hold multiple riders; it should be a compositional change, not a breaking one. Surge pricing belongs in a pricing service that the dispatch service calls, not inside the matching algorithm. These are extensibility questions and the right answers are about where concepts live architecturally.

I did not need to write fully working code. The interviewer cared about abstraction boundaries and the naming of the interfaces more than whether my Python compiled.

[[problem/260?company=12|Design Uber / Ride Hailing]]

Coding Round 3: System Design — Uber Eats Home Feed

Problem: Design the backend for the Uber Eats home page feed. This is a personalized feed showing restaurants, promotions, and recommended items.

I opened with clarifying questions: Are we doing personalization or generic? What latency budget? What scale? The interviewer confirmed personalized, p95 under 300ms, roughly 100k QPS at peak.

The skeleton I drew:

Client → API Gateway → Feed Service
Feed Service fans out to Restaurant Service, Promotion Service, Inventory Service
Results aggregate, get scored by a rules-based ranker (not ML), get cached in Redis, returned

The interviewer deep-dived on four things.

Pull vs push. I started with pull but moved to hybrid after he pushed on latency. For highly active users we precompute a partial feed on write (a promotion posted by a restaurant triggers a fanout to nearby users' feed caches). Cold or inactive users fall back to pull.
Cache invalidation. Redis keys are feed snapshots per user, and inventory changes trigger targeted invalidations for users whose feed contains the affected restaurant. We accept bounded staleness of 30 seconds.
Read-path consistency. Even with caching, at the moment of click we re-check restaurant availability. The cost is one fast DB read per tap, which is acceptable.
Multi-region. I drew active-active with per-region writes and async cross-region replication. User state is sticky to home region. Cross-region traffic hits the owning region via the gateway.

No ML in the discussion. The interviewer explicitly said Uber Eats treats this as a data-aggregation-plus-caching problem, not a recommendation ML problem.

[[problem/262?company=12|Design Uber Eats Search/Recommendation]]

Behavioral Round (45 min)

Pretty standard collaboration-and-leadership bucket. The interviewer asked about a difficult teammate experience, a time I owned a project end to end, and one deeper technical dive into my recommendation-system class project. The ML follow-up caught me off guard: offline metric improved, online metric did not, why? I explained population shift and the mismatch between engagement-based online metrics versus precision-at-k offline. That seemed to land.

Result

Offer arrived eight business days after the final round. Level 4 new grad. Base plus stock in the standard Uber new-grad band. I signed two days later.

Tips

Drill Prime Jumps and Minimum Edge Reversals cold before the OA. These are the 2026 recurring Hard problems in the Uber OA pool. If you see either one and do not already know the pattern, you will run out of time. Know the sieve-plus-DP template for Prime Jumps and the two-pass rerooting algorithm for Edge Reversals.
Expect the interval concurrency family to appear more than once. It showed up in my phone screen and again in my Coding Round 1 onsite. Master the batch version, the online version with TreeMap, the deletion variant, and the ranked-top-K-peaks variant.
For the OOP design round, practice naming interfaces, not just writing algorithms. The matching-service prompt has no "correct" algorithmic solution. The signal is the cleanness of your abstraction: what does a `Trip` know, what does a `MatchingService` know, where does pricing live. Practice out loud.
For Uber Eats system design, lead with the data flow, not the diagram. Describe what happens on a single request end to end before you draw any boxes. Uber explicitly does not want you to open with "here is my architecture diagram."
Write behavioral answers with a technical deep-dive escape hatch. The behavioral round interviewer may suddenly ask a real technical question. Your collaboration story about a project that happened to use a recommendation system can pivot into "explain the offline-online metric mismatch." Prepare for that pivot for every major project you list.
Do not let silence accumulate. If you are stuck, say what you are thinking about. The interviewer cannot grade empty airtime and will assume you are frozen. "Let me consider whether a segment tree would help here" is a full sentence that buys you thirty seconds of thinking time.

Best of luck to anyone in the 2026 Uber NG cycle. The loop is demanding but everyone I met was genuinely nice. Ask for the team you actually want when the recruiter asks; they listen more than people expect.