面试题库

30 天从前端工程师到 Agent 工程师

D7 封装成服务：Fastify + SSE + Docker（dg P07）；W1 复盘

• 自我介绍时，怎么在两分钟里讲清楚一个 Agent 项目的价值？In a two-minute self-introduction, how do you convey the value of an agent project?

  国内高频海外高频基础#interview-prep#communication

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

  1. 这题没有标准答案，但有明确的失败模式：从技术栈开始报菜名（我用了 Fastify、SSE、Docker、向量库……）。面试官记不住工具清单，他记得住的是问题和数字。
  2. 用一条固定结构去组织，两分钟正好够：一句话说你是谁和转型方向，一句话说项目解决的业务问题（谁在什么场景下受什么苦），三到四句说你的关键技术决定和它换来了什么，最后一句给可验证的结果。
  3. 关键技术决定要挑「有取舍的」讲，不要讲「有实现的」。比如「流式用 SSE 而不是 WebSocket，因为上行只有一次，这样鉴权限流日志这套现成设施全部照用」——这种句子同时展示了你知道有别的选项、也知道选它的代价，比列出十个工具有效得多。
  4. 结果要尽量带数字，哪怕是自测数据：首字延迟从几秒降到几百毫秒、分层路由把日成本从 300 元降到 125 元、多 provider 冗余让可用性不再取决于单家厂商。没有生产数据就诚实说明是自测环境，编数字是最危险的做法，追问两句就穿帮。
  5. 常见误区是把学习项目说成生产项目。正确姿势是主动定位：这是我为了搞懂生产级 Agent 架构而完整实现的一套系统，规模是自测级，但每个决定都对着真实约束做过取舍——面试官对诚实的自评远比对夸大的描述宽容。
  6. 可以预期的追问：这个项目最难的地方是什么？提前准备一个具体的、有过程的答案（比如流式接口推流之后没法用状态码报错，最后改成流内 error 事件加上把校验全部前置），比任何形容词都有说服力。

  How to reason about it · think before answering

  1. There is no model answer, but there is a clear failure mode: opening with a tool list. Interviewers do not remember stacks; they remember problems and numbers.
  2. Use a fixed structure that fits two minutes: one line on who you are and where you are heading, one line on the business problem (who suffers, in what situation), three or four lines on your key technical decisions and what each bought you, and one closing line with a verifiable result.
  3. Choose decisions that involved a trade-off, not decisions that merely involved implementation. 'We stream over SSE rather than WebSocket because upstream traffic is a single request, which lets us keep existing auth, rate limiting and logging' shows you knew the alternative and priced it — far stronger than naming ten tools.
  4. Attach numbers wherever you can, even self-measured ones: time-to-first-token dropping from seconds to a few hundred milliseconds, tiered routing cutting daily spend by more than half, multi-provider fallback removing a single vendor from your availability ceiling. If the numbers are from a test environment, say so; inventing them collapses after two follow-ups.
  5. A common mistake is presenting a learning project as production. Position it yourself: a complete system built to understand production agent architecture, at self-test scale, where every decision was made against real constraints. Interviewers forgive honest scoping far more readily than inflated claims.
  6. Expect: what was the hardest part? Prepare one concrete story with a process — for example, discovering that a streaming endpoint cannot report errors by status code once it has started pushing, and redesigning around an in-stream error event plus front-loaded validation.

  答题要点

  • 结构固定：定位一句、业务问题一句、三到四个有取舍的技术决定、一句可验证的结果
  • 不要报菜名：面试官记不住工具清单，记得住问题、取舍和数字
  • 技术决定要讲取舍而不是讲实现，说清楚备选方案是什么、为什么没选它
  • 结果尽量带数字，自测数据也可以，但必须标明来源，绝不编造
  • 主动定位项目规模：为搞懂生产架构而完整实现、自测级规模，诚实自评比夸大更容易通过

  Key points

  • Keep a fixed structure: positioning, the business problem, three or four traded-off decisions, and one verifiable result
  • Do not recite a stack — interviewers retain problems, trade-offs and numbers, not tool lists
  • Frame decisions as trade-offs, naming the alternative and why it lost
  • Attach numbers even from self-testing, but label their source and never invent them
  • Scope the project honestly as a complete build at self-test scale; honest framing survives follow-ups better than inflation

D28 模拟面试日：国内/海外各一套全流程，自评

