When an agent has to run untrusted code or commands, what sandboxing options do you have? Which tier would you pick and why?

For execute-style tools the danger is in the arguments, so an allowlist cannot help; isolate instead — shrink what the code can reach rather than judging it Process level: child process, hard timeout, environment allowlist, read-only workdir; stops crashes, hangs and secret theft, not exfiltration Container level: no network, read-only rootfs, non-root, CPU/memory/pid limits, disposable; stops exfiltration and out-of-bounds access, not kernel escapes MicroVM: own kernel, stops most escapes, costs cold start and money; choose by who wrote the code and whether you serve it publicly The classic bug is handing the child process the whole parent environment — isolated process, leaked secrets

How should secrets be managed in an agent system? Where must they never appear, and how do you rotate them without downtime?

Four nevers: never in code, never in logs, never in the LLM context, never in error messages The agent-specific one is the context — anything there reaches the vendor, the history and the traces, and can be read out by an injection The agent needs the capability to call an API, not the key; the key stays inside the tool implementation Redact at one logging exit instead of trusting callers, and route the exception path through it too Use a secret manager with workload identity in production, and rotate dual-key: accept both, shift traffic, verify no old callers, then revoke

What roles do the MCP server and client play, what can a server expose, and which transports exist?

The server is the capability provider in its own process; a client connects to exactly one server; the host holds many clients Three server-side primitives: tools chosen by the model, resources as URI-addressed read-only data, prompts as reusable templates — the latter two usually chosen by a human Clients can declare sampling, roots and elicitation so the server can call back into the host Two transports: stdio for local subprocesses and Streamable HTTP for remote; the old HTTP+SSE transport is legacy On stdio, stdout belongs to JSON-RPC so logs must go to stderr, and the host must reap the child process

When should you reach for MCP instead of plain function calling, and what does it cost when you shouldn't?

Three criteria, any one justifies MCP: reuse across hosts, ownership by another team, or add/remove without touching host code The default is no — if none of the three apply, a local function is the better engineering decision Costs: another process to supervise, another handshake with timeouts, and a debug path that grows from one hop to three MCP does not change your cost structure: descriptions still enter context every turn and too many tools still hurt selection Once third-party capabilities are attached, your tool list is no longer fully under your control, which is itself a design problem

How do you merge two retrieval rankings, and why not just take a weighted sum of the scores?

Use RRF: map each channel's rank to 1/(k + rank) and sum, with k = 60. Weighted sums fail because the scores are different units — bounded, tightly clustered cosine versus unbounded BM25, so BM25 decides the outcome. Weights also do not transfer: tuned on one corpus, they drift on the next. Ranks are unitless and need no calibration; k flattens the head so cross-channel consensus outweighs single-channel confidence. Break ties explicitly (by id) or ordering depends on hash iteration order and your evaluation numbers stop being reproducible.

How is reranking usually implemented, what problem does it solve, and what does it cost?

The first pass ranks by retrieval signals so it can scan a large index fast; coarseness is the trade. Reranking feeds query and candidate through one model together (cross-encoder): much sharper, but one forward pass per candidate, so only tens of items. Batch LLM scoring works for teaching; production uses a dedicated reranker, costing an extra 100-300 ms hop plus an inference box. Reranking does not raise recall — it raises recall@5 and MRR (measured 80% to 91%, 0.732 to 0.908) while recall@20 barely moves from 95% to 98%. So judge a reranker by small-k metrics, never by recall@20.

What is different about frontend state management under streaming, and why not call setState on every token?

One setState per token means tens of full renders per second, and each render costs more as the list grows — long replies jank at the end. Batch instead: accumulate tokens in a ref and flush every 30 ms; measured, 200 tokens produced only 8 commits. Ship the details with it: force a flush on stream end and on interrupt, and keep the buffer in a ref rather than state. Keep parsing, event reduction and batching as pure functions outside React; subscribe via useSyncExternalStore. The payoff of that split is unit-testable streaming logic with no browser in the loop.

How do you design retry so it does not duplicate side effects, and should the tool-call process be visible to the user?

Retry carries the idempotency key minted on the first attempt; the backend hits a unique constraint and reattaches to the existing run. The rule for minting a new key is whether the content changed — same message keeps the key, edited content gets a new one. The same pattern recurs in write dedup, cron ticks, cross-service delivery and frontend retry, always arbitrated by a database unique constraint. Make tool calls visible so users can decide whether to interrupt, tolerate the wait, and describe where it hung. But filter: human-readable tool names, no internal ids or secrets in the arguments, classified error reasons instead of raw stack traces.

For a multi-tenant agent service, how do you design data isolation and billing isolation, and when do you move from a shared table to a dedicated database per tenant?

Three parallel layers, each missing one causing its own class of incident: data, resources, billing Data isolation is backstopped by row-level security; the application where clause is only an optimisation Resource isolation is a per-tenant rate-limit bucket plus sharding workers by tenant hash, aimed at noisy neighbours Billing isolation is a tenant column on the usage ledger, powering invoices, quotas and degradation Escalate to schema or database isolation based on starvation risk and compliance mandates, not tenant count Per-tenant databases multiply migrations, backups, monitoring and connection pools — operational cost jumps The idempotency key algorithm stays, but its scope must include the tenant id or identical keys across tenants collide

An agent system's model spend is out of control. Which levers do you pull, in what order, and roughly how much does each save?

Open with 'look at the ledger', not 'use a cheaper model': slice by user, by day and by model to locate the growth Set a baseline: about $0.0006 per turn, roughly $30/day and $900/month at 10k DAU and five turns Five layers ordered by cost to you: caching and prompt cache, tiered routing, context compression, step and tool budget caps, rate limiting and degradation Tiered routing is the only order-of-magnitude lever, but only if the baseline is a flagship model — say so when it is not Compression from 2000 to 1200 input tokens gives $0.00048 per turn, about $720/month, a 20% cut Tool budget caps buy predictability: with a cap the per-turn ceiling is $0.0012, without one there is no ceiling Rate limiting comes last because users feel it; degrade before refusing

Suppose I open one of your GitHub projects — what should a good README show me?

Start from the reader: a three-minute budget and no intention of cloning, so the first screen answers what it is and whether it runs Seven sections: one-line positioning, architecture diagram, quick start, three key design decisions, known limitations, directory guide, license Quick start must work in three commands or fewer, verified on a machine that has never run it Every design decision states what was given up — the one part no template provides, and where interviewers pick their follow-up Use Mermaid rather than screenshots: native GitHub rendering, text diffs, and it does not go stale

What most commonly goes wrong in the self-introduction, and what does a good one look like?

The interviewer is doing two things at once: assessing structure and choosing which project to dig into The common failure is chronological order, which burns the clock before reaching recent work; reverse it Keep three blocks: current engineering focus, one or two signature results with numbers, and why this role Landing the main line in ninety seconds and leaving room for follow-up beats filling all three minutes Every technology you name is an invitation: omit unfamiliar stacks, plant the topics you want asked, and rehearse a sixty-second and a ninety-second version

After a mock interview, how do you assess yourself objectively instead of settling for 'that felt okay'?

Evidence before judgment: record throughout, run real time boxes, and score against the replay rather than on feeling at the buzzer Use five fixed dimensions (intro, project depth, coding, system design, communication and candidate questions) scored 1 to 5 out of 25, each with anchors for what 1, 3 and 5 look like Fix thresholds before scoring: any dimension below 3 goes on the weakness list, a total below 18 means rerunning the loop two days later Translate low scores into four columns — observation, root cause, smallest drill, verification — where the observation is a pointable fact and the drill fits in one day Practicing alone, use a model as interviewer but write the rules first: one question at a time, three layers of follow-up, no praise, no evaluation, no answers

How would you build a scheduler that caps in-flight async tasks, and why is Promise.all or asyncio.gather not enough?

Promise.all and asyncio.gather only wait; the work started when each promise was created, so concurrency equals the task count Two correct shapes: a fixed worker set pulling from a shared cursor, or a semaphore gating task start The slot must be returned on every exit path — finally in Java, async with in Python, error-to-value inside a Swift task, try/catch inside the JS loop A leaked slot shows up as gradual slowdown to a full stall once the downstream starts erroring, and is invisible on the happy path The payoff is peak memory scaling with the concurrency limit rather than the task count; retries must stay inside the slot and carry jitter

How do you turn scattered knowledge into a map that is actually useful for review?

Grouping into layers is what any table of contents does; a map's information is in its edges One rule for edges: draw one only when A is a genuine prerequisite for B — sibling topics and course order do not count Paint your weak spots on the nodes and fix upstream first when reds cluster; one fix lights up several downstream nodes Long cross-layer edges are the valuable ones — following them in an interview shows a system, isolated nodes only produce fragments Keep it redrawable on a whiteboard in five minutes; finer detail belongs in the question bank, not the map

Interview Bank

328 questions total; 15 shown with current filters.

CourseAll From Frontend Engineer to Agent Engineer in 30 Days Prompt Engineering From Scratch in 5 Days Mastering Claude: From Conversation to Claude Code in 5 Days Mastering Codex and the OpenAI Agents SDK in 5 Days MCP in 7 Days: Wire Tools Into Any Agent Agent Skills in 7 Days: Turn Experience Into Reusable Capability Context Engineering in 5 Days RAG in 14 Days: From Retrieval to Trustworthy Answers Build an AI Short-Drama Production Pipeline With Agents in 14 Days

WeekAll W1 W2 W3 W4

MarketAll Common in China Common overseas

DifficultyAll Basic Intermediate Deep dive

From Frontend Engineer to Agent Engineer in 30 Days

D22 Security: Prompt Injection, Least Privilege for Tools, Sandboxing Approaches, Secret Management

