The Machine-Coding Round: A Senior Playbook

Why this round is different from everything else you’ve practiced

By now you can apply SOLID, recognize when a Strategy beats a switch, and model a parking lot in your sleep. The machine-coding round does not test whether you know these things — it tests whether you can run a controlled design process under a clock, out loud, with an interviewer changing the requirements on you. The artifact (your code) matters, but the round is really an audit of your judgment: what you choose to build, what you deliberately defer, and whether you can say why.

This lesson is a playbook, not a problem. It gives you a phase-by-phase script, a time budget, concrete good-vs-weak moves, and the exact sentences that move you from hire to strong-hire.

The single biggest scoring lever at Senior level is legibility of reasoning. Two candidates can write the same class Order. The one who said “I’m making PricingStrategy an interface now because discounts and taxes are the most likely change axis” out-scores the one who silently typed it — even if the code is byte-identical.

The time budget (90-minute round)

Treat the clock as a first-class constraint. A working, slightly-narrow solution beats a beautiful half-finished one every time. Reserve the back end for a working demo.

Phase 1 — Clarify and scope (the highest-leverage 10 minutes)

Vague prompts (“Design a ride-sharing system”) are intentional. Scoping is the test. Your job is to convert an open prompt into a bounded, demonstrable problem and get the interviewer to nod.

Drive it along these axes, fast:

• Actors & core use cases — who uses it, what are the 2-3 verbs? (“Riders request, drivers accept, system matches and prices.”)
• Functional MUST vs NICE — propose the cut yourself, don’t ask permission for everything.
• Scale & concurrency — single-process in-memory? Or do they want thread-safety modeled? This decides whether you reach for mutex/locks.
• Persistence — almost always say: “I’ll use in-memory repositories behind an interface so storage is swappable; no real DB.” This is the correct default and shows you know the seam.
• The likely change axis — ask this explicitly: “What’s most likely to change later — pricing rules, matching strategy, vehicle types?” Their answer tells you where to spend your design budget.

Weak move: “Should I handle payments?” → “Up to you.” (You offloaded the decision.) Strong move: “Payments touch external gateways and add little design signal, so I’ll model a PaymentService interface and stub it — in scope as an interface, out of scope as an implementation. Sound good?”

Then write the scope down (top of the file or a corner of the board) as a contract:

IN  : request ride, match nearest driver, surge pricing, ride lifecycle
OUT : auth, real payments, persistence, maps/routing (stub distance)
ASSUME: single process, in-memory, ~thousands of drivers

Phase 2 — Drive the design top-down

Now externalize a model before implementing. You want a small diagram and a short list of interfaces at the change axes you identified in Phase 1. Top-down means: nouns → responsibilities → relationships → the 1-2 interfaces that carry your extensibility story. Resist jumping to a clever pattern; let the requirement summon it.

        +-----------+      requests      +------------------+
 Rider  |   Rider   |------------------->|   RideService    |
        +-----------+                    | (orchestrator)   |
                                         +--------+---------+
                                                  | uses
                  +-------------------------------+------------------+
                  |                  |                   |           |
            +-----v------+   +-------v--------+   +-------v------+   +v---------+
            | Matching   |   | Pricing        |   | Driver       |   | Ride     |
            | Strategy   |   | Strategy       |   | Repository   |   | (entity, |
            | <<iface>>  |   | <<iface>>      |   | <<iface>>    |   |  FSM)    |
            +-----+------+   +-------+--------+   +--------------+   +----------+
                  |                  |
           NearestDriver        SurgePricing
           (impl)               (impl)

State machines are gold when the entity has a lifecycle — model Ride as an explicit FSM and say it’s a state machine; it pre-empts a whole class of “what if a cancelled ride gets accepted?” questions:

REQUESTED --accept--> MATCHED --start--> ONGOING --end--> COMPLETED
    |                    |
 cancel               cancel
    v                    v
