宋杰峰 .net 全栈 12年经验 面试官：李恺 已完成
百分制得分： 51.3 分
可托付度 权重 0.4
3.50

核心考察：出问题时的行为模式。决定你能不能放心把事情交给他。

Q1：🔴你有没有遇到过做到一半发现做不完或做错了的情况？你怎么处理的？
关键看点：关键看：是否主动暴露问题 + 是否带着方案去沟通 + 是否有事后改进追问路径：回答得浅 →"当时 leader 的反应是什么？" 回答得好 →"后来你做了什么调整来避免类似情况？"
分数 回答特征
5分 有具体案例，第一时间主动同步leader，给出了替代方案和时间评估，事后还做了复盘
4分 有具体案例，主动同步了，但替代方案不够完整，或者没有复盘
3分 有案例但比较模糊，说"会跟leader说"但没有具体细节，没有替代方案
2分 说"没遇到过"或者"加班赶出来了"，没有沟通意识
1分 说"先做完再说"或者"等别人发现再处理"，藏问题的倾向
Q2：🔴讲一个你在线上出过的事故，你当时怎么处理的？后来做了什么防止再发生？
关键看点：关键看：是否诚实面对错误 + 处理是否有章法 + 是否有闭环（不只是灭火，还要防火）追问路径：回答得浅 →"影响范围有多大？持续了多久？" 回答得好 →"复盘文档里写了什么？后来团队流程有什么变化？"
分数 回答特征
5分 讲得很细（时间线、影响范围、排查过程、修复方案），主动承担责任，事后有复盘文档和防重犯机制（加监控/加测试/改流程）
4分 过程讲得清楚，主动承担，有防重犯措施但不够系统
3分 能讲出事故和处理过程，但细节不够，防重犯措施比较泛（"以后注意"）
2分 讲得含糊，有甩锅倾向（"测试没测出来"、"产品需求不清楚"），没有防重犯措施
1分 说"没出过事故"（不可信）或者明显在推卸责任
Q3：🔵你有没有在 code review 的时候发现过别人代码里的问题？能讲一个具体的例子吗？你当时怎么处理的？
关键看点：关键看：是否有真实的 review 经历 + 沟通方式是否成熟 + 是否以团队利益为先追问路径：回答得浅 →"如果对方不接受你的意见，你会怎么办？" 回答得好 →"你觉得 code review 最容易发现什么类型的问题？最不容易发现什么？"
分数 回答特征
5分 有具体案例（如发现了性能隐患、安全漏洞、逻辑错误等），先私下沟通说清楚问题和影响，如果对方不改会在 review 里正式提出，必要时升级给 leader，态度是对事不对人
4分 有案例，会私下沟通或在 review 里提，但没有考虑到升级路径
3分 说"会在 review 里提"但举不出具体案例，比较被动
2分 说"不太好意思说"或"看情况"，回避冲突
1分 说"不关我事"或"他的代码他负责"，完全没有团队意识
Q4：🔵需求做到一半产品改了方向，你怎么应对？
关键看点：关键看：情绪是否稳定 + 是否有成本意识 + 是否主动管理变化而不是被动接受追问路径：回答得浅 →"你当时跟产品怎么沟通的？" 回答得好 →"有没有遇到过你觉得不合理但还是得做的需求变更？你怎么处理的？"
分数 回答特征
5分 先评估已做工作的复用性，给出改方向的成本和时间评估，主动跟产品和leader对齐优先级，必要时推回不合理的变更
4分 会评估影响和沟通，但缺少推回不合理需求的意识
3分 说"那就改呗"，能接受变化但没有评估和沟通的习惯
2分 表现出明显的抱怨情绪，或者说"产品老改需求很烦"
1分 说"直接重写"不做任何评估，或者情绪化地拒绝
取四个问题得分的平均值，再结合整体面试中的感受微调。重点关注： 他讲的是真实经历还是编的？（真实经历有细节、有情绪、有反思；编的通常很笼统、结构完美但没有个人痕迹） 他的第一反应是什么？（第一反应最真实，后面补充的可能是"正确答案"） 整场面试中他有没有说过"我不知道"或"我当时做得不好"？（敢承认不足的人更可信） 警惕"完美答案"：如果每个问题都回答得滴水不漏，反而要怀疑真实性
技术原理认知 权重 1.5
2.43

核心考察：是否理解技术原理，而不是只会调用 API。决定了他的天花板。

