Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D15 A Tour of Multi-Agent Patterns (Router/Supervisor, Planner-Executor, Critic, Swarm, Blackboard) and When Not to Use Them; Getting Started With LangGraph

• When should you not introduce a multi-agent system? Give operational criteria, not it depends.什么情况下不应该引入多 Agent 系统？请给出可操作的判据，而不是「视情况而定」。

  Common in ChinaCommon overseasDeep dive#multi-agent#architecture#trade-offs

  How to reason about it · think before answering

  1. This is the highest-signal question in the set because it is asked in reverse. Most candidates keep selling how powerful multi-agent is, while the interviewer is looking for someone who will say no — on a real team, blocking one unnecessary architecture upgrade is worth more than implementing three patterns.
  2. Lead with the default: do not split. Then give three criteria, any one of which justifies splitting — the system prompt contains mutually exclusive behavioural requirements (strictly enforce refund rules while also warmly retaining the customer; these are not hard to write, they are impossible to optimise together); the tool count exceeds what the model picks reliably (roughly eight as a rule of thumb, and the first response to crossing it is consolidating tools, not splitting agents); or one step needs its own failure and retry semantics. None of the three, and a single agent with a few tools is enough.
  3. Then name the most common bad split: treating a prompt problem as an architecture problem. Quality is poor, so we split into three agents — but nine times out of ten poor quality comes from vague prompts, tool descriptions that interfere with each other, or irrelevant history in the context. All three survive the split and are now harder to find. Splitting fixes conflicting responsibilities, not weak capability.
  4. Add two scenarios that clearly should not split: latency-sensitive interactions, where each extra hop is another model round trip and voice or realtime completion becomes unusable; and read-only lookup flows, where a support assistant with three or four tools gains no accuracy from splitting and simply triples the bill.
  5. Then offer an executable verification path, which earns points: keep the single-agent version as a baseline for any split and A/B both against the same golden set, comparing accuracy, per-conversation cost and latency together. An architecture upgrade with no baseline is a refactor with no evidence.
  6. Expect: what if your manager insists on multi-agent? Frame it as a reversible experiment — make the one cut you are most confident in (usually the conflicting-rules criterion), keep the baseline, and bring data in two weeks. That answer shows technical judgement and a way to disagree without stonewalling.

  分析过程 · 先想清楚再作答

  1. 这是本组最有区分度的题，因为它反着问。绝大多数候选人会顺着「多 Agent 很强大」讲下去，而面试官问这题正是想找那个会说不的人——**在真实团队里，拦住一次不必要的架构升级，价值高于实现三个模式**。
  2. 先给结论式的默认值：默认答案是不拆。然后给三条判据，命中任意一条才拆——一是单个 Agent 的系统提示词里出现了互斥的行为要求（既要严格核对退款规则又要热情挽留，这两条不是难写，是不可能同时最优）；二是工具数量超过模型能稳定选对的规模（经验线大约八个，超线的第一反应是合并工具而不是拆 Agent）；三是某一步需要独立的失败与重试语义。三条都不命中，单 Agent 加几个工具就够。
  3. 接着点名最常见的错拆：把提示词问题当成架构问题。「回答质量不好，所以拆成三个 Agent」——质量差有九成来自提示词含糊、工具描述互相干扰、上下文塞了无关历史，这三样拆完一样存在，只是分散到三个地方更难查。**拆 Agent 解决的是职责冲突，不是能力不足。**
  4. 再补两类明确不该拆的场景：一是低延迟要求的场景，多一跳就多一次模型往返，对语音或实时补全这类交互直接不可用；二是只读的简单查询链路，三五个工具的客服助手拆了只是把一次调用变成三次，准确率不会涨、账单会涨。
  5. 然后给一条可执行的验证路径，这是加分项：任何拆分都先留住单 Agent 版本当对照基线，用同一批标准样本集跑 A/B，同时比准确率、每次对话成本和延迟。**拿不出对照基线的架构升级，等于没有证据的重构。**
  6. 可以预期的追问：那如果老板就是要求上多 Agent 呢？答：那就把它当成一个可回退的实验来做——先按判据拆最有把握的那一刀（通常是互斥规则那一条），保留基线，两周后拿数据说话。这个回答同时展示了技术判断和沟通方式，比硬顶或硬上都好。

  Key points

  • Default to not splitting; split only if one of three criteria holds: mutually exclusive prompt requirements, tool count past the roughly-eight warning line, or a step needing its own failure and retry semantics
  • Too many tools should first trigger tool consolidation and tighter descriptions; splitting agents is the second response
  • The most common bad split is treating a prompt problem as an architecture problem — vague prompts, interfering tool descriptions and irrelevant history all survive the split
  • Clear do-not-split cases: latency-sensitive interactions where every hop adds a model round trip, and read-only lookup flows where accuracy does not move but the bill does
  • Always keep the single-agent version as a baseline and compare accuracy, cost and latency on the same golden set
  • Say the costs out loud: latency multiplies with steps, spend roughly triples, and debugging now spans routing plus state merging

  答题要点

  • 默认答案是不拆；三条判据命中任意一条才拆：提示词有互斥要求、工具超过约八个的告警线、某一步需要独立的失败与重试语义
  • 工具太多的第一反应是合并工具与收敛描述，拆 Agent 是第二反应
  • 最常见的错拆是把提示词问题当架构问题——质量差多半来自提示词含糊、工具描述干扰、上下文塞了无关历史，拆完这三样照旧存在
  • 明确不该拆：低延迟交互（每多一跳就多一次模型往返）、只读的简单查询链路（准确率不涨、账单涨）
  • 任何拆分都要留单 Agent 版本当对照基线，用同一批标准样本集比准确率、成本和延迟
  • 代价要说出口：延迟按步数乘倍数、成本约三倍、调试要同时排查路由与状态合并

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

