Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D20 Scheduled Jobs and Proactive Outreach: Time Zones, Quiet Hours, Daily Caps, a Notification Provider Abstraction

• How does a system-initiated message differ from a user-triggered one, from a system design point of view?系统主动发给用户的消息，和用户自己触发的消息，在系统设计上有什么不同？

  Common in ChinaCommon overseasBasic#proactive-messaging#system-design#product-engineering

  How to reason about it · think before answering

  1. This looks like a definition question but it is really a filter. Answering both send a message, only the trigger differs stays at the shallowest layer — the interviewer wants to know what extra code the difference forces you to write.
  2. Give three structured differences: who is waiting (a user-triggered reply has someone staring at the screen, a proactive message has nobody waiting); how failure is handled (user-triggered failures must surface as errors, proactive failures should usually be silently deferred or dropped); and what justifies sending (the user asked, versus you having to justify it yourself).
  3. The third is the hinge, so make it explicit: the default answer for a proactive message is do not send. Every one must answer why now, why this user, and why this content is worth interrupting them. Fail any of the three and it should not go out.
  4. Then land the difference in the system: the proactive path needs an admission layer the reactive path does not — compute the user's local time from their timezone, defer if it falls inside quiet hours, drop if the daily cap is used up.
  5. Quantify the cost, which is what separates having read about this from having shipped it: tolerance for proactive messages is very low. After a few irrelevant pushes the user will not argue about the content, they will revoke the notification permission — and once revoked, the genuinely important message cannot reach them either. You are spending a budget that never refills.
  6. Expect: so is a cron job the same thing as a proactive message? No. The scheduler solves firing on time (central scheduling, an idempotency key anchored to the scheduled minute); proactive care solves whether to send at all. One is mechanism, the other is admission, and they belong in separate layers.

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

  1. 这题看着像概念题，其实是筛人题。答「都是发消息，只是触发方不同」就落进了最浅的一层——面试官想听的是这个差别会逼你多写哪些代码。
  2. 先给三条结构化的差别：谁在等（用户触发时他正盯着屏幕，主动消息没有人在等）；失败怎么处理（用户触发的失败必须报错给他看，主动消息的失败多数时候应该安静地推迟或放弃）；凭什么发（用户触发是他开了口，主动消息你得自己说出理由）。
  3. 第三条是题眼，要说透：主动消息的默认答案是不发。每一条都要能回答为什么是现在、为什么是这个用户、为什么这条内容值得打断他，三个问题答不上任何一个就不该发。
  4. 然后给出这个差别在系统里的落点：主动消息这一侧必须多出一层准入判断，本课叫三道闸——按用户时区算本地时间、安静时段命中就推迟、每日上限满了就拦下。用户触发那一侧完全不需要这层。
  5. 代价也要算清楚，这是区分「读过文章」和「做过系统」的地方：用户对主动消息的容忍度极低，连着几条无关紧要的推送之后他不会争论内容对不对，直接关掉通知权限——而权限一关，你连真正重要的那条也送不出去了。你消耗的是一个用完就拿不回来的额度。
  6. 可以预期的追问：那定时任务和主动消息是不是一回事？答不是。定时任务解决的是「能按时触发」（中心调度、幂等键锚在计划触发的那一分钟），主动消息解决的是「该不该发」，前者是机制、后者是准入，两层要分开做。

  Key points

  • Three differences: who is waiting, how failure is handled, and what justifies sending — the third is the crux
  • The default answer for a proactive message is no; each one must justify why now, why this user, why worth interrupting
  • In the system this becomes an admission layer — timezone, quiet hours, daily cap — that the reactive path does not need
  • The cost is a non-renewable budget: annoy the user and they revoke notifications, taking the important messages down with them
  • Scheduling (fire on time) and proactive care (should we send) are two separate layers

  答题要点

  • 三条差别：谁在等、失败怎么处理、凭什么发；第三条是关键
  • 主动消息的默认答案是不发，每条要能回答为什么是现在、为什么是这个用户、为什么值得打断他
  • 落到系统上就是多一层准入判断：时区换算、安静时段、每日上限，用户触发那一侧不需要
  • 代价是一个不可再生的额度：推送惹烦了用户，他关掉权限之后重要消息也送不出去
  • 定时机制（能按时触发）和主动关怀（该不该发）是两层，不要混在一起做

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

