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.

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.

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.

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