技术一面结束后的反问清单

技术一面的反问不是为了“考倒面试官”，而是为了确认岗位是否匹配，并展示自己对工作内容、工程质量和成长路径的关注。一般准备 5～8 个候选问题，根据面试过程选择 2～3 个即可，不要把清单全部问完。

反问原则

1. 优先问入职后真实工作：职责、短期目标、技术挑战，比泛泛询问公司文化更有信息量；
2. 结合本场内容追问：面试官刚聊过网络、性能或服务架构，就沿着该主题问团队实践；
3. 使用开放式问题：让面试官介绍背景、取舍和评价标准，避免只能回答“是/否”；
4. 根据面试官角色选择：技术面试官适合问架构和工程实践，负责人适合问岗位目标和团队协作；
5. 控制数量和时间：通常问 2～3 个，每个问题让对方完整回答，必要时只追问一次；
6. 避免索取敏感信息：不要追问具体用户量、收入、事故细节或未公开项目，可询问一般性的技术约束和处理方法。

最推荐的反问

1. 入职后的工作内容

如果有机会加入，这个岗位入职后前三个月通常会参与哪些工作？您希望新人先解决什么问题？

可以确认：岗位是否与招聘描述一致、是业务开发还是基础设施、是否有明确的新人任务。

2. 当前最重要的技术挑战

团队目前最希望解决的技术挑战是什么？它更偏性能、稳定性、架构演进，还是研发效率？

如果面试中已经谈过某个主题，可以替换为：

刚才我们讨论了网络 I/O 和服务性能。团队在实际开发中，目前更关注吞吐、尾延迟、资源成本还是稳定性？

3. 对优秀新人的评价标准

您认为在这个岗位上，表现比较好的校招生或新人，半年后通常具备哪些能力？

这个问题比“多久晋升”更适合技术一面，可以了解团队真正看重的是交付、基础知识、代码质量、排障能力还是业务理解。

4. 代码质量与研发流程

团队平时如何保证代码质量？会有哪些 Code Review、自动化测试、灰度发布或线上回滚机制？

可以判断团队是否只关注快速交付，还是有稳定的工程规范和反馈机制。

5. 新人的培养和反馈

新人加入后通常如何熟悉代码和业务？团队是否有导师、设计评审或定期反馈机制？

不要只问“有没有导师”，更重要的是有没有可执行的 onboarding、review 和反馈流程。

6. 技术方案如何决策

当团队需要引入新组件或调整架构时，通常如何做技术选型和评审？主要看哪些指标？

这个问题可以了解团队是否会做压测、成本评估、故障演练和方案复盘，而不是仅凭个人偏好选技术。

7. 稳定性与排障实践

对线上服务，团队通常重点监控哪些指标？发生性能抖动或故障后，一般如何定位和复盘？

服务端方向可进一步关注 P95/P99、错误率、队列积压、限流、降级、日志、Tracing 和容量规划，但不要要求面试官透露具体事故或业务数据。

8. 团队协作方式

这个岗位平时主要和哪些角色协作？需求、技术方案和上线风险通常由哪些人一起评审？

适合确认服务端是否需要与客户端、策划、测试、运维、SRE 或平台团队频繁协作。

9. 技术栈的演进方向

团队现有技术栈比较成熟的部分是什么？接下来准备重点改进哪些方向？

如果岗位描述已经写了技术栈，不要只问“你们用什么语言或框架”，而应询问为什么这样选择、目前有什么约束以及未来如何演进。

10. 请面试官给学习建议

结合今天讨论的内容，如果我想更好地胜任这个方向，您建议我接下来重点补充哪些能力？

这是比“您觉得我今天表现怎么样”更自然的问法。面试官未必能透露评价，但通常可以给出岗位相关的学习方向。

服务端 / 游戏服务器方向可选问题

架构与职责

• 这个岗位更偏网关、业务逻辑、基础设施、数据存储，还是性能与稳定性建设？
• 团队的服务通常如何划分边界？新增功能时如何判断放在现有服务还是拆成新模块？
• 状态型服务如何做玩家、房间或场景分片？同一实体的消息顺序如何保证？

性能与稳定性

