system-design-interview-coaching ยท diff
git:20260913.a7ccfad to git:20261021.8da3953
32 added, 42 removed. Audit A to A.
---
name: system-design-interview-coaching
- description: "Runs a timed mock system design round as the interviewer, then scores it as the coach: seven phases on a 45-minute clock, one follow-up on the weakest area, Mermaid sketches in chat, a six-criterion 0-3 rubric with quoted evidence. Use for interview practice, prep, or grading a practice design."
+ description: "Facilitate timed system-design interview practice across backend, mobile/client, SDK/library, and full-stack surfaces. Use risk-driven probes, an adverse timeline, mechanism revision, one changed constraint, and the existing six-criterion evidence-based debrief."
metadata:
triggers:
keywords:
- mock interview
- interview practice
- interview prep
- practice round
- system design round
- grade my design
- time budget
---
# System Design Interview Coaching
## **Priority: P1 (HIGH)**
- Be the interviewer during the round and the coach after it. Never design for the candidate mid-round.
+ Classify practice mode independently from depth and surface. Surface may be backend, mobile/client, SDK/library, or full stack; load the client skill only where applicable. The candidate designs; the interviewer probes and the coach scores after the round.
## Roles
- - **Interviewer during the round**: states the problem and the clock, answers scoping questions tersely, changes a requirement on purpose once, tracks time.
- - **Coach after it**: scores with the rubric, quotes the candidate's own words as evidence, names the two fixes to work on first.
- - The candidate talks 80 % of the time; the interviewer 20 %. A monologue from the interviewer is a failed round.
+ - Interviewer: state the problem, clock, and "start by scoping it"; answer questions tersely, track time, introduce one changed constraint.
+ - Candidate: drive the design and talk about 80% of the time. Interviewer does not design for them mid-round.
+ - Coach: use the existing six-criterion rubric, quote evidence, and name two fixes first.
## Round Protocol
- 1. Open with the problem, the length (45 minutes unless told otherwise), and "start by scoping it". Start the clock.
- 2. Run the seven phases in order per [time budget](references/time-budget.md): requirements, estimation, high-level design, data model, API, deep dive, bottlenecks.
- 3. When a phase overruns, interrupt with the remaining time and the next phase's question ("Two minutes left in estimation. What is the shaping quantity?").
- 4. Once, around the deep dive, change one requirement deliberately (read ratio, retention, consistency). Absorbing it is expected and scored.
- 5. Push on the weakest area with one follow-up, not a list of gaps.
- 6. Give the model answer only after the candidate commits to an approach, and only for the part they committed to.
- 7. Stop at time. Debrief per [rubric](references/rubric.md): six criteria scored 0-3, quoted evidence per score, two fixes first, next practice problem.
+ 1. Agree the time limit and classify the surface. Retain the seven phases in [time budget](references/time-budget.md).
+ 2. Scope journeys, boundaries, and quality scenarios; estimate only decision-relevant quantities. Do not require backend QPS for an SDK contract.
+ 3. Have the candidate explain the logical critical flow before selecting physical components. Link a material flow to the canonical [flow contract](../system-design-data-architecture/references/flow-contracts.md); no repeated field checklist.
+ 4. Select zero or more deep dives from risk and remaining time. Use an adverse timeline, ask for the invariant and mechanism/recovery, then change one material constraint and ask what must change.
+ 5. Ask one follow-up on the weakest area. Give a model answer only after the candidate commits, and only for that part.
+ 6. Stop at time. Debrief with the existing rubric; score explanation, invariant, mechanism, and adaptation, not number of technologies or diagrams.
- ## Rules
+ ## Surface and views
- - **Numbers before boxes**: no component until the shaping quantity exists; a guessed number labelled `ASSUMED` is fine, a missing one is not.
- - **No buzzword without a reason**: "NoSQL", "Kafka", "sharding" earn a follow-up "why this, here" every time.
- - **No component without a constraint**: each box answers "what breaks without it".
- - **A changed requirement is deliberate**: expected, and scored under trade-offs.
- - **Silence is not help**: when the candidate stalls for a minute, ask one question that names the phase, never the answer.
+ - Client/mobile: examine authority, pending versus confirmed state, lifecycle, offline need, and relevant device limits.
+ - SDK/library: examine public behavior, compatibility, cancellation/concurrency, resource bounds, host responsibility, and lifecycle.
+ - Backend/full stack: follow the named journey across relevant boundaries; do not require a separate component for every layer.
+ - Sketch only when it helps answer a question. A dataflow view explains movement/authority; sequence explains ordering/acknowledgment; state explains lifecycle. A table or prose is enough. No fixed sketch-per-phase rule.
+ - For a selected diagram, JSON is semantic source of truth; draw.io is editable presentation and image is an exported copy. During chat practice, use concise Mermaid only when it adds clarity.
- ## Sketching
+ ## Rules
- - During the round: Mermaid inline in chat, at most one sketch per phase, per [whiteboard rules](references/whiteboard-rules.md). Same conventions as the house style: labelled arrows, dashed for async, one level per sketch, acronyms expanded, assumptions marked `ASSUMED`.
- - After the round: the model answer may be rendered through `common-architecture-diagramming` when a real system sits behind the practice; a classic catalog problem stays as Mermaid.
+ - No component before its constraint; no technology name without a reason.
+ - An unknown quantity is an explicit assumption, never a fabricated number. Distinguish estimate, target, and measured evidence.
+ - Planned checks and documents do not prove execution or operations.
+ - Keep the interview design scope appropriate; production migration, compliance, and operations details are not assumed unless the prompt makes them material.
## Debrief
- - Score each of the six criteria 0-3 with one quoted line from the round as evidence; totals map to bands (strong hire, hire, borderline, no hire).
- - Name the two fixes to work on first, each tied to a row in [mistakes](references/mistakes.md).
- - Recommend the next practice problem from `system-design-case-catalog` that exercises the weakest criterion.
+ - Score the unchanged six criteria 0-3 with a quoted line per score; follow [rubric](references/rubric.md).
+ - Name two prioritized fixes tied to [mistakes](references/mistakes.md). Recommend a next practice case only when useful; do not invent quotas.
## Anti-Patterns
- - **No answer dump**: the value is the questions asked; the model answer waits for a commitment.
- - **No skipped estimation**: "I know this one" still needs this problem's numbers.
- - **No score without evidence**: a number with no quote is an opinion, not feedback.
- - **No hire inflation**: the band follows the total; confidence is not a criterion.
- - **No production plan**: an interview answer omits migration, cost, compliance, and team constraints; say so once, do not grade on them.
-
- ## Red Flags
-
- | Thought | Reality |
- |---------|---------|
- | "Just tell me the answer" | The model answer comes after the candidate commits to an approach, and only for that part. |
- | "I know this one, skip the numbers" | Numbers before boxes. Estimation is the phase most rounds fail on. |
- | "We're out of time, dump the architecture" | Time is the constraint being tested. Score what exists, coach the pacing. |
- | "Score it a hire, I need the confidence" | Quoted evidence decides the band, not the candidate's mood. |
+ - **No answer dump**: coach only after the candidate commits.
+ - **No forced topology**: no mandatory database, queue, cache, specialist count, or architecture layer.
+ - **No skipped learning loop**: present a concrete counterexample, require a mechanism revision, then test adaptation to the changed constraint.
+ - **No score without evidence**: the six existing criteria and quoted evidence remain the scoring contract.
## References
- - [Time budget](references/time-budget.md) - minutes per phase at 45 and 60, what must exist, the interrupt lines
+ - [Time budget](references/time-budget.md) - pacing and interrupt guidance
- [Rubric](references/rubric.md) - six criteria, 0-3 descriptors, bands, report template
- - [Mistakes](references/mistakes.md) - symptom, what the coach says, recovery
- - [Whiteboard rules](references/whiteboard-rules.md) - what to sketch per phase, Mermaid conventions, when to render the model answer
- - Problem bank: `system-design-case-catalog`. Phases and deliverables: `system-design-methodology/references/phase-deliverables.md`.
+ - [Mistakes](references/mistakes.md) - symptom, coaching prompt, recovery
+ - [Whiteboard rules](references/whiteboard-rules.md) - conditional view selection and semantics
+ - [Phase deliverables](../system-design-methodology/references/phase-deliverables.md)