The Practical Coding Screen Playbook

TL;DR: Clarify the inputs, failure behavior and constraints, then implement a simple correct core. Test the important invariants and explain complexity. Adapt to follow-ups by changing the model deliberately rather than patching special cases. Confirm and follow the interview’s policy on external tools.

The minute-by-minute plan

Adapt this illustrative 45-minute plan to the problem and interview format. Related practice includes: 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

A useful self-review asks whether the model makes the invariants clear, whether the core operations work, and whether the tests cover failure paths. Explain the cost of each operation and how a follow-up changes it.

Interview rubrics vary. Keep the discussion responsive: state assumptions, narrate consequential choices and make room for the interviewer to redirect. A design change is not a failure if new requirements justify it; explain why the earlier model no longer fits.

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 you remain responsible for checking that it meets the specification.
• 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 makes it difficult to explain or safely change the result.
• 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; keep ownership of the design and its correctness.
• 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.

Habits that make the work harder to assess

• 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.
• Leave enough time for correctness checks, communicate important choices and review any permitted assistant output.