When an agent has to run untrusted code or commands, what sandboxing options do you have? Which tier would you pick and why?Agent 要执行不受信任的代码或命令时，有哪些沙箱隔离思路？你们选了哪一档，为什么？
Common in ChinaCommon overseasIntermediate#sandboxing#security#tool-execution
How to reason about it · think before answering
The spread here is not how many isolation techniques you can name, it is whether you can say what each tier stops and what it lets through. 'We use a sandbox' says nothing, and the next question will be 'does it stop data exfiltration?'
First explain why these tools are special: an allowlist governs whether a tool may be called, but for a tool whose whole job is 'run this thing I hand you', the allowlist degrades into a hall pass, because the danger lives in the arguments rather than the name. So you switch technique — instead of judging whether the code is bad, you shrink what it can reach. Same idea as permission enforcement, applied to a process instead of a tool.
Then give three tiers by cost. Process level: a separate child process, a hard timeout, an environment-variable allowlist, a read-only working directory; stops crash propagation, hung loops and secret theft; does not stop network exfiltration or reads elsewhere on the host. Container level: no network, read-only rootfs, non-root user, CPU/memory/pid limits, disposable per run; adds exfiltration and out-of-bounds access; does not stop a kernel escape. MicroVM: a lightweight VM with its own kernel, stops most escapes, at the price of cold start and cost.
Give the selection rule, which is what the interviewer actually wants: if you wrote the code and only the arguments are untrusted, process level is enough; if the code itself comes from the model or a user, container level is the floor; if you run arbitrary third-party code as a service, go to microVM.
Call out the classic implementation bug: people spawn a child process and assume they are isolated, then hand it the parent's entire environment. The process is separate but the secrets went with it, and one line reading an environment variable prints your API key. The child's environment must be a fresh object copied from an allowlist, never inherited.
Expect the follow-up: what happens on timeout? Use a signal that actually kills the process, and report 'killed by timeout' as its own failure class rather than folding it into generic errors — it usually means somebody is probing for resource exhaustion, not that the code has a bug.
分析过程 · 先想清楚再作答
这题的区分度不在于能背出几种隔离手段，而在于你说不说得出每一档挡住了什么、放过了什么。只说「我们用了沙箱」等于没说，面试官下一句一定是「那它挡得住外发数据吗」。
先说清这类工具为什么特殊：白名单管的是「能不能调」，但「执行一段你给的东西」这类工具一旦进了工具表，白名单就退化成一张通行证，因为危险面在参数里不在工具名里。所以要换一种手段——不判断这段代码坏不坏，而是收窄它能触碰的东西。这和权限侧强制是同一个思路，只是对象从工具换成了进程。
然后按代价从低到高给三档。进程级：独立子进程、超时必杀、环境变量白名单、只读工作目录；挡住崩溃传染、死循环挂住主进程、密钥被读走；挡不住网络外发和读系统里的其他文件。容器级：无网络、只读 rootfs、非 root、CPU 与内存限额、进程数限额、用完即弃；把外发和越界读写也挡掉；挡不住内核漏洞逃逸。microVM：独立内核的轻量虚拟机，挡住多数逃逸，代价是冷启动和成本。
给选型判据，这是面试官真正想听的：代码是你写的、只是参数不可信，进程级够用；代码本身来自模型或用户，最低容器级；要跑第三方任意代码还对外提供服务，上 microVM。
点一个高频实现坑：很多人起了子进程就以为隔离了，却把父进程的环境变量整个传过去——进程是独立了，密钥跟着过去了，子进程一句读环境变量就把 API key 打印出来。子进程的环境必须是白名单拷出来的新对象，而不是继承。
可以预期的追问：超时之后怎么办？要用能真正杀死进程的信号，并且把「被超时杀掉」当成一个独立的失败类型上报，而不是混进普通报错——它通常意味着有人在试资源耗尽，而不是代码写错了。
Key points
For execute-style tools the danger is in the arguments, so an allowlist cannot help; isolate instead — shrink what the code can reach rather than judging it
Process level: child process, hard timeout, environment allowlist, read-only workdir; stops crashes, hangs and secret theft, not exfiltration
Container level: no network, read-only rootfs, non-root, CPU/memory/pid limits, disposable; stops exfiltration and out-of-bounds access, not kernel escapes
MicroVM: own kernel, stops most escapes, costs cold start and money; choose by who wrote the code and whether you serve it publicly
The classic bug is handing the child process the whole parent environment — isolated process, leaked secrets
答题要点
执行类工具的危险面在参数里，白名单管不住，要靠隔离：不判断代码坏不坏，而是收窄它能触碰的东西
进程级：子进程 + 超时必杀 + 环境变量白名单 + 只读工作目录；挡崩溃、死循环、密钥泄漏，挡不住外发
容器级：无网络、只读 rootfs、非 root、CPU 内存与进程数限额、用完即弃；挡外发与越界读写，挡不住内核逃逸
microVM：独立内核，挡多数逃逸，代价是冷启动与成本；判据是代码来自谁、要不要对外提供服务
最常见的实现坑是把 process.env 整个传给子进程——进程隔离了，密钥跟着过去了
How should secrets be managed in an agent system? Where must they never appear, and how do you rotate them without downtime?Agent 系统里的密钥应该怎么管理？它绝对不能出现在哪些地方，轮换要怎么做才能不停机？
Common in ChinaCommon overseasIntermediate#secrets-management#security#observability
How to reason about it · think before answering
It reads like a giveaway, but there is one answer point specific to agents, and missing it makes you sound like a generic backend engineer: secrets must never enter the LLM context. The interviewer asked about an agent system, and that is the line he is waiting for.
Give the four 'nevers', one line each. Never in code — hardcoding hands the secret to everyone with read access, and deleting the line does not remove it from git history. Never in logs — the highest-frequency leak channel; nobody prints a secret on purpose, but 'log the whole request header so we can debug' is universal. Never in the LLM context. Never in error messages — responses to the frontend and exceptions thrown upstream are both outbound channels.
Expand the third one, since it is what differentiates the answer: once a secret is in the context it will be sent to the model vendor, stored in conversation history, written into traces, and eventually read out loud by some prompt injection. What the agent needs is the capability to call an API, not the key itself — the key stays inside the tool implementation, and the model only ever sees the tool name and its arguments.
Then the mechanics: redact at a single logging exit rather than trusting callers. Relying on everyone to mask by hand guarantees a miss. Do it in the one place logs leave the process, with two passes — replace known secret values from the environment, then catch the rest with generic shape patterns. Route the exception path through the same exit, because stack traces routinely carry connection strings with credentials.
Storage and rotation: dotenv plus gitignore locally; in production a secret manager the process reads at startup under its own workload identity, never values baked into an image or a deployment manifest. Rotate dual-key: accept old and new simultaneously, shift traffic to the new one, confirm the old one has no remaining callers, then revoke. A single-shot swap always leaves a failure window on some replica.
Expect the follow-up: how often do you rotate? The interval is secondary — what you should actually rehearse is whether you can revoke and replace a suspected-leaked key within five minutes. Saying that shows you are thinking about incident response rather than a compliance checkbox.
分析过程 · 先想清楚再作答
这题看着是送分题，但有一个专属于 Agent 的答案点，答不出来就只是通用后端水平：密钥不能进 LLM 上下文。面试官问的是 Agent 系统，这一条就是他在等的。
先给四不入，一条一句：不入代码（写死在源码里等于给了所有有仓库读权限的人，而且删掉那一行 git 历史里还在）；不入日志（最高频的泄漏渠道，没人故意打印密钥，但「把请求头整个打出来方便排查」每个团队都干过）；不入 LLM 上下文；不入错误信息（返回给前端的报错和抛给上游的异常都是对外出口）。
把第三条展开，这是本题的差异点：密钥一旦进了上下文，就意味着它会被送到模型厂商、被存进会话历史、被写进 trace，然后在某一次提示词注入里被完整地念出来。正确的形态是 Agent 需要的是「能调用某个 API」这个能力，而不是那把钥匙本身——密钥留在工具的实现里，模型只看得到工具名和参数。
再给落地手段：日志出口统一脱敏，不靠调用方自觉。靠每个人写日志时记得手动打码，一定会漏。做法是在唯一的日志出口做替换，两条路一起用——进程里已知的密钥值整段替换，再用通用形状兜底那些不是从环境变量来的密钥。异常处理那一支也要走同一个出口，堆栈里经常夹着带密钥的连接串。
存储与轮换：本地开发用 .env 加 gitignore；线上走密钥管理服务，进程启动时按自己的身份去取，不要把值烤进镜像或写进部署清单。轮换要双活——同时允许新旧两把 key，流量切到新 key、观察到没有旧 key 的调用了再吊销，一次性替换必然在某个副本上留下失败窗口。
可以预期的追问：轮换周期定多久？周期是次要的，真正要演练的是「能不能在 5 分钟内换掉一把疑似泄漏的 key」。答得出这一句，说明你想的是事故响应而不是合规打卡。
Key points
Four nevers: never in code, never in logs, never in the LLM context, never in error messages
The agent-specific one is the context — anything there reaches the vendor, the history and the traces, and can be read out by an injection
The agent needs the capability to call an API, not the key; the key stays inside the tool implementation
Redact at one logging exit instead of trusting callers, and route the exception path through it too
Use a secret manager with workload identity in production, and rotate dual-key: accept both, shift traffic, verify no old callers, then revoke
答题要点
四不入：不入代码、不入日志、不入 LLM 上下文、不入错误信息
Agent 特有的一条是不入上下文——进了上下文就会被送到厂商、存进历史、写进 trace，并可能被注入念出来
Agent 需要的是「能调用某个 API」的能力而不是钥匙本身，密钥留在工具实现里
日志出口统一 redact，不靠调用方自觉；异常路径走同一个出口，堆栈里常夹着连接串
线上走密钥管理服务按身份拉取；轮换用双活，新旧同时有效、切流量、确认无旧调用再吊销

D23 MCP and Skills: the Protocol, Server/Client, How It Differs From Function Calling; a Tour of the Claude Agent SDK

