API Rate Limiter and Quota Enforcement
Concurrency, tests, time-based boundaries
Use the rubric while implementing per-client request budgets in an existing backend repository.
Open challenge100-point rubricInterviewer scorecardCandidate checklist
Machine Coding Round Evaluation Rubric
A practical framework for evaluating a timed machine-coding round from observable evidence. It balances a working result with repository fluency, tests, domain judgment, reliability, communication, and delivery under a clock. Candidates can use the same criteria after a practice attempt.
This is a general-purpose rubric, not an official scorecard for any employer. Adapt the evidence prompts to the exercise before the round, then apply the same version to every candidate completing that exercise.
Written by Sahil Srivastav, founder of Gronex and backend and infrastructure engineer.
How to use the rubric consistently
Score what the candidate demonstrates, not what you assume they know. Capture concrete evidence during the round, assign points after the coding time ends, and discuss meaningful differences in the debrief.
- 1Before the roundMark prompt-specific must-haves and decide which edge cases, tests, and reliability risks are in scope. Keep the total at 100 if you change a weight.
- 2During the roundWrite down observed actions, named tradeoffs, commands run, and behavior demonstrated. Avoid scoring typing speed or stylistic preference.
- 3After the roundScore each dimension independently against its anchors. Do not award the same evidence twice: working behavior belongs in correctness; proof quality belongs in tests.
- 4In debriefUse the total as a summary, not an automatic decision. Discuss requirement-critical failures separately and calibrate against the same prompt and level.
The 100-point scoring rubric
Use integer scores inside each listed range. Strong means repeated, independent evidence; acceptable means the core bar is met with bounded gaps; risky means the evidence is missing or a requirement is materially compromised.
30 correctness + 10 codebase navigation + 15 tests + 15 API/domain design + 15 concurrency/reliability + 10 communication + 5 time management = 100 points.
| Dimension | Strong | Acceptable | Risky |
|---|---|---|---|
| Functional correctness30 pointsRequired behavior, validation, state transitions, edge cases, and a runnable end-to-end flow. | 24-30 pointsDemonstrates the required core flow without workarounds. Invalid input and important boundary cases produce intentional outcomes, and the implementation preserves stated invariants. | 15-23 pointsThe main flow works. One or two secondary cases remain incomplete, but the candidate identifies them accurately and the gaps do not undermine the central behavior. | 0-14 pointsThe core flow does not run reliably, behavior diverges from the contract, or failures leave contradictory or silently corrupted state. |
| Codebase navigation10 pointsFinding entry points, tracing contracts, using repository conventions, and limiting the change surface. | 8-10 pointsLocates the relevant tests, interfaces, and data flow before editing. Changes stay in the owning layer and reuse established patterns with little unrelated churn. | 5-7 pointsFinds the correct path after some detours. The change fits the repository overall, with minor duplication or a slightly broader edit than necessary. | 0-4 pointsGuesses at contracts, bypasses existing abstractions, rewrites unrelated code, or cannot explain how a request moves through the repository. |
| Tests and verification15 pointsBaseline checks, focused test selection, meaningful assertions, regression coverage, and final verification. | 12-15 pointsRuns a baseline, uses failures to guide the change, and adds focused coverage for the happy path plus a boundary or failure case. Re-runs the relevant suite and reports the result precisely. | 8-11 pointsRuns the existing tests and adds or updates at least one useful regression test. Some edge coverage is absent, but the remaining gap is explicit. | 0-7 pointsDoes not execute the relevant tests, weakens assertions to get green output, relies only on manual inspection, or cannot distinguish a product failure from a test setup failure. |
| API and domain design15 pointsClear contracts, domain invariants, error semantics, appropriate boundaries, and proportionate extensibility. | 12-15 pointsNames operations and state in domain terms, keeps invariants in one clear owner, and returns specific errors. The design supports the stated follow-up without speculative architecture. | 8-11 pointsContracts are understandable and the model fits the current requirement. Some coupling or ambiguity remains, but it is local and does not block the expected extension. | 0-7 pointsExposes storage details as the API, scatters invariant checks, introduces ambiguous states, breaks existing contracts, or spends substantial time on abstractions the prompt does not need. |
| Concurrency and reliability15 pointsShared-state races, atomicity, retry behavior, partial failure, deterministic outcomes, and operational limits. | 12-15 pointsIdentifies the contested state and failure boundary, then makes the critical operation atomic or otherwise race-safe. Retry and partial-failure behavior are deliberate and verified where the prompt requires them. | 8-11 pointsProtects the obvious shared-state path and explains the chosen boundary. Residual risks or scaling limits are named accurately, even if not all are implemented in the timebox. | 0-7 pointsUses a check-then-act sequence on shared state, permits partial updates, treats retries as new operations, adds accidental global serialization, or makes concurrency claims without evidence. |
| Communication10 pointsClarifying assumptions, explaining decisions, responding to feedback, and giving an accurate final status. | 8-10 pointsClarifies material ambiguity early, states tradeoffs at decision points, and gives concise progress updates. The final summary separates completed behavior, open risks, and verified tests. | 5-7 pointsExplains the main approach and answers questions directly, though some assumptions or tradeoffs emerge only when prompted. | 0-4 pointsWorks from unstated assumptions, cannot connect edits to requirements, ignores new information, or reports completion more confidently than the evidence supports. |
| Time management5 pointsPrioritization, checkpoints, scope control, and preserving a runnable result inside the timebox. | 4-5 pointsBuilds a thin end-to-end slice first, checks progress against the clock, and defers polish deliberately. Leaves a runnable, explainable state at the deadline. | 3 pointsCompletes the core late or skips useful polish, but protects the main requirement and can state what would come next. | 0-2 pointsFront-loads optional architecture, stays blocked without changing approach, or reaches the deadline without an integrated core flow. |
| Total | 100 points | ||
For a deliberately single-threaded exercise, evaluate concurrency and reliability through deterministic behavior, failure boundaries, retry awareness, and an accurate statement of where the design stops. Do not invent distributed-system requirements that are outside the prompt.
Practical interviewer scorecard
Enter an integer score for every dimension and record the behavior that supports it. Evidence should name an observed action, implementation result, test, or explanation rather than a personality impression.
Functional correctness
Required behavior, validation, state transitions, edge cases, and a runnable end-to-end flow.
Codebase navigation
Finding entry points, tracing contracts, using repository conventions, and limiting the change surface.
Tests and verification
Baseline checks, focused test selection, meaningful assertions, regression coverage, and final verification.
API and domain design
Clear contracts, domain invariants, error semantics, appropriate boundaries, and proportionate extensibility.
Concurrency and reliability
Shared-state races, atomicity, retry behavior, partial failure, deterministic outcomes, and operational limits.
Communication
Clarifying assumptions, explaining decisions, responding to feedback, and giving an accurate final status.
Time management
Prioritization, checkpoints, scope control, and preserving a runnable result inside the timebox.
Total: 0 / 100
0 of 7 dimensions scored
Complete all seven dimensions before interpreting the total.
Candidate self-review checklist
Run this review immediately after a timed attempt. Unchecked items are concrete targets for the next practice session; they are more useful than judging the attempt only by whether the suite turned green.
Correctness
Codebase navigation
Tests
API and domain design
Concurrency and reliability
Communication
Time management
Apply the rubric to a real challenge
Choose a repository-based challenge, set a timebox, and use the scorecard only after the attempt. The focus labels identify useful evaluation dimensions without revealing an implementation.
Bank Transfer and Deadlock Prevention
Correctness, atomicity, failure handling
Score how well the implementation preserves transfer invariants when operations overlap or fail.
Open challengeInventory Stock Reservation
Domain design, state transitions, scope control
Practice modeling reservations while keeping the implementation narrow enough for a timed round.
Open challengeMessage Queue Consumer Idempotency and Retry
Retries, reliability, communication
Evaluate whether retry and failure behavior are explicit, testable, and accurately explained.
Open challengeBuild a repeatable practice loop
Start with the round-format guide, attempt one challenge under a fixed clock, complete the self-review, and pick the lowest-scoring dimension for the next session.
Go to machine coding round practice