面试题库

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

D27 简历与项目包装：STAR、README、架构图、demo 视频、英文简历

• 我们点开了你 GitHub 上的项目，你觉得一份好的 README 应该让我看到什么？Suppose I open one of your GitHub projects — what should a good README show me?

  国内高频海外高频进阶#behavioral#documentation#portfolio

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

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

  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.

  答题要点

  • 先说读者：三分钟预算、不会 clone 下来跑，所以第一屏解决「是什么」和「能不能跑」
  • 七段结构：一句话定位、架构图、快速开始、关键设计决策 3 条、已知限制、目录导读、许可
  • 快速开始的硬指标是三条命令之内，且要在一台没跑过的机器上验证
  • 关键设计决策每条含「放弃了什么」，这是唯一抄不来的部分，也是面试官挑追问的地方
  • 架构图用 Mermaid 而不是截图：GitHub 原生渲染、改动是文本 diff、不会过期

  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