Backend coding interview
Calendar Slot Booking Coding Interview Problem
What this interview round tests
The meeting scheduler is the multi-resource concurrency problem in calendar clothing: booking a slot for three attendees must check and claim time on three calendars at once — all or nothing — while other bookings race to claim overlapping slots on overlapping sets of people. It is the Google-Calendar-style round, and it is one of the cleanest ways an interviewer can test whether you understand deadlock rather than merely recognise the word.
The problem escalates in two steps. Step one is the double-booking race on a single calendar: two meetings that overlap must not both be confirmed for the same person, which needs an atomic check-and-claim, not a check followed by a claim. Step two is where it earns its HARD rating: a booking locking attendees A then B while another locks B then A is a textbook deadlock, and the fix — acquiring locks in one globally stable order — is the exact answer interviewers wait for in every multi-account, multi-resource follow-up.
The scenario
You are handed the booking service of a shared calendar: meetings are requested for a set of attendees and a time range, each attendee’s calendar is checked for conflicts, and the meeting is confirmed on all of them or none. Sequentially, it books meetings fine.
Under the test suite’s concurrent load it breaks both ways: overlapping meetings get confirmed onto the same attendee’s calendar, and bookings with intersecting attendee sets deadlock the system solid. Cancellations also fail to free every attendee’s slot, and partially failed bookings leave some calendars claimed. Your job is to make booking atomic, race-free, and deadlock-free.
What you’ll practice
- Interval conflict detection on a calendar: overlap checks done atomically
- Multi-resource atomicity: a meeting lands on every calendar or on none
- Lock ordering: acquiring per-attendee locks in a stable global order
- The deadlock scenario itself: why A→B and B→A hangs, and the fix
- Rollback: a booking that fails one attendee releases the calendars it touched
- Cancellation that frees the slot on every attendee, immediately
How to approach it
Solve one calendar first: conflict check and slot claim must be a single critical section per attendee, so two overlapping requests serialize and the second sees the first’s claim. Then compose calendars without composing a deadlock: sort the attendee set by a stable key before acquiring locks, so every booking that touches attendees A and B takes them in the same order, and the circular wait becomes structurally impossible.
Atomicity across attendees is the remaining piece: validate every calendar before mutating any, and if a conflict surfaces partway, release exactly what was claimed. Holding all needed locks for the duration of validate-plus-commit is the simple correct shape; the tests hammer intersecting attendee sets from many threads and will find both the race you left in one calendar and the ordering you forgot across several.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
How is this different from the bank transfer deadlock problem?
Bank transfer locks exactly two resources; a meeting locks N attendees, and any two bookings may intersect on any subset. The lock-ordering principle is the same — one global order, always — but applying it to a variable-sized set, with conflict checks and rollback layered on top, is a genuinely harder exercise.
Why not one global lock for the whole calendar system?
It is correct and it serialises every booking in the company through one mutex — bookings touching disjoint attendees have no reason to wait on each other. Per-attendee locks in a stable order keep unrelated meetings concurrent, and articulating that trade-off is part of what the round grades.
How do the tests catch a deadlock?
They fire concurrent bookings with deliberately intersecting attendee sets — the A,B versus B,A pattern and larger cycles — under a timeout. An implementation with inconsistent lock ordering hangs and fails; a correct one completes with every calendar consistent and no double-booked slot.