AI システム設計面接の質問に答える方法

**

For years, system design interviews meant "Design YouTube," "Design Uber," or "Design WhatsApp." Companies hiring AI Engineers, Applied Scientists, and GenAI Engineers now ask a different set of questions: "Design ChatGPT," "Design a customer support AI," "Design GitHub Copilot," "Design an AI code reviewer," "Design a legal document assistant."

Most engineers can call an LLM API. Fewer can explain the surrounding architecture and defend the design choices under pressure. That second skill is what these rounds test. We will give you one reusable framework that works across all of these prompts, so you stop memorizing a separate answer for each.

# Why The Questions Changed

AI hiring grew fast enough to reshape the interview process. AI Engineer** was ranked the #1 fastest-growing job in the US for the second year running, with postings up 143% year over year in 2025.

LinkedIn data shows that the role added 75,000 US postings between 2023 and 2025, and that the share of AI and machine learning jobs in the tech market rose from 10% to 50% over the same period.

With that volume, the questions shifted toward AI-first software. IGotAnOffer reports that these rounds now center on how you wrap large language models (LLMs) into products: designing agentic loops, integrating retrieval, and reasoning about cost. Deep knowledge of model internals matters less than it used to.

A practitioner field guide built from late-2025 and early-2026 interview reports lists the most common prompts as designing an AI chatbot, a document question-and-answer or retrieval-augmented generation (RAG) system, an AI coding agent, and a voice assistant.

# What Interviewers Evaluate

**

Educative describes the shift well: these interviews test your ability to reason about probabilistic, cost-constrained systems rather than deterministic CRUD** services. The core skill is navigating trade-offs among latency, cost, quality, and safety when these pressures pull in opposite directions.

Strong candidates explain why each layer exists and what breaks without it. Naming the layers without that reasoning reads as shallow.

Senior-level reports say interviewers pick 3 to 5 areas and drill into failure modes and "what went wrong last time" rather than skimming many topics. What sets people apart is production experience and a willingness to talk about what they have actually shipped.

# The Framework

**

Across guides, the same sequence recurs. The System Design Handbook lays it out as eight steps; we use seven.

• Clarify. Pin down the data sources, privacy rules, latency budget, tolerance for factual errors, expected scale, freshness needs, and whether you can call a third-party API or must self-host.
• Estimate. Work out tokens per second, context window size, embedding volume, cost per call, and peak queries per second (QPS).
• Sketch the architecture. A defensible default flows through an input layer, a safety and personally identifiable information (PII) layer, an orchestrator, retrieval (a vector database plus a reranker), the model (routed by task difficulty), post-LLM guardrails, response streaming, and observability.
• Deep dive. Pick one or two components and go deep: RAG strategy (chunking, hybrid BM25 plus dense retrieval, reranking), prompt design, caching (exact and semantic), and model tiering.
• Trade-offs. Say them out loud: latency versus quality, RAG versus fine-tuning, cost ceilings, fallback models when capacity is tight.
• Failure modes and observability. Hallucinations, prompt injection, provider outages, embedding drift, multi-tenant isolation, and how you would detect each.
• Evolution. A/B prompt testing, feedback loops, eval gates before release, and gradual model migration.

The single most reported failure is jumping to a solution before clarifying requirements, constraints, and success criteria. Spend the first few minutes on step 1.

# The Primitives You Need To Know

Most "Design X" prompts reuse the same parts. Know these five well enough to draw and defend them.

// Retrieval-Augmented Generation (RAG)

At its core, a RAG** system has a query encoder, a retriever that fetches a ranked list of documents from a corpus, and a generator that conditions on both the query and the retrieved context.

Production deployments add document chunking, embedding pipelines, vector retrieval, caching, and evaluation logging, and they enforce access boundaries so users cannot pull data they should not see.

RAG alone often cuts hallucinations by roughly 40 to 71%.

// Model Routing

Cost and latency are real constraints, so say how you handle them.

GPT-4-tier models cost about $10 and $30 per million input and output tokens, respond in 3 to 5 seconds, and an agent handling 10,000 conversations a day at 5,000 tokens each runs past $7,500 a month on a single provider.

Send routine requests to cheap models and reserve frontier models for the hard ones. Since 60 to 80% of agent requests are routine, routing usually saves 40 to 70%.

Routing, semantic caching, prompt compression, and streaming together cut costs by 40 to 60% while holding quality steady.

