← Uber Interview Insights

Uber·Software Engineer·Onsite - Coding / Algorithms·Senior

SeniorPrefer not to say
May 2026

Summary

Uber SWE loop with a phone screen and onsite, both heavily focused on meeting room scheduling problems in different forms. The stateful OOD version was the main event, but they also run the classic LC 252/253 variants as warmups, so you really need all three cold.

Questions Asked (5)

Q1

Design a meeting room booking system: given a fixed list of room IDs, implement bookMeeting(start, end) that finds an available room with no overlapping booking, records it, and returns the room ID (or signals no availability).

System DesignAlgorithms & Data Structures
Author's notes

This is the main course.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., single vs. multiple rooms, concurrency, time granularity) and then propose a data structure that efficiently finds an available room. For each room, maintain a sorted list of bookings (e.g., using a balanced BST or sorted array) to check for overlaps in O(log n) time. If no room is available, return a sentinel value like -1 or null.

Pro tip: Discuss how to handle concurrent booking requests to avoid double-booking, such as using locks or optimistic concurrency control, and mention that in a real system you'd likely use a database with transactions.

1. Clarify Requirements

Ask about constraints: number of rooms, expected booking frequency, time granularity, concurrency needs, and whether bookings can be modified or cancelled.

2. Design Data Structures

For each room, store bookings in a sorted structure (e.g., balanced BST or sorted list) to enable efficient overlap checks. Alternatively, use an interval tree per room.

3. Implement bookMeeting

Iterate through rooms, and for each, check if the new interval overlaps with any existing booking using binary search. If no overlap, insert the booking and return the room ID.

4. Handle Edge Cases

Consider zero-length meetings, back-to-back bookings (end == start), and no available rooms. Return a sentinel value (e.g., -1) when no room is free.

5. Discuss Scalability and Concurrency

Mention how to scale with many rooms/bookings (e.g., sharding by room) and how to handle concurrent requests (e.g., locking, transactions, or optimistic concurrency).

Key Points to Mention

  • Time complexity: O(R log B) per booking, where R is number of rooms and B is bookings per room, using binary search for overlap checks.
  • Space complexity: O(total bookings) to store all bookings.
  • Overlap condition: new.start < existing.end && new.end > existing.start.
  • Data structure choice: sorted list/balanced BST per room for efficient insertion and search.
  • Concurrency control: use locks or database transactions to prevent race conditions.
  • Return value: use -1 or null to indicate no availability, and document it clearly.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q2

Follow-up to the booking system: implement cancelMeeting(roomId, start) to remove a specific booking, and lastNScheduled(n) to return the most recently created N bookings across all rooms.

Algorithms & Data StructuresSystem Design
Author's notes

cancelMeeting was straightforward, just a map remove.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

First, clarify the data structures needed: a map from roomId to a map of start times to booking details for O(1) cancellation, and a global list or deque to track bookings in creation order for lastNScheduled. Then, implement cancelMeeting by removing the entry from the room's map and marking the booking as cancelled in the global list (or removing it if using a doubly-linked list), and implement lastNScheduled by iterating backwards from the most recent bookings, skipping cancelled ones, until N valid bookings are collected.

Pro tip: Discuss the trade-offs between eager and lazy deletion: lazy deletion (marking as cancelled) makes cancellation O(1) but requires filtering in lastNScheduled, while eager deletion (removing from a list) keeps lastNScheduled simple but may make cancellation O(n) unless using a doubly-linked list with node references. Choose based on expected read/write patterns.

1. Clarify requirements and constraints

Ask about expected frequency of cancellations vs. lastNScheduled calls, whether bookings can be cancelled multiple times, and if N can exceed the number of active bookings. This determines the optimal data structure.

2. Design data structures

Propose a hash map (roomId -> map of start -> booking) for O(1) cancellation, and a global doubly-linked list or dynamic array of bookings in creation order. Each booking node should have a reference to its room and start for easy removal.

3. Implement cancelMeeting

Remove the booking from the room's map and from the global list. If using a doubly-linked list, unlink the node in O(1); if using an array, mark as cancelled or swap-remove with index tracking.

4. Implement lastNScheduled

Traverse the global list from the end (most recent) backwards, collecting up to N non-cancelled bookings. If using lazy deletion, skip cancelled entries; if eager, just take the last N.

5. Analyze complexity and edge cases

State time complexities: cancelMeeting O(1) with linked list, lastNScheduled O(N) or O(N + cancellations) with lazy deletion. Discuss edge cases: cancelling non-existent booking, N larger than active bookings, and concurrent modifications.

Key Points to Mention

  • Use a hash map for O(1) lookup and deletion by (roomId, start).
  • Maintain a global order of bookings using a doubly-linked list or dynamic array for lastNScheduled.
  • Consider lazy vs. eager deletion and its impact on performance and complexity.
  • Ensure lastNScheduled returns bookings in reverse chronological order of creation, skipping cancelled ones.
  • Handle edge cases: cancelling a non-existent booking, N > number of active bookings, and duplicate cancellations.
  • Discuss thread-safety if the system is concurrent, e.g., using locks or concurrent data structures.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q3

Concurrency follow-up: how would you handle two clients trying to book the same room at the same time?

System DesignTechnical Trade-offs
Author's notes

Saw this coming but still spent too long on it.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the requirements and constraints (e.g., consistency vs. availability, scale, latency). Then propose a layered solution: database-level locking (optimistic or pessimistic), distributed locking for multi-service architectures, and idempotency to handle retries. Finally, discuss trade-offs and failure scenarios to show depth.