What roles do the MCP server and client play, what can a server expose, and which transports exist?MCP 里 server 和 client 分别承担什么角色？server 能暴露哪几类东西，传输方式有哪些？
Common in ChinaCommon overseasIntermediate#mcp#protocol#transport
How to reason about it · think before answering
This looks like recall, but it discriminates on two small things: whether you separate host from client, and whether you know there are primitives beyond tools. 'Server provides tools, client calls them' is below the bar.
Lay out three roles: the server is the capability provider and its own process; the client is the piece inside the host that talks to exactly one server; the host is your agent application, holding several clients at once. People who conflate host and client fall apart the moment you ask how they would connect to three servers.
Cover all three server-side primitives and say who chooses each: tools are executable actions chosen by the model; resources are read-only data addressed by URI; prompts are reusable templates — the latter two are normally chosen by the user or host. That 'who chooses' framing shows you actually read the spec: modelling a large document as a resource rather than a tool moves the decision to spend those tokens from the model back to a human.
The client side declares capabilities too, letting the server call back into the host: sampling asks the host to run a model completion, roots tells the server which directories are visible, elicitation asks the host to collect user input. Naming them without elaborating is the right level of detail.
Two transports: stdio for a local subprocess, Streamable HTTP for remote. The dated detail worth knowing is that the older two-endpoint HTTP+SSE transport is now legacy, kept only for backwards compatibility — presenting it as current signals you read last year's blog posts.
Expect the follow-up: anything special about stdio servers? Stdout is reserved for JSON-RPC, so every log line must go to stderr or the client receives unparseable messages; and the host owns the subprocess lifecycle, so it must reap the child on exit or leave orphans behind.
分析过程 · 先想清楚再作答
这题看着是背概念，实际区分度在两个小地方：一是能不能把宿主和 client 分开说，二是知不知道 tools 之外还有别的原语。只答「server 提供工具、client 调用工具」是及格线以下。
先把三个角色摆清楚：server 是能力提供方，一个独立进程；client 是宿主里负责跟某一个 server 说话的那一小块，一个 client 只连一个 server；宿主是你的 Agent 应用，它同时持有多个 client。很多人把宿主和 client 当成一个东西，一问「连三个 server 怎么办」就露馅。
server 侧三种原语要一起说，并且要说清谁来选：tools 是可执行的动作，由模型来挑；resources 是按 URI 读的只读数据；prompts 是可复用的提示词模板，后两者通常由用户或宿主来挑。这句「谁来选」比原语名字本身更能体现你真读过协议——把一份大文档做成 resource 而不是 tool，等于把花不花这笔 token 的决定权从模型手里收回给人。
client 侧也能声明能力让 server 反过来请求宿主：sampling 是让宿主跑一次模型补全，roots 是告诉 server 哪些目录可见，elicitation 是请宿主向用户要一条输入。知道有这三样、不展开，分寸刚好。
传输两种：stdio 用于本地子进程，Streamable HTTP 用于远程。这里有个时间戳式的加分点——旧的 HTTP 加 SSE 双端点传输已经被标为 legacy，只为兼容老客户端保留；把它当现行方案讲，等于告诉对方你看的是去年的文章。
可以预期的追问：stdio server 有什么特别要注意的？答 stdout 被 JSON-RPC 独占，所有日志必须走 stderr，否则 client 会收到解析不了的消息；另外子进程的生命周期归宿主管，退出时要杀掉，不然留一堆孤儿进程。
Key points
The server is the capability provider in its own process; a client connects to exactly one server; the host holds many clients
Three server-side primitives: tools chosen by the model, resources as URI-addressed read-only data, prompts as reusable templates — the latter two usually chosen by a human
Clients can declare sampling, roots and elicitation so the server can call back into the host
Two transports: stdio for local subprocesses and Streamable HTTP for remote; the old HTTP+SSE transport is legacy
On stdio, stdout belongs to JSON-RPC so logs must go to stderr, and the host must reap the child process
答题要点
server 是能力提供方（独立进程），client 是宿主里连接单个 server 的那一块，宿主可以同时持有多个 client
server 侧三种原语：tools 由模型挑，resources 是按 URI 读的只读数据，prompts 是可复用模板，后两者通常由人来挑
client 侧还能声明 sampling、roots、elicitation，让 server 反过来请求宿主做事
传输两种：stdio（本地子进程）与 Streamable HTTP（远程）；旧的 HTTP 加 SSE 已是 legacy，不要当现行方案讲
stdio server 的 stdout 被 JSON-RPC 独占，日志必须走 stderr；子进程生命周期由宿主负责回收
When should you reach for MCP instead of plain function calling, and what does it cost when you shouldn't?什么场景下应该考虑用 MCP，而不是直接写 function calling？不该用的时候硬上会付出什么代价？
Common in ChinaCommon overseasIntermediate#mcp#architecture#trade-offs
How to reason about it · think before answering
The hinge is the second half. Answering only 'MCP is more standard and decoupled' is like saying 'microservices are more decoupled' — true-sounding but with no criterion, and the interviewer will immediately ask whether you turned every tool into an MCP server.
Give three actionable criteria: the capability must be reused by more than one host, owned by another team or a third party, or added and removed without changing host code. Any one of them justifies MCP; none of them means write a local function. Making 'no' the default answer shows more engineering judgment than the criteria themselves.
Attach a reason to each: multi-host reuse turns N times M into N plus M; external ownership makes the process boundary the responsibility boundary, so their change is not your release; hot-swapping demotes adding an internal tool from a deployment to a config change.
Then state the costs honestly, which is where shipped experience shows: another process to keep alive, another handshake with its own timeouts and reconnects, and a debugging path that went from one hop to three — a tool that never got called might mean the model did not pick it, the schema lost fields in translation, or the server never started. On stdio you also own reaping the child process.
One more point that is easy to miss and scores well: MCP does not change your cost structure. Tool descriptions still enter the context every turn, and more tools still degrade tool selection. The rule that you should consolidate tools past a certain count survives MCP unchanged — arguably it matters more, because now other people can add entries to your tool list.
Expect the follow-up: so internal tools never go through MCP? Not quite. If you want the same capability available to an IDE assistant and an ops bot as well, the first criterion is met even though you own the code.
分析过程 · 先想清楚再作答
题眼在后半句。只会说「MCP 更标准更解耦」的人，等于说「微服务更解耦」——听起来对，但没有判据，面试官会立刻追问「那你们所有工具都做成 MCP server 了吗」。
先给判据，而且要是可执行的三条：能力要被多个宿主复用、能力由另一个团队或第三方维护、需要不改宿主代码就能增删能力。命中任意一条才考虑，**一条都不命中就直接写本地函数**——把默认答案摆成「不上」，这条比三条判据本身更能体现工程判断。
每条判据配一句为什么：多宿主复用把 N 乘 M 变成 N 加 M；别人维护时进程边界就是责任边界，他们改他们的、你不用发版；热插拔让加一个内部工具从一次发布降级成一次配置变更。
然后老实说代价，这是区分「用过」和「读过」的地方：多一个进程要保活、多一次握手要处理超时与重连、排障链路从一段变三段——工具没被调用，现在可能是模型没选、可能是 schema 翻译时丢了字段、也可能是 server 压根没起来。stdio 的子进程还要你自己回收，否则留孤儿进程。
还有一条容易被忽略但很加分：MCP 不改变你的成本结构。工具描述照样每轮都进上下文，工具多了照样会让模型选错——D5 那条「工具超过一定数量就该合并描述」在接了 MCP 之后一字不变，甚至更需要，因为现在别人可以往你的工具列表里塞东西。
可以预期的追问：那内部工具一律不上 MCP 吗？不是。有一类值得例外——你希望它能被 IDE 里的助手和运维机器人一起用，那第一条判据就命中了，即使它是你自己维护的。
Key points
Three criteria, any one justifies MCP: reuse across hosts, ownership by another team, or add/remove without touching host code
The default is no — if none of the three apply, a local function is the better engineering decision
Costs: another process to supervise, another handshake with timeouts, and a debug path that grows from one hop to three
MCP does not change your cost structure: descriptions still enter context every turn and too many tools still hurt selection
Once third-party capabilities are attached, your tool list is no longer fully under your control, which is itself a design problem
答题要点
三条判据，命中任意一条才考虑 MCP：多宿主复用、由他人维护、需要不改代码增删能力
默认答案是不上：三条都不命中就直接写本地函数，这是更好的工程决策
代价是多一个进程要保活、多一次握手要处理超时、排障从一段链路变成三段
MCP 不改变成本结构：工具描述照样每轮进上下文，工具过多照样会让模型选错，该合并还是要合并
第三方能力接进来之后，工具列表不再完全由你掌控，这本身就是需要设计的一件事

D24 RAG, Level Up: Hybrid Search, Reranking, Citations, Recall Evaluation

