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.

Start here

Define the AI boundary

Clarify what the model decides, what deterministic services own, and what the system must never do.

Core architecture

Design the request path

Trace input through policy, retrieval, orchestration, model execution, validation, and response delivery.

Best deep dive

Follow the hardest risk

Choose RAG, inference, agents, or evaluation according to the product constraint that matters most.

Strong finish

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

AreaTraditional focusGenerative AI focusStrong interview signal
RequirementsTraffic, storage, consistency, availabilityModel boundary, grounding, privacy, output riskScope the product before naming a model
CapacityQPS, bandwidth, storage growthInput/output tokens, concurrency, TTFT, GPU or API quotasUse estimates to justify routing and limits
DataEntities, access patterns, retentionKnowledge freshness, chunking, embeddings, prompt contextSeparate ingestion from the online request path
CorrectnessDeterministic tests and invariantsTask evals, groundedness, human review, regression setsDefine how quality is measured before launch
FailureTimeouts, overload, data lossBad retrieval, unsafe output, model drift, vendor limitsDegrade to a bounded experience, not a confident guess
Requirements

Model boundary, grounding, privacy, output risk

Scope the product before naming a model

Traditional baseline: Traffic, storage, consistency, availability
Capacity

Input/output tokens, concurrency, TTFT, GPU or API quotas

Use estimates to justify routing and limits

Traditional baseline: QPS, bandwidth, storage growth
Data

Knowledge freshness, chunking, embeddings, prompt context

Separate ingestion from the online request path

Traditional baseline: Entities, access patterns, retention
Correctness

Task evals, groundedness, human review, regression sets

Define how quality is measured before launch

Traditional baseline: Deterministic tests and invariants
Failure

Bad retrieval, unsafe output, model drift, vendor limits

Degrade to a bounded experience, not a confident guess

Traditional baseline: Timeouts, overload, data loss

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.

01
0-5 min

Clarify the use case

Agree on users, core action, output format, domain boundary, freshness, privacy, and unacceptable failures.

Interviewer probeDoes the answer need citations? Can private data leave the tenant? Which decisions require human approval?
02
5-9 min

Define success and risk

Choose one product metric, task-quality metrics, latency targets, and safety release criteria.

Interviewer probeWhat is worse: no answer, a slow answer, or an ungrounded answer?
03
9-13 min

Estimate tokens and load

Estimate requests, average context, output length, peak concurrency, retrieval volume, and the cost unit that drives design.

Interviewer probeWhich assumption changes the architecture if it doubles?
04
13-20 min

Draw the baseline

Show client, API boundary, policy layer, orchestrator, context builder, model gateway, output checks, storage, and telemetry.

Interviewer probeKeep the first design simple enough to explain end to end.
05
20-32 min

Deep dive once

Choose RAG, inference serving, model routing, or agent tool use and defend the hardest trade-off.

Interviewer probeDo not attempt four shallow deep dives.
06
32-39 min

Design evaluation

Connect offline evals, adversarial cases, human review, online signals, and regression gates.

Interviewer probeWhich change can silently make the system worse?
07
39-45 min

Break the system safely

Cover timeouts, rate limits, stale retrieval, prompt injection, unsafe output, observability, and fallback behavior.

Interviewer probeWhat does the user see when each critical dependency fails?
08
45-50 min

Summarize and evolve

Restate the request path, largest trade-off, open risk, and the next improvement after real usage data.

Interviewer probeEnd with priorities, not a list of every technology you know.
The model name is not the design.Use model capabilities and constraints to justify architecture decisions, but keep the request path understandable if the provider or model version changes.

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.

Capacity check 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.

01

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.

02

Version every changing artifact

Track prompts, model routes, tools, embedding models, indexes, policies, and eval datasets so regressions can be reproduced.

03

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.

R

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
Trade-off: More context does not guarantee a better answer; irrelevant context can make a response confidently wrong.
I

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
Trade-off: A cheaper route only saves money if its lower quality does not create retries, escalation, or user churn.
A

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
Trade-off: Agent flexibility adds nondeterminism, latency, cost, and a larger security boundary.
E

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
Trade-off: A single aggregate score can hide failures in a critical slice, language, tenant, or user journey.

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.

01
Release gate

Task quality

What to measure

Accuracy, relevance, completeness, format adherence, and groundedness on representative tasks.

Weak signal

The team uses one generic benchmark that does not represent the product.

02
RAG systems

Retrieval quality

What to measure

Recall, precision, freshness, citation coverage, and whether the right evidence reaches the prompt.

Weak signal

Generation is tuned while bad retrieval remains invisible.

03
Risk gate

Safety and privacy

What to measure

Prompt injection resistance, sensitive-data handling, harmful output, tool permissions, and auditability.

Weak signal

Safety is treated as one output filter after the model call.

04
SLOs

System performance

What to measure

Time to first token, end-to-end latency, throughput, error rate, saturation, and fallback rate.

Weak signal

Only average latency is reported while tail behavior remains unknown.

05
Economics

Cost and value

What to measure

Cost per successful task, token mix, retrieval cost, escalation rate, and product outcome.

Weak signal

Token cost falls while task completion or user trust also falls.

Strong evaluation loopRepresentative and adversarial casesHuman-calibrated gradersRegression checks on every material changeProduction failures added back to the eval set

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.

Primary userTechnical candidate preparing for a role-specific loop
Core SLONatural follow-up latency with a recoverable session
Highest riskConfident but unsupported feedback
FallbackContinue from a bounded question bank and flag scoring uncertainty
01

Session setup

The candidate selects role, seniority, interview type, and sanitized context. The service creates a bounded session policy.

02

Question planning

A deterministic controller chooses competencies and difficulty; the model generates one question within that plan.

03

Adaptive follow-up

The orchestrator combines the transcript, rubric gaps, and remaining time, then requests one follow-up at a time.

04

Evidence capture

Audio transcription, timing, question IDs, model version, prompts, and safety events are stored with strict retention controls.

05

Structured scoring

Rubric-specific graders produce evidence-linked observations. Low-confidence or contradictory judgments are flagged.

06

Feedback and retry

The report names observable moments and one repair drill; the next session tests whether that behavior improved.

Deep-dive choice

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.

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.

RAG

Design an internal knowledge assistant

Freshness, permissions, chunking, hybrid retrieval, citations, and stale-index behavior.

Inference

Design a multi-tenant LLM API

Admission control, batching, quotas, routing, noisy neighbors, billing, and graceful degradation.

Product

Design an AI code assistant

Context collection, privacy, latency, streaming, repository grounding, and acceptance feedback.

Agents

Design an incident-response agent

Tool permissions, approvals, rollback, audit logs, stop conditions, and adversarial input.

Evaluation

Build an LLM evaluation platform

Datasets, graders, human calibration, slices, versioning, regression gates, and experiment review.

Multimodal

Design an AI document analyst

OCR, layout, retrieval, table reasoning, citations, PII controls, and long-running jobs.

Copyable prompts for mock practice

Run a full mock

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.
Review a transcript

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.
Pressure test

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.

Common 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.