Pro tip: Mention that you'd first try to avoid distributed locks by using a single database with ACID transactions and unique constraints, as this is simpler and more reliable. Only escalate to distributed locks when necessary, and always include a fallback for lock acquisition failures.

1. Clarify requirements and constraints

Ask about consistency needs, expected scale, latency requirements, and whether the system is single-node or distributed. This ensures your solution fits the context.

2. Propose database-level concurrency control

Suggest using transactions with optimistic locking (version column) or pessimistic locking (SELECT FOR UPDATE) to prevent double booking. Highlight that this works well for single-database setups.

3. Introduce distributed locking if needed

For microservices or multi-database scenarios, propose a distributed lock (e.g., Redis Redlock, ZooKeeper, etcd) with a lease and fencing token to ensure only one client proceeds.

4. Add idempotency and retry handling

Ensure booking requests are idempotent using a unique request ID, so retries don't cause double bookings. Discuss how to handle lock timeouts and client retries gracefully.

5. Discuss trade-offs and failure modes

Compare approaches: optimistic vs. pessimistic locking, database vs. distributed locks, and their impact on latency, throughput, and complexity. Mention how to handle lock failures (e.g., return a conflict error).

Key Points to Mention

  • Optimistic locking with version numbers or timestamps
  • Pessimistic locking with SELECT FOR UPDATE
  • Distributed locks (Redis, ZooKeeper) and their pitfalls (e.g., clock drift, lock expiration)
  • Idempotency keys to handle retries safely
  • Trade-offs: consistency vs. availability, latency vs. correctness
  • Failure scenarios: lock acquisition failure, network partitions, and how to recover

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q4

Given a list of meeting intervals, determine whether a single person can attend all of them with no overlaps (touching endpoints are allowed).

Algorithms & Data Structures
Author's notes

Phone screen opener.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify that 'touching endpoints are allowed' means intervals like [1,2] and [2,3] do not conflict. Then sort the intervals by start time and check if any interval's start is strictly less than the previous interval's end. If so, return false; otherwise, return true.

Pro tip: Mention that this is equivalent to detecting overlapping intervals and that sorting is the key to an O(n log n) solution. Also, discuss edge cases like empty input, single interval, and intervals with zero duration.

1. Clarify the problem

Confirm that intervals are closed and touching endpoints are allowed. Ask about input format and constraints.

2. Choose the algorithm

Sort intervals by start time. Then iterate through them, comparing each start with the previous end.

3. Implement the check

If current start < previous end, return false. Otherwise, update previous end to max(previous end, current end) and continue.

4. Analyze complexity

Time complexity is O(n log n) due to sorting, space is O(1) if sorting in place or O(n) if creating a new list.

5. Test with examples

Walk through edge cases: empty list, single interval, touching intervals, overlapping intervals, and intervals with same start/end.

Key Points to Mention

  • Sorting by start time is crucial for efficient overlap detection.
  • Touching endpoints (e.g., [1,2] and [2,3]) are allowed, so use strict inequality (<) when comparing start and previous end.
  • Time complexity: O(n log n) due to sorting; space complexity: O(1) or O(n) depending on implementation.
  • Edge cases: empty input, single interval, intervals with zero duration, and intervals that are nested.
  • Alternative approach: merge intervals and check if any merge occurs, but sorting is simpler.
  • If the input is already sorted, the check can be done in O(n) time.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

Q5

Given a list of meeting intervals, find the minimum number of rooms required to schedule all of them without conflict.

Algorithms & Data Structures
Author's notes

Natural escalation from the previous one.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Clarify the problem constraints (e.g., intervals may be unsorted, inclusive/exclusive endpoints) and then present the sweep line algorithm: separate start and end times, sort them, and use a two-pointer technique to count concurrent meetings. Alternatively, use a min-heap to track end times while iterating through sorted intervals. Analyze time and space complexity, and discuss edge cases.

Pro tip: Mention that the minimum number of rooms equals the maximum number of overlapping intervals at any point, and that this can be computed in O(n log n) time. Also, proactively discuss how to handle edge cases like zero-length intervals or back-to-back meetings.

1. Clarify the problem

Ask about input format, interval inclusivity, whether intervals are sorted, and if zero-length intervals are allowed. Confirm that the goal is to find the minimum number of rooms to avoid any overlap.

2. Choose an approach

Decide between the sweep line (two sorted arrays) or min-heap method. Explain that both are O(n log n) time and O(n) space, but the sweep line is simpler to implement.

3. Walk through the algorithm

For sweep line: extract start and end times, sort both arrays, then use two pointers to count active meetings, updating the maximum. For min-heap: sort intervals by start time, push end times into a min-heap, and pop when a meeting ends before the next starts.

4. Analyze complexity and edge cases

State time complexity O(n log n) due to sorting, space O(n). Discuss edge cases: empty input, single interval, all overlapping, back-to-back meetings (end == start), and unsorted input.

5. Test with examples

Walk through a small example like [[0,30],[5,10],[15,20]] to show the algorithm yields 2 rooms. Optionally, mention that the problem is equivalent to finding the maximum number of overlapping intervals.

Key Points to Mention

  • Sweep line algorithm with separate sorted start and end times
  • Min-heap approach to track end times of ongoing meetings
  • Time complexity O(n log n) and space complexity O(n)
  • The minimum rooms equals the maximum number of concurrent meetings
  • Handling edge cases: empty input, zero-length intervals, back-to-back meetings
  • Comparison of approaches and trade-offs (e.g., simplicity vs. memory)

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.