Requirements checklist

Ask, one at a time, absorbing each answer:

□ request types                hall call (floor, direction) vs car call
                               (car, destination) — say the two-type sentence
□ cars and floors              calibrates the engineering (4 x 20: scans are fine)
□ optimization metric          PROPOSE one: average wait + fairness constraint
□ hardware boundary            events in, commands out; no physics, no door timing
□ time model                   discrete events, fake the clock — testability
□ out of scope                 capacity, overload, failures — draw it out loud

The core model

Car (x4, independent)   state machine: IDLE / MOVING_UP / MOVING_DOWN / DOORS_OPEN
                        stopsAbove (asc) + stopsBelow (desc) — the sweep
                        addStop(): placement relative to current floor
                        nextStop(): first() of the committed direction's set
Events -> transitions   arrived(): stop here? open doors : keep moving
                        doorsClosed(): continue sweep, reverse, or idle
Dispatcher              owns hall-call assignment; car calls skip it
DispatchStrategy (seam) choose(call, cars) — nearest-in-direction v1,
                        3-pass: sweeping toward it > idle > anyone

Invariants: every hall call assigned to exactly one in-service car · stop sets consistent with car position · only events mutate state, commands are outputs · dispatcher decides, cars move.

Principles demonstrated (name them at the decision)

• Cohesion / SRP — one state machine per car; each machine owns one car's motion and nothing else.
• Separation of decision from action — assignment (dispatcher) vs movement (car); policy changes never touch car code.
• Open/closed — dispatch policy behind a strategy seam, justified by change-anticipation: scheduling is tuned forever.
• Model the domain's real types — hall calls and car calls kept distinct because they carry different information with different owners.

Complexity facts

assignment       O(cars) scan per hall call — 4 cars; say plainly that
                 no index pays for itself here
stop insertion   O(log s), s <= floors; nextStop() O(1) via ordered sets
transitions      O(1) per event
FIFO pathology   arrival-order service ping-pongs the shaft; the sweep
                 serves in shaft order — that's the whole argument

What earns points, per report dimension

• Requirements & interface — you surfaced the two request types unprompted, proposed the optimization metric, and pinned the event/command hardware boundary.
• Core design & invariants — independent per-car machines, dispatcher-owned assignment behind a seam, the sweep with the why-not-FIFO argument, invariants stated.
• Extension probe — the round will move the requirements; points come from landing the change in the right component — and being able to say why the others didn't move.
• Complexity honesty — boring costs stated plainly (O(cars), ordered-set ops) without invented sophistication.
• Communication — the two-type sentence early, transitions narrated as you code them, probes answered at the seam they belong to.