【.NET 核心与异步编程】
Q1：🔴你写过的代码里，有没有遇到过异步相关的坑？比如死锁、线程问题、或者性能不符合预期的情况？
关键看点：关键看：是否有真实踩坑经历 + 是否理解背后的原理（状态机、SynchronizationContext）+ 是否形成了避坑习惯追问路径：回答得浅 →"你知道 async/await 编译后变成了什么吗？" 回答得好 →"ConfigureAwait(false) 在 ASP.NET Core 里还有必要吗？为什么？"
分数 回答特征
5分 能讲出具体的踩坑经历（如 .Result/.Wait() 导致死锁、忘了 ConfigureAwait(false) 在库代码中引发问题、async void 导致异常丢失等），并且能解释背后的原理（状态机、SynchronizationContext），说明后来怎么解决和避免的
4分 有踩坑经历，能解释原因，但对底层机制（状态机、线程调度）的理解不够完整
3分 知道"不能用 .Result 会死锁"，但说不清为什么，没有具体的踩坑案例
2分 只会用 async/await 语法，没遇到过问题（或者遇到了但不知道是异步导致的）
1分 对异步编程的理解停留在"加个 await 就行"，说不出任何原理
Q2：🔴假设你要批量调 100 个第三方接口拿数据，你会怎么写？一个一个 await 还是有别的办法？
关键看点：关键看：是否能区分 I/O 并发和 CPU 并行 + 是否有并发度控制意识 + 是否考虑了异常和超时追问路径：回答得浅 →"Parallel.ForEach 和 Task.WhenAll 有什么区别？" 回答得好 →"如果 100 个里面有 3 个超时了，你怎么处理？其他 97 个的结果还要不要？"
分数 回答特征
5分 直接说用 Task.WhenAll 做异步并发，并且会控制并发度（SemaphoreSlim），知道不能无限制并发（会打爆对方接口或耗尽连接池）。能区分这个场景和 CPU 密集型场景的区别（后者用 Parallel.ForEach），还会考虑超时、重试、部分失败的处理
4分 知道用 Task.WhenAll，提到了并发度控制，但对超时和部分失败的处理考虑不够
3分 知道不该一个一个 await，但对 Task.WhenAll 和 Parallel 的区别说不清，并发度控制没概念
2分 说"用 Parallel.ForEach"（I/O 场景用错了），或者说"一个一个调也行"
1分 不了解批量异步调用的方式
Q3：🔵Task.Run 和直接 async 方法有什么区别？什么场景下该用 Task.Run？
关键看点：关键看：是否理解线程调度的区别 + 是否知道适用场景 + 是否了解在 Web 应用中的注意事项
分数 回答特征
5分 能讲清楚 Task.Run 是把工作调度到线程池线程执行，而直接 async 方法在当前线程开始执行直到遇到第一个 await。知道 Task.Run 适合 CPU 密集型工作，不应该在 ASP.NET Core 中滥用（因为请求本身已经在线程池线程上），能举出具体的正确和错误使用场景
4分 区别讲得清楚，知道 CPU 密集型场景该用 Task.Run，但对 ASP.NET Core 中的使用注意事项不够了解
3分 知道 Task.Run 会用线程池，但对"什么时候该用什么时候不该用"说不清楚
2分 混淆两者的区别，或者说"都差不多"
1分 不了解 Task.Run 的作用
Q4：🔵.NET 8 或最近的 .NET 版本里，有没有哪个新特性你在项目里实际用过？用了之后效果怎么样？
关键看点：关键看：是否持续关注技术演进 + 是否有实际升级/使用经验 + 是否能评估新特性的实际价值（而不是只背特性列表）
分数 回答特征
5分 能说出实际用过的新特性并讲清楚使用场景和效果（如用 Native AOT 减少启动时间和内存占用、用 Frozen collections 优化热路径性能、用 Identity API endpoints 简化认证开发、用 Time abstraction 提升可测试性等），能对比用之前和用之后的差异
4分 能说出用过的新特性且理解正确，但对效果的量化或对比不够具体
3分 知道一两个新特性（如"性能更好了"），但没有实际使用经验，停留在"看过文章"
2分 只知道版本号升级了，说不出具体改进
1分 不了解 .NET 版本演进，一直用旧版本没关注过
【数据访问与 SQL 优化】
Q5：🔴假设你有一个页面要展示订单列表，数据从数据库查出来只是展示用，不需要修改。你用 EF Core 查的时候会注意什么？
关键看点：关键看：是否本能地想到 AsNoTracking + 是否理解变更追踪的性能影响 + 是否有查询优化的整体意识追问路径：回答得浅 →"你知道 EF Core 的变更追踪是怎么工作的吗？" 回答得好 →"AsNoTracking 和 AsNoTrackingWithIdentityResolution 有什么区别？什么时候用后者？"
分数 回答特征
5分 第一反应就是用 AsNoTracking（只读场景不需要变更追踪），能解释为什么（跳过快照创建，减少内存开销），还会考虑只查需要的字段（Select 投影）、分页、避免 N+1 查询。能提到 ChangeTracker 的工作机制（快照对比检测变更）
4分 知道用 AsNoTracking，能解释原因，但对 Select 投影或 N+1 问题没主动提到
3分 知道 AsNoTracking 是"只读时用"，但说不清内部机制，也没考虑其他优化点
2分 直接 ToList 查出来，没想过 AsNoTracking，对变更追踪没概念
1分 不了解 EF Core 的查询优化
Q6：🔴联合索引 (A, B, C)，WHERE B=1 AND A=2 能走索引吗？WHERE A=1 ORDER BY C 呢？
关键看点：关键看：是否理解最左前缀匹配 + 是否知道优化器会重排条件 + 是否能分析复杂场景
分数 回答特征
5分 知道数据库优化器会重排条件顺序，WHERE B=1 AND A=2 能走索引（优化器重排为 A=2 AND B=1 匹配最左前缀）。WHERE A=1 ORDER BY C 只能用到索引的 A 部分，ORDER BY C 无法利用索引（中间跳过了 B），需要额外排序。能分析更多场景（如 WHERE A=1 AND B>5 ORDER BY C 的情况）
4分 两个场景分析正确，知道最左前缀原则和优化器重排，但对更复杂场景分析不够
3分 知道"有顺序要求"（最左前缀），但具体分析有误，比如认为 WHERE B=1 AND A=2 不能走索引
2分 概念模糊，分不清联合索引和单列索引的区别
1分 不了解联合索引原理
Q7：🔵100 万条数据要导出，你用 EF Core 怎么做？直接 ToList 行不行？
关键看点：关键看：是否有大数据量处理意识 + 方案是否考虑了内存和数据库压力 + 是否有实际经验
分数 回答特征
5分 明确说不能直接 ToList（内存会爆），给出分批方案：分页查询（Skip/Take）或使用 AsNoTracking + 流式读取（AsAsyncEnumerable / IAsyncEnumerable），每批处理后释放 DbContext 避免内存膨胀。还会考虑导出格式（CSV 流式写入而非全部加载到内存），以及数据库端的压力（避免长事务、考虑快照隔离）
4分 知道不能 ToList，给出分批方案，但没考虑 DbContext 内存膨胀或导出格式优化
3分 知道"数据量大不能一次加载"，但方案不够具体，只说"分页查"
2分 说"直接 ToList 应该可以"或"加大内存"，对大数据量处理没概念
1分 没有处理大数据量的经验，说不出方案
Q8：🔵给你一条慢 SQL，你怎么分析？说说你看执行计划的思路。
关键看点：关键看：是否有结构化的分析思路 + 是否能读懂执行计划的关键指标 + 是否知道常见的索引失效场景
分数 回答特征
5分 有系统的分析流程：先用 EXPLAIN / EXPLAIN ANALYZE 看执行计划，关注扫描方式（全表扫描 vs 索引扫描）、预估行数 vs 实际行数、是否有排序/临时表/文件排序。能根据执行计划判断是缺索引、索引失效（函数操作、隐式转换、LIKE '%xx'）、还是统计信息过期。会结合实际场景给出优化建议（加索引、改写SQL、分表等）
4分 知道看执行计划，能分析扫描方式和索引使用情况，但对统计信息、隐式转换等细节不够了解
3分 知道"看执行计划"和"加索引"，但具体怎么看、看什么说不清楚
2分 只会说"加索引"或"优化SQL"，没有分析思路
1分 没有 SQL 调优经验
【后台任务与消息驱动】
Q9：🔴一个订单创建后要通知库存、支付、物流三个服务，你怎么设计？
关键看点：关键看：是否有事件驱动思维 + 是否考虑了可靠性（发布可靠、消费幂等、失败补偿）+ 是否能做 trade-off 分析
分数 回答特征
5分 首选事件驱动架构：订单服务发布"订单已创建"事件到消息队列，三个服务各自订阅消费。能考虑到：事件发布的可靠性（Outbox Pattern / 事务性发件箱），消费端的幂等性，部分服务失败的补偿机制（Saga 模式），以及监控和告警。还能对比同步调用 vs 异步事件的 trade-off
4分 选择事件驱动，方案基本合理，但缺少 Outbox Pattern 或 Saga 等可靠性设计
3分 知道用消息队列解耦，但方案比较粗糙，没考虑失败处理和一致性
2分 说"依次调用三个服务的接口"，同步调用思维，没有解耦意识
1分 没有设计思路
Q10：🔵BackgroundService 和 Hangfire/Quartz 你怎么选？各自适合什么场景？
关键看点：关键看：是否理解轻量级 vs 持久化调度的区别 + 是否能根据场景做选择 + 是否考虑了可靠性
分数 回答特征
5分 能讲清楚 BackgroundService 是进程内轻量级后台任务（随应用启停，适合简单的定时轮询、队列消费），Hangfire/Quartz 是持久化的任务调度框架（支持 Cron 表达式、任务重试、Dashboard 监控、分布式调度）。知道 BackgroundService 不适合需要持久化和可靠性的场景（应用重启任务丢失），能根据具体需求选择
4分 区别和适用场景基本正确，但对持久化、分布式调度等细节不够深入
3分 知道两者都能做后台任务，但说不清具体区别和选择依据
2分 只用过其中一个，对另一个不了解
1分 不了解后台任务的实现方式
Q11：🔵Kafka 和 RabbitMQ 的核心区别是什么？你们项目里用的哪个？为什么？
关键看点：关键看：是否理解两者的架构差异 + 是否有实际使用经验 + 选型是否有依据
分数 回答特征
5分 能讲清楚核心区别：Kafka 是分布式日志系统（高吞吐、消息持久化、分区有序、消费者组、适合事件流和大数据场景），RabbitMQ 是传统消息代理（灵活路由、多种交换机类型、消息确认机制成熟、适合业务解耦和任务队列）。能结合项目实际说出选型理由，知道各自的局限性
4分 核心区别讲得清楚，有项目使用经验，但对比分析不够全面
3分 知道"Kafka 吞吐量大"、"RabbitMQ 更灵活"，但说不清具体区别
2分 只用过其中一个，对另一个只是听说过
1分 不了解消息队列
Q12：🔵假设你们的订单消费服务处理太慢，消息开始积压了，你怎么办？
关键看点：关键看：是否有止血+根治的分层思路 + 是否理解不同消息队列的扩展机制 + 是否考虑了顺序性追问路径：回答得浅 →"Kafka 的消费者数量和分区数有什么关系？" 回答得好 →"如果必须保证同一个订单的消息按顺序处理，你怎么设计？"
分数 回答特征
5分 先止血（临时扩消费者实例），然后分析慢的原因（是消费逻辑慢还是下游依赖慢）。知道 Kafka 通过增加分区+消费者来扩展（但消费者数不能超过分区数），RabbitMQ 通过竞争消费直接加消费者。会考虑消息顺序性问题（扩展后同一订单的消息可能被不同消费者处理），以及积压消息的监控告警
4分 知道加消费者，了解分区和竞争消费的区别，但对顺序性或扩展上限考虑不够
3分 说"加消费者"，但不清楚 Kafka 和 RabbitMQ 扩展机制的区别
2分 只知道"加机器"，不了解消费者扩展的具体机制
1分 没有处理消息积压的经验和思路
【可靠性设计】
Q13：🔴两个请求同时修改同一条数据，你怎么处理？乐观锁还是悲观锁？
关键看点：关键看：是否理解两种锁的原理和适用场景 + 是否知道 EF Core 中的实现方式 + 冲突处理策略是否完整
分数 回答特征
5分 能区分乐观锁（版本号/RowVersion/ConcurrencyToken，适合读多写少、冲突概率低的场景）和悲观锁（SELECT FOR UPDATE / 数据库行锁，适合写多冲突高的场景）。知道 EF Core 中通过 [ConcurrencyCheck] 或 [Timestamp] 实现乐观锁，能说出冲突时的处理策略（重试、合并、提示用户）。还能提到分布式锁（Redis / 数据库）的适用场景
4分 乐观锁和悲观锁的原理和场景都清楚，但缺少 EF Core 具体实现或分布式锁的补充
3分 知道乐观锁和悲观锁的概念，但具体实现和场景选择说不清
2分 只知道"加锁"，分不清乐观锁和悲观锁
1分 没有并发处理的概念
Q14：🔵重试策略你怎么设计？指数退避听说过吗？Polly 用过吗？
关键看点：关键看：是否区分可重试和不可重试异常 + 是否了解指数退避和抖动 + 是否熟悉 Polly 的实际使用
分数 回答特征
5分 能讲清楚重试策略的设计要点：区分可重试异常（网络超时、503）和不可重试异常（400、业务逻辑错误），使用指数退避（Exponential Backoff）+ 抖动（Jitter）避免重试风暴。熟悉 Polly 的使用（Retry、CircuitBreaker、Timeout、Bulkhead），知道如何组合策略（PolicyWrap），能结合 HttpClientFactory 使用
4分 知道指数退避和 Polly，使用场景正确，但对策略组合或抖动等细节不够了解
3分 知道"失败了重试几次"，听说过 Polly 但没深入用过，指数退避概念模糊
2分 只会写 for 循环重试，不了解退避策略和 Polly
1分 没有重试设计的概念
Q15：🔵你在项目里遇到过跨服务数据不一致的情况吗？比如这边扣了钱那边没发货，或者订单状态对不上。当时怎么处理的？
关键看点：关键看：是否有真实的不一致处理经历 + 是否理解分布式事务的 trade-off + 是否倾向最终一致性而非强一致追问路径：回答得浅 →"Saga 模式你了解吗？编排式和协调式有什么区别？" 回答得好 →"事件发布本身怎么保证可靠？如果发事件的时候应用挂了呢？"
分数 回答特征
5分 有真实案例，能讲清楚不一致是怎么发生的、当时怎么修复的。在方案层面倾向最终一致性（Saga 模式、事务性发件箱 Outbox Pattern、补偿机制），知道分布式事务的问题（性能差、可用性低），能根据业务场景选择一致性级别
4分 有案例或清晰的方案思路，了解 Saga 或最终一致性，但缺少实际落地细节
3分 知道"分布式事务很难"，提到过 Saga 或 TCC 但说不清具体怎么做
2分 说"用分布式事务框架"或"两阶段提交就行"，没有深入理解 trade-off
1分 不了解跨服务一致性问题
Q16：🔵Redis 缓存和数据库数据不一致了怎么办？你们怎么处理的？
关键看点：关键看：是否理解缓存策略的 trade-off + 是否知道常见异常场景的防护 + 是否有实际经验
分数 回答特征
5分 能讲清楚常见的缓存策略（Cache Aside / Read Through / Write Through / Write Behind）和各自的一致性问题。知道"先更新数据库再删缓存"的方案及其延迟双删的改进，能分析缓存击穿（热点key过期）、缓存穿透（查不存在的数据）、缓存雪崩（大量key同时过期）的防护方案。有实际项目中的处理经验
4分 知道主要的缓存策略和一致性处理方案，但对击穿/穿透/雪崩的防护不够全面
3分 知道"先更新数据库再删缓存"，但对其他策略和异常场景了解不多
2分 只知道"设过期时间"，对缓存一致性问题没有系统认识
1分 不了解缓存一致性问题
【性能调优】
Q17：🔴你们系统的 QPS 大概多少？做过哪些性能优化？效果怎么样？
关键看点：关键看：是否有实际的性能数据 + 优化手段是否有层次 + 是否能量化效果
分数 回答特征
5分 能说出具体的 QPS 数据和优化前后的对比，优化手段有层次（代码层面：减少不必要的查询、异步化；数据库层面：索引优化、读写分离、分库分表；缓存层面：热点数据缓存、本地缓存+分布式缓存多级架构；架构层面：限流、降级、CDN）。能量化优化效果（如"P99 从 500ms 降到 50ms"）
4分 有实际优化经验，能说出具体手段和效果，但优化层次不够全面
3分 做过一些优化（如"加了索引"、"加了缓存"），但缺少量化数据和系统性思路
2分 说不出具体的 QPS 和优化经验，只有泛泛的概念
1分 没有性能优化经验
Q18：🔵你们项目里有用 APM 工具吗？怎么通过日志和指标定位瓶颈？
关键看点：关键看：是否有 APM 工具的实际使用经验 + 定位流程是否系统 + 是否了解分布式追踪
分数 回答特征
5分 有实际使用 APM 工具的经验（如 Application Insights、SkyWalking、Jaeger、Prometheus+Grafana），能讲清楚定位流程：先看整体指标（QPS、P99、错误率）发现异常 → 通过 traceId 追踪具体请求链路 → 定位慢的环节（数据库、外部调用、代码逻辑）→ 结合日志看具体原因。知道结构化日志（Serilog）和分布式追踪的价值
4分 用过 APM 工具，定位流程基本正确，但对分布式追踪或结构化日志的理解不够深入
3分 知道 APM 工具的概念，但实际使用经验有限，定位瓶颈主要靠看日志
2分 只靠 Console.WriteLine 或简单日志排查，没用过 APM 工具
1分 没有性能监控和定位的经验
Q19：🔵你们项目里为什么用 Redis 而不是 MemoryCache？反过来呢？
关键看点：关键看：是否理解进程内缓存 vs 分布式缓存的 trade-off + 是否能根据场景选择 + 是否了解多级缓存
分数 回答特征
5分 能讲清楚核心区别：MemoryCache 是进程内缓存（速度快、无网络开销，但不能跨实例共享、应用重启丢失、占用应用内存），Redis 是分布式缓存（跨实例共享、持久化、丰富的数据结构，但有网络开销）。能根据场景选择：单实例+数据量小用 MemoryCache，多实例/需要共享/数据量大用 Redis。还能提到多级缓存架构（MemoryCache 做 L1 + Redis 做 L2）
4分 区别和选择依据正确，但没提到多级缓存或内存压力等细节
3分 知道"Redis 是分布式的，MemoryCache 是本地的"，但选择依据不够清晰
2分 只用过其中一个，说不清区别
1分 不了解缓存方案的选择
【架构设计】
Q20：🔴你们项目的分层结构是怎样的？Controller 里该不该写业务逻辑？为什么？
关键看点：关键看：是否理解各层职责 + 是否能说出分层的好处和不分层的坏处 + 是否有实际经验
分数 回答特征
5分 清晰的分层理解：Controller 只做参数校验、请求转发和响应封装，业务逻辑在 Service 层，数据访问在 Repository 层。能说出为什么（关注点分离、可测试性、可复用性），能举出 Controller 写业务逻辑导致的实际问题（如代码膨胀、难以测试、逻辑重复）。还能讨论是否需要 Repository 层的 trade-off
4分 分层正确，知道 Controller 不该写业务逻辑，但对"为什么"解释不够深入
3分 知道要分层，但职责划分不够清晰，比如 Service 和 Repository 的边界模糊
2分 分层概念模糊，Controller 里写业务逻辑觉得"也可以"
1分 不了解分层架构
Q21：🔴DI 容器里 Singleton、Scoped、Transient 分别什么时候用？用错了会出什么问题？
关键看点：关键看：是否理解三种生命周期的适用场景 + 是否知道 Captive Dependency 问题 + 是否有实际踩坑经验
分数 回答特征
5分 能讲清楚三种生命周期：Singleton（全局单例，适合无状态服务、配置、HttpClient 工厂），Scoped（每个请求一个实例，适合 DbContext、UnitOfWork），Transient（每次注入新实例，适合轻量无状态服务）。知道经典错误：Singleton 依赖 Scoped 会导致 Captive Dependency（Scoped 服务被提升为 Singleton 生命周期，DbContext 不会被释放导致内存泄漏和数据过期）。知道 ValidateScopes 开发环境检测
4分 三种生命周期和适用场景正确，知道 Captive Dependency 问题，但细节不够完整
3分 知道三种生命周期的基本含义，但对"用错了会怎样"说不清楚
2分 只知道名称，不清楚具体区别和适用场景
1分 不了解依赖注入的生命周期
Q22：🔵假设你要给所有 API 请求加一个统一的耗时日志，记录每个请求花了多长时间，你会怎么做？
关键看点：关键看：是否本能想到中间件 + 是否理解洋葱模型 + 是否知道中间件顺序的重要性追问路径：回答得浅 →"中间件和 Filter 有什么区别？各自适合什么场景？" 回答得好 →"如果只想给某些路径加日志，不是所有请求都加，你怎么做？"
分数 回答特征
5分 第一反应就是写一个自定义中间件，能讲清楚中间件的洋葱模型（请求进来 → next() → 响应出去，在 next 前后记录时间差）。知道中间件注册顺序很重要（这个日志中间件要放在靠外层），能说出常见中间件的顺序（异常处理 → 日志 → 路由 → 认证 → 授权 → 端点），知道 Use/Map/Run 的区别
4分 知道用中间件，洋葱模型理解正确，但对中间件顺序的重要性或 Use/Map/Run 的区别不够清楚
3分 知道"用中间件"，但对洋葱模型和执行顺序理解不够，可能说"用 Filter 也行"但分不清两者的区别
2分 说"在每个 Controller 里加日志"或"用 AOP"，没想到中间件
1分 不了解中间件的概念
Q23：🔵你们项目现在是单体还是微服务？有没有遇到过'这个功能到底该放哪个服务'的纠结？最后怎么决定的？
关键看点：关键看：是否有真实的架构决策经历 + 是否按业务域而非技术层思考 + 是否了解拆分成本追问路径：回答得浅 →"你觉得什么时候该从单体拆出微服务？有什么信号？" 回答得好 →"拆完之后遇到过什么新问题吗？"
分数 回答特征
5分 有真实的纠结案例，能讲清楚最终按什么依据决定的（按业务领域边界 / DDD 限界上下文，而不是按技术层拆）。知道拆分的成本（分布式事务、服务间通信、运维复杂度），有"不要过早拆分"的意识，能说出什么时候该拆什么时候不该拆
4分 拆分思路正确（按业务域），知道拆分的成本，但缺少实际纠结和决策的经历
3分 知道"按功能拆"，但对拆分边界和成本的理解不够深入
2分 说"每个功能一个服务"，过度拆分倾向，不了解成本
1分 不了解微服务拆分的考量
Q24：🔵你在项目里用过哪些设计模式？举个实际例子说说为什么用它而不是别的方案。
关键看点：关键看：是否有实际应用经验 + 是否能做 trade-off 分析 + 是否有避免过度设计的意识
分数 回答特征
5分 能举出实际项目中的例子（如用策略模式处理多种支付渠道、用工厂模式创建不同类型的通知服务、用中介者模式解耦模块间通信），说清楚为什么选这个模式而不是别的（trade-off 分析），知道过度设计的问题
4分 有实际例子，选择理由合理，但对比分析不够深入
3分 能说出几个模式名称和基本概念，但举不出实际应用的例子
2分 只知道名称（"单例模式"、"工厂模式"），不知道怎么在项目中用
1分 不了解设计模式
Q25：🔵你在项目里有没有用过聚合根、领域事件这类 DDD 的东西？在什么场景下用的？觉得值不值？
关键看点：关键看：是否有实际应用经验 + 是否知道 DDD 的适用场景和局限性 + 是否有"不过度设计"的意识追问路径：回答得浅 →"聚合根和普通实体有什么区别？为什么要有这个概念？" 回答得好 →"你们的领域事件是怎么发布和消费的？进程内还是跨服务？"
分数 回答特征
5分 有实际使用经验，能讲清楚在什么业务场景下引入的（如复杂的订单状态流转、多实体一致性保证），用了之后的效果和代价。理解聚合根的核心价值（一致性边界），知道 DDD 不是银弹，简单 CRUD 场景用 DDD 是过度设计
4分 概念理解正确，有一定实践经验，但对"什么时候该用什么时候不该用"的判断不够清晰
3分 知道 DDD 的基本概念（实体、值对象、聚合根），但没有实际应用经验
2分 只听说过 DDD，说不清具体概念
1分 不了解 DDD
Q26：🔵假设你要做一个电商的订单模块，订单里有商品明细、收货地址、优惠券信息。如果让你用 DDD 的思路来建模，订单这个聚合根的边界你会怎么画？哪些东西放在聚合内，哪些放在外面？
关键看点：关键看：是否理解聚合边界的核心依据（一致性边界）+ 是否能区分"聚合内实体"和"跨聚合引用" + 是否考虑了聚合大小的 trade-off追问路径：回答得浅 →"如果用户修改了收货地址，已经创建的订单里的地址要不要跟着变？这说明什么？" 回答得好 →"如果订单明细有几百条，每次加载整个聚合性能很差，你怎么处理？还能保持聚合的一致性吗？"
分数 回答特征
5分 能讲清楚聚合边界的划分依据（一致性边界：必须在同一个事务里保证一致的放在聚合内）。订单明细放在订单聚合内（订单和明细必须一起创建、一起修改），收货地址作为值对象嵌入聚合，优惠券信息只保留快照（优惠券本身属于营销域，不应该放在订单聚合里）。能解释为什么不把商品实体放进来（商品属于商品域，订单只引用商品ID+快照价格）。还能讨论聚合过大的问题（加载慢、并发冲突多）
4分 边界划分基本合理，知道聚合根的核心是一致性边界，但对"什么该放进来什么该引用"的判断有一两处不够准确（比如把优惠券实体也放进了聚合）
3分 知道聚合根的概念，能说出"订单是聚合根，明细是子实体"，但对边界划分的依据说不清楚，更多是凭直觉
2分 把 DDD 建模等同于数据库表设计，说"订单表、明细表、地址表"，没有领域建模的思维
1分 不了解聚合根和聚合边界的概念
本维度题目最多，不需要也不应该全部问完。推荐流程： 先问完所有 🔴核心必考 题（Q1、Q2、Q5、Q6、Q9、Q13、Q17、Q20、Q21，共 9 道），这些覆盖了每个分类的基础能力，确保评分公平 根据候选人核心题的表现和简历侧重，选 2-4 道 🔵选考深挖 题追问，用于区分中高水平 如果核心题已经暴露出明显短板（如异步和索引都答不上来），可以不再深挖，节省时间给其他维度 其他关注点： 他是"背答案"还是真理解？（追问实现细节不会卡壳的是真理解，回答得很"漂亮"但追问就露馅的是背的） 深度比广度重要：一个方向能讲透比每个都知道皮毛更有价值 有没有实际踩坑经验？（踩过坑的人讲出来有血有肉） 不要因为一道题答不上来就否定：看他答不上来时的反应，坦然说"没接触过"比硬编一个答案更可信
AI 工具提效能力 权重 2.5
2.33

