SDE Path

Craft

The Machine-Coding Playbook

A repeatable 5-step method to go from a vague prompt to clean, tested, extensible code in 60–90 minutes.

12 min5 steps · 8 checks
Step 1 of 50/8 checks correct

A machine-coding prompt is deliberately underspecified. "Design a parking lot" hides a dozen decisions, and the candidates who lose the round are usually the ones who start typing before deciding which problem they are actually solving. Spend the first five to seven minutes turning the fog into a written contract.

Split what you hear into two buckets. Functional requirements are the behaviors the system must exhibit: park a vehicle, find the nearest free spot, compute a ticket fee. Non-functional requirements are the qualities around those behaviors: thread safety, pricing that changes later, multiple vehicle sizes. You cannot satisfy both if you never separate them, so say them out loud and let the interviewer correct you.

Then state what is out of scope. Announcing "I will not build payments or a persistence layer, I will keep state in memory" is not a weakness; it is you controlling the blast radius so you can finish. Ask for exactly one concrete end-to-end example and pin it down, because a single worked case removes more ambiguity than ten abstract questions.

A short exchange looks like this:

  • Candidate: "Do multiple floors matter, or is one flat lot fine for now?"
  • Interviewer: "Assume multiple floors."
  • Candidate: "Are fees by the hour, and do vehicle sizes change the rate?"
  • Interviewer: "Hourly, and bikes are cheaper than cars."
  • Candidate: "I will keep it in memory, single process, and skip payment gateways. Good?"
  • Interviewer: "Good."

Finally, write your assumptions into the code itself so they are visible and timeboxed:

/*
 * ParkingLot — machine-coding scope contract
 *
 * FUNCTIONAL
 *   - park(vehicle) -> Ticket, unpark(ticket) -> Fee
 *   - find nearest free spot that fits the vehicle size
 *   - hourly fee, rate depends on vehicle size
 *
 * NON-FUNCTIONAL (called out, not all built today)
 *   - pricing strategy must be swappable later
 *   - single JVM, in-memory state (no DB, no payment gateway)
 *
 * ASSUMPTIONS (confirmed with interviewer)
 *   - multiple floors, spots typed SMALL/MEDIUM/LARGE
 *   - a larger spot may hold a smaller vehicle
 *   - one process, concurrency deferred unless time allows
 */

That block is your compass. When you drift or the interviewer adds a twist, you re-read it instead of re-deriving the whole problem.

Quick check

The prompt is 'Design a ride-hailing dispatcher' with no other detail. What should you do FIRST?

Quick check

Why explicitly say 'I'll keep state in memory and skip payments' at the start?