HackTheRounds Interview Experiences

Uber New Grad VO Interview Experience (2026) - Meeting Concurrency Sweep Line & Online TreeMap, Offer

Uber 2026 NG VO first two coding rounds: sweep line on meeting intervals, streaming online version with TreeMap, follow ups on merged peak intervals, and behavi

By Anonymous ยท 2026-04-15

Background

Passed the Uber OA in late February and got into the new-grad VO loop shortly after. I am wrapping up a CS undergrad at a non-top-tier school and picked up Uber through on-campus recruiting. Two of my friends had interviewed with Uber earlier in the cycle and both reported the same pattern: two back-to-back coding rounds that start easy and then pile on follow-ups until something breaks. I treated the prep as "know one pattern very deeply" rather than "grind 400 LeetCode problems." That worked.

Timeline

Total: about 5 weeks from OA to offer.

Round 1: Coding plus Behavioral (45 min)

Behavioral (10 min)

The interviewer was a friendly Senior SWE on the Rider team. She opened with a 5-minute resume chat and then three behavioral questions in tight succession:

  1. Tell me about a time you helped a teammate unblock on something hard.
  2. What was the most challenging project you have shipped, and what made it hard?
  3. If you joined Uber, what team or area do you see yourself being most useful in, and why?

I went STAR format on all three. For the teammate question I told a story about pair-debugging a race condition in a classmate's senior project. The story landed because I talked about what I learned, not just what I did. The third question is a soft culture-fit check. The mistake is to say "I am open to anything." The right move is to name a specific team, reference an engineering blog post from that team, and connect it to your skills.

Coding (30 min)

Problem: Given a list of meetings as (start, end) pairs, find a time interval during which the maximum number of meetings overlap. Return any one valid interval.

Classic sweep line. I talked through the approach first, then coded.

  1. Expand every meeting into two events: `(start, +1)` and `(end, -1)`.
  2. Sort events. On ties, ends must come before starts so a meeting that ends at time `t` does not count as overlapping with one that starts at `t`.
  3. Walk events, maintain a running count, track the max and the interval where the max was first observed.

Follow-up 1: return all maximal intervals, merging adjacent ones.

This is a scan variant. While walking events, whenever count == best , emit the current interval. After the scan, merge overlapping or adjacent intervals with a standard interval-merge sweep.

Follow-up 2: what if meetings arrive as a stream and you need to maintain the current peak in real time?

This is where the interviewer wanted to hear TreeMap out loud. Maintain an ordered map from timestamp to delta. Every new meeting adds +1 at start and -1 at end . To find the current peak you iterate the map once and maintain a running sum. That is O(n) per query, which the interviewer accepted as a starting point. For sub-linear you need a segment tree with lazy propagation over timestamps, which I sketched but did not implement.

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

Round 2: Coding (45 min)

The second round was the surprise: the coding problem was almost identical to Round 1. Same interval concurrency flavor, same sweep line, same family of follow-ups. The interviewer was a Senior Engineer on the Maps team, and his stated goal was to see how I handled "the online version" from the ground up.

Problem: Same meeting-overlap setup. But this time the follow-ups were baked in from the start. "I want you to design a class that accepts meetings one at a time and can always tell me the current peak concurrency."

I led with the TreeMap structure. In Python that is sortedcontainers.SortedDict . Each timestamp maps to a running delta. addMeeting(s, e) updates the map with +1 at s and -1 at e . A separate currentPeak() method walks the map with a running sum and returns the max.

He pushed: can we avoid a full map walk on every query? I moved to an approach where we maintain the current peak incrementally. When a new meeting (s, e) is added, the intervals affected are those whose sweep count could change. The cleanest structure is to hold the running counts as a sorted sequence of (timestamp, count after) pairs, and on insert, update only the affected range. I sketched this without fully coding it and flagged that for a production system I would consider a segment tree on compressed timestamps.

Follow-up: return all intervals tied at the peak.

I extended the class with a peakIntervals() method that walks the map once and collects all intervals where the running count equals the peak. Then a merge pass stitches adjacent intervals.

He also asked about time complexity tradeoffs. Building once from a batch of n meetings is O(n log n) for the sort plus O(n) for the sweep. Incremental updates with the sorted map are O(log n) per event. A segment tree would give O(log n) for peak query, but the constant overhead is significant.

Round 2 Overall Feel

Harder than Round 1, but the interviewer was patient and nudged me through the online variant. I had about 5 minutes of silence in the middle where I was clearly stuck on the incremental-peak bookkeeping, and he said "step back and talk me through what you are tracking." That reset got me unstuck.

Practice it: [[problem/257?company=12|Counter with TTL]]

Result

Round 3 invite came three days after Round 2. I did that one, and about six business days later the offer landed. Level 4 new grad. Base plus stock in the expected band.

Tips

  1. Master the meeting concurrency family. Uber reuses interval-overlap problems across coding rounds aggressively. Know the batch version, the streaming version with TreeMap or SortedDict, and the merged-all-peaks variant. If you do not know at least two variants cold, you will not survive the follow-ups.
  2. For the online variant, say `TreeMap` early. The interviewer is waiting to hear it. In Python you can use `sortedcontainers.SortedDict`; in Java it is `TreeMap`. Either way, articulate the data structure by name before you start coding.
  3. Think out loud about tie-break ordering. The `(end, -1)` before `(start, +1)` rule at equal timestamps is the single most common bug in this problem family. Even if you get it right naturally, say out loud why. The interviewer is listening for it.
  4. Behavioral answers need a "team you want to join" prepared. The "where do you see yourself at Uber" question is a filter. Name a real team (Maps, Eats, Rider, Driver, Trust and Safety). Reference something specific that team has shipped. Generic "anywhere is fine" answers hurt you.
  5. If you get stuck, ask for a reset. Round 2 had me frozen at minute 30. Saying "let me step back and talk through what state I am tracking" is not weakness. It is exactly what senior engineers do in code review. The interviewer helped me reset and the remaining 15 minutes went clean.
  6. Expect topic overlap across rounds. My Round 1 and Round 2 were both interval-concurrency problems. Uber sometimes batches a single topic family across two interviews to evaluate depth. Do not assume "I just did a sweep line, they will not ask it again."