Build a Java restaurant table booking service that prevents double bookings

In a timed live coding session you build a working restaurant booking system in Java. You share your screen from your own IDE and you may use an AI coding assistant, but you are accountable for every line that ends up in the program. The interviewer is looking for working code produced quickly, with you clearly in control of the design and of whatever the assistant generates. No formal specification is given. For practice, start from this baseline and confirm it out loud before writing code: - A restaurant has a fixed set of tables, each with an identifier and a seat capacity. - A guest asks for a party size and a start time; a booking holds one table for a fixed sitting length. - Two bookings must never hold the same table at overlapping times. - A guest can cancel a booking by its id, and staff can list a restaurant's bookings for a given day. - State lives in memory; no database or web layer is needed unless the interviewer asks for one. ### Constraints and Clarifications - Java, compiled and run in your own environment during the session. - An AI assistant is allowed; expect to explain and defend any generated code. - Speed matters: a correct, running core beats a broad design that does not run. - Sitting length, opening hours and whether tables can be combined are not specified; ask rather than assume silently. ### Clarifying Questions - How long does a sitting last, and is it the same for every party size? - Can two smaller tables be joined for a large party, or must one table seat the whole group? - Are start times free-form, or restricted to opening hours and fixed slot boundaries? - Does the system choose the table, or does the guest pick one? - Is concurrent access in scope, for example several hosts or a public API booking at the same moment? - Is a waitlist or walk-in flow expected? ### Part 1 — Model the domain and the public API Define the types and the operations a caller uses: registering a restaurant with its tables, checking availability, booking, cancelling and listing. Decide what each operation returns, and what it throws when a request cannot be met. ```hint Keep the core small Name the few entities you actually need and the invariant each one protects before asking an assistant to generate anything. ``` #### What This Part Should Cover - Entities with clear ownership of mutable state, and immutable value types where they fit - An API whose failure cases (unknown restaurant, invalid party size, nothing free) are explicit - How time is represented and how a sitting's end is derived ### Part 2 — Allocate tables without double booking Implement booking so that a request either gets a suitable free table or a clear refusal. Explain how you decide whether a table is free for the requested interval, which table you pick when several fit, and what changes if two hosts can book at the same moment. ```hint Think in intervals Two reservations on one table clash under a precise condition on their start and end times; get that condition right first, including sittings that touch end to start. ``` #### What This Part Should Cover - A correct overlap test with a stated convention for back-to-back sittings - A deterministic table-choice rule and its effect on remaining capacity - The cost of an availability check as bookings accumulate - Thread safety for concurrent booking attempts ### Part 3 — Prove it works, then extend it Show how you would convince the interviewer the code is correct within the session, including how you check code the assistant wrote. Then describe how the design changes if bookings must survive a restart and be served to many users at once. ```hint Attack your own code List the inputs most likely to break a booking system and decide which deserve a test before you add any new feature. ``` #### What This Part Should Cover - Targeted tests for overlaps, boundaries, cancellation and invalid input - A concrete routine for reviewing and correcting assistant-generated code - A path to persistence in which the database itself enforces the no-overlap rule ### What a Strong Answer Covers - Runnable code early, then features added in small verified steps - Correct interval logic and an explicit table-allocation policy - Clear handling of invalid input and of requests that cannot be served - Concurrency safety proportional to the scope agreed with the interviewer - Visible ownership of the assistant's output: reading, testing and fixing it rather than pasting it ### Follow-up Questions - A party of eight arrives and only two adjacent four-seat tables are free. How would you support joining tables? - How would you add per-restaurant opening hours and a cleaning buffer between sittings? - Two requests for the last free table reach different servers at the same instant. What guarantees that only one succeeds? - How would you add a waitlist that offers a freed table to the next suitable party after a cancellation?