核心考察：是否拥抱 AI 工具，能否用 AI 大幅提升开发效率。不只是会用 AI 补全代码，更要看能不能用 AI 驱动整个开发流程。技术基础 + AI 是团队的硬性要求，敷衍的就算了。

【基础使用】
Q1：🔴你平时写代码用 AI 工具吗？用的哪些？怎么用的？
关键看点：关键看：是否已经形成使用习惯 + 使用场景是否多样 + 是主动探索还是被动接触
分数 回答特征
5分 日常深度使用（Copilot/Cursor/Kiro 等），能说出具体使用场景（写业务代码、生成模型映射、写SQL、排查问题、写文档），已经形成了自己的工作流，AI 是开发流程的一部分而不是偶尔用用
4分 日常在用，能举出具体场景，但使用范围偏窄（比如只用来补全代码，没用来排查问题或写测试）
3分 用过，但不是日常习惯，偶尔遇到问题会问 ChatGPT，没有深度集成到开发流程里
2分 只是听说过或简单试过，没有实际使用经验，说"还没来得及学"
1分 完全没用过，或者明确表示排斥（"AI 写的代码不靠谱，不如自己写"）
Q2：🔴AI 生成的代码你会直接用吗？你怎么判断它生成的代码靠不靠谱？
关键看点：关键看：是否有审查意识 + 审查方法是否具体 + 是否踩过坑并从中学到了什么（这其实也在考技术判断力）
分数 回答特征
5分 明确说不会直接用，有系统的审查方法：先看逻辑是否正确、再看边界情况、检查安全隐患（SQL注入、资源泄漏）、确认是否符合项目规范。能举出 AI 生成的代码有问题的具体例子（如没加 AsNoTracking、没处理空值、过度设计等）
4分 知道要审查，能说出几个审查维度，有踩过坑的经历，但审查方法不够系统
3分 说"会看一下再用"，但说不清楚具体看什么，审查意识有但方法模糊
2分 说"大部分时候直接用，有问题再改"，审查意识薄弱
1分 完全不审查直接用，或者因为"不信任"所以完全不用
Q3：🔵举个例子，AI 工具帮你解决过什么实际问题？省了多少时间？
关键看点：关键看：例子是否具体且有业务价值 + 是否能感知到效率提升 + 是否在复杂场景下也能用好
分数 回答特征
5分 能举出具体且有价值的例子（如用 AI 快速理解陌生代码库、批量生成数据迁移脚本、辅助设计复杂业务逻辑的方案），能量化效率提升（"原来要半天，现在一小时"），并且不止一个例子
4分 有具体例子且有说服力，但量化不够精确，或者只有一个例子
3分 例子比较泛（"帮我写过一些代码"、"查过一些报错"），看不出实际提效幅度
2分 举不出具体例子，或者例子很简单（"帮我写了个 for 循环"）
1分 没有任何使用经历可以分享
Q4：🔵你用 AI 生成代码的时候，有没有遇到过它生成的东西看着对但其实有坑的情况？能举个例子吗？
关键看点：关键看：是否有真实的踩坑经历 + 是否形成了审查习惯 + 认知是否理性客观追问路径：回答得浅 →"你一般怎么判断 AI 生成的代码靠不靠谱？会检查哪些方面？" 回答得好 →"有没有什么场景你觉得完全不应该让 AI 来写？"
分数 回答特征
5分 能举出具体的踩坑案例（如 AI 生成的代码没处理空值、用了过时的 API、没加 AsNoTracking、SQL 注入风险、过度设计等），并且能说出自己的审查方法和应对策略。对 AI 既不盲信也不排斥，态度理性务实
4分 有踩坑经历，态度理性，但审查方法不够系统
3分 说"有时候不太准"，但举不出具体例子，对 AI 的局限性认知比较模糊
2分 说不出具体问题，要么过度信任（"AI 生成的基本都对"），要么过度否定（"AI 都不靠谱"）
1分 对 AI 完全没有使用经验，说不出任何看法
Q5：🔵假设你入职后发现团队要求所有人日常开发必须用 AI Coding 工具，你会怎么融入这个工作方式？
关键看点：关键看：态度是主动拥抱还是被动接受 + 是否有推动团队提效的意识 + 是否把 AI 当作长期趋势追问路径：回答得浅 →"你觉得团队用 AI 工具最容易踩什么坑？怎么避免？" 回答得好 →"如果让你给团队制定一个 AI 使用规范，你会包含哪些内容？"
分数 回答特征
5分 非常积极，自己已经在用了，能说出具体怎么融入（如先了解团队用的工具和规范，分享自己的使用经验，主动探索新的提效场景）。还能提出建设性想法（如团队共享 prompt 模板、建立 AI 代码审查规范）
4分 积极接受，愿意学习和适应，但没有额外的建设性想法
3分 接受但不主动，说"团队要求就用"，态度是配合而非主动拥抱
2分 有顾虑或抵触，说"担心代码质量"或"不太习惯"，需要较多推动
1分 明确抵触，认为 AI 是噱头或者会降低代码质量
【进阶能力：SDD / Agent / Skills】
Q6：🔵假设你要做一个比较复杂的功能，比如一个完整的订单退款流程（涉及退款申请、审批、退款执行、通知用户、更新库存），你会怎么用 AI 工具来帮你做这件事？是一个文件一个文件地让它写，还是有别的方式？
关键看点：关键看：是否有"先定义再执行"的 SDD 思维 + 是否会把需求结构化为 AI 可执行的 spec + 是否理解这样做对输出质量的影响追问路径：回答得浅 →"你觉得直接把整个需求丢给 AI 和先拆好再给，效果差别大吗？" 回答得好 →"你写 spec 的时候一般会写到什么粒度？太粗和太细各有什么问题？"
分数 回答特征
5分 有结构化拆解的意识：先把需求拆成清晰的模块/步骤（如退款状态机、审批规则、退款接口对接、通知逻辑），写成某种形式的规格文档或任务清单，然后让 AI 按照 spec 逐步实现。知道 SDD（Spec-Driven Development）的思路——先定义清楚"要做什么"再让 AI 去"怎么做"，而不是边想边让 AI 写。能说出这样做的好处（AI 输出更可控、减少返工、方便 review）
4分 会先做需求拆解再让 AI 写，但没有形成系统的 spec 文档习惯，更多是口头或脑子里拆完直接 prompt
3分 说"一个功能一个功能地让 AI 写"，有拆解意识但粒度比较粗，没有先写 spec 再执行的概念
2分 说"直接把需求丢给 AI 让它写"，没有拆解和规格化的意识，完全依赖 AI 自己理解
1分 没有用 AI 做过复杂功能，或者说"复杂功能还是自己写靠谱"
Q7：🔵你用 AI 写代码的时候，是主要用它的自动补全，还是会让它自己规划怎么做然后一步步执行？比如 Cursor 的 Agent 模式、Kiro 的 Autopilot 这类，你用过吗？
关键看点：关键看：是否了解 Agent 模式的工作方式 + 是否有实际使用经验 + 是否能判断什么场景用 Agent 什么场景用补全追问路径：回答得浅 →"你觉得什么样的任务适合用 Agent 模式？什么样的不适合？" 回答得好 →"Agent 模式跑偏的时候你一般怎么纠正？有没有什么技巧让它更可控？"
分数 回答特征
5分 用过 Agent 模式（Cursor Agent / Kiro Autopilot / Copilot Agent 等），能讲出具体使用场景和体验。知道 Agent 模式和补全模式的本质区别（Agent 能自主规划执行步骤、读写多个文件、调用工具，而补全只是逐行建议）。能说出 Agent 模式的优势（处理跨文件任务效率高）和局限（容易跑偏、需要好的 spec 引导、复杂任务需要人工检查点），有自己的使用策略
4分 用过 Agent 模式，体验正面，但对优势和局限的总结不够系统，使用策略偏感性（"感觉复杂的时候用 Agent"）
3分 听说过 Agent 模式，试过几次但没有深度使用，主要还是用补全模式
2分 不了解 Agent 模式，只用过自动补全和对话问答
1分 不了解 AI Coding 工具的不同模式
Q8：🔵你有没有给 AI 工具配置过自定义的规则或者扩展能力？比如 Cursor Rules、Kiro 的 Steering/Skills、或者接过 MCP 工具之类的？
关键看点：关键看：是否有定制 AI 工具的意识和实践 + 是否理解"让 AI 了解项目上下文"的价值 + 是否探索过 MCP 等扩展能力追问路径：回答得浅 →"你觉得不配置任何规则直接用和配置了之后，AI 的输出质量差别大吗？" 回答得好 →"如果让你给团队搭一套 AI 开发工作流（从 spec 到 agent 到 skills），你会怎么设计？"
分数 回答特征
5分 有实际配置经验，能举出具体例子（如写过 Cursor Rules 约束代码风格、配置过 Kiro Steering 文件定义项目规范、接过 MCP Server 让 Agent 能查数据库或调内部 API）。理解这些配置的价值——让 AI 了解项目上下文和团队规范，输出更贴合实际需求。还能说出配置过程中踩过的坑
4分 配置过一些规则（如代码风格约束、项目说明），但没有接过 MCP 或更深度的扩展，理解到位但实践范围偏窄
3分 知道可以配置规则，试过简单的（如加了个 system prompt），但没有深入使用
2分 听说过但没配置过，说"还没研究"
1分 不知道 AI 工具可以自定义配置和扩展
取八个问题得分的平均值，再结合整体感受微调。Q1-Q5 考察基础使用能力，Q6-Q8 考察进阶能力。重点关注： 他是"真用"还是"嘴上说用"？（真用的人能讲出具体工具版本、使用场景、踩过的坑） 审查意识是关键分水岭：会用 + 会审 = 靠谱，会用 + 不审 = 危险，不用 = 淘汰 态度比熟练度重要：积极拥抱的人上手很快，排斥的人推不动 注意区分"会说"和"会做"：说"我天天用 AI"但举不出具体例子的，可能只是跟风 进阶题（Q6-Q8）不要求所有候选人都答好，但如果能答好说明他已经走在前面了。SDD 思维和 Agent 使用经验是加分项，没有不扣分，但有的话能明显拉开差距 警惕只会说术语的人：说"我用 SDD"但问他 spec 怎么写就卡壳的，和说"我用 Agent"但说不出什么场景该用的，都是背概念
交付闭环能力 权重 0.3
3.00