• You get 35 to 40 minutes for a system design round. How do you budget that time, and why is drawing the architecture not step one?系统设计环节只有 35 到 40 分钟，你会怎么分配时间？为什么第一步不是画架构图？

  Common in ChinaCommon overseasBasic#system-design#interview-process

  How to reason about it · think before answering

  1. This question tests pacing, not knowledge. Interviewers ask it because the previous candidate spent 25 minutes on the architecture diagram and left five each for deep dives and trade-offs — which is exactly where the rubric puts most of the weight.
  2. Give the structure with explicit time boxes: 5 minutes clarifying requirements, 3 minutes on capacity and cost estimation, 8 minutes sketching the architecture, 15 minutes going deep on two or three areas, 5 minutes on trade-offs. Naming actual minute counts is itself worth points, because it shows you have rehearsed against a clock.
  3. Then answer the 'why not draw first' half head on: a one-line prompt leaves five things unknown — daily actives, latency budget, cost budget, multi-tenancy, and failure tolerance — and every one of them changes the architecture materially. Drawing first means at best you guessed right, at worst the interviewer realises twenty minutes in that you solved a different problem. An analogy lands it: the client said 'we need an office building' and you unrolled construction drawings before hearing whether the budget is twenty million or two hundred million.
  4. Add the situation that comes up almost every time: you start asking and the interviewer says 'just assume something'. That is not permission to skip clarification, it is an invitation to state a number and its justification. The right reply is 'then I will assume 10k daily actives at five turns each, and I will flag in the final step what changes at 100k'. You keep the pacing and turn the assumption into a traceable premise.
  5. Close by explaining how step four is prepared: those 15 minutes cannot be improvised. Have three deep-dive packages ready — state and ordering, cost and rate limiting, failure and retry — so any pick is covered. Saying you prepared three directions signals rehearsal better than winging one.
  6. Expect the follow-up: what if you run out of time? Cut step three, never step five. An unfinished sketch can be closed with 'the rest follows the standard pattern, happy to come back to it', but dropping the trade-off section makes you indistinguishable from someone who memorised an architecture.

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

  1. 这题考的不是知识，是节奏感。面试官问它，通常是因为上一位候选人在架构图上讲了 25 分钟，深入和权衡各剩五分钟——而评分表上分数最重的恰恰是后两步。
  2. 先给结构，五步加时间盒：需求澄清 5 分钟、容量与成本估算 3 分钟、架构草图 8 分钟、深入 2 到 3 个点 15 分钟、权衡与取舍 5 分钟。给得出具体分钟数本身就是分数，因为它说明你掐过表。
  3. 然后正面回答「为什么不先画图」：一句话的题干里，日活、延迟预算、成本预算、是否多租户、失败可容忍度这五件事全是未知的，而它们每一个都会实质改变架构。不问就画，最好的结果是运气好蒙对，最坏的结果是二十分钟后面试官发现你解的是另一道题。用一个类比说清：甲方只说「我要一栋办公楼」，你就展开施工图，而他连预算是两千万还是两个亿都没讲。
  4. 补一条几乎每次都会遇到的现场情况：你开始问，面试官说「你先自己假设一个」。这不是让你别问了，是让你自己给一个数并说出依据。正确接法是「那我按日活 1 万、人均 5 轮算，如果实际是十万级我会在最后一步说明哪里要改」——既守住了节奏，又把假设变成了可追溯的前提。
  5. 最后主动交代第四步的准备方式：深入的 15 分钟不能临场想，要提前备好三个「深入包」（状态与保序、成本与限流、失败与重试），面试官挑哪个都有货。说得出「我提前准备了三个方向」，比现场硬讲一个更能体现你练过。
  6. 可以预期的追问：如果时间不够怎么办？答案是砍第三步而不是砍第五步——草图讲不完可以说「其余按常规做，需要的话我们回头补」，但权衡那 5 分钟一旦砍掉，你就和一个只会背架构的人没有区别。

  Key points

  • Five steps with time boxes: clarify 5, estimate 3, sketch 8, deep dive 15, trade-offs 5
  • Do not sketch first because DAU, latency budget, cost budget, multi-tenancy and failure tolerance all change the architecture
  • When told to 'just assume something', state a number with its justification instead of skipping clarification
  • Fill the 15-minute deep dive from three pre-prepared packages: state and ordering, cost and rate limiting, failure and retry
  • If time runs short, cut the sketch, never the trade-offs — almost nobody does that section, so doing it stands out

  答题要点

  • 五步加时间盒：澄清 5 分钟、估算 3 分钟、草图 8 分钟、深入 15 分钟、权衡 5 分钟
  • 不先画图，是因为日活、延迟预算、成本预算、是否多租户、失败可容忍度这五件事都会实质改变架构
  • 面试官说「你先假设一个」时，要自己给数并说出依据，而不是跳过澄清
  • 深入的 15 分钟要靠提前备好的三个「深入包」：状态与保序、成本与限流、失败与重试
  • 时间不够时砍草图不砍权衡——权衡那 5 分钟几乎没人做，做了就是加分

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