• 自我介绍环节最容易出的问题是什么？一段好的自我介绍应该长什么样？What most commonly goes wrong in the self-introduction, and what does a good one look like?

  国内高频海外高频进阶#self-presentation#communication

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

  1. 先看清面试官在这 3 分钟里做什么：一是看你能不能自己组织一段有结构的表达，二是决定接下来 25 分钟挖你哪个项目。看懂第二件事，答案就不是「讲短一点」这么浅了。
  2. 最容易出的问题有一个统一的根因——按时间顺序讲。从大学讲起、顺着简历从上往下念，于是 3 分钟到点时你还没讲到最近、最有价值的那段经历，而那恰恰是唯一有人想听的部分。
  3. 由此推出正确形态：倒序，只留三块——你现在是什么方向的工程师、一到两个带数字的代表作、你为什么来面这个岗位。90 秒讲完主线，把剩下的时间让给对方追问，而不是把 3 分钟填满。留白是主动权，不是浪费。
  4. 第二个高频问题是通篇形容词、没有一个数字。「我做过一个高性能的 Agent 服务」几乎不携带信息；换成一句带约束和指标的话（在什么约束下、为了什么目标、做了什么、把哪个指标从多少改善到多少），才会让对方接着问下去。
  5. 第三个问题最隐蔽：自我介绍里埋了自己不想被问的东西。你说出口的每一个技术名词都是一张邀请函，不熟的栈别写也别说；反过来，希望被问的点要主动埋进去，这是全场唯一由你控制议题的机会。
  6. 可以预期的追问：面试官打断你说「再简单说一下」，说明你已经超时或跑题了。所以要提前排练两个版本，一个 60 秒、一个 90 秒，现场直接切，不要临场压缩——临场压缩的结果通常是把结论也一起删掉了。

  How to reason about it · think before answering

  1. 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'.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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 分钟里同时做两件事：判断你的表达结构，决定接下来挖哪个项目
  • 最常见的错是按时间顺序讲，时间用完还没讲到最近最有价值的经历；正确做法是倒序
  • 结构只留三块：现在的技术方向、一到两个带数字的代表作、为什么来面这个岗位
  • 90 秒讲完主线、主动留白给对方追问，比把 3 分钟填满更有利
  • 每个说出口的技术名词都是邀请函：不熟的不提，想被问的主动埋进去；提前排练 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

Codex 与 OpenAI Agents SDK 高效使用

D1 Codex CLI 入门：安装、AGENTS.md、审批模式与沙箱、常用命令

• 你要在团队里引入一个能在本地执行命令的 coding agent，怎么向不放心的同事解释它的风险边界？You want to introduce a coding agent that runs commands locally. How do you explain its risk boundary to skeptical teammates?

  国内高频海外高频进阶#coding-agent#security#communication

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

  1. 这题考的是沟通加工程两层：既要说清技术上的边界，又要用对方能验证的方式说，不能只说「它很安全」。
  2. 拆成三层防线来讲：第一层文字规则（AGENTS.md）管习惯；第二层沙箱管能力，只读或只能写工作区、网络默认关；第三层审批管例外，越界的每一步都要人批。
  3. 给出可验证的承诺：所有改动都在 git 工作区里，`git diff` 能看、`git checkout` 能撤；脱手运行只跑在一次性分支或容器里。
  4. 主动说出剩余风险：模型可能误读需求写出错误但能通过的代码，所以审查和测试不能省；密钥不要放在它能读到的文件里。
  5. 可预期的追问：能不能完全禁止它联网？可以，沙箱默认就不通网，需要装依赖时逐次批准，或在配置里给一个允许的域名清单。

  How to reason about it · think before answering

  1. This tests communication as much as engineering: state the technical boundary in terms the listener can verify, not just 'it is safe'.
  2. Present three layers of defense: written rules (AGENTS.md) shape habits; the sandbox limits capability to read-only or workspace-only writes with network off; approvals gate every exception.
  3. Offer verifiable guarantees: every change lands in the git working tree, visible via diff and revertable via checkout; unattended runs stay on throwaway branches or containers.
  4. Name the residual risk yourself: the model can misread a requirement and produce wrong but passing code, so review and tests remain mandatory, and secrets stay out of readable files.
  5. Expect the follow-up: can network be fully blocked? Yes, the sandbox is offline by default; approve installs case by case or configure an allow-list of domains.

  答题要点

  • 三层防线：文字规则管习惯、沙箱管能力、审批管例外
  • 改动全在 git 工作区，可 diff 可撤销；脱手运行只在一次性分支或容器
  • 主动说明剩余风险：错误但能通过的代码、密钥暴露，所以审查与测试不能省
  • 网络默认关闭，联网按次批准或配置允许域名清单

  Key points

  • Three layers: written rules for habits, the sandbox for capability, approvals for exceptions
  • All edits live in the git working tree and are diffable and revertable; unattended runs use throwaway branches or containers
  • State residual risks yourself: wrong-but-passing code and secret exposure, hence mandatory review and tests
  • Network is off by default; approve per request or configure an allow-list