CANCELLED            CANCELLED

Choose patterns deliberately, and say the alternative you rejected

Pattern-dropping for its own sake reads as junior. The senior signal is naming the alternative you didn’t pick.

Phase 3 — Write clean code that actually compiles

This is where most candidates lose points silently. The rules:

1. Keep it compiling at all times. Stub a method with a return, don’t leave a half-typed expression. A green compile at minute 70 beats elegant code that doesn’t build.
2. Program to interfaces at the seams you identified — but use concrete classes everywhere else. Don’t interface-ize value objects.
3. Make illegal states unrepresentable where cheap: enums for status, private fields with controlled transitions, no public setters that break invariants.
4. Small methods, intention-revealing names. findNearestAvailableDriver, not process2.
5. Handle the obvious error — request with no available driver, transition from a terminal state — at least with a thrown domain exception. You don’t need every edge, you need to show you see them.

Here’s the kind of clean, interface-driven core the interviewer wants to see — Strategy at the pricing seam, an orchestrator that depends only on abstractions, plus a tiny driver so the “prove it runs” claim is demonstrated by the very code shown. All three tabs round fares to 2 decimals, generate the ride id, and produce identical output for the same inputs.

// --- seams (interfaces) ---
interface PricingStrategy {
price(base: number, demand: number): number;
}
interface MatchingStrategy {
match(drivers: Driver[], rider: Rider): Driver | null;
}

// --- a concrete strategy ---
class SurgePricing implements PricingStrategy {
price(base: number, demand: number): number {
  const multiplier = demand > 1 ? 1 + (demand - 1) * 0.5 : 1;
  return Math.round(base * multiplier * 100) / 100; // 2-dp
}
}

// numeric (non-const) enum: RideStatus[r.status] reverse-mapping works.
// A string/const enum would be safer but would break reverse lookups.
enum RideStatus { Requested, Matched, Ongoing, Completed, Cancelled }

interface Rider { id: string }
interface Driver { id: string; available: boolean }

class Ride {
status = RideStatus.Requested;
constructor(readonly id: string, readonly rider: Rider) {}

private static allowed: Record<RideStatus, RideStatus[]> = {
  [RideStatus.Requested]: [RideStatus.Matched, RideStatus.Cancelled],
  [RideStatus.Matched]:   [RideStatus.Ongoing, RideStatus.Cancelled],
  [RideStatus.Ongoing]:   [RideStatus.Completed],
  [RideStatus.Completed]: [],
  [RideStatus.Cancelled]: [],
};

transition(to: RideStatus): void {
  if (!Ride.allowed[this.status].includes(to))
    throw new Error(`illegal transition ${this.status} -> ${to}`);
  this.status = to;
}
}

// id generation injected so the orchestrator stays runtime-agnostic
type IdGen = () => string;

// --- orchestrator depends only on abstractions ---
class RideService {
constructor(
  private pricing: PricingStrategy,
  private matching: MatchingStrategy,
  private newId: IdGen,
) {}

request(rider: Rider, drivers: Driver[], base: number, demand: number): Ride {
  const ride = new Ride(this.newId(), rider);
  const driver = this.matching.match(drivers, rider);
  if (!driver) throw new Error("no driver available");
  ride.transition(RideStatus.Matched);
  const fare = this.pricing.price(base, demand);
  console.log(`matched ${driver.id}, fare = ${fare}`);
  return ride;
}
}

// --- one-line driver: proves it runs ---
class NearestDriver implements MatchingStrategy {
match(drivers: Driver[], _r: Rider): Driver | null {
  return drivers.find(d => d.available) ?? null;
}
}
let n = 0;
const svc = new RideService(new SurgePricing(), new NearestDriver(), () => `r-${++n}`);
svc.request({ id: "u1" }, [{ id: "d1", available: true }], 99.99, 2);
// -> matched d1, fare = 149.98