How do you merge two retrieval rankings, and why not just take a weighted sum of the scores?两路检索结果怎么合并？为什么不能直接加权求和？
Common in ChinaCommon overseasIntermediate#rag#rrf#ranking
How to reason about it · think before answering
The second half is the real question. Anyone can say 'RRF'; explaining why weighted sums fail is what separates people who have looked at the score distributions.
Decompose it: are the two scores even the same unit? Cosine similarity is bounded in 0 to 1 and tightly clustered — candidates often differ by 0.02. BM25 is unbounded and a few rare-term hits reach 12. Adding them lets the larger-magnitude channel decide everything; the weight only tunes how much it dominates.
Worse, it is unstable. Weights tuned on one corpus drift on the next, so you re-tune forever.
Conclusion: fuse ranks, not scores. RRF maps each rank to 1/(k + rank) and sums, with k = 60. Ranks are unitless and need no calibration. k flattens the head of the list so that 'top-ranked in both channels' beats 'first in one channel' — consensus over single-source confidence.
A hand-checkable example helps: rankings [a,b,c] and [c,d,a] give a = 1/61 + 1/63 ≈ 0.0323, while a raw score sum promotes c on the strength of its BM25 12.
Expected follow-up: what about ties? You must break them explicitly, e.g. by id. Otherwise ordering depends on hash-map iteration order and differs across languages and runs, which makes your evaluation numbers irreproducible. Mentioning this signals you actually ran it more than once.
分析过程 · 先想清楚再作答
题眼在后半句。前半句答「RRF」谁都会，后半句「为什么不能加权求和」才是筛人的地方——它考的是你有没有真的看过两路分数的分布。
怎么拆：先问自己两个分数是不是同一个量纲。余弦相似度有界（0 到 1）且分布密集，同一批候选常常只差 0.02；BM25 无上界，命中几个稀有词就能到 12 分。**不同量纲的数相加，等于让量纲大的那一路单方面决定结果**，权重只是在调「它说了算的程度」。
更麻烦的是它不稳定：权重在这批语料上调好了，换一批语料分布就变了，得重调。这是一个永远还不完的技术债。
结论：改用名次。RRF 把每一路的名次折算成 `1/(k + rank)` 再相加，k 取 60。名次是无量纲的，不需要任何标定。k 的作用是压平头部差距，让「两路都进前列」压过「一路排第一」——共识优先于单点自信。
一个能当场手算的例子很加分：两路排名 [a,b,c] 与 [c,d,a]，a 得 1/61 + 1/63 ≈ 0.0323；而分数直接相加的版本会把 BM25 里 12 分的 c 顶到第一。
可预期的追问：同分了怎么办？必须显式定序（比如按 id），否则结果取决于哈希表遍历顺序，同一份输入在不同语言、不同运行里给出不同排序——评估集量出来的数字也就不可复现了。这一条答出来会非常加分，因为它说明你真的跑过多次。
Key points
Use RRF: map each channel's rank to 1/(k + rank) and sum, with k = 60.
Weighted sums fail because the scores are different units — bounded, tightly clustered cosine versus unbounded BM25, so BM25 decides the outcome.
Weights also do not transfer: tuned on one corpus, they drift on the next.
Ranks are unitless and need no calibration; k flattens the head so cross-channel consensus outweighs single-channel confidence.
Break ties explicitly (by id) or ordering depends on hash iteration order and your evaluation numbers stop being reproducible.
答题要点
用 RRF：每一路的名次折算成 1/(k + rank) 再相加，k 取 60。
不能加权求和是因为两个分数量纲不同——余弦有界密集、BM25 无上界，相加等于让 BM25 单方面决定结果。
而且权重不可迁移：这批语料调好，换一批就得重调，是还不完的债。
名次是无量纲的，不需要标定；k 压平头部差距，让两路共识压过单路自信。
同分必须显式定序（按 id），否则结果依赖哈希表遍历顺序，评估数字不可复现。
How is reranking usually implemented, what problem does it solve, and what does it cost?重排（rerank）一般怎么实现？它解决了初步检索的什么问题，代价是什么？
Common in ChinaCommon overseasIntermediate#rag#rerank#latency
How to reason about it · think before answering
The lazy answer is 'sort again, more accurately'. What the interviewer wants is why the first pass cannot rank well, and why reranking cannot run over the whole corpus.
Decompose: the first pass ranks by retrieval signals — cosine distance or term statistics — which are designed to scan millions of items fast, and coarseness is the price. Reranking changes the algorithm: query and candidate go into one model together (a cross-encoder), which is far more accurate but costs one forward pass per candidate. Hence it must sit behind a wide recall stage.
Distinguish two implementations. For teaching or prototypes, batch-score with an LLM (0-10 for 40 candidates in one call). Production uses a trained cross-encoder reranker. Name the cost: an extra 100-300 ms hop plus an inference box — it is not a per-token API, it consumes capacity.
Framing it as a funnel is clearest: recall sets the ceiling, reranking decides whether what is under the ceiling reaches the top five. Measured: adding the keyword channel lifts recall@20 from 83% to 95%; adding reranking moves recall@20 only to 98%, but recall@5 jumps from 80% to 91% and MRR from 0.732 to 0.908.
Expected follow-up 1: does reranking improve recall? No. It introduces no new candidates, so recall@20 is the wrong metric to judge it by.
Expected follow-up 2: why not ship LLM scoring to production? Unpredictable latency, per-token cost, scores that drift with prompt wording, and no clean path to offline distillation.
分析过程 · 先想清楚再作答
这题最容易答成「再排一次序，更准」。面试官想听的是**为什么第一轮不能直接排准**，以及**为什么重排不能对全库做**。
怎么拆：第一轮的排序依据是「检索信号」——余弦距离或词频统计，它们是为了能在百万条里快速筛选而设计的，代价就是粗。重排换了一种算法：把 query 和候选**拼在一起**送进同一个模型算相关度（cross-encoder），精度高得多，但复杂度是每条候选一次前向，没法对全库做。所以它必须跟在一个宽召回后面。
结论要区分两种实现：教学 / 原型可以用 LLM 批量打分（一次调用给 40 条打 0 到 10 分），生产用专门训练的 cross-encoder 重排模型。**代价说清楚：多一次 100 到 300 毫秒的调用，外加一台推理机器**——它不是按 token 计费的 API，是要占资源的。
把它放进漏斗里说最清楚：召回决定天花板，重排决定天花板上的东西能不能排到前五。实测的样子是——加了关键词那一路，recall@20 从 83% 涨到 95%（天花板抬高）；再加重排，recall@20 只到 98%，但 recall@5 从 80% 跳到 91%、MRR 从 0.732 到 0.908。
可预期的追问一：重排能不能提高召回？不能。它不引入新候选，只重排已有的那批——所以看 recall@20 判断重排效果是错的指标。
可预期的追问二：为什么不用 LLM 打分上生产？延迟不可控、成本按 token 走、分数会随提示词措辞漂移，而且没法做批量离线蒸馏。
Key points
The first pass ranks by retrieval signals so it can scan a large index fast; coarseness is the trade.
Reranking feeds query and candidate through one model together (cross-encoder): much sharper, but one forward pass per candidate, so only tens of items.
Batch LLM scoring works for teaching; production uses a dedicated reranker, costing an extra 100-300 ms hop plus an inference box.
Reranking does not raise recall — it raises recall@5 and MRR (measured 80% to 91%, 0.732 to 0.908) while recall@20 barely moves from 95% to 98%.
So judge a reranker by small-k metrics, never by recall@20.
答题要点
第一轮按检索信号粗排（余弦、词频），为的是能在大库里快速筛，代价是粗。
重排把 query 和候选拼在一起过同一个模型（cross-encoder），精度高但每条一次前向，只能对几十条做。
教学版可用 LLM 批量打 0 到 10 分；生产用专用重排模型，代价是多一次 100 到 300 毫秒的调用加一台推理机器。
重排不提高召回，它提高的是 recall@5 与 MRR——实测 80% → 91%、0.732 → 0.908，而 recall@20 只从 95% 到 98%。
所以判断重排效果要看前 k 小的指标，不要看 recall@20。

D25 The Frontend Agent Experience: Streaming Rendering, Visualizing Tool Calls, Interrupt/Retry, SSE Hooks

