# 1. 业务方给你的需求和 SLA 写得很模糊（"高可用""快速响应"），你按字面实现后被批评"没达到预期"，该怎么推动量化 SLA A 辩解自己按字面做了 B 推动把模糊标准量化成可用率/延迟/吞吐等指标，用数据对账并沉淀验收标准流程 ✓ 正确答案 C 加快实现让它"看起来达标" D 接受批评不再讨论
# 2. 你的代码导师说"风格不对重写"，但你按团队 code style 写的，你怀疑导师说的"风格"其实是个人偏好，怎么在不被冒犯的前提下 argue A 直接说导师是个人偏好 B 无条件重写 C 请教式确认具体指哪部分，把对齐团队规范作为判断标准，并推动沉淀规范 ✓ 正确答案 D 不重写也不沟通
# 3. 你的模块被 leader 临时改需求，已经写了一半的代码需要推翻重做，你担心影响交付日期但不敢 argue，应该用什么数据推动 leader 重排优先级 A 默默加班硬扛 B 直接拒绝改需求 C 用数据量化变更成本、重做成本、日期影响，给出选项让 leader 决策 ✓ 正确答案 D 抱怨 leader 想不清楚
# 4. 你的模块被 leader 在周会上当众表扬了"做得不错"，但你内心知道自己做得不够好，担心下次无法维持高预期该怎么调整 A 享受表扬，维持现状 B 焦虑担心被看穿 C 客观复盘不足，制定补强计划，并主动向 leader 对齐改进空间 ✓ 正确答案 D 向 team 澄清自己没那么好
# 5. 你的模块被 leader 要求"做得通用一点将来给别的项目用"，但过度抽象让当前项目变复杂，应该用什么原则说服 leader 先做简单版本 A 直接反对抽象 B 无条件做过度抽象 C 用 YAGNI 原则，先做满足当前需求的简单版并预留扩展点，按真实需求再抽象 ✓ 正确答案 D 抱怨需求不明确
# 6. 导师 review 你的 PR 时只说"这里改一下"没解释原因，你按要求改完后不理解原理，下次遇到类似场景还是会错，怎么打破这种循环 A 按改就行，不再深究 B 只改这一次 C 不理会 review 意见 D 当场追问原因、自行研究、沉淀成踩坑清单、下次反馈理解 ✓ 正确答案
# 7. 导师给你的需求文档只写了"实现 XX 功能"没有任何验收标准，你按自己理解做完后业务方说"完全不是这个意思"，怎样从一开始就推动明确标准 A 按自己理解直接做完 B 等做完再说 C 开工前拆解成可验证行为、案例确认、写验收标准文档，必要时用最小可用迭代 ✓ 正确答案 D 让业务方自己写清楚
# 8. 导师让你做的功能你做完后发现有更好的开源方案，但导师坚持用团队既有技术栈，你应该用什么论据说服而不是简单说"业界都用 X" A 业界都用 X B 用可衡量的收益、风险可控、迁移成本、渐进式试点来论证 ✓ 正确答案 C 说既有技术栈落后 D 直接换，不等同意
# 9. 独立交付一个紧急 feature，导师不在工位没法 review，你直接部署后线上出 bug，你判断 review 能避免这个 bug，怎样的证据链能让 leader 不把责任全推给你 A 隐瞒没 review 的事实 B 不解释，接受批评 C 把责任全推给流程 D 用沟通痕迹、风险提示、归因证据还原过程，诚实认领设计责任并指出流程缺口 ✓ 正确答案
# 10. 独立开发的 feature 上线后被 leader 临时改方向，之前的工作归零，你怀疑是 leader 没想清楚，怎么用证据链推动 leader 先想清楚再决定 A 直接说 leader 没想清楚 B 默默放弃之前的成果 C 量化投入与改方向成本，请教决策依据，建议小范围验证后再投入 ✓ 正确答案 D 拒绝执行新方向
# 11. 独立负责的第一个模块上线后被测试发现 3 个 P1 缺陷，你怀疑测试环境配置不一致，应该用哪些证据链证明是环境问题不是代码问题 A 同一代码在不同环境复现对比 + 配置差异证据 + 日志堆栈定位 ✓ 正确答案 B 口头声称环境有问题 C 让测试重测 D 直接改代码
# 12. 你的模块被 leader 要求"和 XX 系统对齐数据格式"，但 XX 系统格式是历史包袱根本不合理，怎么推动改造而不是被动兼容 A 顺从兼容，长期背负 B 咒骂 XX 系统 C 直接拒绝兼容 D 用兼容成本 vs 改造收益的 ROI 论证，渐进式推进并找到推动对象 ✓ 正确答案
# 13. 你的模块被 leader 要求"性能提升 10 倍"但需求方没说不准加机器，怎样的优化方案既提了性能又不让 leader 觉得你只懂加机器 A 只提加机器 B 只优化代码，不讨论资源 C 直接说做不到 D 先 profiling 定位瓶颈，再按代码/架构/资源分层优化，说明加机器的适用边界 ✓ 正确答案
# 14. 导师给你 review 一个 PR 后说"差不多"，你担心这不代表 approval 只是"懒得再看"，怎么确认 review 结论而不是自己想当然 A 直接当 approval 上线 B 再等导师主动说 C 主动澄清结论、确认 review 范围、必要时补足自查并留痕 ✓ 正确答案 D 放弃这次上线
# 15. 导师给你一个任务评估后发现根本不是初级工程师该做的，但拒绝显得不能扛事，应该怎么 argue 需要更高 level 的人来 lead A 表达愿做主力，客观说明任务需要更高 level 的 lead 把控风险，并愿在过程中成长 ✓ 正确答案 B 直接说"我做不了" C 硬扛下来 D 抱怨任务不合理
# 16. 独立开发的 feature 上线后业务方要求"再加一个相似功能"，你担心变成需求黑洞，应该怎么评估边界在哪里 A 一律接受，避免冲突 B 一律拒绝新需求 C 区分合理演进与需求蔓延，用成本-价值评估，界定范围并纳入排期 ✓ 正确答案 D 让 PM 处理
# 17. 上线后监控显示你的接口 QPS 比预期低 10 倍，业务方质疑"是不是做错了"，你该怎么定位是产品没人用、技术问题还是埋点错了 A 先查埋点/监控准确性，再查技术故障，最后分析产品侧 ✓ 正确答案 B 直接认定产品没人用 C 直接改代码 D 让业务方解释
# 18. 你的模块被 leader 要求"先做个 demo 给老板看"，但 demo 和实际生产差距巨大，怎么提前沟通让老板不会基于 demo 做错误决策 A 让 demo 尽量做得像生产 B 事前标注差距、演示时主动声明边界、把 demo 定位为方向验证 ✓ 正确答案 C 不做 demo D 让老板自己判断
# 19. 你的模块被业务方绕过直接调用私有 API，他们改了你不知道的字段导致数据错乱，应该用哪些防御性设计提前堵住 A 只靠口头警告 B 用契约校验、权限控制、字段容错、版本化、监控告警等多层防御 ✓ 正确答案 C 把私有 API 设为公开 D 事后修复
# 20. 你的模块被业务方要求"兼容历史数据"，但历史数据格式有几十种异常你代码里只处理了 3 种，上线后大量数据解析失败怎么应急 A 直接回滚全部 B 只修复当前报错 C 先止损隔离，按异常分类统计，分批修复主类，并建立全量扫描与回归机制 ✓ 正确答案 D 责怪业务方历史数据太乱
# 21. 你的独立模块上线后第一周没出任何事故，但第二周集中出 3 个小事故，leader 质疑是不是第一周是运气好，应该用什么数据反驳 A 强调第一周确实没出事 B 用事故成因、触发条件、监控兜底等数据分析第一周平稳的机制 ✓ 正确答案 C 承认是运气 D 责怪流量变化
# 22. 你的独立模块被另一位初级同事 fork 出去做了不同版本上线，行为不一致导致线上数据混乱，应该用哪些代码层面的约束防止 A 提醒大家不要 fork B 加密代码 C 把模块做成单一来源、有版本、有契约的可复用组件，并用包管理和契约测试约束 ✓ 正确答案 D 删除模块
# 23. 独立开发的模块在季度总结时发现实际收益只有预期 30%，leader 质疑是不是技术方案选错了，怎么复盘才不会被定性为失败 A 承认技术方案选错了 B 拆解收益不足是因业务假设还是技术执行，展示技术价值，客观改进并给下一步 ✓ 正确答案 C 隐瞒收益数据 D 指责业务方
# 24. 独立模块上线一周后线上出现内存缓慢上涨，dump 文件显示是你引入的缓存使用方式有问题，你该怎么写事故复盘才不会被定为"低级错误" A 只承认"我写错了缓存配置" B 淡化问题 C 深度归因缓存生命周期管理缺失，并上升为团队规范、review checklist、监控等系统性改进 ✓ 正确答案 D 归咎于 JVM
# 25. 你的代码导师 review 时提了 30 条意见，大部分是格式问题，你按要求改完后发现逻辑漏洞没被发现，这种 review 质量怎么反馈 A 指责导师 review 不认真 B 自己默默补逻辑 C 不再让导师 review D 用具体例子说明逻辑比格式重要，提议 lint 管格式、人管逻辑的分层 review ✓ 正确答案
# 26. 你的独立模块上线后用户反馈"操作反人类"，但你看代码逻辑没问题，可能是 UX 问题，怎么定位到底是技术还是 UX 问题 A 认定是用户不会用 B 用埋点数据看用户操作路径、用户访谈归因，区分交互设计与技术实现细节 ✓ 正确答案 C 只改代码 D 忽略用户反馈
# 27. 独立开发的 feature 上线后 leader 让你"写个文档总结一下"，你不知道要总结到什么粒度，应该用哪些维度才算合格 A 只写做了什么 B 只写代码注释 C 越详细越好，堆砌流水账 D 覆盖背景、方案、实现、结果、复盘，让不了解的人能看懂、接手的人能实现、团队能吸取经验 ✓ 正确答案
# 28. 独立模块上线后你发现了一个边界 case 的 bug 但业务影响小，leader 说"先这样吧以后再说"，你担心未来爆发该怎么留证据 A 口头记住即可 B 不记录，等爆发再说 C 偷偷修掉 D 用 issue 记录、决策留痕、监控观测、backlog 排期把它变成可追踪的已知问题 ✓ 正确答案
# 29. 独立模块上线后被业务方说"和 XX 家的产品不一样"，但你做的是 B 端不是 C 端，怎么解释定位差异又不显得傲慢 A 说"我们是 B 端，你不懂" B 不理睬业务方 C 直接承认做得差 D 先认同观察，用 B/C 端用户与场景差异的业务逻辑解释，用用户视角沟通并可用数据验证 ✓ 正确答案