核心考察：能否把事情从需求到上线完整做完。决定了他能不能独立扛模块。

Q1：🔴给你一个需求：做一个批量支付接口，你从拿到需求到上线，整个过程你会怎么做？
关键看点：关键看：是否有端到端的全局视角 + 是否针对具体场景做了特殊设计 + 是否考虑了上线后的事情（监控、回滚）
分数 回答特征
5分 完整链路：澄清需求（支付渠道、金额上限、频率、失败处理）→ 技术方案设计（分批、异步、幂等）→ 表结构和接口设计 → 开发自测 → code review → 测试环境验证 → 灰度/小流量上线 → 监控告警配置 → 全量上线。还会主动提到回滚方案和容量评估
4分 流程基本完整（需求确认→设计→开发→测试→上线），但缺少灰度发布、监控配置或容量评估中的一两项
3分 能说出"看需求→写代码→提测→上线"的基本流程，但比较模板化，没有针对"批量支付"这个场景做特殊考虑（如分批、幂等、对账）
2分 只关注写代码环节，对需求澄清和上线保障基本没概念
1分 说"拿到需求就开始写"，完全没有工程流程意识
Q2：🔴假设产品给你一个需求：'用户可以批量导出订单'，就这一句话，没有其他细节。你拿到之后第一步做什么？你会问产品哪些问题？
关键看点：关键看：是否能快速识别需求中的模糊点 + 是否主动澄清而不是被动等待 + 是否有记录确认的习惯
分数 回答特征
5分 能快速列出关键的模糊点并主动澄清：导出哪些字段？最大数据量多少？导出格式（Excel/CSV）？是否需要筛选条件？是同步下载还是异步生成后通知？权限控制？确认结果会用文字记录，开发前再同步一次方案。如果产品也说不清，会给出两种方案让对方选
4分 会主动找产品确认关键问题，但遗漏了一些重要点（如数据量上限、同步/异步），记录和同步方案的习惯不够系统
3分 说"会问产品"，但没有主动梳理模糊点的习惯，是遇到一个问一个
2分 说"按自己理解先做，做完再看"，缺乏前置沟通意识
1分 说"需求不清楚是产品的问题"，推责且不主动解决
Q3：🔵如果这个接口上线后出了问题，你的回滚方案是什么？
关键看点：关键看：是否理解回滚不只是代码回退 + 是否考虑了数据一致性 + 是否有预案而不是临时应对
分数 回答特征
5分 分层回滚思路：代码层面（版本回退/功能开关）、数据层面（补偿脚本/对账修复）、业务层面（通知下游/暂停相关任务）。能区分"代码bug回滚"和"数据问题修复"是两回事，还会提到回滚演练
4分 知道代码回退和功能开关，也考虑了数据修复，但没有形成体系化的回滚策略
3分 说"回退代码版本"或"发修复版本"，但没考虑数据层面的回滚和业务影响
2分 只说"回滚代码"，对数据不一致的处理没有概念
1分 没想过回滚，或者说"出了问题再说"
Q4：🔵假设你刚上线了一个支付回调接口，第二天有用户投诉说付了钱但订单没更新。你去查的时候，你希望日志里能看到什么信息？你平时写代码会怎么埋日志？
关键看点：关键看：是否有日志分级意识 + 是否考虑了可排查性（traceId、结构化、关键上下文）+ 是否平衡了信息量和性能
分数 回答特征
5分 能说出关键业务节点必须记日志（回调入参、签名验证结果、订单状态变更前后、数据库操作结果、耗时），异常必须记完整堆栈+上下文（订单号、用户ID）。会用结构化日志（Serilog 等）方便搜索，用 traceId 串联整条链路。也会考虑日志量对性能和存储的影响，调试日志可配置开关
4分 知道关键节点和异常要记，有日志分级意识（Info/Warn/Error），但没提到结构化日志或 traceId 串联
3分 说"重要的地方加日志"、"异常要记"，但标准比较模糊，没有体系化的思路
2分 说"多加点日志方便排查"，没有分级意识，容易记太多或太少
1分 不关注日志，或者说"出问题了再加"
Q5：🔵假设你做订单模块，需要调用同事负责的库存服务来扣减库存。你们怎么约定接口？如果他的服务上线比你晚，或者他的接口挂了，你怎么办？
关键看点：关键看：是否有契约意识（接口怎么约定的）+ 是否考虑了依赖方故障的降级 + 是否有协同上线的节奏意识
分数 回答特征
5分 先和对方约定接口契约（入参、出参、异常码、超时时间），用文档或 Swagger 固化下来，各自 Mock 对方接口独立开发。考虑了对方服务不可用时的降级方案（如库存扣减失败时暂存请求稍后重试，或走兜底逻辑），会主动和对方对齐上线节奏，先上谁后上谁有计划
4分 知道要定接口契约，会和对方沟通，但缺少降级方案或上线协调的考虑
3分 说"商量着来"或"谁的模块谁负责"，有边界意识但不够具体
2分 边界意识模糊，容易出现"这块到底谁负责"的扯皮
1分 没有边界概念，或者说"都写在一起就行了"
取五个问题得分的平均值，再结合整体感受微调。重点关注： 他的回答是"教科书式"的还是有实际经验支撑的？（有经验的人会提到具体踩过的坑，"完美答案"反而可疑） 他是否主动考虑了"上线后"的事情？（只想到开发阶段的人闭环能力不足） 他遇到不确定性时的第一反应是什么？（主动澄清 vs 自己猜 vs 推给别人） 关注他的第一反应：听到"批量支付接口"先想到什么？先问需求边界的人和先想技术方案的人，工作方式很不一样
风险意识 权重 0.3
3.00