• 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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.

  分析过程 · 先想清楚再作答

  1. 题眼在后半句。只会说「MCP 更标准更解耦」的人，等于说「微服务更解耦」——听起来对，但没有判据，面试官会立刻追问「那你们所有工具都做成 MCP server 了吗」。
  2. 先给判据，而且要是可执行的三条：能力要被多个宿主复用、能力由另一个团队或第三方维护、需要不改宿主代码就能增删能力。命中任意一条才考虑，**一条都不命中就直接写本地函数**——把默认答案摆成「不上」，这条比三条判据本身更能体现工程判断。
  3. 每条判据配一句为什么：多宿主复用把 N 乘 M 变成 N 加 M；别人维护时进程边界就是责任边界，他们改他们的、你不用发版；热插拔让加一个内部工具从一次发布降级成一次配置变更。
  4. 然后老实说代价，这是区分「用过」和「读过」的地方：多一个进程要保活、多一次握手要处理超时与重连、排障链路从一段变三段——工具没被调用，现在可能是模型没选、可能是 schema 翻译时丢了字段、也可能是 server 压根没起来。stdio 的子进程还要你自己回收，否则留孤儿进程。
  5. 还有一条容易被忽略但很加分：MCP 不改变你的成本结构。工具描述照样每轮都进上下文，工具多了照样会让模型选错——D5 那条「工具超过一定数量就该合并描述」在接了 MCP 之后一字不变，甚至更需要，因为现在别人可以往你的工具列表里塞东西。
  6. 可以预期的追问：那内部工具一律不上 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 不改变成本结构：工具描述照样每轮进上下文，工具过多照样会让模型选错，该合并还是要合并
  • 第三方能力接进来之后，工具列表不再完全由你掌控，这本身就是需要设计的一件事

RAG in 14 Days: From Retrieval to Trustworthy Answers

D5 Vector Indexes and Store Selection: HNSW vs. Inverted File, Quantization to Save Memory, Filtered Queries and Multi-Tenant Isolation