Notice what this code does not do: no payment gateway, no persistence, no geo math. Those are stubs by design — and you said so in Phase 1. Scoped narrowness is a feature.

Two implementation notes worth saying out loud, because an interviewer who knows the language will check for them:

• Id generation is injected (IdGen / new_id / std::function) rather than calling a runtime API inside the orchestrator. TS crypto.randomUUID() would couple the service to a modern runtime (Node ≥19 or a secure browser context with WebCrypto); passing an id generator keeps RideService pure, testable, and runtime-agnostic. Python’s uuid.uuid4() is stdlib-portable and used as the default factory.
• The C++ transition map intentionally omits terminal-state keys. Completed and Cancelled are not in the map; allowed.find(status_) returns end() for them, which correctly rejects any outbound transition. That is the behavior, not a bug — call it out so the interviewer doesn’t mistake the omission for an oversight.

Phase 4 — Prove it runs

Always write a tiny driver and run it (or trace it) in front of the interviewer. “It works” is a claim; printed output is evidence. The main() / __main__ / driver block above requests a ride, transitions it to Matched, and prints the fare — that is the proof, shown in the same snippet, not asserted separately.

Strong-hire tell: the candidate wants to run the code and is mildly annoyed when it doesn’t compile, fixes it fast, and keeps going. Hire-but-not-strong: shrugs and says “you get the idea.”

Phase 5 — Absorb the extension volley without flinching

The interviewer will throw a curveball: “Now add scheduled rides” or “support pooling / shared rides” or “make pricing depend on weather.” This is the whole point — they’re testing whether your seams hold. The grade is close to binary:

• Strong-hire: “Weather pricing is just another PricingStrategy — I add WeatherSurgePricing, no change to RideService. Here’s the class.” (touches one new file, points at the seam)
• Hire: Adds an if (weather) branch inside the existing pricing method. Works, but the seam didn’t pay off.
• No-hire: Has to restructure the orchestrator — RideService itself changes because pricing/matching were hardwired. The whole Phase 2 extensibility story collapses on first contact.

The move that earns the most credit is to map the curveball to a seam before you touch the keyboard: “That’s a pricing-rule change, so it lives behind PricingStrategy — RideService and Ride don’t move.” Then write the ~8 lines and re-run the driver with the new strategy injected. You’ve demonstrated, live, that your abstraction was load-bearing.

When the curveball lands outside your seams (e.g. “now make it multi-region with per-region driver pools” when you modeled a flat DriverRepository), do not pretend it’s free. The senior move is: “That doesn’t fit my current seam cleanly. The smallest honest change is to make DriverRepository region-aware — one method signature changes and RideService passes a region through. That’s a deliberate, localized change, not a rewrite.” Naming the cost accurately beats hand-waving that “it’s just another strategy” when it isn’t.

Phase 6 — Wrap up and defend trade-offs

With ~5 minutes left, stop coding and narrate. This is free signal that most candidates leave on the table. Hit three things:

1. What’s in, what’s stubbed, and why — “Pricing and matching are real and extensible; payments and persistence are interfaces with in-memory stubs, by scope.”
2. The trade-offs you made, as trade-offs — “I used an in-memory map for drivers; O(n) matching is fine for thousands, but I’d swap NearestDriver for a spatial index (geohash / quadtree) at city scale. The interface makes that a one-class change.”
3. What you’d do with more time — concurrency (a mutex around ride state), idempotency on request, retry/timeout on the payment seam.

Weak close: “Yeah, I think that’s it.” (No reflection, no ownership of the gaps.) Strong close: “Given the clock I prioritized the matching/pricing core and a runnable demo over breadth. The two things I’d harden first are thread-safety on Ride.transition and a real spatial index for matching — both are isolated behind the seams I already drew.”

The hire vs strong-hire summary

The throughline: a senior candidate is legible. Every decision is spoken, scoped, and defensible. The code is necessary but not sufficient — the round is won in the narration.