The Practical Coding Screen Playbook

TL;DR: Minutes 0 to 5: restate the problem, ask the two or three questions that change the design (units, ordering, what happens on failure, is the input sorted), state assumptions and write them as a comment. Minutes 5 to 20: the working core, simplest correct version, typed and narrated, with the data model first. Minutes 20 to 25: three or four tests named for invariants, run them. Minutes 25 to 40: the follow-ups, each as a small change with the invariant re-stated; complexity said unasked. Minutes 40 to 45: what you would change for production (bounds, concurrency, persistence, observability). The habits that score: working code before clever code, tests before follow-ups, narration of trade-offs, and never arguing with the problem. Under an assistant-allowed policy the score shifts to specification, verification and judgment; under a ban it shifts to fluency; the plan is the same.

The minute-by-minute plan

The plan is the same for every problem in this track: The GPU Credit Scheduler Pattern, Rate-Limiting Algorithms, Batching Queues and Backpressure, Interval Merging and Utilization Logs, Parsing Kernel Traces and Logs, and the concurrency problems.

What the interviewer is scoring

• Modelling: did the data model come first, and does it make the invariants easy to keep?
• Correctness under change: did the follow-ups slot in, or did the first design have to be thrown away?
• Testing instinct: did tests appear before being asked, and do they test invariants rather than the happy path?
• Complexity fluency: can you say the cost of each operation and where it changes under a follow-up?
• Communication: narration that is neither silence nor a monologue; questions when the problem is ambiguous; agreement when the interviewer redirects.
• Judgment: the production notes, and the willingness to say "I would not do this in production, here is why, and here is the version I would."

The reported loops weight these differently: a fleet-infrastructure screen leans on modelling and the follow-ups; a performance-engineering screen leans on complexity and the numbers; a platform screen leans on tests and production notes. All of them mark down a candidate who spends ten minutes on an optimal solution to the first version and has no time for the second.

The assistant policy, and what changes

Companies have split. Some ban assistants outright in coding rounds (and say so in the invitation, sometimes with a proctored environment); some allow or expect them, and a few run rounds that are explicitly "build this with the assistant of your choice." The evidence for each company's policy is in the loop notes (the company pages), and a candidate should ask the recruiter rather than guess.

Under a ban, the round measures fluency: you write the heap, the lock, the generator from memory, and the plan above is exactly how to spend the time. Practice typing the five patterns cold until each takes under ten minutes.

With an assistant allowed, the round measures something else: whether you can specify precisely, verify what comes back, and keep the design in your own head. The scored behaviours change:

• Write the specification (data model, invariants, the test cases) before asking the assistant for code; the assistant produces what you specified, and the specification is what is graded.
• Read every line it returns and say what you are checking ("the eviction is on the front, the lock is held across both operations"). An unread paste is the fastest way to fail the round.
• Run the tests you wrote, not the ones it wrote, or at least read its tests as skeptically as its code.
• Take the follow-ups yourself first, then use the assistant to accelerate the typing; an interviewer who watches you delegate the thinking marks that down.
• Say when the assistant is wrong. It happens on the concurrency problems and the interval edge cases, and catching it is the strongest signal the format can give.

The same skills matter in the job: the field's daily work with assistants is specification, review and judgment, and the round is a sample of it.

The habits, in the order they pay

1. Working before clever. A correct O(n log n) with tests beats an unfinished O(n).
2. Data model first. The classes and their fields, then the operations. Follow-ups become field additions.
3. Invariants out loud. "Balance is always at least reserved." Every change ends with "and that still holds because..."
4. Tests named for what they protect. test_failure_refunds_reservation, not test_2.
5. Complexity unasked. After each operation, its cost; after each follow-up, what changed.
6. Injected clocks and randomness. Anything with time or jitter takes now and rng as parameters so tests run without sleeping.
7. Bounded everything. Queues, retries, buffers; say where the bound is and what happens when it is hit.
8. Production notes at the end. Two minutes, unprompted.

The mistakes that end the screen

• Silence for ten minutes, then a wall of code.
• Arguing that the problem is unrealistic instead of asking the question that makes it realistic.
• Optimizing the first version and running out of time for the follow-ups.
• No tests, or tests that only cover the happy path.
• Charging at submit "because it's simpler" and being surprised by the refund follow-up (the scheduler's classic).
• time.sleep in a test; time.time() in a rate limiter; an unbounded list as a queue.
• Pasting assistant output without reading it, in a round that allows assistants.
• Refusing the follow-up ("that's out of scope") instead of sketching it.

A worked opening

prompt: "Implement a rate limiter for our API gateway."
minute 0 to 3, out loud:
  "Per what key: tenant, IP, or both?  Requests or tokens?  Burst allowed, or a smooth rate?
   Single process, or shared across gateway instances?  I'll assume per-tenant, requests, burst allowed,
   single process first, and I'll sketch the shared version at the end."
minute 3: a comment block with those assumptions, then:
  class TokenBucket: rate, capacity, tokens, last  (monotonic clock injected)
minute 12: try_acquire with lazy refill; retry_after computed
minute 15: tests: burst then deny, refill over time (fake clock), retry_after value, n larger than capacity rejected
minute 20: follow-up 1, tokens-per-minute with unknown output length: reserve then settle
minute 30: follow-up 2, many gateways: an atomic script over shared state, or leases
minute 40: production notes: per-request cap, separate stream semaphore, metrics on rejections

What to remember

• Five minutes of questions and assumptions, fifteen of the simplest correct core, five of invariant-named tests, fifteen of follow-ups with complexity, five of production notes.
• Data model first; invariants out loud; tests before follow-ups; clocks and randomness injected; everything bounded.
• Ask the recruiter about the assistant policy; under a ban, practice the five patterns cold; with an assistant, the specification, the review and the catch are what score.
• The screen ends on silence, arguing with the problem, over-optimizing the first version, missing tests, or an unread paste.