• When should you move your vectors out of PostgreSQL into a dedicated vector database? Give measurable triggers, and also make the case for staying.什么时候应该把向量搬出 PostgreSQL？给出可量化的触发条件，也说说不该搬的理由。

  Common in ChinaCommon overseasIntermediate#vector-database#architecture#trade-offs

  How to reason about it · think before answering

  1. This tests engineering judgement, not tooling preference. Opening with 'dedicated vector databases are better' invites follow-ups you cannot answer.
  2. State the default position and justify it: keep the first version in PostgreSQL, because transactions, backups, point-in-time recovery, permissions, joins with business tables and the tooling your team already knows all come free. A second datastore adds synchronisation, a consistency surface and an on-call burden that selection documents rarely price in.
  3. Then give four measurable triggers: data volume (the test is whether the index still fits in memory, not the raw row count), write frequency (minute-level streaming updates distort clusters and inflate graphs), filter complexity (arbitrary combinations of a dozen attributes defeat both partial indexes and partitioning), and operational capacity.
  4. Expand on filter complexity, because it is most often the real reason: dedicated vector databases push filtering into the index structure instead of applying it after the scan, which is a mechanical advantage rather than a reputational one.
  5. Volunteer the alternative people skip: many 'vector search is not good enough' problems are actually solved by hybrid retrieval plus re-ranking, not by a new database. Add the keyword path and a re-ranker first, then decide.
  6. Expected follow-up: how would you migrate? Dual-write, compare recall and latency on shadow traffic, shift read traffic gradually, and only then retire the old path. Stop at any step where the metrics regress.

  分析过程 · 先想清楚再作答

  1. 这题考的是工程判断，不是技术偏好。开口就说「专用向量库更专业」的人会被追问到答不上来；面试官想看的是你有没有把迁移成本算进去。
  2. 先给默认立场并给出理由：第一版留在 PostgreSQL，因为事务、备份、时间点恢复、权限、跟业务表 JOIN 和现成的运维工具全是白送的。多一个数据库就多一份同步、一份一致性问题、一份值班负担，这些成本很少被写进选型文档。
  3. 然后给四条可量化的触发线：数据量（判据不是行数而是索引还塞不塞得进内存）、写入频率（分钟级流式更新会让聚类失真、让图持续膨胀）、过滤复杂度（十几个属性的任意组合让部分索引和分区都排列组合不过来）、团队运维能力（没人愿意长期照看第二个数据库，前三条再成立也别搬）。
  4. 第三条要展开一点，因为它最常是真正的原因：专用向量库把过滤做进了索引结构本身，而不是扫完索引再筛，所以在复杂过滤下天然占优。把这一点说出来，说明你理解的是机制而不是口碑。
  5. 还要主动给一条常被忽略的替代路径：很多「向量检索不够用」的问题，真正的解法是混合检索加重排，而不是换数据库。先把关键词一路加回来、把重排接上，再决定要不要搬——顺序搞反了会白搬一次。
  6. 可预期的追问：真要搬怎么迁？答分三步——先双写并在影子流量上比对两边的召回与延迟，再把读流量按比例切过去，最后才停掉旧路径。中间任何一步指标不达标就停下，这比一次性切换安全得多。

  Key points

  • Default to staying in PostgreSQL: transactions, backups, recovery, permissions, joins and familiar tooling are free, and a second store adds sync and on-call cost.
  • Trigger one is data volume, measured by whether the index still fits in memory rather than by row count.
  • Trigger two is write frequency: minute-level streaming updates distort clusters and inflate graphs.
  • Trigger three is filter complexity: dedicated stores push filtering into the index structure, a mechanical advantage under complex predicates.
  • Trigger four cuts the other way: without people to run a second database, do not move even if the first three hold. Often hybrid retrieval plus re-ranking is the real fix.

  答题要点

  • 默认留在 PostgreSQL：事务、备份、恢复、权限、JOIN 和现成运维都是白送的，多一个库就多一份同步与值班成本。
  • 触发线一是数据量，判据是索引还塞不塞得进内存，而不是行数本身。
  • 触发线二是写入频率，分钟级流式更新会让聚类失真、让图持续膨胀。
  • 触发线三是过滤复杂度，专用库把过滤做进索引结构，复杂过滤下有机制上的优势。
  • 触发线四反过来看：没有长期运维第二个数据库的人手，前三条成立也不该搬；很多问题的真正解法是混合检索加重排。

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

D14 A Five-Episode Season: Batch Production, Portfolio Packaging, and a Short-Drama Pipeline Interview Deep Dive

