# 1. 技术债导致线上事故后，团队只修了表面症状，你如何推动把事故暴露的技术债纳入正式还债队列，而不是又变成一次救火 A 修好表面症状就结束 B 等下次事故再说 C 用事故数据量化代价，将根因技术债登记进正式队列并分配 owner 和预算 ✓ 正确答案 D 工程师自己修，不纳入规划
# 2. 你的项目依赖另一个团队提供 UI 设计，但 UI 团队排期满，你看怎么 argue A 干等 UI 团队 B 直接绕过 UI 团队自己做 C 量化影响、寻求替代方案、必要时升级到共同负责人协调 ✓ 正确答案 D 取消项目
# 3. 你的项目依赖另一个团队的 code review，但他们要求严且慢，你看怎么 argue A 抱怨对方太严格 B 分析慢的原因，拆小 PR、给足上下文、约定 SLA 来提升效率 ✓ 正确答案 C 绕过 review 直接合入 D 降低自己代码质量迎合速度
# 4. 你的项目依赖另一个团队的人员 review 方案，但他们一直没时间，你看怎么 argue A 无限期等待对方 B 自己伪造 review 记录 C 不 review 直接实施 D 讲清影响、推动明确时间承诺，必要时升级到双方 leader 裁决 ✓ 正确答案
# 5. 你做了一个技术债改进但出了事故，leader 质疑"为什么要改"，你怎么看怎么 argue A 辩解"我是对的" B 隐瞒事故 C 诚实承认事故、复盘根因、说明改进价值并提供修复与更稳妥的方案 ✓ 正确答案 D 放弃技术债改进
# 6. 你负责的模块依赖的上游契约频繁变更，你的设计被迫反复返工，如何推动上游把契约变更纳入变更评审并给下游留出迁移窗口 A 每次都默默返工 B 拒绝上游的所有变更 C 量化成本并推动上游建立变更评审与迁移窗口机制 ✓ 正确答案 D 自己改一份契约
# 7. 你发现了一个新的技术债但项目马上要上线，你怎么看怎么 argue A 一律先处理才能上线 B 一律记录延后 C 隐瞒不报 D 按风险区分：高风险需处理或缓解，低风险记录并排入上线后计划 ✓ 正确答案
# 8. 你发现团队的测试覆盖率低想做改进但 PM 说"不需要"，你怎么看怎么 argue A 把低覆盖率翻译成 bug/事故成本，用渐进方案争取投入 ✓ 正确答案 B 认同 PM，不做测试 C 强制要求全量补测试 D 自己偷偷补
# 9. 你的项目依赖另一个团队 review 你的代码，但他们的 reviewer 一直没空，你怎么看怎么 argue A 请对方安排替代 reviewer、拆小 PR、约明确时间，必要时升级协调 ✓ 正确答案 B 绕过 review 直接合入 C 无限期等待 D 降低代码质量让 review 更快
# 10. 你的项目依赖另一个团队做压测，但他们说"没压测环境"，你怎么看怎么 argue A 跳过压测直接上线 B 评估风险、提供替代方案（临时环境/部分压测），必要时装环境并明确负责人 ✓ 正确答案 C 承认没环境就放弃 D 隐瞒压测缺失
# 11. 你如何把技术债的“利息”量化为可理解的指标（开发速度下降、事故率上升），争取还债预算？ A 技术债无法量化 B 技术债只有工程师能看到 C 用开发速度下降、事故率上升等指标量化，并对比还债前后 ROI 来争取预算 ✓ 正确答案 D 只要口头说明即可
# 12. 你的项目依赖另一团队维护的组件，但该组件不在对方未来两个季度的 roadmap 上，你如何把依赖项推进成对方 roadmap 的正式条目（影响面量化、双方 owner、排期承诺），对方以「没资源」拒绝时按什么标准决定是否升级？ A 放弃这个依赖 B 无脑升级找领导 C 量化影响面、推动双方 owner 与排期承诺，按影响面/替代/紧迫性标准决定是否升级 ✓ 正确答案 D 自己重写组件
# 14. 你的项目依赖另一个团队提供 PRD，但 PM 没写 PRD，你看怎么 argue A 直接开始开发，出了偏差再改 B 自己编一份需求 C 拒绝开发 D 推动 PM 补写关键需求，或协同产出最小 PRD 明确范围与验收标准 ✓ 正确答案
# 15. 如何用依赖图与里程碑检查预警依赖阻塞？ A 依赖图只用于展示，不能预警 B 依赖图用于可视化依赖关系，里程碑检查对照进度，结合可提前预警阻塞 ✓ 正确答案 C 预警依赖只靠经验 D 里程碑检查与依赖无关
# 17. 跨团队依赖阻塞时你如何推动建立“双方 owner + 定期同步”机制，而不是每次临时找人？ A 每次临时找人即可 B 推动明确双方 owner 并建立定期同步机制，让依赖状态持续透明 ✓ 正确答案 C 依赖问题只能靠运气 D 建立机制太麻烦，不值得