核心考察：是否会主动扫描隐患。决定线上事故概率。

Q1：🔴一个接口平时 100ms，突然变成 10s，你怎么排查？
关键看点：关键看：排查是否有层次（网络→应用→数据库→外部依赖）+ 是否有止血意识（先恢复再查因）+ 是否用过实际的监控/诊断工具
分数 回答特征
5分 有系统性排查思路：先看监控/APM确认是哪个环节慢（网络、数据库、外部依赖、GC），再看日志定位具体请求，检查数据库慢查询/锁等待/连接池耗尽，检查是否有资源竞争或线程饥饿，最后能给出临时止血方案（限流、降级）和根治方案
4分 排查思路基本正确（看日志→看数据库→看外部依赖），但缺少监控工具的使用或止血方案
3分 知道看日志和数据库，但排查路径不够系统，容易遗漏（比如只想到SQL慢，没想到连接池、GC、线程池等）
2分 只会说"看日志"或"重启试试"，没有结构化的排查思路
1分 完全没有排查经验，说不出任何思路
Q2：🔴假设你上线了一个订单创建接口，运营反馈说有些订单被重复创建了，你怎么排查？怎么防止？
关键看点：关键看：是否有分层防护意识（前端→接口→数据库→消息消费）+ 幂等方案是否具体可落地 + 是否有实际处理经验追问路径：回答得浅 →"幂等性你一般怎么实现？唯一键放在哪一层？" 回答得好 →"如果是消息队列重复投递导致的，你怎么在消费端做幂等？"
分数 回答特征
5分 排查思路清晰（看日志确认是否同一请求重复提交、还是消息重复消费、还是前端重复点击），防护方案完整：前端防重（按钮禁用/loading）、接口层幂等（唯一请求ID/Token机制）、数据库层兜底（唯一键约束）、消息消费层幂等（去重表/状态机）。能讲清楚具体实现方式，有实际处理经验
4分 排查和防护都能讲到，但方案不够分层（比如只考虑了数据库唯一键，没考虑接口层幂等）
3分 知道"加唯一键"或"前端防重复点击"，但方案不够系统，对消息重复消费场景没考虑
2分 只能说"加个判断"，对幂等性没有系统认识
1分 没有处理重复数据的经验和思路
Q3：🔵你们系统上线后出过什么印象比较深的故障或者险情？当时是什么原因，你做了什么防护？
关键看点：关键看：是否有主动扫描隐患的习惯 + 防护措施是否有层次（不只是代码层面，还有监控、告警、兜底）
分数 回答特征
5分 能讲出具体的故障案例（如某次并发写入导致数据重复、第三方接口超时拖垮整个服务、缓存雪崩等），分析清楚根因，讲出做了哪些防护（限流、熔断、监控告警、兜底方案），并且是主动建设而非事后补救
4分 能指出风险点并讲出防护措施，但防护不够体系化，偏单点防护
3分 能说出"数据库是瓶颈"或"第三方接口不稳定"这类泛泛的回答，防护措施比较基础（加try-catch、加日志）
2分 说不出具体风险点，或者说"我们系统还好没什么问题"，缺乏风险扫描意识
1分 完全没有风险概念，从没想过系统哪里会出问题
Q4：🔵批量导入 10 万条数据，中间第 5 万条失败了，你怎么处理？
关键看点：关键看：是否有分批思维 + 是否考虑部分失败的处理 + 是否有幂等和断点续传意识 + 是否考虑了失败后的补偿路径
分数 回答特征
5分 第一反应就是不能全放一个事务里，要分批处理（比如每批1000条）。失败的批次记录到错误表，成功的不回滚。支持断点续传（记录处理进度）。有重试机制，重试仍失败的走人工处理或告警。还会考虑幂等性（重复导入不会产生重复数据）
4分 知道分批处理，失败记录下来后续重试，但没考虑断点续传或幂等性
3分 先想到事务回滚，追问后能改口说分批处理，但方案不够完整
2分 说"全部回滚重来"或"失败了就报错"，没有部分成功的概念
1分 没有处理思路，或者说"应该不会失败"
取四个问题得分的平均值，再结合整体感受微调。重点关注： 他是主动想到风险，还是被追问才想到？（主动的加分，被动的减分） 他的方案是停留在"知道"层面，还是"做过"层面？（做过的人能讲出具体参数和踩过的坑） 他有没有提到监控和告警？（有风险意识的人不只防，还要能发现） 同一个考察点可以和其他维度的回答交叉验证：比如他在"可托付度"里说自己很注重质量，但在风险意识题里完全没考虑异常路径，就有矛盾
沟通顺畅度 权重 0.1
4.00