• If you rebuilt this pipeline from scratch, what would you change architecturally?如果让你重做一遍这条生产线，架构上你会怎么改？

  Common in ChinaCommon overseasDeep dive#architecture-review#trade-offs

  How to reason about it · think before answering

  1. This tests the quality of your self-critique. Saying nothing needs changing ends the conversation; listing trendy technologies is just as bad, because it shows you learned nothing from the build. A good answer is specific, has a cost analysis, and traces back to a concrete stumble.
  2. Set a filter first: only discuss places where you actually got tripped up and now know the right approach. Say plainly where you are still unsure, because naming the limits of your solution proves more than the solution itself.
  3. First, recomputation scope. Editing one line of dialogue currently recomputes the whole downstream subgraph. Better would be for each node to declare which input fields it depends on, so a dialogue edit triggers only speech and subtitles, never video. The cost is more complex node definitions; the benefit is redoing one synthesis instead of a whole shot.
  4. Second, the cost model. The rate card today mixes derived prices with deliberate blanks, which is fine for projection but useless for reconciliation. Once real invoices exist, back out measured unit prices from them and keep a drift alert that fires when projection and reality diverge past a threshold, which beats after-the-fact reconciliation.
  5. Third, the concurrency model. Gates are currently keyed by provider, but modelling them as quota buckets matches reality better, since different endpoints from one vendor have independent quotas while different vendors are fully independent. Rate-limit diagnosis gets far more precise.
  6. Expect the follow-up: why not build it that way originally? Answer honestly that you shipped the smallest working version and spent complexity only where data justified it. That sentence is itself an architectural judgement, and distinguishing necessary complexity from premature complexity is exactly what the interviewer is listening for.

  分析过程 · 先想清楚再作答

  1. 这题在考自我批判的质量。答「没什么要改的」直接出局；答一堆花哨的新技术也不行，因为那说明你没从这次的实践里学到东西。好答案是具体的、有代价分析的、并且能追溯到某一次踩坑。
  2. 先立一个筛选标准：只讲那些我这次真的被绊过、而且知道正确做法的地方。不确定的部分坦白说不确定——说得出方案的边界，比说得出方案本身更能证明你做过。
  3. 第一处可以讲重算范围。审核台上改一句台词，现在是按节点依赖整体重算下游，粒度偏粗；更好的做法是让每个节点声明自己依赖输入的哪几个字段，改台词只触发配音与字幕，不碰视频。代价是节点定义变复杂，收益是重做成本从一整镜降到一次语音合成。
  4. 第二处是成本模型。现在的单价表里有折算值和留空项，估算够用但不能对账；接了真实账单之后应该改成从账单反推实测单价，并保留一个偏差告警——估算和实际差超过阈值就报警，这比事后对账有用得多。
  5. 第三处是并发模型。现在闸门是按 provider 分类做的，更贴近现实的做法是按「配额桶」建模，因为同一家厂商的不同接口配额独立，而不同厂商之间又完全独立。改了之后限流的定位会准很多。
  6. 可预期的追问是「为什么当初不那样做」。诚实回答：当时先做能跑通的最小版本，把复杂度留给已经被数据证明值得的地方。这句话本身就是架构判断——面试官想听的正是你会不会区分「必要的复杂度」和「过早的复杂度」。

  Key points

  • Only discuss stumbles you actually hit and now know how to fix; admit what you are unsure about
  • Move recomputation to field-level dependencies so a dialogue edit skips video regeneration
  • Back out measured unit prices from real invoices and add a projection-versus-actual drift alert
  • Model concurrency gates as quota buckets rather than per provider, matching per-endpoint quotas
  • Explain the original choice: ship the smallest working version and spend complexity only where data justifies it

  答题要点

  • 只讲真的踩过且知道正确做法的地方，不确定的坦白说不确定
  • 重算范围改成按字段级依赖，改台词只触发配音与字幕而不重生成视频
  • 成本模型接真实账单后反推实测单价，并加一个估算与实际的偏差告警
  • 并发闸门从按 provider 改成按配额桶建模，贴合各接口配额独立的现实
  • 解释当初为何没这么做：先做最小可跑版本，把复杂度留给数据证明值得的地方