Katkat

Find earliest common meeting slot

UberSoftware Engineer · Onsite

Last updated

This problem tests interval management and the ability to find a common free window across multiple disjoint sets of busy times while respecting daily working constraints.

Problem Statement

You are tasked with scheduling a meeting of duration d (in minutes) for a group of employees. Each employee has a list of busy intervals [start, end) (in minutes from the start of the day) and a working shift defined by [shift_start, shift_end).

Find the earliest time t such that for all employees, the interval [t, t + d) is entirely within their working shift and does not overlap with any of their busy intervals. If no such time exists within a given day range [0, 1440), return -1.

Function Signature

find_earliest_slot(schedules, working_hours, d)

  • schedules: A list of lists, where schedules[i] contains sorted disjoint busy intervals for employee i.
  • working_hours: A list of pairs [start, end] for each employee.
  • d: An integer representing the required meeting duration.

Example

# schedules = [[[100, 200]], [[150, 250]]]
# working_hours = [[0, 500], [0, 500]]
# d = 60
# Output: 0 
# Explanation: The range [0, 60] is free for both. 

Constraints

  • 0 <= d <= 1440
  • schedules are always sorted and non-overlapping.
  • Number of employees N is up to 1000.
  • Total number of busy intervals across all employees is M.

Hints

Hint 1

Normalize the problem by treating the non-working hours (before shift_start and after shift_end) as additional 'busy' intervals for each employee.

Hint 2

Merge all busy intervals for each employee into a single list, then merge all employees' busy intervals into one global set of blocked segments.

Hint 3

Once you have a consolidated list of blocked time ranges, iterate through the gaps between these sorted intervals to find the first one with a width of at least `d`.

Follow-up questions

  • How would you optimize this if N is very large, but the number of busy intervals is sparse?
  • How does the complexity change if you must account for different time zones and daylight savings time transitions?
  • If calendar data updates frequently in real-time, what architectural changes are needed to ensure the 'earliest slot' calculation remains efficient and accurate?