Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

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

• Walk me through a technical project of yours using the STAR framework.请用 STAR 法则讲一个你做过的技术项目。

  Common in ChinaCommon overseasBasic#behavioral#star#resume

  How to reason about it · think before answering

  1. This question tests whether you can control information density, not whether you remember four letters. The interviewer has heard STAR dozens of times; what he is actually timing is how long you spend on background versus on what you personally did, and whether you land on a number he can probe.
  2. Decide the time split before you open your mouth: 20 seconds of situation, 15 of task, 90 of action, 25 of result. The classic failure is spending 90 seconds on situation — it feels safe because it says nothing about your ability, so people hide there.
  3. In those 90 seconds of action, say 'I', not 'we'. Summarize the team's work in one sentence, then cut straight back to 'my piece was X, and the way I did it was Y'. If your boundary with the rest of the team is unclear, the story is scored as unverifiable.
  4. The result has to be a before-and-after number, and you volunteer the measurement conditions with it: 'shard utilization went from 1 of 256 to all 256, and the largest bucket dropped from 2000 to 19 — measured locally with 2000 simulated users across 256 shards.' Naming the conditions is not hedging; it shows you know what you measured.
  5. If it is a personal or course project, say so inside the first 20 seconds rather than waiting to be asked. Volunteering the origin makes your numbers more credible, not less; being caught hiding it forces the interviewer to re-weigh everything you said before.
  6. Expect two follow-ups: 'how did you measure that?' and 'does this still hold at ten times the scale?' The first tests honesty, the second tests judgment — answer the second by naming the scale at which you would throw this design away.

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

  1. 这题在考「你会不会控制信息密度」，不是考你记不记得 STAR 四个字母。面试官已经听过几十遍 STAR，他真正在数的是：你花了多少时间讲背景、多少时间讲你自己做了什么、最后有没有一个能被追问的数字。
  2. 先定时间分配再开口，这是可以现场执行的一条纪律：情境 20 秒、任务 15 秒、行动 90 秒、结果 25 秒。绝大多数人的失败模式是情境讲了 90 秒——那部分听起来最安全，因为不涉及你的能力，所以人会不自觉地躲在那里。
  3. 行动那 90 秒里只讲你亲手做的部分，主语必须是「我」。团队做了什么用一句话带过，然后立刻切回「我负责的是其中的 X，我的做法是 Y」。说不清「我和别人的边界在哪」，这条经历在评分表上会被打成不可验证。
  4. 结果必须落到一个带前后对照的数字，并且主动补一句测量条件。比如「分片利用率从 256 个里只占 1 个变成全占满，最大桶从 2000 条降到 19 条，这是本地单机、2000 个模拟用户、256 个分片的自检结果」。补测量条件不是示弱——它把「我知道自己测的是什么」这件事直接摆出来了。
  5. 如果这段经历是学习项目或课程项目，在情境那 20 秒里就说清楚，不要等到被追问。主动交代来源的人，后面报的数字反而更容易被相信；藏着掖着被问出来，之前讲的全部要被重新掂量一遍。
  6. 可以预期的追问：「这个数字是怎么测的？」以及「如果规模再大十倍，这个做法还成立吗？」第一个考真实性，第二个考边界感——答第二个时要主动说出「在什么规模下我会推翻现在这个设计」，这一句几乎没人说，说了就是加分。

  Key points

  • Budget the time before speaking: 20s situation, 15s task, 90s action, 25s result — never let background eat half the answer
  • Say 'I' in the action section and draw a clear line between your work and the team's
  • End on a before-and-after number and volunteer how it was measured
  • Disclose that it is a personal or course project up front, not under questioning
  • Close by naming the scale at which the design would break — it signals judgment

  答题要点

  • 开口前先分配时间：情境 20 秒、任务 15 秒、行动 90 秒、结果 25 秒，别让背景吃掉一半时长
  • 行动部分主语是「我」，明确说出自己和团队的边界
  • 结果给一个带前后对照的数字，并主动补上测量条件
  • 学习项目在情境阶段就主动交代，不等追问
  • 结尾主动加一句「在什么规模下这个设计会失效」，把边界感摆出来
