def party_time_blocks(parties, geo):
You are given two lists of records for parties held on one day. Party records hold a party_id, a start timestamp and an end timestamp; geo records hold a party_id with the neighborhood, city and state where that party is held. In one reported version a helper that extracts the hour is provided; this page provides one. Two graded parts; Part 2 is built on Part 1's output.
Part 1 — Party time block per neighborhood. Join the two lists on party_id and return, for each neighborhood, its party time block: the earliest start hour and the latest end hour of any party there, as a dict of integers. Here: party_time_blocks(parties, geo), using the given get_hour(timestamp).
Follow-ups reported after the code: what corner cases your solution might miss, how you would design and test it for production, and how you would design unit tests.
Timestamps vary by version. Reports describe strings like 2am and 10pm that you convert yourself, a provided helper, and timestamp strings you parse. The record shapes and timestamp format on this page are ours; ask which you have.
Input shape varies too. Some versions give the data as several classes (one for a party's time window, one for its location), others as parsed or nested JSON you read with dictionary keys. Either way, the reports consistently build Part 2 from Part 1's per-neighborhood blocks.
Build on Part 1's output. Group all party intervals by city (not neighborhood). Sort intervals by start time, then sweep through them to find gaps between consecutive intervals. The dead-zone for a city is the sum of those gaps. The critical edge case is overlapping intervals: if you have (3,8), (5,7), (10,13), the gap is 10-8=2, not computed naively as two separate gaps. Candidates who passed identified this overlapping case explicitly and explained why their code handles it correctly — typically by tracking the running maximum end time as they sweep rather than blindly subtracting adjacent endpoints.
Standard explanation — no candidate report records what the interviewer accepted here.
Discuss separation of concerns (parsing, joining, computing), edge-case unit tests (overlapping intervals, single party, no parties), and integration tests with sample JSON payloads.
The interviewer pushed on overlapping intervals as the primary corner case. A strong answer identifies that when intervals overlap (e.g., (3,8) and (5,7) both exist in the same city), naive gap calculation between consecutive sorted intervals will produce wrong results. The candidate should explain that the fix is to track the furthest end time seen so far when sweeping, so an interval fully contained inside another does not create a false gap. One candidate passed the given test cases but the interviewer explicitly said the test data was not comprehensive and prompted for harder cases — the expected response was to name overlapping intervals and explain the handling.
Mostly a phone-screen question from early 2025 to early 2026, reported in 12 threads; one of them is an engineering-manager onsite coding round. The screen is 60 minutes with long, multi-class input rather than a LeetCode problem, and candidates say most of the time goes to reading and understanding the statement. Tests are provided and have to pass; one candidate passed every test by reverse-engineering them, left a bug in place and was rejected, and another passed both parts' tests and was still not moved forward. One interviewer said the provided test data was not comprehensive and asked for corner cases. The recruiter's prep material was described as close to the actual question. Versions differ in details: am/pm strings versus a provided helper, and town versus neighborhood naming.
You are given two lists of records for parties held on one day. Party records hold a party_id, a start timestamp and an end timestamp; geo records hold a party_id with the neighborhood, city and state where that party is held. In one reported version a helper that extracts the hour is provided; this page provides one. Two graded parts; Part 2 is built on Part 1's output.
Part 1 — Party time block per neighborhood. Join the two lists on party_id and return, for each neighborhood, its party time block: the earliest start hour and the latest end hour of any party there, as a dict of integers. Here: party_time_blocks(parties, geo), using the given get_hour(timestamp).
Part 2 — Dead-zone hours per city. Built on Part 1's output: group the neighborhood blocks by city and count, for each city, the hours between its blocks that no block covers. Blocks can overlap or sit inside one another: for blocks (3, 8), (5, 7) and (10, 13) the dead zone is 10 - 8 = 2, not (5 - 8) + (10 - 7). Here: dead_zone_hours(parties, geo).
Follow-ups reported after the code: what corner cases your solution might miss, how you would design and test it for production, and how you would design unit tests.
Timestamps vary by version. Reports describe strings like 2am and 10pm that you convert yourself, a provided helper, and timestamp strings you parse. The record shapes and timestamp format on this page are ours; ask which you have.
Input shape varies too. Some versions give the data as several classes (one for a party's time window, one for its location), others as parsed or nested JSON you read with dictionary keys. Either way, the reports consistently build Part 2 from Part 1's per-neighborhood blocks.
Now compute the total dead-zone (quiet) hours per city — time within the overall party window when no party is active.
If this were production code, how would you design the architecture and write unit tests?
What corner cases might your solution miss or handle incorrectly?
| Approach | Notes |
|---|---|
| Flat iteration without pre-building party map | Simpler to code but requires nested loops (O(n*m)) to join party and geo data, versus O(n+m) with a hash map. More prone to bugs and slower. |
| Tracking only min/max per neighborhood (skipping full interval list) | Sufficient for Part 1 but cannot directly support Part 2 gap computation, which requires knowing all individual intervals. |
Common mistakes: Using the wrong grouping key in Part 1 (e.g., grouping by city instead of neighborhood), leading to incorrect output that required debugging under pressure.; Failing to handle overlapping intervals in the dead-zone calculation — computing gaps between every consecutive pair rather than tracking the running maximum end time, which produces wrong results when one interval is contained inside another.; Running out of time before finishing Part 2 or before being able to run test cases, which directly led to rejection even when the algorithmic approach was correct.; Making the tests pass by reverse-engineering them instead of fixing the logic: one candidate passed every test, left a bug in, and was rejected.; Not writing new test cases beyond the provided ones when time allowed — the interviewer noted that the provided test data was not comprehensive.
Interviewer hints: After a candidate passes the provided test cases, the interviewer may explicitly say 'the test data is not comprehensive' and ask for more complex corner cases — the expected answer is overlapping intervals.; One interviewer suggested adding an extra data field to the Part 1 output to make Part 2 easier — candidates with a helpful interviewer received this nudge.; The prep document provided by the recruiter was described as closely matching the actual question — candidates were advised to read it carefully.
What passers do: Candidates who moved on to the onsite report finishing both parts; one, when asked, explained why their code handled overlapping intervals.; Joining the two data sources with a map keyed by party_id, then grouping intervals by neighborhood (Part 1) or city (Part 2), is the approach candidates describe.; Reading the problem statement carefully to get the correct grouping key (neighborhood for Part 1, city for Part 2) was essential — at least one candidate failed Part 1 initially by using the wrong key.
Why people fail: Not finishing Part 2 due to time spent reading the long problem statement; Passing all provided test cases but having an underlying bug found during interviewer review; Writing correct logic but with a wrong output format (int vs. dict structure); Not writing or running any test cases during the session; Getting stuck on timestamp parsing rather than using the provided helper function; Coding without narrating thought process, leaving interviewer unable to assess reasoning
Edge cases probed: Overlapping party intervals: e.g., (3,8),(5,7),(10,13) — gap should be 10−8=2, not computed naively from each pair; One interval fully contained within another (e.g., (5,7) inside (3,8)) — must not double-count or produce negative gaps; Single party in a neighborhood or city (no gaps); Timestamp format variation (12-hour strings vs. ISO strings vs. integers); Using the wrong grouping key (e.g., grouping by city instead of neighborhood for Part 1)
Send them this page. It is free to read, no account needed.
What you just read — canonical solution, follow-up arc, what passing candidates actually did — exists for all 17 Scale AI questions, refreshed monthly from new candidate reports.