What is different about frontend state management under streaming, and why not call setState on every token?流式场景下前端的状态管理要注意什么？为什么不能每个 token 都 setState？
Common in ChinaCommon overseasIntermediate#react#streaming#performance
How to reason about it · think before answering
This question probes whether you have watched a long reply drop frames. 'Keep messages in useState and setState on each delta' is functionally correct but reveals you only tried short replies.
Do the arithmetic first: streaming delivers tens of tokens per second, so one setState per token means tens of full render passes per second. The message list keeps growing, so each pass gets more expensive as the conversation goes — the jank peaks late in long replies and long sessions, exactly when it hurts most.
The fix is batching: append tokens into a ref without rendering, and flush the accumulated text on a 30 ms timer. Thirty milliseconds is roughly 33 fps, still a smooth typewriter, while render count drops by one to two orders of magnitude — measured, 200 tokens produced 8 commits.
Three details that must ship with it: force a final flush when the stream ends, or the last sub-batch stays in the buffer and the user sees a truncated reply; flush on interrupt too, so the user sees exactly where it stopped; and keep the buffer in a ref, not state, or the code you wrote to avoid renders is itself causing them.
One level up is layering: streaming logic should live outside React. Parsing, event reduction and batching are pure functions; a store holds state and exposes subscribe and getSnapshot; React only calls useSyncExternalStore. The concrete payoff is that this logic can be unit tested with no browser instead of being click-tested.
Expected follow-up: why not just use a state library? Libraries solve cross-component sharing and update granularity, while the hard parts here are lifecycle (connect, cancel, cleanup on unmount) and flush cadence — no library does those for you. The interviewer wants your reasoning, not your library list.
分析过程 · 先想清楚再作答
这题考的是「你有没有在长回复下真的看过掉帧」。答「用 useState 存消息数组，收到 delta 就 setState」在功能上没错，但它暴露的是只在短回复上试过。
先算一笔账：流式一秒来几十个 token，每个 token 一次 setState 就是一秒几十轮完整渲染。而消息列表是越来越长的，每一轮的代价随对话轮数增长——所以卡顿在回复后半段和长会话里最明显，正好是最不该卡的时候。
做法是攒批：token 先追加进 ref（不触发渲染），一个定时器每 30 毫秒把攒下的一次性提交。30 毫秒约等于 33 帧每秒，肉眼仍是连续的打字机，渲染次数掉一到两个数量级——实测 200 个 token 只提交 8 次。
三个必须配套的细节：流结束时强制 flush 一次（否则最后不足一个批次的内容永远留在缓冲里，用户看到回复少半句）；打断时也要 flush（让用户看到停在哪个字）；缓冲状态必须放 ref 不放 state，否则你为了省渲染写的代码本身在触发渲染。
再往上一层是分层：**流式逻辑应该活在 React 外面。** 解析、事件归并、攒批都是纯函数，store 持有状态并暴露 subscribe 和 getSnapshot，React 侧只用 useSyncExternalStore 订阅。这样做的直接好处是**这套逻辑可以在没有浏览器的环境里跑单元测试**，而不是只能靠手点。
可预期的追问：为什么不直接用某个状态库？答：状态库解决的是跨组件共享和更新粒度，而流式的难点在生命周期（连接、取消、卸载清理）和批处理频率——这两件事没有哪个库替你做。面试官问这题想听的是你怎么想，不是你会用哪个库。
Key points
One setState per token means tens of full renders per second, and each render costs more as the list grows — long replies jank at the end.
Batch instead: accumulate tokens in a ref and flush every 30 ms; measured, 200 tokens produced only 8 commits.
Ship the details with it: force a flush on stream end and on interrupt, and keep the buffer in a ref rather than state.
Keep parsing, event reduction and batching as pure functions outside React; subscribe via useSyncExternalStore.
The payoff of that split is unit-testable streaming logic with no browser in the loop.
答题要点
每个 token 一次 setState 等于一秒几十轮全量渲染，而消息列表越长每轮越贵，长回复后半段必然掉帧。
做法是攒批：token 进 ref 不触发渲染，30 毫秒定时 flush 一次，实测 200 个 token 只提交 8 次。
必须配套：流结束和打断时强制 flush；缓冲放 ref 不放 state。
流式逻辑（解析、归并、攒批）应该是 React 之外的纯函数，React 只用 useSyncExternalStore 订阅。
这样分层的直接好处是能脱离浏览器做单元测试，而不是只能手点验证。
How do you design retry so it does not duplicate side effects, and should the tool-call process be visible to the user?失败重试怎么设计才不会产生重复副作用？工具调用过程要不要暴露给用户？
Common in ChinaCommon overseasIntermediate#idempotency#retry#ux
How to reason about it · think before answering
The question bundles two topics, and the test is whether you see what they share: both turn invisible intermediate state into something the user can act on. Answering them separately is fine, but naming the link reads as senior.
Chain for retry: retrying means the same message may execute twice, costing double tokens and possibly duplicating irreversible tool calls such as issuing a refund twice. Hence idempotency. The key must be generated by the client on the first attempt and resent unchanged on retry, and the backend enforces it with a unique constraint, reattaching to the existing run instead of creating a new one.
State the decision rule clearly: when do you mint a new key? The rule is whether the content being sent changed, not which button the user pressed. Same message retried keeps the key; edited content is a new message and needs a new key.
Mentioning how far this pattern reaches scores well: write deduplication, cron ticks consumed exactly once, cross-service delivery, and frontend retry — the same shape at four layers, with the database's unique constraint always the final arbiter rather than an application-level check-then-write.
For tool visibility: expose the process, for three reasons. The user can decide whether to interrupt instead of waiting blind; waiting becomes tolerable, since a spinner for fifteen seconds invites a page refresh that wastes the whole turn; and when something breaks the user can say 'it hung on looking up my order', which saves everyone time.
Expected follow-up: does exposing everything leak internals? It can, so filter. Show human-readable tool names rather than function names, hide user identifiers, internal ids and secrets from the arguments, and show classified error reasons rather than raw stack traces. You are surfacing the process, not the internal structure.
分析过程 · 先想清楚再作答
这题把两件事绑在一起问，考的是你能不能看出它们的共同点：**都是「把不可见的中间状态变成可控的」**。分开答也行，但点出这层关系会显得成熟。
重试这一半的推导链：重试意味着同一句话可能被执行两遍 → 两倍 token，还可能两次不可逆的工具调用（比如退款打两次钱）→ 所以要幂等 → 幂等键必须由**客户端在第一次发送时生成**并在重试时原样带上 → 后端拿它做唯一约束，命中就把已有 run 的流接回来，而不是新建。
关键判据要说清：**什么时候该换新键？** 判据是「要发送的内容变没变」，不是「用户点了哪个按钮」。同一句话重试用同一个键；用户改了内容重新发，那是新的一句话，必须换新键。
顺带提一句这一招的复用面会很加分：落库去重、定时任务防止一个 tick 被消费两次、跨服务调用防重复投递、前端重试——同一个形状用在四个层面，最终裁判永远是数据库的唯一约束，不是应用层的先查后写。
工具可视化这一半：中间过程要暴露，理由有三条——用户能判断要不要打断（不然他只能盲等）；等待变得可以忍受（十几秒的转圈会让人刷新页面，而刷新意味着这一轮的钱白花）；出问题时用户能说清「卡在查订单那一步」，客服和你都省事。
可预期的追问：全都暴露会不会泄露内部实现？会，所以要过滤——工具名用人话不用函数名，参数里的用户标识、内部 id、密钥一律不显示，错误显示归类后的原因而不是原始堆栈。**可视化的是过程，不是内部结构。**
Key points
Retry carries the idempotency key minted on the first attempt; the backend hits a unique constraint and reattaches to the existing run.
The rule for minting a new key is whether the content changed — same message keeps the key, edited content gets a new one.
The same pattern recurs in write dedup, cron ticks, cross-service delivery and frontend retry, always arbitrated by a database unique constraint.
Make tool calls visible so users can decide whether to interrupt, tolerate the wait, and describe where it hung.
But filter: human-readable tool names, no internal ids or secrets in the arguments, classified error reasons instead of raw stack traces.
答题要点
重试要带客户端首次生成的幂等键，后端用唯一约束命中后把已有 run 的流接回来，不新建。
换不换键的判据是「内容变没变」：同一句话重试用同一个键，改了内容才换新键。
同一招在落库、定时任务、跨服务调用、前端重试四处复用，最终裁判永远是数据库的唯一约束。
工具调用要可视化：用户才能判断要不要打断、等待变得可忍受、出问题时说得清卡在哪一步。
但要过滤：工具名用人话、参数里的内部 id 与密钥不显示、错误显示归类原因而不是原始堆栈。

D26 System Design Deep Dive: Agent Platforms / Customer-Support Agents / Multi-Tenancy / Cost Control

