简历项目与面试准备

这一天不负责把项目“包装得更大”，而是把你亲自做过的工作说明白：解决什么问题、做了什么取舍、怎样验证、还有哪些边界。

今日目标

• 把一个项目写成简历上的两三条事实陈述
• 准备一段 60–90 秒的项目介绍
• 用真实代码和记录回答实现细节
• 找出知识盲区，并把“会说”与“做过”区分开

1. 简历项目描述：事实、决策、证据

可以先用这个句式搭草稿：

围绕 [用户场景]，实现了 [具体能力]；通过 [关键技术决策] 处理 [约束或失败场景]；使用 [测试、日志或测量方式] 验证 [可观察结果]。

方括号需要由你的实际经历填充。数字只在有记录、说得清测量方法时使用。没有生产流量数据，就写清楚实现和验证范围，不要把本地压测、Mock 或教程自带功能写成线上效果。

一个待填写的 SaaS 项目草稿

使用 Next.js、tRPC 和 PostgreSQL 实现多工作区任务管理；通过数据库约束和应用层成员校验处理工作区数据边界；用 [你实际运行过的测试或冒烟步骤] 验证 [具体路径]。

这只是句式示例。应根据自己实际完成的功能、自己负责的部分和当前仓库证据修改；如果没有亲自实现某项能力，就不要把它写成自己的产出。

好的项目描述让读者能继续追问，而不是堆一串技术名词。准备好指向代码、迁移、测试记录或运行日志，说明证据能证明什么、不能证明什么。

2. 准备一段项目介绍

用四句话控制在 60–90 秒：

1. 背景：项目给谁用，解决什么具体问题？
2. 职责：你实际负责了哪些模块？
3. 难点：遇到的关键约束是什么，为什么选择当前方案？
4. 验证与下一步：你怎样验证它？现在仍有哪些不足？

先练清楚主线，再等面试官追问。不要一开口就从工具栈清单讲起。

深挖一项技术决策

挑一个真实决策，用下面的顺序准备：

问题 → 约束 → 备选方案 → 选择理由 → 失败边界 → 验证方式 → 后续改进

例如讲数据库索引时，不能只说“加索引提升查询”。还要说明被优化的查询形状、执行计划的观察、写入成本以及数据规模限制。没有测量记录时，就把它说成设计理由或练习，不要描述成已验证的性能提升。

3. 把知识清单变成可追问的问题

不要只背定义。每个主题准备“原理、项目中的位置、失败场景、取舍”四个角度：

主题	追问示例
Node.js 事件循环	哪些工作会阻塞当前进程？怎样从 Profile 找证据？
API 与事务	哪一步需要事务？并发请求怎样避免重复或覆盖？
PostgreSQL	这个索引对应哪种查询？怎样读执行计划？
缓存	键如何设计，何时失效？短暂陈旧是否可接受？
队列	消费失败、重试和重复投递分别怎样处理？
认证授权	身份认证与资源授权分别在哪一层执行？
SSE / WebSocket	断线、重连和多实例部署会发生什么？
Docker / CI	镜像怎样构建、迁移何时运行、失败如何回滚？
系统设计	关键假设是什么？怎样用数据决定下一步？

每个问题都用项目文件、可复现步骤或文档作为依据。若某部分只读过教程没有实践，直接标为“了解”并说明边界。

4. 模拟面试与复盘

找同伴互问，或自己录音回答 5 道题。每题结束后按四项打分（0–2 分）：

• 结论是否先说清楚；
• 是否解释了原因和取舍；
• 是否覆盖失败场景；
• 是否有真实实现或验证证据。

总分用于找短板，不代表面试通过概率。复盘时把卡住的问题改写成一个能在半天内完成的小练习或代码阅读任务。

实践练习：交付求职材料草稿

完成以下材料：

1. 写 2–3 条项目描述，每条都能指出对应代码或验证记录；
2. 准备一段 60–90 秒的项目介绍；
3. 回答表格里至少 5 个问题，并各自附上证据位置或复现方式；
4. 列出 3 个当前不会的问题和下一步补齐方式。

验收清单

• 项目介绍能在 90 秒内讲完，职责范围具体
• 每条简历描述都能解释实现细节并指出证据
• 没有把假设、教程演示或 Mock 结果说成生产事实
• 至少 5 个面试问题包含原理、取舍、失败边界和证据
• 复盘列出具体的补齐动作，而不是“继续学习”

参考资料

• Tech Interview Handbook

⬅️ Day 58 | ➡️ Day 60