A scheduler chooses an interval on a real timeline, not a string on a clock. Keep the resource time zone, exact instant, duration, availability version, and hold state explicit. The browser presents candidates; the server grants a short-lived hold and confirms the booking once.
A date picker can work with calendar dates. A scheduler cannot stop there. "9
AM" needs a date, a named time zone, and a rule for the days when clocks move. A free slot can become occupied between rendering and confirmation.The design must keep temporal correctness and booking correctness visible instead of hiding them inside formatting code.
Start with the booking identity
A useful appointment value includes:
- resource or calendar ID;
- exact start instant;
- duration or exact end instant;
- named time zone used for presentation and policy;
- service version or hold token during confirmation.
The named zone matters even when the instant is exact. It explains why an appointment appears at a particular local time and how future recurring rules would be interpreted.
The public interview prompt
Design a reusable scheduler and time-slot picker for appointments across time zones. Explain:
- slot identity, exact instants, resource zones, duration, and form serialization;
- date navigation, grouping, selection, hold, confirmation, expiry, and cancellation;
- versioned availability, stale responses, capacity, conflicts, retries, and idempotency;
- daylight-saving gaps and folds, locale labels, right-to-left layout, and travel;
- keyboard, screen-reader, pointer, touch, zoom, and narrow-screen behavior;
- security, privacy, observability, testing, rollout, and future evolution.
Assume a service can return bounded availability, create a short-lived hold, and confirm it. Version one handles one resource and one attendee, not recurring meetings, group polls, or multi-resource optimization.
What the premium solution covers
The complete solution defines interval identity, Temporal-based conversion boundaries, daylight-saving policies, availability and hold APIs, a reservation state machine, stale guards, idempotent confirmation, focus-stable refreshes, mobile list adaptation, conflict recovery, privacy controls, performance budgets, deterministic time tests, rollout gates, and an interview scoring rubric.
Original media shows the candidate-to-hold-to-confirm lifecycle and a repeated wall-clock hour with two distinct instants. A deterministic lab demonstrates why a selected-looking slot is not booked until the server grants and confirms a hold.