Standard v1.0
The Standard
Low-level design is subjective, so the training is not. Five dimensions, four levels each, and twenty written anchors that say what each level looks like — the same twenty strings the grader is given and the app shows, quoted here without paraphrase.
How to read a level
Level 2 is the bar. Level 1 is an attempt that would not pass, and level 3 is not "more patterns" — read D3's level 3 and note that it penalises a speculative interface as hard as level 0 penalises having no seam at all. That asymmetry is deliberate: a rubric that only rewarded abstraction would train exactly the over-abstraction real interviewers reject.
Two of the five dimensions are arithmetic rather than opinion. D2 comes from whether it compiles, whether a driver exists, and how much of the base suite is green; D4 comes from measuring the diff a new requirement costs against the reference solution's own. Together that is 40% of the score which no model can move, which is what keeps the other 60% honest.
A zero in any single dimension is disqualifying whatever the weighted total says, because a single absent dimension is what an interviewer actually rejects on.
| Dimension | Weight | How it is scored |
|---|---|---|
| D1 Code design & structure | 30% | judged against these anchors |
| D2 Working functionality | 25% | computed, never judged |
| D3 Design patterns & SOLID | 20% | judged against these anchors |
| D4 Extensibility | 15% | computed, never judged |
| D5 Edge cases & error handling | 10% | judged against these anchors |
Code design & structure
Boundaries are obvious enough that a new requirement's home is unambiguous. Invariants live in constructors, so no invalid instance can exist
Each class has one reason to change. Entities, values and services are distinguished. Names read as domain language. No class over ~150 lines
Multiple classes, but responsibilities overlap; a class both stores and decides
One god class holding all state and behaviour; or logic in main
Static checks contributing: god-class thresholds (methods, fields, fan-out), stringly-typed constants that should be enums, mutable collections leaked from getters, catch-and-swallow.
Working functionality
Base suite green with the clock still running, and the driver shows the interesting cases rather than the happy path only
Compiles, main demonstrates the core flow, base suite fully green
Compiles; under half the base suite passes
Does not compile, or no main/driver exists
Computed from javac exit status, summarise() over the base suite, and the presence of a main. Never overridden by an LLM. A missing driver caps this dimension at 0 — interviewers run it first.
Design patterns & SOLID
The seam set is minimal — no speculative interface with a single implementation and no foreseeable second one
Variation points sit behind interfaces. New behaviour is a new class. Dependencies are injected, including time
One seam exists but is bypassed elsewhere, or a pattern is named without being used
Behaviour selected by if/switch on a type field, in more than one place
Note the symmetry: level 3 penalises over-abstraction as much as level 0 penalises none. A FooFactoryProvider for one concrete type is not sophistication. A speculative interface with a single implementation and no foreseeable second one scores LOWER, not higher. The failure tag for this is over-engineered (premature interface).
Extensibility
Curveball absorbed by adding files only — zero lines changed in pre-existing files
Curveball suite passes within the measured budget
Curveball suite passes, but diff exceeded budget by more than 2×
Curveball suite fails, or the change was abandoned
Computed by measureChange(). Budgets are measured against the reference solution’s own diff plus slack, never guessed. The raw number is always shown next to the verdict so the judgement is inspectable.
Edge cases & error handling
Failure modes named in the code's structure — impossible states unrepresentable rather than merely checked
Boundaries rejected explicitly with meaningful domain exceptions. Empty, full, duplicate and not-found cases handled
Some validation, inconsistently applied
Happy path only; invalid input produces wrong state silently
A deterministic edge-case suite contributes; the LLM judges what the suite cannot see.