For a multi-tenant agent service, how do you design data isolation and billing isolation, and when do you move from a shared table to a dedicated database per tenant?一个多租户的 Agent 服务，数据隔离和计费隔离要怎么设计？什么时候该从共享表升级到独立库？
Common in ChinaCommon overseasIntermediate#system-design#multi-tenancy#isolation
How to reason about it · think before answering
The hinge is that 'isolation' is plural. Plenty of candidates answer only data isolation, but the layer that actually breaks in production is resources: one tenant's spike starves everyone else, no rows leak, and users still complain. Open with all three — data, resources, billing — and note that each missing layer maps to its own class of incident.
On data, one sentence separates people who shipped this from people who read about it: 'every query carries tenant_id' versus 'row-level security is the backstop'. The first eventually misses a query, and the one it misses is always the newest, least-tested feature. The correct framing is that RLS is the gate and the application-level where clause is just an optimisation — the same reasoning as idempotency being adjudicated by a database unique constraint. Whatever the data layer can enforce should not depend on everyone remembering.
On resources, give two concrete things: a rate-limit bucket per tenant, and workers sharded by a hash of the tenant id. That is the same sharding mechanism used to preserve per-user ordering, with a different hash input and a different purpose — containing spikes rather than serialising. Noisy neighbours hurt more in agent workloads because a single execution can run thirty seconds, so a thousand queued items from one tenant leaves everyone else waiting.
Billing is the simplest and the most often forgotten: add a tenant column to the token usage ledger and tag every write. Invoicing, quotas and over-budget degradation all hang off it. Bring the cost figures too — roughly $0.0006 per turn at 2000 in and 500 out, about $900 a month at 10k daily actives and five turns each — because quoting per-tenant economics shows you actually ran the numbers.
Then the escalation criteria, the second discriminator. Three tiers: shared table with a tenant column, schema per tenant, database per tenant. The trigger is not tenant count, it is whether a single tenant can starve the rest and whether there is a hard compliance requirement. 'Split the database past a hundred tenants' is guesswork: a hundred small tenants share a table happily, while one regulated enterprise customer may require physical separation on its own. State the cost too — a database per tenant looks clean, but migrations, backups, monitoring and connection pools all multiply by tenant count, so operational cost jumps rather than scaling linearly.
Expect the sharpest follow-up: does the idempotency key change under multi-tenancy? The algorithm does not, but its scope must include the tenant id. Without it, two tenants whose clients independently produce the same string — both using order id order-1024 — collide, and the later request is rejected by the unique constraint as a duplicate. One tenant's write is swallowed by another tenant's history, both logs look perfectly normal, and it is the hardest class of multi-tenant bug to find.
分析过程 · 先想清楚再作答
这题的题眼在「隔离」是复数。只答数据隔离的候选人非常多，而多租户翻车最多的其实是资源那一层——一个租户的洪峰打穿别人的处理能力，数据一条都没串，用户照样投诉。所以第一句先把三层摆出来：数据、资源、计费，缺哪一层对应一类事故。
数据这一层，判断一个人有没有真做过就看一句话：他说「每条查询都带 tenant_id」还是「靠数据库的行级安全兜底」。前者迟早会漏一处，而漏掉的那处通常是最新加、最没被测过的功能。正确说法是行级安全是闸门，应用层那句 where 只是优化——这和幂等的最终裁判必须是数据库唯一约束，是同一种思路：能在数据层强制的，不要指望每个人写代码时都记得。
资源这一层给两件具体的东西：每个租户一个独立限流桶，以及 worker 按租户标识哈希分片。分片这一招和「按用户哈希保住同一用户顺序」是同一套机制，只是哈希的输入换了，目的从保序变成隔离洪峰。Agent 场景里噪声邻居格外突出，因为单次执行可能跑三十秒，一个租户灌一千条进来，别人就得排队。
计费这一层最简单也最容易漏：token 用量台账加一列租户标识，写入时打标。账单、配额、超支降级三件事全靠它。顺带说一句成本口径——单轮 2000 输入加 500 输出约 0.0006 美元，日活 1 万人均 5 轮约每月 900 美元，能报出这个量级说明你真的算过每租户成本。
然后回答升级判据，这是本题的第二个区分点。三档是共享表加租户列、schema 级、库级；**判据不是租户数量，是「有没有单个租户能把别人拖垮」和「有没有合规硬要求」**。答「超过一百个租户就该分库」是典型的凭感觉，因为一百个小租户共享一张表毫无问题，而一个受监管的大客户哪怕只有一个也可能必须物理隔离。代价要一起说：库级隔离看着干净，但迁移脚本、备份、监控、连接池全部乘以租户数，运维成本是陡增不是线性。
可以预期的追问，也是最见功力的一问：幂等键在多租户下要不要变？答案是键的算法不用变，但**作用域必须带上租户标识**。不带的话两个租户的客户端各自生成了同一个字符串（都用订单号 order-1024），后来那个会被唯一约束当成重复请求挡掉——一个租户的写入被另一个租户的历史请求吞掉，两边日志都完全正常，是多租户里最难查的一类 bug。
Key points
Three parallel layers, each missing one causing its own class of incident: data, resources, billing
Data isolation is backstopped by row-level security; the application where clause is only an optimisation
Resource isolation is a per-tenant rate-limit bucket plus sharding workers by tenant hash, aimed at noisy neighbours
Billing isolation is a tenant column on the usage ledger, powering invoices, quotas and degradation
Escalate to schema or database isolation based on starvation risk and compliance mandates, not tenant count
Per-tenant databases multiply migrations, backups, monitoring and connection pools — operational cost jumps
The idempotency key algorithm stays, but its scope must include the tenant id or identical keys across tenants collide
答题要点
三层隔离并列，缺一层对应一类事故：数据、资源、计费
数据靠行级安全兜底，应用层的 where 只是优化——能在数据层强制的不要靠人记得
资源是每租户独立限流桶加按租户标识哈希分片，防的是噪声邻居而不是数据串
计费是台账加一列租户标识，账单、配额、超支降级全靠它
升级到 schema 级或库级的判据是「单租户能否拖垮别人」与「有没有合规硬要求」，不是租户数量
库级隔离的代价是迁移、备份、监控、连接池全部乘以租户数，运维成本陡增
幂等键算法不变，但作用域必须带租户标识，否则两个租户的同名键会互相挡掉请求
An agent system's model spend is out of control. Which levers do you pull, in what order, and roughly how much does each save?一个 Agent 系统的模型成本失控了，你会从哪几个层面着手控制？每一层大概能省多少？
Common in ChinaCommon overseasIntermediate#system-design#cost#capacity-planning
How to reason about it · think before answering
The reflex answer is 'switch to a cheaper model', and it is also the easiest one to get killed on: the follow-up is 'how do you know quality did not drop', and without an offline eval set and a comparison run you are exposed. The right opening is 'look at the ledger first' — slice by user, by day and by model to find which dimension is growing. Locate before you act.
Second, put the baseline on the table, because cost talk without a baseline is noise. At 2000 input and 500 output tokens per turn, input is 2000 over a million times $0.15 which is $0.0003, output is 500 over a million times $0.60 which is also $0.0003, so about $0.0006 per turn. 10k daily actives at five turns is 50k turns, roughly $30 a day and $900 a month.
Then give five layers ordered by the cost you pay, not by the savings: caching and prompt caching, tiered model routing, context compression, step and tool budget caps, rate limiting and degradation. The ordering is part of the answer, because it also communicates your rollout sequence.
Attach a number derived from the baseline to each layer. Caching at a 15% hit rate takes $900 to roughly $765. For tiered routing, state the precondition honestly: it is the only layer that can change the order of magnitude, but only if your baseline runs a flagship model — if you already run the cheapest tier there is nothing left to squeeze. Saying that out loud is far more credible than inventing a savings percentage. Compression takes input from 2000 to 1200 tokens, so $0.00048 per turn, about $720 a month, a 20% cut.
Layer four is usually mis-sold as savings; what it actually buys is predictability. With a cap of five tool calls per subtask, per-turn cost finally has a ceiling: five calls each feeding back 800 tokens pushes input to 6000, so $0.0012 per turn, exactly double the baseline — and with no cap there is no ceiling at all. The right phrasing is 'this does not save money, it makes the bill predictable'.
Layer five is rate limiting and degradation, last because it costs the most: $900 across 10k daily actives is about $0.09 per user per month, so a $1 monthly hard cap is invisible to real users and only stops scripted abuse. The nuance is degrade before refusing — this is the only layer users can feel.
Expect the follow-up: which layer first? Say layers one and three, because they only touch your own code, change no product promise, and need no quality re-validation, whereas tiered routing needs an eval set and rate limiting needs product buy-in.
分析过程 · 先想清楚再作答
这题最容易脱口而出的答案是「换个便宜模型」，也是最容易被追死的答案——面试官紧跟着就问「你怎么知道换了质量不掉」，答不出离线评估集和对比实验就露馅了。正确的第一句是「先看台账」：按用户、按天、按模型各切一刀，找出是哪一维在涨。先定位再动手，这是工程习惯。
第二步是把基准摆到桌上，没有基准的成本讨论全是废话。单轮 2000 输入加 500 输出，输入 2000 除以一百万乘 0.15 等于 0.0003 美元，输出 500 除以一百万乘 0.60 也等于 0.0003 美元，一轮约 0.0006 美元；日活 1 万、人均 5 轮就是 5 万轮，一天约 30 美元、一个月约 900 美元。
然后给五层，排序的依据是**你要付出的代价从小到大**，不是省钱多少：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级。这个顺序本身就是答案的一部分，因为它同时说明了你的落地顺序。
每层配一个从基准推出来的数字。缓存按一成半命中估，900 降到 765 左右。分级路由要诚实说清前提：它是唯一能改数量级的一层，但前提是你的基准用的是旗舰模型；基准已经是最便宜那档时这一层榨不出东西——主动说破这一条，比硬编一个省钱比例可信得多。上下文压缩把输入从 2000 压到 1200，单轮变成 0.00048 美元，一个月 720 美元，降两成。
第四层最容易被讲成「省钱」，其实它买的是**可预测**：给每个子任务设 5 次工具调用上限之后，单轮成本才有上界——调满 5 次、每次结果回灌 800 token，输入涨到 6000，单轮 0.0012 美元，正好是基准的两倍；没有上限时这个数字没有上界。这一层的正确说法是「我不是靠它省钱，我是靠它让账单可以被预测」。
第五层是限流与降级，代价最大所以放最后：900 美元摊到 1 万日活是每人每月 0.09 美元，给单用户设 1 美元硬顶，正常用户碰不到，挡的是脚本刷接口那种极端户。要点是超预算先降档再拒绝，而不是直接拒绝——它是五层里唯一用户能感觉到的一层。
可以预期的追问：这五层里哪一层最先做？答「第一层和第三层」，因为它们只改自己的代码、不动产品承诺、也不需要重新验证质量；而分级路由要配离线评估集，限流要配产品沟通，都不是当天能上的。
Key points
Open with 'look at the ledger', not 'use a cheaper model': slice by user, by day and by model to locate the growth
Set a baseline: about $0.0006 per turn, roughly $30/day and $900/month at 10k DAU and five turns
Five layers ordered by cost to you: caching and prompt cache, tiered routing, context compression, step and tool budget caps, rate limiting and degradation
Tiered routing is the only order-of-magnitude lever, but only if the baseline is a flagship model — say so when it is not
Compression from 2000 to 1200 input tokens gives $0.00048 per turn, about $720/month, a 20% cut
Tool budget caps buy predictability: with a cap the per-turn ceiling is $0.0012, without one there is no ceiling
Rate limiting comes last because users feel it; degrade before refusing
答题要点
第一句不是「换便宜模型」，是「先看台账」：按用户、按天、按模型各切一刀定位是哪一维在涨
先立基准：单轮约 0.0006 美元，日活 1 万人均 5 轮约每天 30 美元、每月 900 美元
五层按代价从小到大：缓存与 prompt cache、模型分级路由、上下文压缩、步数与工具预算上限、限流与降级
分级路由是唯一能改数量级的一层，但前提是基准用的是旗舰模型；基准已经最便宜时要诚实说没得省
上下文压缩把输入从 2000 压到 1200，单轮 0.00048 美元、每月 720 美元，降两成
工具预算上限买的是可预测：有上限时单轮上界是 0.0012 美元，没上限时没有上界
限流降级放最后，因为它是唯一用户能感觉到的一层；超预算先降档再拒绝

D27 Resume and Project Packaging: STAR, README, Architecture Diagrams, a Demo Video, an English Resume