• Tell me about the most challenging project you have worked on. What made it hard?讲讲你做过的最有挑战的一个项目，难在哪里？

  Common in ChinaCommon overseasDeep dive#behavioral#project-storytelling

  How to reason about it · think before answering

  1. The hinge is the word 'challenging', and almost everyone falls into the same trap: treating 'a lot of work' as a challenge. Three months of overtime proves stamina, not judgment. The interviewer wants to see how you decide under incomplete information.
  2. Pick the story first, because it caps everything after it: choose the project where you can name what you gave up. Hard test — if your answer is only 'I did A and it worked', with no 'I chose A over B and paid C for it', pick a different project.
  3. Order the answer as difficulty, decision, cost, outcome — not chronologically. Chronology drags the listener through a diary; leading with the difficulty pins their attention on the first sentence. 'With three replicas consuming in parallel, one user's messages arrived out of order' beats 'the project started in March'.
  4. When describing the difficulty, explain why it could not be solved by reading the docs. Real challenges carry conflicting constraints: parallel replicas for throughput versus strict per-user ordering. Surfacing that conflict is what makes the difficulty credible.
  5. Do not end on pure success. Volunteer one sentence on what you would change today — this is the highest-signal line available on this question, because it shows you kept thinking after shipping.
  6. Expect: 'did you consider alternatives?' It is nearly guaranteed, so prepare the option you rejected and an engineering reason for rejecting it — latency, cost, operational load — never 'it just felt wrong'.

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

  1. 这题的题眼在「挑战」这两个字上，而它有一个几乎所有人都会踩的陷阱：把「工作量大」当成挑战。加了三个月班、写了两万行代码，这些证明的是耐力，不是判断力。面试官想看的是你在信息不足的情况下怎么做决定。
  2. 先做选题，这一步决定了后面的天花板：选那个**你能说出「我放弃了什么」**的项目。判据很硬——如果你的答案里只有「我做了 A，效果很好」，没有「我在 A 和 B 之间选了 A，代价是 C」，那这个项目就不适合回答这道题，换一个。
  3. 组织顺序建议用「困难 → 我的判断 → 代价 → 结果」，而不是时间顺序。时间顺序会把听众拖进流水账；从困难切入，第一句话就把对方的注意力钉住了。比如「三个副本同时消费的时候，同一个用户的消息顺序会乱」，比「这个项目是三月份开始的」有效得多。
  4. 描述困难时要给出「为什么这不是查一下文档就能解决的」。真正的挑战都带着约束冲突：既要多副本并行提高吞吐，又要同一用户严格保序——这两个诉求天然打架，所以才需要设计而不是查资料。把这层冲突讲出来，难度就立住了。
  5. 结果那部分不要只报成功。**主动说一句「现在回头看，我会改哪里」**，这是这道题上区分度最大的一句话。它表明你在项目结束之后还继续想过这件事，而不是交付完就翻篇了。
  6. 可以预期的追问：「当时有没有考虑过别的方案？」这几乎是必问。所以准备答案时要备好那个被你放弃的方案，以及放弃它的具体理由——理由要是工程性的（延迟、成本、运维复杂度），不能是「感觉那样不好」。

  Key points

  • Challenge means judgment, not volume — overtime and lines of code are not difficulty
  • Pick a story where you can say 'I chose A over B and paid C for it'
  • Structure it as difficulty, decision, cost, outcome — never as a chronological diary
  • Name the conflicting constraints (parallel replicas versus strict per-user ordering) to make the difficulty real
  • Close with what you would change today, and have the rejected alternative plus an engineering reason ready

  答题要点

  • 挑战 = 判断力，不是工作量；别拿加班和代码行数当难度
  • 选题判据：这个项目你能说出「我在 A 和 B 之间选了 A，代价是 C」
  • 按「困难 → 判断 → 代价 → 结果」组织，不要按时间顺序讲流水账
  • 把约束冲突讲出来（比如既要多副本并行、又要同一用户保序），难度才立得住
  • 结尾主动说「现在回头看我会改哪里」，并备好那个被放弃的方案和工程性的理由
• 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

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

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

  1. 这题表面在问文档规范，实际在考「你有没有读者意识」。答成一串小标题清单（简介、安装、使用、贡献指南）会显得像背模板；面试官想听的是你知道读者是谁、他有多少时间、他在找什么。
  2. 先把读者说清楚再列结构，这一步就能拉开差距：看 README 的人预算大约三分钟，而且不打算 clone 下来跑。所以第一屏必须解决「这是什么」和「能不能跑」，深入的东西往后放。
  3. 然后给结构，并且为每一段说出它服务的是哪个读者：一句话定位（筛简历的人）、架构图（想快速建立心智模型的人）、快速开始（想验证能不能跑的人）、关键设计决策（面试官）、已知限制（面试官）、目录导读与许可（真的要读代码的人）。
  4. 重点落在两段上。「快速开始」的硬指标是三条命令之内跑起来，超了说明有隐性依赖；判据是拿一台没跑过的机器照着敲一遍，而不是在自己机器上试。「关键设计决策」每条要含「放弃了什么」，因为这是唯一无法从模板抄来的部分。
  5. 「已知限制」值得单独说一句：主动写出边界不是暴露短板，而是同时证明了自我认知和诚信。而且你先说了，对方就很难再拿它当把柄，最多顺着问「上生产你会先补哪个」——那是你准备好的题。
  6. 可以预期的追问：「你的项目 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、不会过期
