Debug a Seeded-Bug Python Ticket Booking System With an AI Assistant

In a technical screen, the usual algorithm question is replaced by an AI-assisted debugging exercise. You receive a small Python codebase, a little over a hundred lines, that simulates a ticket booking system. It already contains several bugs (candidates report about five), and your task is to find and fix them while talking the interviewer through your work. You may use an AI coding assistant throughout. Candidates report that fixing every bug is not required to pass: the interviewer also weighs how you communicate and how you use the AI tool. The report does not reproduce the code or the bugs, so this version asks you to demonstrate the method you would apply to such a codebase: how you get oriented, which booking-specific failures you look for, how you prove and fix each one, and how you work with the assistant and the interviewer. ### Clarifying Questions - Does the codebase come with tests, a main script or sample inputs, and may I add my own tests? - What are the intended booking rules: can a seat be booked twice, can bookings exceed a show's capacity, what does a cancellation release, and do holds expire? - Is the system meant to be used from several threads at once, or is it single-threaded? - Which AI assistant is available, and may it see the whole codebase? - Should I limit myself to fixing bugs, or may I refactor? ### Part 1 — Get oriented and make the bugs visible You have just been handed the code. Describe what you do before changing anything, which rules of a booking system you write down and check, and how you turn a suspected bug into a reproducible failure. ```hint Write the rules before reading the code List what must always be true of seats, bookings and cancellations, then look for every code path that could break each rule. ``` #### What This Part Should Cover - A reading order for an unfamiliar codebase: how state is stored, what changes it, and the entry point - Booking-system invariants written as executable checks - A failing test or minimal reproduction for each suspect before any fix ### Part 2 — Find and fix the bugs Walk through the kinds of defects you would hunt for in code like this, how you confirm each one, and how you fix it with a minimal change. Explain how you know each fix is correct and has not broken anything else, and what you do when time is running out with suspects left. ```hint Follow a seat through its life Trace one seat from available to held to booked to cancelled, and look at every line where its state or a counter changes. ``` #### What This Part Should Cover - Defect classes typical of booking logic: capacity boundaries, state not restored on failure or cancellation, duplicate booking, shared mutable state, identifiers, time and money - Minimal, targeted fixes, each pinned by a regression test - Prioritizing by impact and reporting what remains unconfirmed ### Part 3 — Work with the AI assistant and the interviewer Show how you use the AI assistant during the session: what you ask it, how you check what it tells you, and how you keep the interviewer informed of your reasoning. ```hint Trust, but reproduce Ask what evidence you need before accepting a bug the assistant reports or a patch it proposes. ``` #### What This Part Should Cover - Narrow prompts that ask for hypotheses and tests rather than rewrites - Verifying every claim and patch from the assistant with a test or a trace - Thinking aloud, flagging uncertainty and summarizing progress for the interviewer ### What a Strong Answer Covers - Systematic orientation and explicit booking invariants before any edits - Each bug reproduced, explained, fixed minimally and pinned by a test - Disciplined use of the AI assistant: scoped, verified and explained - Clear communication and sensible time management when not every bug is found ### Follow-up Questions - Two users try to book the last seat at the same moment. How would you make booking safe under concurrency? - The assistant proposes rewriting the whole booking module to fix one bug. How do you respond? - How would you make sure the bugs you fixed stay fixed? - A fix for one bug makes another existing test fail. How do you decide which behaviour is correct?