Situation（背景）：用 1 句话描述场景，让面试官快速理解上下文
Task（任务）：用 1 句话说明你面临的任务或挑战
Action（行动）：用 60% 的篇幅讲你具体做了什么、为什么这么做
Result（结果）：用数据展示最终成果和学到的教训

面试官："讲一次你推动技术变革的经历"

Situation：去年 Q3，我们线上推理服务的 GPU 利用率长期在 45% 左右，成本很高。

Task：我的目标是把 GPU 利用率提升到 70% 以上，同时不降低服务质量。

Action：
- 首先做了 profiling，发现主要问题是静态 batching 导致 GPU 空转
- 调研了 Continuous Batching 方案，但团队担心引入新风险
- 我的做法是先做 PoC：在测试环境搭建对比实验，数据证明吞吐可提升 2 倍
- 然后用小范围灰度（5% 流量）验证线上效果
- 同时建立了完整的监控，确保出问题能第一时间回滚
- 过程中遇到的阻力是两位资深工程师担心稳定性，
  我通过让他们参与方案设计，化解了顾虑

Result：
- GPU 利用率从 45% 提升到 75%
- 吞吐提升 2.5 倍，年节省 GPU 成本约 200 万
- 两位之前有顾虑的工程师后来成了方案的积极推动者

模板：

Situation："当时用 [旧方案] 有 [具体问题]。"
Task："我需要在 [约束条件] 下引入 [新方案]。"
Action：
  1. 分析现状：通过 [数据/监控] 发现问题
  2. 调研方案：对比了 [A/B/C] 三个方案，选了 [X] 因为 [理由]
  3. 推动落地：先做 PoC 证明收益，再小范围灰度，最后全量推广
  4. 化解阻力：[具体的沟通/说服方法]
Result："最终 [量化成果]。"

"当时用 FP16 部署 13B 模型，GPU 利用率只有 45%，成本压力大。
我需要在不影响精度的前提下降低显存占用。
对比了 INT4、INT8、FP8，最终选择 INT8（工具链成熟、精度损失可控）。
先做 PoC 验证精度损失 小于0.5%，然后灰度发布。
过程中有同事担心精度问题，我通过 AB 测试数据打消了顾虑。
最终 GPU 利用率提升到 75%，GPU 数量从 16 张减少到 10 张。"

模板：

Situation："在 [项目] 中，我在 [环节] 做了一个决定。"
Task："当时的目标是 [目标]，但忽视了 [风险]。"
Action："结果是 [具体失败表现]。我很快意识到问题在于 [根因]。"
Result：
  - 补救措施："我立刻 [具体行动] 控制影响"
  - 教训总结："我学到了 [具体教训]"
  - 后续改进："后来我建立了 [机制]，确保不再犯同样的错误"

"在量化 70B 模型的灰度发布中，我在 5% 流量只观察了 24 小时就加速到 50%。
结果差点漏掉一个边界 case：某个长尾业务场景的 prompt 格式特殊，
量化后精度下降比较明显。
我意识到问题在于灰度时间不够，没有覆盖足够的场景。
后来我建立了 72 小时灰度标准，并且要求必须有场景覆盖率的评估报告。
这个教训让我明白，优化方案不能只在通用场景验证，必须覆盖边界 case。"

模板：

Situation："在 [场景] 中，我和上级在 [决策点] 上有不同意见。"
Action：
  1. 先理解对方角度："我首先理解了领导担心的点是 [X]"
  2. 用数据对比："我做了一组对比实验，数据证明了 [Y]"
  3. 提议 PoC 验证："我提议先做小规模实验，用结果说话"
  4. 尊重决策："最终领导采纳了建议 / 我尊重了领导的决定并全力执行"
Result："[具体成果]，领导也认可了我的方法。"

