A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.
How to answer
The merge is textbook sort-and-sweep; the test is converting first, and knowing where conversion goes wrong. Say early: “Everything becomes UTC first; the merge never sees a local time.”
- Ask what a window looks like. Local times with an IANA zone like
America/Chicago, a fixed offset, or an abbreviation? “CST” is also China Standard Time, so reject abbreviations or map them with the customer’s sign-off. Ask whether touching windows merge. - Normalize with real zone rules. Attach the zone with Python’s
zoneinfoand convert to UTC. A spring-forward gap time doesn’t exist andzoneinfowon’t raise, so convert back and check the wall time survived. A time in the fall-back hour happens twice, andfold(its PEP) picks which. Reject, or widen: the earlier instant for a start, the later for an end. In the fall-back hour that isfold=0for a start andfold=1for an end; in the gap it flips. Compute both, take the min or max rather than trust the flag, and log it. - Validate after converting. An end at or before its start is an error. A window crossing midnight carries its end date.
- Sort and sweep. Sort by UTC start. If the next start is before the current end (or equal, if touching windows merge), set the current end to the later of the two ends: a short window can sit inside a long one, so test that case by name. Otherwise start a new window. Keep each merged window’s source ids.
- Render at the edge. Store UTC; convert to a reader’s zone only for display. Recurring windows are the exception: store the rule in local time with its zone, expand each occurrence locally, then convert. Weekly local is not every 168 hours in UTC.
The trap is merging naive local times, which passes every test written in one zone.
Follow-ups
What the interviewer may ask next, once your first answer is on the table.
- One site reports its zone as “CST”. What do you do with that?
- A window starts at a local time that does not exist on the night clocks spring forward. What does your code do?
- Two windows touch, one ending exactly when the next starts. Are they one window or two?
- The operations team wants the merged schedule in each site’s local time. How do you render it?
- Windows repeat every week. What changes when a repeat crosses a daylight saving change?
Where answers go wrong
- Sorting and merging on local wall-clock times, so windows that overlap in real time look disjoint.
- Converting with the zone’s standard-time offset all year, which is wrong for months at a time in any zone with daylight saving.
- Letting the library resolve a nonexistent or repeated local time silently, with nothing logged or rejected.
- Merging correctly but dropping which source windows formed each merged one, so nobody can trace a result back to a site.
Answer this in two minutes
Write the answer you would say out loud. The clock starts with your first word.
Model answer
“Before I write anything: what does a row look like, and do touching windows merge? You said each site sends an id, a zone name and local start and end times, and that a window ending at 02:00 and one starting at 02:00 are one outage to the operations team.