The trap this round sets on purpose
A machine-coding prompt — "design and implement a parking lot management system," "build an in-memory rate limiter," "implement a simplified splitwise" — is almost always phrased ambitiously enough that a complete, fully general implementation would take several hours, not the 60-90 minutes actually given. That gap is intentional: the round isn't measuring whether you can build the whole thing, it's measuring what you do when the stated scope and the available time obviously don't match. Candidates who don't notice the mismatch, or notice it and say nothing, tend to run out of time with an ambitious but half-finished, untested mess. This subtopic assumes you already know how to design the system (that's the LLD track's job) — it's specifically about the time-management layer on top.
Negotiate scope explicitly, in the first five minutes
Before writing any code, state out loud what you think the minimal "core" is, and explicitly ask whether that's the right target given the time available: "I'll treat multiple vehicle types and a pluggable fee strategy as the core, and treat things like persistence, concurrency, and a full admin API as extensions I'll only get to if time allows — does that split make sense?" This does three things at once: it demonstrates you can see the difference between "interesting" and "necessary" for this specific time budget, it gives the interviewer a chance to redirect you before you've sunk 20 minutes into the wrong scope, and it converts an implicit, easy-to-mismanage decision into an explicit, shared one.
Sequence by "always demoable," not by "logical build order"
A natural instinct is to build in the order a class diagram suggests — all the entity classes first, then all the business logic, then wiring it together, then finally something you can actually run. That order front-loads risk: if you run out of time partway through, you're left with a pile of classes that have never been executed together, and it's genuinely unclear to an interviewer (or to you) whether any of it actually works. The stronger sequencing principle: build the thinnest possible vertical slice first — one entity, one operation, wired end-to-end and actually run once — then widen. Concretely, for a parking lot system: get a single ParkingLot with a single parkVehicle/removeVehicle pair working and demonstrably correct (even hardcoded to one vehicle type, one fee rule) before adding a second vehicle type, a second fee strategy, or a query API. At every checkpoint, you have something real to show, and expanding a working slice is safer than debugging a fully-built but never-executed system with 10 minutes left.
Announce phase transitions instead of just moving through them
Explicitly marking transitions — "that's the core flow working, I'm going to spend the next chunk of time on the fee-strategy extension point," "I've got about 15 minutes left, I'm going to prioritize a couple of tests over the admin-listing feature" — keeps the interviewer oriented on your plan and your remaining budget without them having to ask. This is the machine-coding-specific version of the continuous narration habit from Working Under Observation: the content being narrated here is specifically time allocation, which is the resource this round is actually testing your management of.
When time runs short: cut breadth, not correctness
If it becomes clear you won't finish everything discussed, the right cut is fewer features done correctly, not more features done sloppily. Dropping the second vehicle type entirely while keeping the first one correct and tested reads as good judgment under a hard constraint; keeping both vehicle types half-working with untested edge cases reads as not having noticed the time was running out. Saying so explicitly — "I'm going to stop here and make sure what I have is correct rather than start the next feature with 5 minutes left" — turns a forced stopping point into a demonstration of judgment rather than an unexplained gap.