Simulate Roller Coaster Boarding: Runs, Total Time and Seat Utilization

Write a program that plans how a queue of waiting groups rides a roller coaster and reports how the session went. The original prompt was long and was not fully recalled; the facts below are the ones reported, and the riding rules are left for you to settle with the interviewer. In the reported round an AI coding assistant was allowed, and the bar was code that runs and passes the interviewer's tests, as if the task had come up at work. You are given: - the coaster: the number of rows and the number of seats in each row; - how long one run of the coaster takes; - how long the break between two consecutive runs takes, during which riders get off and the next riders get on; - the waiting queue: the number of groups and the size of each group, in queue order; - rules that every group must satisfy when it rides (only partly recalled). Compute: - how many runs are needed until every group has ridden; - the total time this takes; - the seat utilization, and similar summary statistics. A possible interface (adjust it as you clarify): ```python def simulate(rows: int, seats_per_row: int, ride_time: int, break_time: int, groups: list[int]) -> dict: """Returns {"runs": ..., "total_time": ..., "utilization": ...}.""" ``` ### Clarifying Questions - Must every member of a group ride in the same run? Must they sit in the same row, and if so, what happens to a group larger than a row? - If the group at the front of the queue does not fit in the seats that are left, does the coaster leave with empty seats, or may a smaller group behind it board first? - Does the coaster leave as soon as the next group cannot board, or can it wait? - What should happen to a group that can never fit, for example one larger than the whole train? - Does the total time count only the runs and the breaks between them, or also the first boarding and the last unloading? - Do the empty seats on the last run, which may leave partly filled because the queue ran out, count against utilization? ### Part 1 — Board the groups and count the runs Implement the boarding of one run under the rules you agreed on, and repeat it until the queue is empty. Return the number of runs. ```hint Separate the rule from the loop Write one function that decides whether the next group can board a partly filled train and where it sits. The loop that fills runs until the queue is empty should not need to change when that rule does. ``` #### What This Part Should Cover - The agreed rules, stated before coding and reflected in the code - A loop that is guaranteed to finish, including when some group can never board - How seats are tracked within one run (one pool of seats, or free seats per row) ### Part 2 — Total time Compute the total time needed to carry every group, from the run time and the break time. ```hint Draw the timeline Sketch the timeline for one, two and three runs and count the breaks in each. Then check which of them your agreed definition of total time includes. ``` #### What This Part Should Cover - A correct count of runs and breaks, with no off-by-one error - The edge cases of an empty queue and a single run - Consistent time units ### Part 3 — Seat utilization and other statistics Report the seat utilization and any other statistics that describe the session. ```hint Fix the denominator first Utilization is a ratio. Decide which seats count as offered, in particular the empty seats on a last run that leaves partly filled. ``` #### What This Part Should Cover - A precise definition of utilization and why it was chosen - Other useful statistics (riders per run, empty seats) computed in the same pass - Tests or sanity checks on the results ### What a Strong Answer Covers - Recognizes that the rules are underspecified and pins them down before writing code - A simulation that is correct, always terminates, and is easy to change when a rule changes - Exact formulas for runs, total time and utilization, checked on a small hand-worked example - Input validation and edge cases: an empty queue, oversized groups, groups of size zero - Tests that would catch mistakes in code produced with an AI assistant, and a review of that code rather than blind acceptance ### Follow-up Questions - A group larger than the train (or larger than a row, if a group must share a row) is in the queue. What should the simulator do? - If the front group does not fit, may smaller groups behind it board first? How does that change the number of runs, and what fairness problem does it create? - Groups now arrive over time instead of all waiting at the start. What changes in the simulation, and how would you report each group's wait? - The interviewer changes the group rule midway. Which parts of your code change, and which tests would catch a mistake?