核心考察：信息传递的准确率。你说的是东，他理解的也是东，而不是西。决定了协作效率和返工成本。 特别说明：这个维度不需要专门出题。下面的题目表面上都是技术场景题，面试者不会意识到你在考沟通。但他回答的过程中，听没听懂你的问题、答没答到点上、表达是否清晰，全都会自然暴露出来。同时，整场面试中其他维度的所有问答，都是这个维度的观察窗口。

Q1：🔴我们有个定时任务每天凌晨跑，从三个不同的数据源拉数据做汇总，生成报表发给运营。最近运营反馈说报表数据有时候对不上，但不是每天都有问题，大概一周出现两三次。你觉得可能是什么原因？你会怎么排查？
关键看点：关键看（沟通维度）：他是否准确接收了问题中的关键信息（三个数据源、偶发、一周两三次）？回答是否紧扣这些信息展开？有没有丢掉关键细节或者自己脑补了题目里没说的东西？追问路径：回答得浅 →"你刚才说的这个原因，能解释为什么是偶发的吗？不是每天都有？" 回答得好 →"如果你排查完发现是第三个数据源凌晨 2 点才更新完，但你的任务 1 点就跑了，你怎么解决？怎么跟运营解释这个问题？"
分数 回答特征
5分 先确认自己理解了问题（"三个数据源汇总、偶发不一致、一周两三次"），然后有层次地分析：先区分是某个数据源的数据本身有问题，还是汇总逻辑有问题，还是时序问题（某个数据源凌晨还没更新完就被拉了）。排查思路清晰：看出问题那几天的日志、对比三个数据源的数据时间戳、检查任务执行时间和数据源更新时间的关系。回答过程中紧扣"偶发"这个关键词，没有跑偏到"重写整个任务"之类的方向
4分 分析方向基本正确，抓住了"偶发"和"三个数据源"这两个关键信息，但排查步骤不够系统，或者遗漏了时序问题
3分 给出了一些可能原因（如"数据源有问题"、"代码有bug"），但比较泛，没有紧扣题目中的关键细节（偶发、三个数据源），排查思路不够清晰
2分 回答偏离了问题重点，比如直接说"加个校验就行"或者开始讲自己做过的报表项目，没有针对这个具体场景分析
1分 明显没听清或没理解问题，回答的内容和问题对不上，或者抓不住任何关键信息
Q2：🔴假设你做了一个功能，测试跟你说'这个页面在某些情况下数据显示不对'，但他也说不清楚具体是什么情况。你怎么处理？
关键看点：关键看（沟通维度）：面对模糊信息时，他的本能反应是主动澄清还是自己脑补？是协作解决还是推回去？这道题表面考的是 debug 能力，但核心考的是他处理模糊信息的方式——这恰恰是日常工作中"你说东他理解成西"的根源追问路径：回答得浅 →"如果你查了半天也没复现，测试又催你修，你怎么办？" 回答得好 →"你有没有遇到过跟测试对同一个 bug 理解不一致的情况？最后怎么对齐的？"
分数 回答特征
5分 第一反应是跟测试一起还原问题：让他演示一下、或者问他是在什么操作步骤下出现的、用的什么数据、能不能稳定复现。如果测试也说不清，会自己去看日志、检查测试环境的数据状态，缩小排查范围后再跟测试确认。整个过程体现出"先把问题搞清楚再动手"的习惯，而不是拿到一个模糊的 bug 就开始猜和改
4分 会跟测试沟通确认，但追问的维度不够全面（比如只问了"什么情况下"，没问"用的什么数据"），或者沟通完就直接去改了，没有验证自己理解的是否正确
3分 说"我去看看代码"或"我查一下日志"，倾向于自己闷头排查，不太主动跟测试沟通确认
2分 直接说"让测试写清楚再提给我"或者"没有复现步骤我没法查"，把球踢回去，缺乏协作意识
1分 回答偏离问题，或者说"这种情况一般是测试环境的问题"直接下结论，不排查不确认
Q3：🔵假设你接手了一个同事写的老项目，代码没什么注释，你需要在里面加一个新功能：当订单金额超过 5000 的时候，要走一个额外的审批流程。你会怎么入手？
关键看点：关键看（沟通维度）：他的回答是否有结构（先做什么、再做什么、最后做什么）？是否紧扣题目场景而不是发散到别的话题？遇到题目中的模糊点（"额外的审批流程"具体是什么）是主动提出要确认，还是自己脑补了一个方案就往下走？追问路径：回答得浅 →"你说先看代码，具体看什么？怎么快速理清一个没注释的项目的逻辑？" 回答得好 →"如果你看完代码发现订单状态机已经很复杂了，加审批流程可能影响现有逻辑，你怎么跟 leader 同步这个风险？"
分数 回答特征
5分 回答紧扣"接手老项目+加审批流程"这个场景，步骤清晰：先理解现有订单流程的代码逻辑（找入口、理流程），确认"审批流程"的具体要求（谁审批、审批不通过怎么办、审批中订单状态是什么），然后再动手改。会主动提到要跟同事或产品确认不清楚的地方，而不是自己猜。整个回答有条理，先说什么后说什么很清楚
4分 步骤基本合理，但在"审批流程的具体要求"这块没有主动提出要确认，直接按自己的理解往下说了
3分 能说出"先看代码再改"的大方向，但表达比较散，想到哪说到哪，听的人需要自己整理他的思路
2分 跳过了理解现有代码的步骤，直接说"加个 if 判断"，或者回答偏到了"老项目应该重构"的方向，没有回应题目的核心
1分 回答和问题对不上，或者完全没有思路
Q4：🔵你们之前做过的项目里，有没有遇到过上线之后才发现需求理解错了的情况？不一定是你的问题，团队里遇到过也行。当时是什么情况？
关键看点：关键看（沟通维度）：他讲一件事情的时候，能不能让你一次听明白？有没有清晰的时间线和因果关系？还是需要你反复追问"等等，你刚才说的是什么意思？"这道题表面考的是交付闭环，但实际上他讲故事的方式直接暴露了他日常沟通的信息传递质量追问路径：回答得浅 →"当时是谁先发现做错了的？发现之后第一时间做了什么？" 回答得好 →"后来团队有没有做什么调整来避免类似的事情再发生？"
分数 回答特征
5分 能讲出一个具体的案例，把事情的来龙去脉讲得很清楚：需求原本是什么、实际做成了什么、偏差是怎么产生的、什么时候发现的、最后怎么处理的。讲述过程本身就很有条理，面试官不需要追问就能听明白整个故事。还能反思原因（比如"当时没有跟产品确认边界条件"）
4分 有案例，讲得基本清楚，但有些环节需要面试官追问才能补全（比如"偏差是怎么产生的"这个关键点没主动说）
3分 有案例但讲得比较散，面试官需要多次追问才能拼出完整的故事，或者案例本身比较模糊（"好像有一次……"）
2分 说"没遇到过"（不太可信），或者讲了一个案例但逻辑混乱，前后矛盾，面试官听完还是不太清楚到底发生了什么
1分 回答跑题（比如开始讲需求变更而不是需求理解错误），或者表达混乱到面试官无法理解他在说什么
这个维度的核心打分依据不是上面四道题的"答案内容"，而是整场面试中他的沟通表现。上面的题只是提供了额外的观察场景，真正的评分要结合全程表现： 全程观察"你问东他答西"的频率：这是最核心的指标。偶尔跑偏一次可以理解（可能是紧张），但如果反复出现，说明信息接收和处理有问题。具体表现：你问的是 A 场景，他回答的是 B 场景；你追问某个细节，他继续说自己想说的；你问"怎么做的"，他回答"为什么要做" 看他回答时是否丢失你问题中的关键信息：比如你的问题里提到了"偶发"、"三个数据源"、"5000 元以上"这些限定条件，他的回答有没有体现这些条件？还是自动忽略了，给了一个泛泛的回答？ 看他表达的结构性：同样的内容，有的人讲出来你一次就听懂了，有的人讲完你还得问"所以你的意思是……？"。后者在日常工作中会大量消耗协作者的精力 看他对模糊信息的处理方式：面试中如果你故意问得模糊一点（或者他确实没听清），他是主动确认"您是指 XX 吗？"还是自己猜一个方向就开始答？前者在工作中不容易出现理解偏差 警惕"表达能力强但信息准确率低"的人：有些人很能说、很流畅，但仔细听会发现他说了很多却没有回答你的问题。这种人在日常协作中更危险，因为你以为他听懂了（他表现得很自信），但其实他理解的和你说的不是一回事
综合评估
维度 权重 得分 加权得分
可托付度 0.4 3.50 1.4
技术原理认知 1.5 2.43 3.6
AI 工具提效能力 2.5 2.33 5.8
交付闭环能力 0.3 3.00 0.9
风险意识 0.3 3.00 0.9
沟通顺畅度 0.1 4.00 0.4
🔒 解锁后修改评分将自动保存 查看完整报告