外观
评分、复盘与掌握标准
分数用于指导学习,不预测录用。一次回答流畅不等于掌握;至少换一个故障条件再次验证。
统一 100 分量表
每个维度按 0–4 级评分,得分为“权重 × 等级 ÷ 4”。例如实现细节达到 3 级,得到 25 × 3 ÷ 4 = 18.75 分。总分保留一位小数即可。
| 维度 | 权重 | 0–1 级 | 2 级 | 3 级 | 4 级 |
|---|---|---|---|---|---|
| 原理准确性 | 25 | 核心概念错误或只背术语 | 能解释定义但易混淆边界 | 概念正确,能举反例 | 能解释前提、局限与层次关系 |
| 实现细节 | 25 | 不知道数据怎么流动 | 能讲模块,定位不到数据/代码 | 能定位关键结构、函数和状态 | 能现场修改并解释副作用、验证结果 |
| 设计取舍 | 20 | “框架流行所以用” | 能给一项优缺点 | 能结合约束比较有效替代 | 能给决策标准、失败边界与迁移条件 |
| 事实依据 | 20 | 混淆历史、复现、假设 | 知道要证据但拿不出对应记录 | 结论对应代码、日志或简历事实 | 能解释证据范围、测量方法与未验证项 |
| 表达清晰度 | 10 | 无结论、术语堆叠 | 内容基本正确但跳跃 | 先结论,再过程和例子 | 时间可控,能随追问调整深度 |
编造历史成果、性能数字或把模拟测试说成真实调用时,事实依据项记 0,先更正后重测。若只是记不清某项,承认并说明如何核对,不按编造处理。
自测时不要只问“我懂了吗”
- [ ] 不看资料,用 60 秒解释一个机制的输入、输出和责任边界。
- [ ] 打开实际代码,找到对应的数据结构与执行入口。
- [ ] 修改一个规则或参数,预先预测结果,再运行验证。
- [ ] 构造一次失败,解释每个组件留下什么状态。
- [ ] 解释至少一个合理替代方案以及不采用的具体原因。
- [ ] 把历史项目、本次复现和假设设计清楚分开。
这六项中,若“解释”通过但“修改”和“排障”未通过,只能算概念入门。
单轮复盘记录格式
建议每轮只选三个高价值缺口,写入自己的学习笔记;不需要开发在线评分服务。
| 字段 | 应记录的内容 |
|---|---|
| 日期与模式 | 哪一套模拟;是否允许查资料;是否实际运行系统 |
| 问题与原话 | 具体问题和自己答错/说不清的句子 |
| 缺口类型 | 原理、实现、取舍、证据、表达中的哪一类 |
| 正确结论 | 用一两句话写出,不抄整篇答案 |
| 代码与证据 | 文件、数据记录或公开资料位置;没有则明确写未取得 |
| 下一步实验 | 一个可执行、能观察结果的动作 |
| 再测标准 | 改变什么条件后仍需答对;预计何时再练 |
填写示例|假设复盘:“我说超时后直接重试。正确结论是超时不等于未执行。下一步模拟服务接受后超时,检查是否进入结果不明,且没有自动提交第二次请求。再测时把服务改为支持幂等键,解释为什么策略可以不同。”
用 STAR 的正确节奏
技术原理题先给直接答案;再用案例说明应用。简短追问可以把四项压缩成三句话,但必须保留情境、目标、动作和有依据的结果。
| 类型 | 推荐顺序 | R 的依据 |
|---|---|---|
| 项目题 | 简短结论 → S/T → A → R | 简历事实、项目记录、实际交付 |
| 技术题 | 原理 → 边界 → STAR 案例 | 代码与实验记录,或明确标识的验收目标 |
| 排障题 | 已知/未知 → 定位步骤 → STAR | 日志、状态差异、复现前后结果 |
| 假设设计题 | 假设 → 方案与取舍 → STAR | 预期验收标准,不能说已经发生 |
如果为了凑 STAR 编造一个事故,宁可删掉故事,直接标记“假设场景”。如果没有量化结果,可以说“修订范围可追溯”“流程能够停在人工处理”“审核通过内容用于教学”等有依据的完成状态。
面试前最后一次检查
为三个最想讲的结论各准备一条证据:一条历史贡献、一条本次实验、一条未解决限制。每条都能回答“你怎么知道”。这比临时再背二十个术语更有价值。