面试追问地图
| 主问题 | 必讲关键点 | 下一层追问 |
|---|---|---|
| 项目介绍 | 背景、规模、职责、难点、结果 | 架构图、核心链路、上下游 |
| 个人贡献 | 可验证动作和边界 | 如果没有你会怎样、谁做了其他部分 |
| 技术难点 | 约束、候选方案、取舍 | 为什么不用替代方案、如何验证 |
| 性能优化 | 基线、瓶颈、措施、结果 | 压测模型、P99、是否转移瓶颈 |
| 线上故障 | 时间线、止损、根因、复盘 | 为什么监控没发现、如何防复发 |
| 方案失败 | 当时依据、失败原因、改进 | 是否主动暴露风险、如何控制损失 |
| 跨团队协作 | 目标、接口、责任、决策 | 冲突如何解决、延期如何处理 |
| 项目指标 | 性能、稳定性、成本、业务 | 数据来源、统计周期、可信度 |
每个核心项目至少准备两条追问链：一个技术难点和一个线上问题，并能连续回答三层“为什么”。
一、项目介绍
如何在 3 分钟内介绍一个项目？
难度 🔴
使用“背景、职责、难点、方案、结果”五段式，不要从技术栈清单开始讲。
- 背景：项目服务谁，解决什么业务问题，规模和约束是什么。
- 职责：自己负责的边界，避免把团队成果全部说成个人成果。
- 难点：挑 1～2 个真正有取舍的问题。
- 方案：说明为什么选择该方案，以及放弃了什么方案。
- 结果：用延迟、吞吐量、成功率、成本或故障率等指标证明效果。
回答模板
该项目用于解决……问题，日均请求量约……。我主要负责……模块。最大的难点是……，因为……。最终采用……方案，同时通过……控制风险。上线后 P99 延迟从……降低到……，错误率从……降低到……。
面试官为什么会持续追问项目细节？
项目追问主要验证四件事：
- 是否真正参与，而不是只会背架构图。
- 是否理解上下游、数据流和失败路径。
- 是否做过技术取舍，能解释“为什么”。
- 是否能用指标证明结果，并对结果负责。
准备项目时至少画清楚：
请求入口 → 核心服务 → 缓存/数据库/MQ → 下游服务
↓
超时、重试、降级、补偿如何回答“你在项目中的贡献是什么”？
贡献应落到可验证的动作：
- 主导某个模块的设计和落地。
- 定位并解决某类线上故障。
- 将人工流程自动化。
- 降低接口延迟、资源消耗或错误率。
- 建立监控、压测、发布或复盘机制。
不要只回答“负责接口开发”“参与需求评审”，这些无法体现社招候选人的独立性。
二、技术难点与方案选型
业务边界、聚合根、领域事件和状态机类追问见 领域建模与代码设计。
如何描述一个有说服力的技术难点？
一个合格的技术难点应包含：
约束条件 + 冲突目标 + 候选方案 + 取舍依据 + 验证结果例如：
系统既要保证地理围栏命中的实时性，又要控制高频定位点带来的计算成本。我们比较了数据库空间索引、Redis GEO 和内存索引，最终采用粗筛加精算方案：先用空间索引缩小候选围栏，再做精确几何计算。这样降低了计算量，同时保留准确性。
如何回答“为什么不用另一种方案”？
不要说“团队一直这么用”。从以下维度比较：
| 维度 | 关注点 |
|---|---|
| 正确性 | 一致性、精度、边界条件 |
| 性能 | 吞吐量、平均延迟、P99 |
| 可用性 | 单点故障、降级、恢复 |
| 复杂度 | 开发、部署、排障成本 |
| 成本 | 机器、存储、网络、人力 |
| 演进性 | 数据规模和业务增长后的扩展能力 |
如何回答“如果重新设计，你会怎么做”？
先承认原方案的上下文，再提出演进方向：
- 当时为什么合理。
- 现在暴露了什么问题。
- 哪些指标证明需要调整。
- 新方案如何灰度、兼容和回滚。
不要为了显得有深度而否定原方案。
三、线上问题与复盘
如何介绍一次线上故障？
难度 🔴
使用时间线回答：
发现 → 止损 → 定位 → 修复 → 验证 → 复盘- 发现：告警、用户反馈还是巡检发现。
- 止损：限流、降级、回滚、扩容或切流。
- 定位：依据哪些日志、指标和 Trace 缩小范围。
- 修复：根因是什么，临时方案和长期方案分别是什么。
- 验证：核心指标是否恢复，是否补充回归和压测。
- 复盘：为什么没提前发现，如何避免再次发生。
如何区分根因和诱因？
例如“流量上涨”通常只是诱因，根因可能是：
- SQL 缺少索引导致数据库连接池耗尽。
- 无超时和隔离导致下游故障扩散。
- 重试没有退避和上限，形成重试风暴。
- 缓存集中失效，流量直接打到数据库。
复盘时要追到系统为什么无法承受该诱因。
复盘应该产出什么？
- 明确根因和影响范围。
- 补充监控、告警和可观测字段。
- 修复代码、配置或容量问题。
- 增加故障演练、压测和回归用例。
- 明确负责人和完成时间。
复盘的目标不是追责，而是降低相同故障再次发生的概率。
四、指标与结果
项目成果没有现成指标怎么办？
可以从以下方向补齐：
- 性能：平均延迟、P95/P99、QPS、批处理耗时。
- 稳定性：成功率、超时率、故障次数、恢复时间。
- 资源：CPU、内存、数据库连接数、机器数量。
- 业务：转化率、命中率、人工处理量、客诉量。
- 研发效能：发布时间、回滚时间、排查时间。
没有精确历史数据时，应说明是区间或估算，不要编造数字。
如何证明优化结果可信？
- 使用相同流量和数据集做前后对比。
- 同时关注平均值和 P99，避免平均值掩盖长尾。
- 灰度发布，对比实验组和基线组。
- 观察完整业务周期，排除短时波动。
- 确认优化没有转移到下游或牺牲正确性。
五、行为与协作
如何回答“与同事意见不一致怎么办”？
- 先对齐目标和约束，而不是争论技术偏好。
- 列出候选方案和评价维度。
- 用数据、原型或压测验证关键假设。
- 无法统一时，由明确的决策人拍板并记录结论。
- 执行后复盘，不在结果出来前反复争论。
如何回答“需求很急但风险很高怎么办”？
- 识别不可接受的风险和最小交付范围。
- 将完整方案拆成临时止损和长期治理。
- 对高风险操作准备灰度、监控和回滚。
- 将风险、影响和决策人记录清楚。
- 不用“时间紧”作为省略测试和兜底的理由。
如何准备自己的项目问题清单？
每个核心项目至少准备：
- 一段 1 分钟简介和一段 3 分钟简介。
- 一张架构图和一条核心调用链。
- 两个技术难点。
- 一次线上故障。
- 一次方案取舍。
- 三个可量化结果。
- 一个失败或可改进点。