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

SeniorPrefer not to say

Jul 2026

Summary

Uber system design round for a software engineering role, focused entirely on a distributed data pipeline problem. The question was dense and technical, covering a lot of ground in one shot.

Questions Asked (1)

You have a massive log of meeting events with fields like user ID, start/end time, room ID, and office ID. Design a MapReduce or Spark job to compute, for each rolling 15-minute window: the number of concurrent meetings per office, and which rooms exceeded 80% utilization. Walk through your map keys and values, how you handle interval-to-window transformation, shuffle and partition strategy to avoid skew, handling of late or duplicate events, and how you'd validate the output at scale.

System DesignTechnical Trade-offsData Modeling

Author's notes

This one hit me like a wall.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data schema and window semantics, then outline an end-to-end pipeline: interval-to-window expansion, aggregation, and validation. Emphasize partitioning and skew mitigation, and discuss handling of late/duplicate events with watermarks and deduplication.

Pro tip: Mention that you would first compute per-room utilization and then aggregate to office level to avoid double-counting overlapping meetings in the same room. Also, use a two-phase aggregation with a salt key to handle hot partitions.

1. Clarify requirements and data model

Confirm the definition of 'rolling 15-minute window' (e.g., sliding windows every 15 minutes or tumbling windows) and the exact utilization formula. Identify key fields and potential data quality issues.

2. Design interval-to-window transformation

For each meeting, generate all overlapping 15-minute windows by iterating from floor(start/15) to floor(end/15). Emit (window_start, office_id, room_id) as key and a count of 1 as value, ensuring each meeting contributes to each window it overlaps.

3. Define map keys/values and aggregation logic

Map: key = (window_start, office_id, room_id), value = 1. Reduce: sum values to get concurrent meetings per room per window. Then compute room utilization as concurrent_meetings / room_capacity; flag rooms exceeding 80%. Finally, aggregate to office level by summing concurrent meetings per office.

4. Handle shuffle, partitioning, and skew

Partition by window_start and office_id to distribute load. Use salting for hot keys (e.g., popular offices) to avoid skew. Consider using a combiner to pre-aggregate before shuffle.

5. Address late/duplicate events and validation

Use watermarks to handle late events and deduplicate by event ID or (user_id, start_time, room_id). Validate output by comparing with a batch job on a sample, checking invariants (e.g., sum of room meetings equals office meetings), and monitoring job metrics.

Key Points to Mention

Window semantics: sliding vs tumbling, and how to handle boundary conditions (inclusive/exclusive).
Interval-to-window expansion: generating multiple windows per meeting and ensuring correct overlap.
Partitioning strategy: partition by window_start and office_id, and use salting to mitigate skew.
Utilization calculation: per-room utilization and aggregation to office level without double-counting.
Late/duplicate handling: watermarks, deduplication keys, and idempotent processing.
Validation: use of invariants, sampling, and comparison with batch processing for correctness.

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