The interview at a glance
What a generative AI system design interview tests
This round combines distributed systems discipline with the uncertainty of model behavior. The interviewer wants to see whether you can turn a probabilistic capability into a bounded, measurable, operable product.
Define the AI boundary
Clarify what the model decides, what deterministic services own, and what the system must never do.
Design the request path
Trace input through policy, retrieval, orchestration, model execution, validation, and response delivery.
Follow the hardest risk
Choose RAG, inference, agents, or evaluation according to the product constraint that matters most.
Close with evidence
Name quality, latency, cost, safety, and reliability metrics plus the fallback when the model is wrong.
Traditional system design vs generative AI system design
| Area | Traditional focus | Generative AI focus | Strong interview signal |
|---|---|---|---|
| Requirements | Traffic, storage, consistency, availability | Model boundary, grounding, privacy, output risk | Scope the product before naming a model |
| Capacity | QPS, bandwidth, storage growth | Input/output tokens, concurrency, TTFT, GPU or API quotas | Use estimates to justify routing and limits |
| Data | Entities, access patterns, retention | Knowledge freshness, chunking, embeddings, prompt context | Separate ingestion from the online request path |
| Correctness | Deterministic tests and invariants | Task evals, groundedness, human review, regression sets | Define how quality is measured before launch |
| Failure | Timeouts, overload, data loss | Bad retrieval, unsafe output, model drift, vendor limits | Degrade to a bounded experience, not a confident guess |
Model boundary, grounding, privacy, output risk
Scope the product before naming a model
Traditional baseline: Traffic, storage, consistency, availabilityInput/output tokens, concurrency, TTFT, GPU or API quotas
Use estimates to justify routing and limits
Traditional baseline: QPS, bandwidth, storage growthKnowledge freshness, chunking, embeddings, prompt context
Separate ingestion from the online request path
Traditional baseline: Entities, access patterns, retentionTask evals, groundedness, human review, regression sets
Define how quality is measured before launch
Traditional baseline: Deterministic tests and invariantsBad retrieval, unsafe output, model drift, vendor limits
Degrade to a bounded experience, not a confident guess
Traditional baseline: Timeouts, overload, data lossIf the common architecture vocabulary is still unfamiliar, start with the broader system design interview pillar. For labels, features, training, and predictive systems, use the separate machine learning system design interview guide.
A repeatable answer sequence
A 50-minute generative AI system design framework
Use time boxes as guardrails. The right deep dive depends on the prompt, but the sequence keeps requirements, architecture, evaluation, and operations visible.
Clarify the use case
Agree on users, core action, output format, domain boundary, freshness, privacy, and unacceptable failures.
Define success and risk
Choose one product metric, task-quality metrics, latency targets, and safety release criteria.
Estimate tokens and load
Estimate requests, average context, output length, peak concurrency, retrieval volume, and the cost unit that drives design.
Draw the baseline
Show client, API boundary, policy layer, orchestrator, context builder, model gateway, output checks, storage, and telemetry.
Deep dive once
Choose RAG, inference serving, model routing, or agent tool use and defend the hardest trade-off.
Design evaluation
Connect offline evals, adversarial cases, human review, online signals, and regression gates.
Break the system safely
Cover timeouts, rate limits, stale retrieval, prompt injection, unsafe output, observability, and fallback behavior.
Summarize and evolve
Restate the request path, largest trade-off, open risk, and the next improvement after real usage data.
Draw the baseline first
A reference architecture you can explain under pressure
A good diagram separates the online request path from knowledge ingestion and makes policy, evaluation, telemetry, and fallback behavior visible.
daily tokens = daily users x sessions x (average input tokens + average output tokens) Then estimate peak concurrency, time to first token, tokens per second, retrieval load, and cost per successful task. State uncertainty instead of presenting rough assumptions as precise forecasts.
Keep deterministic control outside the model
Authentication, authorization, quotas, irreversible actions, money movement, and policy enforcement should not depend only on free-form model output.
Version every changing artifact
Track prompts, model routes, tools, embedding models, indexes, policies, and eval datasets so regressions can be reproduced.
Make graceful degradation a product decision
Fallback may mean a smaller model, cached response, retrieval-only results, human escalation, or a transparent refusal. Choose it from user risk.
Choose one subsystem
Deep dive where the product is hardest
Interview depth comes from following a constraint through design choices, not from naming every GenAI technique.
RAG and grounding
Fresh or private knowledge with source-backed answers.
- Ingestion, parsing, chunking, and metadata
- Hybrid retrieval and reranking
- Context assembly, citations, and freshness
- Retrieval evals separate from generation evals
Inference and routing
High traffic, strict latency, variable complexity, or private hosting.
- Time to first token and tokens per second
- Batching, queues, caching, and warm capacity
- Model tiers, fallbacks, and tenant quotas
- Quality-cost-latency routing policy
Agents and tools
Tasks that must choose actions, call tools, and recover across multiple steps.
- Workflow versus autonomous agent boundary
- Tool schemas, permissions, and idempotency
- State, budgets, stop conditions, and approvals
- Trace-level evaluation of plans and tool calls
Evaluation and operations
High-risk output or products that change prompts, models, and knowledge frequently.
- Task-specific golden and adversarial sets
- Pairwise or rubric-based graders
- Human calibration and production feedback
- Versioned prompts, models, indexes, and traces
Anthropic's guidance on building effective agents recommends starting with the simplest composable pattern that works. In an interview, explain why a workflow, single model call, or RAG pipeline is insufficient before adding autonomous tool selection.
Prove the system works
Evaluation, safety, reliability, and cost belong in the core design
Generative output is variable, so launch confidence comes from representative evals, production telemetry, human calibration, and explicit release gates.
Task quality
Accuracy, relevance, completeness, format adherence, and groundedness on representative tasks.
The team uses one generic benchmark that does not represent the product.
Retrieval quality
Recall, precision, freshness, citation coverage, and whether the right evidence reaches the prompt.
Generation is tuned while bad retrieval remains invisible.
Safety and privacy
Prompt injection resistance, sensitive-data handling, harmful output, tool permissions, and auditability.
Safety is treated as one output filter after the model call.
System performance
Time to first token, end-to-end latency, throughput, error rate, saturation, and fallback rate.
Only average latency is reported while tail behavior remains unknown.
Cost and value
Cost per successful task, token mix, retrieval cost, escalation rate, and product outcome.
Token cost falls while task completion or user trust also falls.
OpenAI's evaluation guidance emphasizes task-specific evals, continuous evaluation, logging, and human calibration. For security, use threat categories such as prompt injection, sensitive information disclosure, improper output handling, and excessive agency from the OWASP Top 10 for LLM Applications.
Worked interview prompt
Example: design an AI mock interview platform
Design a product that runs adaptive spoken interviews, asks role-aware follow-ups, and returns evidence-linked feedback without exposing private candidate data or pretending uncertain model judgments are facts.
Session setup
The candidate selects role, seniority, interview type, and sanitized context. The service creates a bounded session policy.
Question planning
A deterministic controller chooses competencies and difficulty; the model generates one question within that plan.
Adaptive follow-up
The orchestrator combines the transcript, rubric gaps, and remaining time, then requests one follow-up at a time.
Evidence capture
Audio transcription, timing, question IDs, model version, prompts, and safety events are stored with strict retention controls.
Structured scoring
Rubric-specific graders produce evidence-linked observations. Low-confidence or contradictory judgments are flagged.
Feedback and retry
The report names observable moments and one repair drill; the next session tests whether that behavior improved.
Adaptive follow-ups without an uncontrolled agent
Use a deterministic session controller for time, competencies, question count, safety, and completion. Let the model propose one follow-up from the current transcript and rubric gap, validate it against the session policy, then either ask it or fall back to a curated probe. This preserves adaptability without giving the model ownership of the entire interview.
After learning the architecture, practice the delivery with the 60-minute system design mock interview guide or run a role-aware session through InterviewCue AI mock interviews.
Build transferable depth
Generative AI system design interview questions
Use a small set of prompts that expose different bottlenecks. Repeat each once with a changed privacy, latency, traffic, or cost constraint.
Design an internal knowledge assistant
Freshness, permissions, chunking, hybrid retrieval, citations, and stale-index behavior.
Design a multi-tenant LLM API
Admission control, batching, quotas, routing, noisy neighbors, billing, and graceful degradation.
Design an AI code assistant
Context collection, privacy, latency, streaming, repository grounding, and acceptance feedback.
Design an incident-response agent
Tool permissions, approvals, rollback, audit logs, stop conditions, and adversarial input.
Build an LLM evaluation platform
Datasets, graders, human calibration, slices, versioning, regression gates, and experiment review.
Design an AI document analyst
OCR, layout, retrieval, table reasoning, citations, PII controls, and long-running jobs.
Copyable prompts for mock practice
Generative AI system design interviewer
Act as a senior interviewer running a 50-minute generative AI system design interview.
Give me one open-ended product prompt. Wait for my response and ask one follow-up at a time. Probe requirements, model boundaries, token and load estimates, high-level architecture, one deep dive, evaluation, safety, cost, observability, and failure recovery.
Do not reveal a reference design during the interview. After I summarize, score only observable evidence. For each dimension, return: strong signal, missed signal, impact, and one repair drill. Label uncertain technical judgments for verification. Answer-structure audit
Review this generative AI system design transcript. Do not invent missing statements.
Create a timeline of the candidate's decisions. Then assess: scope, quantitative reasoning, request-path clarity, depth of trade-offs, evaluation design, safety, reliability, cost awareness, and communication.
Quote or reference the exact moment supporting each observation. Identify the highest-impact missing decision and give a 15-minute repair exercise using the same prompt. Constraint-change drill
Use my current architecture and introduce one constraint at a time. Choose from: 10x traffic, half the latency budget, private deployment, rapidly changing knowledge, strict tenant isolation, model-provider outage, prompt injection, or a 40% cost reduction.
After each answer, ask what changes, what remains unchanged, which metric proves the revision works, and what new failure mode appears. Research base
Sources and further reading
This guide synthesizes interview-preparation frameworks with current first-party architecture, evaluation, agent, security, and risk guidance. Provider-specific product names and prices change; verify them before using them in an interview estimate.
ByteByteGo - Generative AI System Design Interview: Introduction and Overview
Broad GenAI foundations and an end-to-end ML system design sequence.
Read source Interview frameworkSystem Design Handbook - Generative AI System Design Interview
Interview-oriented treatment of token budgets, RAG, routing, safety, and operations.
Read source ArchitectureAWS Well-Architected Generative AI Lens
Operational excellence, security, reliability, performance, cost, and lifecycle guidance.
Read source RAGGoogle Cloud - RAG infrastructure reference architecture
Separation of ingestion and serving paths, grounding, security, reliability, cost, and latency.
Read source EvaluationOpenAI - Evaluation best practices
Task-specific evals, continuous evaluation, production data, and human calibration.
Read source AgentsAnthropic - Building effective agents
A practical distinction between workflows and agents, with a bias toward simple composable patterns.
Read source SecurityOWASP Top 10 for LLM Applications
Threat categories including prompt injection, sensitive information disclosure, and excessive agency.
Read source RiskNIST Generative AI Profile
A lifecycle-oriented profile for trustworthy design, deployment, use, and evaluation.
Read sourceCommon preparation questions
Frequently asked questions
What is a generative AI system design interview?
It is an open-ended architecture interview about building a product around foundation models or other generative models. You still cover requirements, scale, APIs, storage, reliability, and trade-offs, but you must also address model boundaries, context, retrieval, inference, evaluation, safety, and token-based cost.
How is it different from a machine learning system design interview?
Traditional ML system design often emphasizes labels, features, training, offline metrics, online serving, drift, and retraining for prediction or ranking. Generative AI interviews add probabilistic output, prompts, context windows, RAG, model routing, tool use, open-ended evaluation, and content safety. The two formats overlap, but they are not interchangeable.
Should I always use RAG?
No. Use RAG when the answer needs fresh, private, large, or source-backed knowledge. A bounded prompt or long-context approach may be simpler for small stable corpora. Fine-tuning is more suitable for changing behavior or style than for keeping factual knowledge current.
Do I need to know how to train an LLM?
Not for every role. Many product and platform interviews focus on integrating, serving, grounding, evaluating, and operating models. Clarify whether the prompt is about building an application around a model, hosting inference, fine-tuning, or training a foundation model because each requires a different depth.
Which metrics should I mention?
Separate product outcomes, task quality, retrieval quality, safety, system performance, and cost. Examples include task completion, groundedness, retrieval recall, unsafe-output rate, time to first token, p95 latency, fallback rate, and cost per successful task. Explain why each metric matters and where it can mislead.
How should I practice?
Use one framework across several prompts, speak and draw the request path, choose one deep dive, and let the interviewer change a constraint. Afterward, score observable decisions and repeat the weakest 15 minutes before switching to a new problem.
The final signal
Design a bounded product, not an impressive model demo
A strong generative AI system design answer makes the model replaceable and the system explainable. Scope the product, quantify the important load, draw one coherent request path, deep dive into the highest-risk component, and prove that quality, safety, latency, reliability, and cost can be observed.
Learn the framework first, then rehearse it under interruption. Use the same prompt twice: repair the weakest 15 minutes, change one constraint, and check whether your reasoning transfers rather than memorizing a diagram.