# Design Interviewer Availability and Atomic Booking APIs Design a relational schema and three APIs for interview scheduling: interviewers mark available time slots, candidates list available slots in the next 14 days, and a candidate books a slot while the system assigns one available interviewer. Prevent double booking under concurrent requests and explain time-zone, idempotency, and cancellation behavior. ### Constraints & Assumptions - Availability is represented as discrete bookable slots for the core design. - One interviewer can hold at most one interview in a slot. - One candidate can hold at most one interview in a slot. - Listing may be slightly stale, but booking must revalidate availability transactionally. ### Clarifying Questions to Ask - What slot duration and time-zone convention are used? - Can an interviewer retract availability after a booking exists? - Does a booking require interviewers with particular skills or panel membership? ### Part 1 — Schema Define Interviewers, Availability, and Interviews tables, including primary keys, foreign keys, time fields, statuses, and uniqueness constraints. #### What This Part Should Cover - UTC storage, stable slot identity, and database constraints that encode no-double-booking invariants. - A distinction between offered availability and a confirmed interview. ### Part 2 — Mark and List Slots Specify `MarkSlots` and `GetAvailableSlots` behavior for idempotent writes and a 14-day query. #### What This Part Should Cover - Validation, deduplication, range filtering, and capacity-aware availability results. ### Part 3 — Book an Interview Specify `BookInterview`, including concurrent assignment, retries, and an idempotent response. #### What This Part Should Cover - A transaction that locks or conditionally claims one eligible slot and inserts the interview once. - Conflict handling that returns a retryable availability result without partial state. ```hint Put the invariant in the database A unique active booking for an interviewer-slot pair protects correctness even when two application workers race. ``` ```hint Treat listing as a hint The booking transaction must check the current authoritative row because a previously listed slot may already be gone. ``` ### What a Strong Answer Covers - Coherent schema, API contracts, atomic assignment, UTC handling, idempotency, cancellation, and indexes for the 14-day query. ### Follow-up Questions - How would you schedule a panel requiring three interviewers with different skills? - How would recurring availability and daylight-saving transitions change the model?