// Guardrails

Guardrails sit at two layers.

Pre-LLM handles input validation, PII redaction, and prompt-injection defense.

Post-LLM handles schema enforcement, refusal policies, and fact-checking against the retrieved context.

Layered guardrails — system prompts, RAG grounding, citation enforcement, confidence scoring, and monitoring — can reduce hallucination risk by 71 to 89% against a baseline rate of 3 to 20%. Present these as ranges in the interview, since the figures come from mixed sources.

// Evaluation And Observability

Log model versions, retrieval metadata, tool traces, safety decisions, latency, and cost per request, using prompt hashes rather than raw text.

**

Combine offline evals (LLM-as-judge calibrated against ground truth) with online metrics such as faithfulness, context recall, and answer relevance. The same logs support debugging, safety, and compliance at once.

// Agentic Loops

For agent-heavy designs (an AI code reviewer, a research assistant, a customer support agent), the pattern is request intake, context assembly, LLM reasoning, action validation, sandboxed execution, result processing, state update, then loop or stop.

Keep concerns separate: the LLM reasons, the orchestrator controls flow, the policy engine governs, and the sandbox executes.

# Reference Architectures Worth Naming

Citing a real system shows you have read past the tutorials.

GitHub Copilot** is well documented. Its integrated development environment (IDE) extension extracts the code before and after the cursor, along with contextual signals such as open files, imports, and language metadata, to construct a prompt for the underlying model.

Fill-in-the-Middle (FIM) gathers neighboring tabs and file-path headers and sends the assembled prompt to GitHub's backend, which filters for safety and routes it to the model running on Azure. FIM gives roughly a 10% relative lift in acceptance over prefix-only prompting.

GitHub also runs a separate model to score completions on quality and safety, refined through offline, pre-production, and production evals.

Other systems worth a sentence:

• Uber's GenAI Gateway with a PII redactor across 60+ use cases.
• Airbnb's conversational AI with chain-of-thought reasoning and guardrails.
• Perplexity serving 200M daily queries on Vespa.ai.
• Slack's stateless RAG with models in an escrow virtual private cloud (VPC).
• Anthropic's multi-agent research system with an Opus orchestrator and Sonnet subagents.

# Common Mistakes

**

A few errors show up again and again, and most are easy to fix once you watch for them.

The biggest is designing before clarifying**. Candidates hear "Design ChatGPT" and start drawing boxes within seconds, skipping the requirements, constraints, and success criteria that should shape all subsequent choices. This is the top reported failure in interview debriefs, so spend the first few minutes asking questions.

A second is listing components without saying why each is there. A diagram with a vector database, a reranker, and a guardrail layer means little if you cannot explain what breaks when you remove each piece. Interviewers read that as memorization without real understanding.

A third is skipping cost and latency. These are first-class constraints in AI systems. A design that ignores the token bill or the 3- to 5-second response time is incomplete, however clean it looks.

The last is forgetting failure modes. Strong answers cover hallucinations, prompt injection, provider outages, and multi-tenant isolation, plus how you would detect each. And when you quote hallucination-reduction numbers, give ranges, since the published results vary by source and setup.

# Conclusion

**

AI system design interviews** reward a repeatable process more than a memorized answer. We looked at why the questions changed: AI hiring grew fast, and companies now ask you to design products built around LLMs rather than classic machine learning pipelines.

**

We looked at what interviewers evaluate: clear reasoning about probabilistic, cost-constrained systems, and honest talk about trade-offs and what has gone wrong in production.

The core is the 7-step framework.** Clarify the problem, estimate the load, sketch the architecture, dig into one or two components, name your trade-offs, plan for failure modes and observability, and say how the system evolves.

Under that sit five primitives you should be able to draw and defend: RAG, model routing, guardrails, evaluation, and agentic loops. Knowing one or two real architectures, such as GitHub Copilot, gives your answer weight.

Practice the framework on a few prompts, and "Design ChatGPT," "Design an AI code reviewer," and "Design GitHub Copilot" start to feel like the same problem with different inputs.

Nate Rosidi is a data scientist and in product strategy. He's also an adjunct professor teaching analytics, and is the founder of StrataScratch, a platform helping data scientists prepare for their interviews with real interview questions from top companies. Nate writes on the latest trends in the career market, gives interview advice, shares data science projects, and covers everything SQL.