HackTheRounds Interview Experiences

Uber SDE New Grad Interview Experience (2026) - Monotonic Deque, Union Find & Uber Eats HLD, Offer

Uber 2026 NG five stage loop: longest subarray with monotonic deques, carpool union find, train scheduler LLD, Uber Eats home feed HLD with geohash caching, and

By Anonymous ยท 2026-03-22

Background

Signed my Uber SDE New Grad offer last Friday after a five-stage loop that spanned just under six weeks. I am graduating this spring from a mid-ranked CS program, and Uber was my top target because the infra scale is genuinely interesting and the interview style leans more on depth of fundamentals than on obscure algorithm tricks. The loop layout matched what my upperclassmen had described almost exactly: a screening coding round, a DSA round heavy on union find, a low-level OOP design, a high-level distributed system design, and a manager behavioral chat at the end.

Timeline

Round 0: Screening Coding (45 min)

Problem: Given an integer array and a number limit , find the length of the longest subarray where any two elements differ by at most limit . The problem is effectively LeetCode 1438.

The interviewer explicitly wanted to see me walk up the optimization ladder rather than jump to the best answer. I started with the quadratic brute force, extending a window while running min and max stayed within limit , and called out why that fails at n around 10^5 .

The clean answer uses two monotonic deques, one tracking the window minimum and one tracking the window maximum. When the gap between the head of the max deque and the head of the min deque exceeds limit , the left pointer advances and stale entries are popped. That is O(n) with O(n) worst-case memory. He asked me to defend why the deques stay ordered, and I walked him through the invariant: max deque non-increasing, min deque non-decreasing, tails evicted on violation.

Round 1: DSA with Union Find (45 min)

Problem: A carpool log arrives as a stream of records, each pairing two users who shared a ride at some timestamp. You need to maintain, across the stream, the current number of distinct ride groups and report at which timestamp all pairs finally merge into a single connected group.

My first instinct was BFS on an implicit graph with a connected-components recompute per edge, and I called that out as too slow. The right structure is disjoint set union with path compression and union by rank. Each user starts as its own parent, each edge attempts a union, and I maintain a counter of the current number of roots. When that counter drops to one, I record the timestamp.

The interviewer wanted the structure from scratch, not a library call. I coded find with recursive path compression, union with rank-based merging, and a size map for a likely follow-up. Amortized cost is effectively constant, controlled by the inverse Ackermann function.

The follow-up pushed on offline versus online: how would I answer "were A and B in the same group at time T" for arbitrary queries. I sketched offline union find with rollback, which sorts events by time and rolls the structure backward as needed. I described the shape rather than coding it.

Round 2: Low-Level System Design (45 min)

Problem: Design a train and platform management system for a single station. It needs to support train arrival scheduling, platform assignment, and time-range queries like "which platforms are occupied between 14:00 and 15:30." You must produce runnable code, not just a diagram.

I decomposed into four classes. Train held id, arrival, departure, and a reference to its platform. Platform held id, capacity (usually one), and a time-ordered list of occupancy windows. Scheduler matched arriving trains to free platforms via a min heap keyed on next free time per platform, keeping assignment logarithmic. StationManager was the facade accepting arrivals, delegating to the scheduler, and serving queries.

The time-range query drew the hardest pressure. Linear scan per platform is acceptable at single-station scale, but he pushed for sub-linear, so I sketched an interval tree per platform with range queries fanning out across platforms.

The extensibility follow-ups were about where logic lives. Two-train capacity changes the scheduler check from boolean to a count-below-capacity check. Rescheduling means occupancy windows become soft and need tombstone markers. The signal is that extensibility is a responsibility-placement question, not a rewrite.

Practice it: [[problem/211?company=12|Banking System Operations]]

Round 3: High-Level System Design (45 min)

Problem: Design the Uber Eats home feed. The feed shows personalized restaurant and dish recommendations, and the home page needs to load fast under heavy mobile traffic.

I opened with clarifying questions. How personalized, p95 latency target, expected peak QPS. The interviewer committed to personalized feed, p95 under 300 ms, and traffic spikes up to 100k QPS during dinner hours.

I sketched the layered flow. Client hits an API gateway routing to a feed service. The feed service fans out in parallel to restaurant, promotions, and inventory services. The restaurant service uses a geospatial index ( GeoHash buckets) to find nearby open restaurants within the delivery radius. Promotions read from a pre-computed Redis cache keyed by region. Inventory is the authoritative availability source.

Ranking was rule-based rather than ML, which the interviewer confirmed. Weights blended per-user signals (order history, cuisine preferences) with business signals (margin, active promotions, delivery time). Results aggregate, get scored, and land in Redis with a 30-second TTL and targeted invalidation on inventory changes.

Database choice was hybrid: Postgres for restaurant metadata, in-memory geospatial index for read speed, key-value store sharded by user id for order history. I also walked through multi-region active-active with sticky home region and cross-region reads through the gateway. The cold-user follow-up was a popularity-based fallback using aggregate regional trending data, no ML dependency.

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

Round 4: Manager Behavioral (45 min)

The most relaxed of the five. The interviewer pulled two projects from my resume and asked about ownership, code review habits, and how I communicate ambiguity upward. The hardest question was "tell me about a time you shipped something with measurable business impact." I picked a batch-job optimization that went from 4 hours to 35 minutes and tied it to the team's release cadence.

The last 10 minutes were my questions: team structure, on-call, and the first 90 days. The signal is whether you treat the team choice as an informed mutual decision.

Result

Offer came six business days after Round 4, at L4 new grad, base plus stock in the standard Uber band. I signed three days later.

Tips

  1. Walk up the optimization ladder out loud in Round 0. The screening round is not graded on whether you jump to the sliding window plus monotonic deque immediately. It is graded on whether you can articulate the brute force, call out the complexity problem, and iterate up cleanly. Silent jumps to the optimal answer cost you signal.
  2. Implement union find from scratch at least three times before the DSA round. Uber will ask you to code `find` and `union` by hand with path compression and rank-based merging. Library calls are not accepted. If you cannot write it in under five minutes without looking, drill it.
  3. In the LLD round, lead with class responsibilities, not with code. Before writing any code, say out loud what each class owns and why. For the train scheduler I said "Scheduler is responsible for assignment, Platform owns its own occupancy, Manager is the facade." That framing kept me from bleeding scheduler logic into the platform class.
  4. For the Uber Eats HLD, never open with a ranking ML model. Uber treats the home feed as a data-aggregation plus caching problem, not a recommendation ML problem. If you lead with model training, you will burn the round. Lead with the fan-out, the geospatial index, and the cache.
  5. Prep a measurable business impact story for the manager round. "I made the code cleaner" is not enough. A specific latency drop, a specific cost saving, or a specific on-call reduction lands. The number is the anchor the interviewer remembers.
  6. Have three thoughtful questions ready for the manager. Ask about team structure, on-call rotation, and the onboarding ramp. Asking no questions or asking generic ones ("what is the culture like") signals that you are not thinking about the mutual fit. Uber pays attention to this more than most loops.