The Design Method

The AI system-design round is not about producing the one true architecture. It's about demonstrating a repeatable method in real time — the interviewer wants to watch you think. This lesson gives you a five-step whiteboard sequence you'll reuse in both design lessons that follow. The method itself IS the deliverable.

"Design an AI-assisted system for X. Take the whiteboard."

The five steps

1. Users and risk. Before any boxes: who uses this, and what's the cost of a wrong answer? An internal drafting aid and a system that touches someone's credential have opposite risk profiles, and everything downstream — autonomy, thresholds, review flows — follows from this. Saying it first signals judgment; skipping it is the round's most common failure.

2. Data. Interrogate the inputs: what documents or records exist, how fresh must they be, how sensitive are they (PII? FERPA-adjacent education records?), and who's allowed to see what? Freshness pushes you toward retrieval over weights; sensitivity pushes you toward access control in the retrieval layer and away from shipping data to places it shouldn't go.

3. Pattern choice. Only now pick from the menu — extraction, classification/matching, RAG Q&A, copilot — and justify it from steps 1 and 2. Say the trade-offs aloud: "I'd use retrieval rather than fine-tuning here because the source documents change and answers must be citable; the cost is an ingestion pipeline to maintain." An unstated trade-off earns no credit; interviewers score reasoning they can hear.

4. Guardrails. Match the risk from step 1: structured-output validation, evidence thresholds with refusal, human-in-the-loop for consequential outcomes, audit logging. Low-risk tools get lighter rails — showing that you scale guardrails to risk beats reciting all of them every time.

5. Operations. The step most candidates forget, and the one that marks you senior: how is quality measured (offline evals on a golden set, re-run on every prompt/model change), what does it cost per document or query, what's monitored in production (latency, error rate, override rate), and what's the rollback story when the model misbehaves.

Running it in the room

Narrate the sequence as a plan before you start — "Let me walk users and risk, then data, then the pattern, guardrails, and operations" — so the interviewer can follow and interject. Budget roughly: a quarter of your time on steps 1–2, half on 3–4, a quarter on 5. When they interrupt with a constraint, place it in the framework ("that's a data-sensitivity constraint — it changes step 2, so let me revisit the retrieval design") rather than improvising a detached patch.

Red flags

• Drawing an architecture before asking a single question.
• Trade-offs decided silently — the interviewer hears conclusions, never reasoning.
• Guardrails and evals bolted on at the end only after a prompt from the interviewer.
• Treating pushback as an attack instead of new requirements to fold in.

Practice prompts

1. Recite the five steps and one key question for each, from memory, in under a minute.
2. Apply the method for five minutes to: "AI triage for our public records requests."
3. Mid-design, the interviewer says half the documents are confidential. Which steps change?