项目经历与场景题¶

面试追问地图¶

主问题	必讲关键点	下一层追问
项目介绍	背景、规模、职责、难点、结果	架构图、核心链路、上下游
个人贡献	可验证动作和边界	如果没有你会怎样、谁做了其他部分
技术难点	约束、候选方案、取舍	为什么不用替代方案、如何验证
性能优化	基线、瓶颈、措施、结果	压测模型、P99、是否转移瓶颈
线上故障	时间线、止损、根因、复盘	为什么监控没发现、如何防复发
方案失败	当时依据、失败原因、改进	是否主动暴露风险、如何控制损失
跨团队协作	目标、接口、责任、决策	冲突如何解决、延期如何处理
项目指标	性能、稳定性、成本、业务	数据来源、统计周期、可信度

每个核心项目至少准备两条追问链：一个技术难点和一个线上问题，并能连续回答三层“为什么”。

一、项目介绍¶

如何在 3 分钟内介绍一个项目？¶

难度 🔴

使用“背景、职责、难点、方案、结果”五段式，不要从技术栈清单开始讲。

背景：项目服务谁，解决什么业务问题，规模和约束是什么。
职责：自己负责的边界，避免把团队成果全部说成个人成果。
难点：挑 1～2 个真正有取舍的问题。
方案：说明为什么选择该方案，以及放弃了什么方案。
结果：用延迟、吞吐量、成功率、成本或故障率等指标证明效果。

回答模板

该项目用于解决……问题，日均请求量约……。我主要负责……模块。最大的难点是……，因为……。最终采用……方案，同时通过……控制风险。上线后 P99 延迟从……降低到……，错误率从……降低到……。

面试官为什么会持续追问项目细节？¶

项目追问主要验证四件事：

是否真正参与，而不是只会背架构图。
是否理解上下游、数据流和失败路径。
是否做过技术取舍，能解释“为什么”。
是否能用指标证明结果，并对结果负责。

准备项目时至少画清楚：

请求入口 → 核心服务 → 缓存/数据库/MQ → 下游服务
              ↓
        超时、重试、降级、补偿

如何回答“你在项目中的贡献是什么”？¶

贡献应落到可验证的动作：

主导某个模块的设计和落地。
定位并解决某类线上故障。
将人工流程自动化。
降低接口延迟、资源消耗或错误率。
建立监控、压测、发布或复盘机制。

不要只回答“负责接口开发”“参与需求评审”，这些无法体现社招候选人的独立性。

二、技术难点与方案选型¶

业务边界、聚合根、领域事件和状态机类追问见领域建模与代码设计。

如何描述一个有说服力的技术难点？¶

一个合格的技术难点应包含：

约束条件 + 冲突目标 + 候选方案 + 取舍依据 + 验证结果

例如：

系统既要保证地理围栏命中的实时性，又要控制高频定位点带来的计算成本。我们比较了数据库空间索引、Redis GEO 和内存索引，最终采用粗筛加精算方案：先用空间索引缩小候选围栏，再做精确几何计算。这样降低了计算量，同时保留准确性。

如何回答“为什么不用另一种方案”？¶

不要说“团队一直这么用”。从以下维度比较：

维度	关注点
正确性	一致性、精度、边界条件
性能	吞吐量、平均延迟、P99
可用性	单点故障、降级、恢复
复杂度	开发、部署、排障成本
成本	机器、存储、网络、人力
演进性	数据规模和业务增长后的扩展能力

如何回答“如果重新设计，你会怎么做”？¶

先承认原方案的上下文，再提出演进方向：

当时为什么合理。
现在暴露了什么问题。
哪些指标证明需要调整。
新方案如何灰度、兼容和回滚。

不要为了显得有深度而否定原方案。

三、线上问题与复盘¶

如何介绍一次线上故障？¶

难度 🔴

使用时间线回答：

发现 → 止损 → 定位 → 修复 → 验证 → 复盘

发现：告警、用户反馈还是巡检发现。
止损：限流、降级、回滚、扩容或切流。
定位：依据哪些日志、指标和 Trace 缩小范围。
修复：根因是什么，临时方案和长期方案分别是什么。
验证：核心指标是否恢复，是否补充回归和压测。
复盘：为什么没提前发现，如何避免再次发生。

如何区分根因和诱因？¶

例如“流量上涨”通常只是诱因，根因可能是：

SQL 缺少索引导致数据库连接池耗尽。
无超时和隔离导致下游故障扩散。
重试没有退避和上限，形成重试风暴。
缓存集中失效，流量直接打到数据库。

复盘时要追到系统为什么无法承受该诱因。

复盘应该产出什么？¶

明确根因和影响范围。
补充监控、告警和可观测字段。
修复代码、配置或容量问题。
增加故障演练、压测和回归用例。
明确负责人和完成时间。

复盘的目标不是追责，而是降低相同故障再次发生的概率。

四、指标与结果¶

项目成果没有现成指标怎么办？¶

可以从以下方向补齐：

性能：平均延迟、P95/P99、QPS、批处理耗时。
稳定性：成功率、超时率、故障次数、恢复时间。
资源：CPU、内存、数据库连接数、机器数量。
业务：转化率、命中率、人工处理量、客诉量。
研发效能：发布时间、回滚时间、排查时间。

没有精确历史数据时，应说明是区间或估算，不要编造数字。

如何证明优化结果可信？¶

使用相同流量和数据集做前后对比。
同时关注平均值和 P99，避免平均值掩盖长尾。
灰度发布，对比实验组和基线组。
观察完整业务周期，排除短时波动。
确认优化没有转移到下游或牺牲正确性。

五、行为与协作¶

如何回答“与同事意见不一致怎么办”？¶

先对齐目标和约束，而不是争论技术偏好。
列出候选方案和评价维度。
用数据、原型或压测验证关键假设。
无法统一时，由明确的决策人拍板并记录结论。
执行后复盘，不在结果出来前反复争论。

如何回答“需求很急但风险很高怎么办”？¶

识别不可接受的风险和最小交付范围。
将完整方案拆成临时止损和长期治理。
对高风险操作准备灰度、监控和回滚。
将风险、影响和决策人记录清楚。
不用“时间紧”作为省略测试和兜底的理由。

如何准备自己的项目问题清单？¶

每个核心项目至少准备：

一段 1 分钟简介和一段 3 分钟简介。
一张架构图和一条核心调用链。
两个技术难点。
一次线上故障。
一次方案取舍。
三个可量化结果。
一个失败或可改进点。