"在推理引擎选型时，我推荐 vLLM，但领导倾向于 TGI。
我先理解了领导担心的是 vLLM 社区不够活跃。
我做了一份详细对比报告，从吞吐、延迟、社区活跃度、定制化能力四个维度
对比了两款引擎。同时在测试环境做了 PoC，数据证明 vLLM 在我们的场景下
吞吐高出 2 倍。
领导看数据后采纳了 vLLM，后来线上表现也验证了这个选择。"

模板：

Situation："同时面临 [任务 A] 和 [任务 B]，资源只能支持一个。"
Action：
  1. 评估影响：分析两个任务的紧急度和重要性
  2. 数据支撑：用数据说明优先级排序的依据
  3. 向上沟通：和领导对齐优先级判断
  4. 寻找替代方案：是否可能并行或分阶段
Result："最终先完成了 [A]，[B] 延期 [X] 天完成。业务影响可控。"

"Q3 同时面临两个任务：70B 模型上线（业务需求）和推理引擎升级（技术需求）。
团队资源只够全力做一个。
我评估后认为 70B 模型上线更紧急（有明确的业务 deadline），
引擎升级可以拆分为两阶段：第一阶段只做必须的改造。
和领导对齐后，先用 70% 人力保障模型上线，30% 人力做引擎升级第一阶段。
最终模型按时上线，引擎升级第一阶段也在季度内完成。"

模板：

Situation："需要和 [X 团队] 协作完成 [目标]，但 [困难点]。"
Action：
  1. 明确接口：定义清晰的协作边界和交付物
  2. 建立机制：定期对齐会议、共享文档、里程碑追踪
  3. 化解冲突：[具体的沟通和协调方法]
  4. 推进落地：按里程碑逐步推进
Result："最终在 [时间] 完成，成果是 [具体数据]。"

回答框架：

"首先我会做 1v1 沟通，了解每个人的状态和困难。
然后分析是能力问题、动力问题还是流程问题：
- 能力问题，则安排导师、技术轮转、培训
- 动力问题，则调整任务分配，让每个人做感兴趣/擅长的方向
- 流程问题，则优化流程和工具
最后建立清晰的绩效追踪机制，每两周 check-in。
如果是我实际遇到的情况：[讲一个具体的团队成员成长故事]"

回答框架：

"技术路线分歧时，我的原则是让数据说话：
1. 让每个方案的支持者准备一份对比分析
2. 搭建 PoC 环境做实际测试
3. 团队一起看数据讨论
4. 如果数据接近，我会基于团队的技术栈和长期维护成本做决策
5. 决策后要求所有人全力执行（disagree and commit）
关键是创造公平的讨论环境，让每个人都觉得自己的意见被听取了。"

回答框架：

"紧急任务我会这样分配：
1. 快速评估任务量和所需技能
2. 根据团队成员的技能矩阵做匹配
3. 明确优先级和 deadline
4. 建立高频同步机制（紧急期间每天站会）
5. 我自己会承担最关键的模块或对外协调工作
6. 任务完成后做复盘，优化流程
核心是'快速决策、清晰分工、高频同步、主动承担'。"

案例：跨部门推理平台共建

背景：需要和算法团队合作部署一套新的推理平台，但两个团队的技术栈和工作节奏不同。

挑战：
- 算法团队关注模型精度，工程团队关注服务性能
- 两个团队的 release cycle 不一致（算法每周迭代，工程每月迭代）
- 缺乏共同的评估标准

做法：
1. 建立联合工作组，指定双方的接口人
2. 定义统一的技术契约（API、性能 SLA、精度指标）
3. 建立双周同步会议，共享进度和风险
4. 搭建联合 CI/CD pipeline，自动化测试覆盖双方需求
5. 设立共同的里程碑和验收标准

结果：
- 平台按时上线，算法团队满意度 4.5/5，工程团队满意度 4.8/5
- 模型上线周期从 2 周缩短到 3 天
- 建立的合作机制后来成为公司标准

关键经验：
- 跨团队协作最重要的是"对齐预期"，在项目开始前就明确定义成功的标准
- 设立接口人制度，减少沟通噪音
- 用自动化工具替代人工协调