Suppose I open one of your GitHub projects — what should a good README show me?我们点开了你 GitHub 上的项目，你觉得一份好的 README 应该让我看到什么？
Common in ChinaCommon overseasIntermediate#behavioral#documentation#portfolio
How to reason about it · think before answering
On the surface this is about documentation conventions; underneath it tests reader awareness. Reciting a list of headings sounds like a template. They want to hear that you know who the reader is, how much time he has, and what he is looking for.
Define the reader before listing sections: someone skimming a README has about three minutes and has no intention of cloning the repo. So the first screen must answer 'what is this' and 'can it run'; everything deep goes below.
Then give the structure, naming the reader each part serves: one-line positioning (the resume screener), architecture diagram (anyone building a mental model), quick start (anyone verifying it runs), key design decisions (the interviewer), known limitations (the interviewer), directory guide and license (people who will actually read the code).
Put the weight on two sections. Quick start has a hard bar — running in three commands or fewer; more than that means hidden setup. Verify it on a machine that has never run the project, not on your own. Key design decisions must each state what you gave up, because that is the one part no template can supply.
Known limitations deserve a sentence of their own: stating boundaries is not exposing weakness, it demonstrates self-awareness and honesty at once. And once you have said it, it is hard to use against you — at most they ask which gap you would close first, which you already prepared.
Expect the follow-up: 'which section took you the longest?' Answer 'key design decisions' and then walk through one on the spot. The question is nominally about READMEs, but it is an invitation to talk about your project — take it.
分析过程 · 先想清楚再作答
这题表面在问文档规范，实际在考「你有没有读者意识」。答成一串小标题清单（简介、安装、使用、贡献指南）会显得像背模板；面试官想听的是你知道读者是谁、他有多少时间、他在找什么。
先把读者说清楚再列结构，这一步就能拉开差距：看 README 的人预算大约三分钟，而且不打算 clone 下来跑。所以第一屏必须解决「这是什么」和「能不能跑」，深入的东西往后放。
然后给结构，并且为每一段说出它服务的是哪个读者：一句话定位（筛简历的人）、架构图（想快速建立心智模型的人）、快速开始（想验证能不能跑的人）、关键设计决策（面试官）、已知限制（面试官）、目录导读与许可（真的要读代码的人）。
重点落在两段上。「快速开始」的硬指标是三条命令之内跑起来，超了说明有隐性依赖；判据是拿一台没跑过的机器照着敲一遍，而不是在自己机器上试。「关键设计决策」每条要含「放弃了什么」，因为这是唯一无法从模板抄来的部分。
「已知限制」值得单独说一句：主动写出边界不是暴露短板，而是同时证明了自我认知和诚信。而且你先说了，对方就很难再拿它当把柄，最多顺着问「上生产你会先补哪个」——那是你准备好的题。
可以预期的追问：「你的项目 README 里最花时间的是哪一段？」答「关键设计决策」，然后现场讲一条。这题问的是 README，落点其实是让你讲项目，别错过这个递过来的机会。
Key points
Start from the reader: a three-minute budget and no intention of cloning, so the first screen answers what it is and whether it runs
Seven sections: one-line positioning, architecture diagram, quick start, three key design decisions, known limitations, directory guide, license
Quick start must work in three commands or fewer, verified on a machine that has never run it
Every design decision states what was given up — the one part no template provides, and where interviewers pick their follow-up
Use Mermaid rather than screenshots: native GitHub rendering, text diffs, and it does not go stale
答题要点
先说读者：三分钟预算、不会 clone 下来跑，所以第一屏解决「是什么」和「能不能跑」
七段结构：一句话定位、架构图、快速开始、关键设计决策 3 条、已知限制、目录导读、许可
快速开始的硬指标是三条命令之内，且要在一台没跑过的机器上验证
关键设计决策每条含「放弃了什么」，这是唯一抄不来的部分，也是面试官挑追问的地方
架构图用 Mermaid 而不是截图：GitHub 原生渲染、改动是文本 diff、不会过期

D28 Mock Interview Day: One Full China-Domestic-Style and One Full Overseas-Style Round, Self-Assessment

What most commonly goes wrong in the self-introduction, and what does a good one look like?自我介绍环节最容易出的问题是什么？一段好的自我介绍应该长什么样？
Common in ChinaCommon overseasIntermediate#self-presentation#communication
How to reason about it · think before answering
Start from what the interviewer is doing during those three minutes: judging whether you can structure a piece of speech unaided, and deciding which project to spend the next twenty-five minutes on. Once you see the second one, the answer stops being 'keep it short'.
The usual failures share one root cause: telling it chronologically. Starting at university and reading the resume top-down means the three minutes expire before you reach the recent work, which is the only part anyone wants to hear.
That gives the correct shape: reverse order, three blocks only — what kind of engineer you are now, one or two signature pieces of work with a number attached, and why this role. Land the main line in ninety seconds and leave room for follow-up rather than filling the slot. The silence is leverage, not waste.
The second frequent failure is adjectives with no numbers. 'I built a high-performance agent service' carries almost no information; a sentence with a constraint, a goal, an action, and a metric moved from X to Y is what makes someone ask the next question.
The third is the subtlest: seeding things you do not want to be asked about. Every technology you name is an invitation, so leave unfamiliar stacks out — and conversely, plant the topics you want to be asked about, since this is the only moment in the loop where you set the agenda.
Expect this follow-up: if the interviewer cuts in with 'just briefly', you have already run long or drifted. Rehearse two versions, sixty and ninety seconds, and switch between them rather than compressing live — live compression usually deletes the conclusion too.
分析过程 · 先想清楚再作答
先看清面试官在这 3 分钟里做什么：一是看你能不能自己组织一段有结构的表达，二是决定接下来 25 分钟挖你哪个项目。看懂第二件事，答案就不是「讲短一点」这么浅了。
最容易出的问题有一个统一的根因——按时间顺序讲。从大学讲起、顺着简历从上往下念，于是 3 分钟到点时你还没讲到最近、最有价值的那段经历，而那恰恰是唯一有人想听的部分。
由此推出正确形态：倒序，只留三块——你现在是什么方向的工程师、一到两个带数字的代表作、你为什么来面这个岗位。90 秒讲完主线，把剩下的时间让给对方追问，而不是把 3 分钟填满。留白是主动权，不是浪费。
第二个高频问题是通篇形容词、没有一个数字。「我做过一个高性能的 Agent 服务」几乎不携带信息；换成一句带约束和指标的话（在什么约束下、为了什么目标、做了什么、把哪个指标从多少改善到多少），才会让对方接着问下去。
第三个问题最隐蔽：自我介绍里埋了自己不想被问的东西。你说出口的每一个技术名词都是一张邀请函，不熟的栈别写也别说；反过来，希望被问的点要主动埋进去，这是全场唯一由你控制议题的机会。
可以预期的追问：面试官打断你说「再简单说一下」，说明你已经超时或跑题了。所以要提前排练两个版本，一个 60 秒、一个 90 秒，现场直接切，不要临场压缩——临场压缩的结果通常是把结论也一起删掉了。
Key points
The interviewer is doing two things at once: assessing structure and choosing which project to dig into
The common failure is chronological order, which burns the clock before reaching recent work; reverse it
Keep three blocks: current engineering focus, one or two signature results with numbers, and why this role
Landing the main line in ninety seconds and leaving room for follow-up beats filling all three minutes
Every technology you name is an invitation: omit unfamiliar stacks, plant the topics you want asked, and rehearse a sixty-second and a ninety-second version
答题要点
面试官在这 3 分钟里同时做两件事：判断你的表达结构，决定接下来挖哪个项目
最常见的错是按时间顺序讲，时间用完还没讲到最近最有价值的经历；正确做法是倒序
结构只留三块：现在的技术方向、一到两个带数字的代表作、为什么来面这个岗位
90 秒讲完主线、主动留白给对方追问，比把 3 分钟填满更有利
每个说出口的技术名词都是邀请函：不熟的不提，想被问的主动埋进去；提前排练 60 秒和 90 秒两个版本
After a mock interview, how do you assess yourself objectively instead of settling for 'that felt okay'?一次模拟面试之后，你怎么做一次客观的自我评估，而不是停在「感觉还行」？
Common in ChinaCommon overseasIntermediate#self-assessment#deliberate-practice
How to reason about it · think before answering
This asks whether you have engineered your practice. 'Record it and listen again' is the passing floor; the discriminator is a repeatable rubric plus thresholds fixed in advance, because without a rubric two sessions are not comparable and improvement is unmeasurable.
Objectivity requires reviewable evidence, so fix three things first: record audio or screen throughout, run the real time boxes, and score against the recording afterwards rather than on feeling at the buzzer. Self-assessment is at its most distorted in the minutes right after you finish.
Then replace overall impression with fixed dimensions: self-introduction, project depth, coding, system design, and communication plus candidate questions, each scored 1 to 5 for a total of 25. What makes it work is writing anchor descriptions for what a 1, a 3, and a 5 look like — otherwise the same '4' means different things in different sessions.
Set thresholds before scoring, which is the only defense against rationalizing afterwards: any dimension below 3 goes on the weakness list, and a total below 18 means rerunning the whole loop two days later instead of pressing on.
The final step carries all the value: translate low scores into four columns — observation, root cause, smallest drill for tomorrow, and how to verify. An observation has to be a fact you can point at in the recording, with a timestamp and the actual words: 'explained it badly' does not qualify, 'eight minutes into the project story and still had not said what I personally did' does. The drill must fit in one day, and verification must be observable, ideally with a numeric bar.
Expect the follow-up: how do you generate follow-up questions alone? Use a model as the interviewer, but write the interrogation rules into the instructions first — one question at a time, three consecutive layers of follow-up grounded in what you just said, and no praise, no evaluation, no supplying the answer. Without those rules it degrades into an encouraging assistant, which defeats the point.
分析过程 · 先想清楚再作答
这题在考你有没有把练习工程化。答「录下来多听几遍」只是及格线，真正的区分度在于有没有可重复的评分口径和事先定好的阈值——没有口径，两次模拟之间就没法比较，也就谈不上进步。
客观的前提是有可回放的证据，所以先固定三件事：全程录音或录屏、按时间盒计时、事后对着回放打分而不是结束时凭感觉打。刚讲完的十几分钟里自我评价偏差最大，讲得顺就全盘肯定，卡过一次就全盘否定。
然后用固定维度代替整体印象：自我介绍、项目讲解深度、编码、系统设计、沟通与反问，各 1 到 5 分，满分 25。关键是每个维度要写好 1 分、3 分、5 分各长什么样的锚点描述，否则同一个「4 分」在两次之间根本不是同一件事。
阈值要在打分之前定好，这是防止事后给自己找理由的唯一办法：任何单项低于 3 分就进弱项清单，总分低于 18 分就隔两天把整套流程重跑一次，而不是硬着头皮往下走。
最后一步才是全部价值所在——把低分翻译成四列：现象、根因、最小动作、怎么验证。现象必须是回放里能指着看的事实（带时间、带原话），「讲得不好」不算，「项目讲解到第 8 分钟还没说到我做了什么」才算；最小动作必须一天内做得完；验证必须可观察，最好带数字门槛。
可以预期的追问：一个人怎么产生追问？用大模型当面试官，但必须先把追问纪律写进指令——一次只问一个问题、基于我的回答连追三层、全程不评价不夸奖不给答案。不写纪律，它会退化成一个不停鼓励你的助手，那就失去了模拟的意义。
Key points
Evidence before judgment: record throughout, run real time boxes, and score against the replay rather than on feeling at the buzzer
Use five fixed dimensions (intro, project depth, coding, system design, communication and candidate questions) scored 1 to 5 out of 25, each with anchors for what 1, 3 and 5 look like
Fix thresholds before scoring: any dimension below 3 goes on the weakness list, a total below 18 means rerunning the loop two days later
Translate low scores into four columns — observation, root cause, smallest drill, verification — where the observation is a pointable fact and the drill fits in one day
Practicing alone, use a model as interviewer but write the rules first: one question at a time, three layers of follow-up, no praise, no evaluation, no answers
答题要点
先有证据再有判断：全程录音或录屏、按时间盒计时、事后对着回放打分，不在结束当场凭感觉打
用固定五个维度（自我介绍、项目讲解深度、编码、系统设计、沟通与反问）各 1 到 5 分、满分 25，并给每个维度写 1/3/5 分的锚点描述
阈值先定后打：任何单项低于 3 分进弱项清单，总分低于 18 分隔两天重跑整套流程
把低分翻译成四列：现象、根因、最小动作、怎么验证；现象必须是回放里能指着看的事实，动作必须一天内做得完
一个人练时用大模型当面试官，但要先写死追问纪律：一次一问、连追三层、不评价不夸奖不给答案