• Have you applied overseas? How does an English tech resume differ from a Chinese one?你投过海外岗位吗？英文简历和中文简历在写法上有什么不同？

  Common in ChinaCommon overseasBasic#behavioral#resume#global-market

  How to reason about it · think before answering

  1. This looks like a trivia question, but the signal is whether you have actually applied or only heard about it. 'English resumes should be concise' is hearsay; naming what must never appear, and why, sounds like experience.
  2. Answer in two halves, forbidden items first, style second — the first half is a hard constraint and the second is preference, and leading with the hard part shows you can tell them apart.
  3. Forbidden: no photo, no age or date of birth, no gender, no marital status, no national ID or household registration, no expected salary. Give the real reason — in the US, Canada and the UK, employers avoid this information to limit hiring-discrimination exposure. Framing it as the employer's compliance concern rather than 'that's just the local habit' is the highest-signal sentence in this answer.
  4. Style: one page, reverse chronological, every bullet starting with a verb, every bullet quantified, and the tech stack on its own line. Give both sides on verbs — Built, Designed, Reduced, Cut are right; Responsible for, Helped with and Familiar with describe a job description, an assist, and an awareness respectively, none of which is your contribution.
  5. Add the detail most people miss: always carry units and currency — 'p95 latency 320 ms', not 'latency 320'; '$0.0006 per turn', not '0.0006 per turn'. Overseas interviewers read magnitudes carefully and cannot judge a bare number. Keep tense consistent too: past tense for finished work, present for ongoing.
  6. Expect: 'did you write it yourself or translate it?' Say you wrote it, and name a concrete step you took — for instance deleting every adjective from the Chinese version before rewriting, because directly translated adjectives read as empty in English.

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

  1. 这题看着像常识题，区分度藏在「你是真投过还是听说过」。只答「英文简历要简洁」是听说过；答得出「哪些东西在英文简历里绝对不能出现，以及为什么」的，才像真做过。
  2. 拆成两半答，顺序是「不该有的」在前、「该怎么写」在后。因为前者是硬约束，后者是风格偏好，先说硬的显得你分得清轻重。
  3. 不该有的那一半：不放照片、不写年龄和出生日期、不写性别、不写婚姻状况、不写身份证与户籍、不写期望薪资。原因要说到点子上——在美加英等地，招聘方为了规避雇佣歧视方面的法律风险，收到这些信息反而为难。说出「这是对方的合规顾虑」而不是「国外习惯这样」，是这题最能体现认知深度的一句。
  4. 该怎么写的那一半是五条格式硬要求：一页、反向时序、每条动词开头、每条带量化结果、技术栈单列一行。动词开头要给正反例——Built / Designed / Reduced / Cut 是对的，Responsible for、Helped with、Familiar with 是三个要避开的开头，因为它们分别在描述职责、描述协助、描述认知，都不是你的贡献。
  5. 补一条很多人漏掉的：单位和货币要写全（写 p95 latency 320 ms 而不是「延迟 320」，写每轮 0.0006 美元而不是「一轮 0.0006」）。海外面试官对量纲敏感，缺单位的数字他判断不了好坏。时态上也要一致：结束的项目用过去时，在推进的用现在时。
  6. 可以预期的追问：「你的英文简历是自己写的还是翻译的？」老实答自己写的，并说出你为此做的一个具体动作——比如把中文那份里的形容词全删掉之后重写，因为直译过来的形容词在英文里会显得空。

  Key points

  • Lead with the hard constraints: no photo, age, gender, marital status, national ID or expected salary
  • The reason is the employer's compliance exposure around hiring discrimination, not local custom
  • Five format rules: one page, reverse chronological, verb-first bullets, quantified results, tech stack on its own line
  • Avoid Responsible for, Helped with and Familiar with; use Built, Designed, Reduced, Cut
  • Always carry units and currency, and keep tense consistent — past for finished work, present for ongoing

  答题要点

  • 先答硬约束：不放照片、年龄、性别、婚姻状况、身份证与户籍、期望薪资
  • 原因是对方的合规顾虑（规避雇佣歧视方面的法律风险），不是「国外习惯这样」
  • 格式五条：一页、反向时序、动词开头、量化结果、技术栈单列一行
  • 动词开头避开 Responsible for、Helped with、Familiar with，改用 Built / Designed / Reduced / Cut
  • 单位与货币写全，时态保持一致：结束的项目用过去时，在推进的用现在时