Uber·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Apr 2026

Summary

Uber system design round for a software engineering role. The question was a meeting room reservation system, which sounds straightforward until you actually have to think through concurrency and cancellations under pressure.

Questions Asked (1)

Design a meeting room reservation system with a fixed set of rooms. Implement a reserve(start, end) method that returns a unique meeting ID if a room is free for the entire interval, or signals failure if none are available. Walk through your data structures, discuss thread-safety, and explain how you'd extend the API to support cancellations and lookups.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I started with a per-room sorted list of intervals and binary search to find gaps, which felt reasonable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a data structure that efficiently finds an available room for the given interval. Discuss thread-safety mechanisms and how to extend the API for cancellations and lookups, considering trade-offs between simplicity and scalability.

Pro tip: Mention that using a priority queue of room availability can optimize for the earliest available room, but a simple linear scan over rooms with interval trees per room is often sufficient for a fixed small set of rooms. Also, highlight the importance of idempotent cancellation and handling edge cases like zero-length meetings.

1. Clarify Requirements and Assumptions

Ask about the number of rooms, expected load, concurrency requirements, and whether intervals are inclusive/exclusive. Confirm that meeting IDs must be unique and that failure should be signaled clearly.

2. Design Data Structures

Propose storing per-room schedules as interval trees or sorted lists of intervals. For a fixed small number of rooms, a simple list per room with linear scan may suffice. Consider using a global lock or per-room locks for thread-safety.

3. Implement reserve(start, end)

Iterate over rooms, check if the interval overlaps with any existing booking. If a free room is found, insert the interval, generate a unique ID (e.g., UUID or atomic counter), and return it. Otherwise, return null or throw an exception.

4. Address Thread-Safety

Discuss using synchronized blocks, ReentrantLock, or read-write locks to protect shared data. For higher concurrency, consider lock striping per room or optimistic concurrency with retries.

5. Extend API for Cancellations and Lookups

Add cancel(meetingId) that removes the interval and lookup(meetingId) that returns details. Maintain a map from meeting ID to room and interval for O(1) access. Ensure cancellation is idempotent and thread-safe.

Key Points to Mention

Interval overlap detection: use condition start < existing.end && end > existing.start for half-open intervals.
Data structure choices: interval tree vs. sorted list vs. simple list, and their time complexities.
Thread-safety: locks, concurrent data structures, and potential deadlocks.
Unique ID generation: UUID, atomic counter, or database sequence.
Cancellation: need to remove interval and update map; consider soft delete vs. hard delete.
Lookup: map from meeting ID to room and interval for O(1) retrieval.
Scalability: if rooms increase, consider sharding or distributed locks.

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