D29 Shoring Up Weak Points + a Coding Warm-Up: Rate Limiter, LRU, Concurrency Control, Streaming JSON Parsing

How would you build a scheduler that caps in-flight async tasks, and why is Promise.all or asyncio.gather not enough?怎么实现一个限制并发数的调度器？为什么不能直接用 Promise.all 或者 asyncio.gather？
Common in ChinaCommon overseasIntermediate#concurrency#async
How to reason about it · think before answering
The hinge is the second half. They are checking whether you separate 'await a batch' from 'cap how many run at once' — similar API names, unrelated semantics.
Name the wrong answer first: mapping 500 items to promises and awaiting them together runs at concurrency 500. Creating the promise already fired the request; awaiting only collects results. gather and CompletableFuture.allOf are the same trap in other accents.
Then give the two correct shapes: a fixed set of workers pulling from a shared cursor (the JS idiom, where a worker is the slot), or a semaphore gating task start (asyncio.Semaphore, java.util.concurrent.Semaphore). Swift needs a manual window over a TaskGroup — fill limit slots, then add one task per result received.
The real failure mode is slot leakage: release must happen in a finally, or the error must be collapsed into a result value inside the task. Code that misses this looks perfect on the happy path and only degrades once the downstream starts failing, which makes it one of the hardest bugs to trace.
Tie it to agents: batch embedding, parallel tool calls, fan-out subtasks. The benefit is not only sparing the downstream — peak memory now scales with the concurrency limit instead of the task count.
Expect the follow-up: what if tasks retry? Retries must happen inside the slot, otherwise a retry storm bypasses the limiter entirely. One level deeper: add jitter so failed tasks do not all come back at the same instant.
分析过程 · 先想清楚再作答
题眼在后半句。面试官在确认你分不分得清「等待一批任务」和「限制同时运行的任务数」——这两件事在 API 名字上很像，在语义上毫无关系。
先说破错误答案为什么错：把 500 个任务全部映射成 Promise 再一起 await，这段代码的并发度是 500。Promise 一被创建，它内部的请求就已经发出去了，await 只是在等结果；gather 和 CompletableFuture.allOf 是同一个坑的另外两种口音。
再给正确形状的两条路：固定数量的工人从同一个游标取任务（JS 的惯用法，槽位就是工人本身），或者用信号量挡在任务启动之前（Python 的 asyncio.Semaphore、Java 的 Semaphore）。Swift 要用 TaskGroup 自己开滑动窗口，先塞满 limit 个、每收一个结果补一个。
本题真正的失分点是槽位泄漏：acquire 之后必须在 finally 里 release，或者把错误在任务内部收敛成结果值。忘了这一步的代码在 happy path 上完全正常，只有下游开始报错时才会一点点变慢直到彻底卡死——这是最难查的那类 bug，因为症状出现在故障之后而不是之中。
落到 Agent 场景说收益：批量 embedding、并行工具调用、多路子任务都靠它。收益不只是「不打爆下游」，还有同时驻留的内存与并发度同阶而不是与任务数同阶。
可以预期的追问：如果任务本身还要重试呢？答案是重试要在槽位内部完成（占着槽位退避重试），否则重试风暴会绕过限流；再追一层就是给重试加抖动，避免所有失败任务在同一时刻一起回来。
Key points
Promise.all and asyncio.gather only wait; the work started when each promise was created, so concurrency equals the task count
Two correct shapes: a fixed worker set pulling from a shared cursor, or a semaphore gating task start
The slot must be returned on every exit path — finally in Java, async with in Python, error-to-value inside a Swift task, try/catch inside the JS loop
A leaked slot shows up as gradual slowdown to a full stall once the downstream starts erroring, and is invisible on the happy path
The payoff is peak memory scaling with the concurrency limit rather than the task count; retries must stay inside the slot and carry jitter
答题要点
Promise.all 与 asyncio.gather 只负责等待，任务在被创建的那一刻就已经启动了，并发度等于任务总数
两种正确形状：固定数量的工人从共享游标取任务，或者用信号量挡在任务启动之前
槽位必须在任何退出路径上归还：Java 写在 finally 里，Python 用 async with，Swift 把错误收敛成结果值，JS 在循环里 try 与 catch
槽位泄漏的症状是「下游一开始报错就越来越慢直到卡死」，happy path 完全看不出来
收益是同时驻留的内存与并发度同阶，而不是与任务总数同阶；重试要占着槽位做，并加抖动

D30 Full Retrospective and Application Kickoff: a Complete Pass Over the Interview Bank, a Knowledge Map, Month-Two Application Cadence, Public Launch of the Site

How do you turn scattered knowledge into a map that is actually useful for review?怎么把零散的知识点组织成一张便于复习的知识地图？
Common in ChinaCommon overseasIntermediate#knowledge-organization#interview-prep
How to reason about it · think before answering
The load-bearing phrase is 'useful for review'. Most answers become 'group things by module and draw a mind map', which produces a table of contents, not a map — a contents page cannot tell you what to fix first. That is where candidates separate.
Break it down: a graph has nodes and edges. Grouping nodes is cheap and almost everyone does it correctly; the information lives in the edges. So ask yourself how many edges your diagram has and what each one means. No answer means you drew a contents page.
Give an operational rule for edges: draw A to B only when not understanding A blocks understanding B. 'Both are about message queues' does not qualify — that is sibling grouping. 'You cannot understand context compression without the context window' does. Course order does not qualify either; that is a calendar, not a dependency.
Conclusion: use the map by painting your weak spots onto it. If a node is shaky, check whether its upstream is shaky too — repair upstream and several downstream nodes light up at once. That is the map's one advantage over a checklist: a checklist says what is broken, a map says where to start.
Production angle: the same habit pays off at work. When debugging an incident, the dependency graph in your head decides whose logs you open first; without it you probe services one by one. Saying this shows the map is a working tool, not an exam prop.
Expect the follow-up: how big should it be? Small enough to redraw on a whiteboard in five minutes. Past that you start maintaining the map instead of using it — merge nodes into themes and leave the detail in your question bank.
分析过程 · 先想清楚再作答
题眼在「便于复习」四个字。绝大多数人答成「按模块分类、画个思维导图」，那产出的是目录不是地图——目录任何一本书的前几页都有，它不能告诉你先补哪里。区分度就在这儿。
怎么拆：一张图有两种元素，节点和边。分层（节点怎么分组）是廉价的、几乎人人做得对；真正的信息量在边上。所以先问自己一个问题——我这张图上有几条边，每条边的含义是什么？答不上来就说明画的是目录。
给一条可操作的连边判据：只有当「不懂 A 就学不懂 B」时才连 A 指向 B。「A 和 B 都属于消息队列」不算，那是同层并列；「不理解上下文窗口就理解不了为什么要压缩」算。课程的先后顺序也不算——那是日历，不是依赖。
结论：地图的用法是把你的弱点涂上去。某个节点讲不清，先看它的上游是不是也红——是的话补上游，一次带亮一串。这就是地图相对清单的唯一优势：清单说哪里错了，地图说该从哪儿开始。
生产视角：这套东西在工作里同样有用。排查一个线上问题时，你脑子里那张「谁依赖谁」的图决定了你先看哪个服务的日志；没有这张图的人只能一个个试。面试时把这个类比说出来，会显得你不是为了背题才画图。
可预期的追问：那张图应该多大？答案是能在白板上 5 分钟画完——超过这个规模你会开始维护它而不是使用它，节点合并成主题，细节留在题库里。
Key points
Grouping into layers is what any table of contents does; a map's information is in its edges
One rule for edges: draw one only when A is a genuine prerequisite for B — sibling topics and course order do not count
Paint your weak spots on the nodes and fix upstream first when reds cluster; one fix lights up several downstream nodes
Long cross-layer edges are the valuable ones — following them in an interview shows a system, isolated nodes only produce fragments
Keep it redrawable on a whiteboard in five minutes; finer detail belongs in the question bank, not the map
答题要点
分层只是分组，任何目录都做得到；地图的信息量全部在边上
连边的判据只有一条：不懂 A 就学不懂 B 才连边，同类并列和课程顺序都不算
把弱项涂到节点上，红点扎堆时优先补上游节点，一次带亮一串下游
跨层的长边最值钱，面试时顺着长边讲能体现体系，孤立节点只能给出零碎答案
规模控制在白板 5 分钟能画完，再细的内容留在题库里而不是图上