• 团队更关注平均延迟还是 P95/P99？出现延迟尖刺时通常从哪些层面定位？
• 服务如何处理突发流量、慢客户端、消息积压和下游超时？
• 容量规划、压测和故障演练一般在什么阶段进行？

网络与并发

• 网络层目前使用事件循环、协程还是线程模型？选择该方案主要基于哪些约束？
• 连接和玩家状态如何在线程之间分片？哪些状态允许并行，哪些必须串行？
• 对可靠消息和实时状态更新，团队如何选择 TCP、QUIC、UDP 或应用层可靠协议？

工程效率

• 本地开发、联调和线上环境之间有哪些差异？团队如何降低联调与问题复现成本？
• 是否有统一的日志、指标、Tracing、配置和发布平台？新人通常需要维护这些基础设施吗？

根据面试官角色选择

面试官角色	优先反问	不宜优先询问
一线开发 / 技术面试官	技术挑战、代码评审、排障、架构取舍	薪资、审批流程、晋升周期
组长 / 技术负责人	入职目标、团队方向、评价标准、协作方式	过细的 API 或工具使用
部门负责人	业务方向、岗位定位、团队阶段、长期挑战	具体代码实现细节
HR	后续流程、岗位安排、薪酬福利、入职时间	深入架构和代码问题

若无法判断面试官角色，优先问“入职后三个月做什么”和“当前最重要的技术挑战”，通常都比较安全。

根据剩余时间组合

只够问 1 个

如果有机会加入，您希望这个岗位的新人前三个月先做好什么？

可以问 2 个

1. 入职后的主要工作和短期目标是什么？
2. 团队当前最重要的技术挑战是什么？

可以问 3 个

1. 入职后三个月的工作和期望；
2. 团队如何保证代码质量和线上稳定性；
3. 优秀新人半年后通常具备哪些能力。

本场技术讨论很充分

1. 先围绕面试中出现的一个技术点追问团队实践；
2. 再问岗位目标或新人评价标准。

例如：

刚才我们讨论了 epoll 和 io_uring。我想了解团队当前网络层主要使用哪种模型，选择它时最重要的约束是什么？另外，您希望新人加入后三个月先承担哪类工作？

不建议直接这样问

不推荐问法	问题	更合适的表达
“我这次能过吗？”	面试官通常不能当场透露结论	“您建议我继续补充哪些岗位相关能力？”
“你们加班多吗？”	容易变成只求肯定/否定	“团队通常的发布节奏和紧急故障处理机制是什么？”
“多久可以晋升？”	技术一面阶段过早，且信息通常不完整	“优秀新人半年到一年通常会承担哪些更复杂的工作？”
“你们技术栈是什么？”	招聘信息往往已有答案，过于宽泛	“当前技术栈主要解决了哪些约束，接下来准备改进什么？”
“公司未来怎么样？”	范围太大，难得到有效回答	“这个团队接下来最重要的目标或技术方向是什么？”
“没有问题了。”	错过了解岗位和展示思考的机会	至少准备一个“三个月工作目标”问题

技术一面一般不优先讨论薪酬细节；若面试官主动介绍或当前就是 HR 环节，可以正常确认薪资结构、工作地点和流程安排。

现场表达模板

我有两个问题想请教：

第一，如果有机会加入，这个岗位的新人前三个月一般会参与哪些工作？

第二，刚才我们讨论了 <某个技术主题>，我想了解团队在实际项目中是如何处理
<性能 / 稳定性 / 架构取舍> 的？

如果对方回答较长，不必机械继续追问清单。可以先复述自己的理解，再追问一个有价值的边界：

我理解主要约束是 <总结对方回答>。那团队在做这个选择时，最看重的是
延迟、吞吐、稳定性还是研发成本？

面试后记录模板

### 本次反问

1. 我问了什么？
2. 面试官回答的核心信息是什么？
3. 这反映出岗位的工作内容、技术成熟度和成长空间如何？
4. 下次是否需要换一种问法或继续追问？

反问的目标不是问得多，而是通过两三个问题判断：我进去做什么、团队如何把事情做好、我怎样才能成长为合格成员。