• Walk me through the AI content pipeline you built. What was the hardest part?介绍一下你做的这条 AI 内容生产线，它最难的地方在哪？

  Common in ChinaCommon overseasBasic#project-storytelling#system-design

  How to reason about it · think before answering

  1. This is an open question that tests convergence. Narrating two weeks of work chronologically loses the interviewer in three minutes; delivering one through-line in thirty seconds is what counts as telling a project well.
  2. Open with positioning and scale: an automated pipeline from a one-line premise to publish-ready vertical episodes, one run producing a five-episode season, with humans stepping in only where judgement is required. Numbers first, detail second.
  3. Then answer hardest. That word should not be spent on debugging pain; spend it on a judgement that generates every downstream decision: video generation is the most expensive, slowest and most failure-prone stage at over ninety percent of per-episode cost, so the whole design revolves around issuing one fewer video call.
  4. Attach the chain of consequences in one sentence: idempotency and caching avoid duplicate calls, reference-image reuse reduces retries, the draft tier makes experimentation cheap, and the budget breaker stops a runaway. The chain proves your choices are derived rather than collected.
  5. Leave a deliberate hook for follow-up, such as saying the async task client turned out far harder than expected. That steers the interviewer toward your strongest material instead of a corner you never considered.
  6. Expect the follow-up: do you have real numbers? Keep four from every run: wall time, spend, failure rate and manual interventions. If spend is estimated, say so, rather than letting them assume you pasted a real invoice.

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

  1. 这是一道开放题，考的是收敛能力。把十四天的东西按时间顺序流水账讲一遍，面试官三分钟后就走神了；能在三十秒内给出一条主线，才算会讲项目。
  2. 开头两句要立住定位与规模：从一句话选题到多平台可发布成片的自动化流水线，一次运行产出一季五集，人只在需要判断的地方介入。数字先给，细节后给。
  3. 然后回答「最难」。这个词不该答成「调试很麻烦」，要答成一条能推出后续所有设计的判断：这条线上最贵、最慢、最容易失败的是视频生成，占单集成本九成以上，所以整套工程都是围着「怎么少调一次视频接口」转的。
  4. 接着一句话挂上推论链：幂等与缓存是为了不重复调，参考图复用是为了少试几次，草稿档路由是为了试错时用便宜规格，预算熔断是为了失控时能停住。这条链子证明你的技术选择不是攒来的最佳实践。
  5. 最后主动留一个可被追问的钩子，比如「异步任务的客户端比我预想的复杂得多」——把面试官引到你准备最充分的地方去，而不是等他随机挑一个你没想过的角落。
  6. 可预期的追问是「有真实数据吗」。所以复盘时必须留下四个数字：耗时、花费、失败率、人工介入次数。花费是估算的就要主动说明是估算，别让人以为你贴了张真实账单。

  Key points

  • Position first: from a one-line premise to multi-platform episodes, one run per five-episode season
  • Frame the hardest part as a judgement: video dominates cost and is the slowest, most failure-prone stage
  • Show the derivation chain: idempotency and caching, reference reuse, draft tier, budget breaker
  • Bring four numbers: wall time, spend, failure rate, manual interventions, flagging estimates as estimates
  • Plant a follow-up hook that steers the conversation to your strongest area

  答题要点

  • 先定位再展开：从一句话到多平台成片，一次运行产出一季五集
  • 把最难点答成一条判断：视频占单集成本九成以上且最慢最易失败
  • 用推论链证明设计是导出来的：幂等缓存、参考图复用、草稿档、预算熔断
  • 带上四个数字：耗时、花费、失败率、人工介入次数，估算值要主动标注
  • 主动留一个追问钩子，把话题引向准备最充分的部分