经验沉淀与可迁移性

共 21 题

#

1. 你过去三年最值得迁移到下一个岗位的经验是什么

A 具体的技术栈

B 熟人关系

C 本公司的内部工具

D 跨岗位通用的底层能力（如数据思维、复盘） ✓ 正确答案

#

2. 你如何在面试中表达"经验可迁移"而不是"经验已堆叠"

A 罗列做过多少项目

B 强调年限

C 把经验抽象成方法论并说明适用边界 ✓ 正确答案

D 只讲具体技术

#

3. 经验沉淀也有成本，你如何判断哪些经验值得写成文档、哪些不值得，避免知识库变成垃圾场？

A 所有经验都写

B 凭感觉

C 复用价值×复用频率，并定期清理 ✓ 正确答案

D 文档越长越好

#

4. 你沉淀的文档或方法论如何对抗"过时失效"，维护与更新机制你如何设计？

A 写一次就不管

B 设置 owner、更新频率与过期标记 ✓ 正确答案

C 删除所有文档

D 只留最新版本

#

5. 讲一次经验迁移失败的经历及原因分析

A 经验本身无用

B 时机不好

C 团队不配合

D 环境变化，需适配新场景而非照搬 ✓ 正确答案

#

6. 你如何在大型组织中沉淀经验形成团队资产

A 标准化、推广并固化到流程 ✓ 正确答案

B 只在自己用

C 保留个人风格

D 靠口头传授

#

7. 你如何用使用数据验证沉淀是否真正生效

A 看文档写了多少

B 不验证

C 感觉有效就行

D 用采用率、上手时间等使用数据对比 ✓ 正确答案

#

8. 请说明你过去一年沉淀出哪些"可跨项目复用"的经验，以及如何被复用

A 说"我有很多经验"

B 给出具体沉淀成果及其被复用实例 ✓ 正确答案

C 只讲一个项目

D 强调年限

#

9. 讲一次你把一次项目经验抽象为通用方法论，被另一个团队直接采纳的事

A 抽象成通用、可落地的方法论并清晰文档化 ✓ 正确答案

B 方法论只属于自己

C 强制采用

D 口头传授

#

10. 经验的沉淀中项目收尾时如何把复盘结论沉淀成可复用的文档、模板或清单而不是停留在口头总结？

A 口头总结即可

B 固化成 checklist、模板、ADR 等物化形式 ✓ 正确答案

C 只写一次长文

D 不沉淀

#

11. 经验沉淀中最难的是隐性知识（决策时的权衡与取舍），你如何把这类知识显性化成别人可用的内容？

A 只记录结论

B 靠口口相传

C 不记录

D 记录决策选项、权衡依据与选择逻辑 ✓ 正确答案

#

12. 把个人方法论变成团队资产时，你如何去除"个人风格"痕迹、降低他人采纳门槛？

A 去个人化、通用化并提供即用模板 ✓ 正确答案

B 保持个人风格

C 强制团队用

D 只自己用

#

13. 跨团队迁移经验时，方法论里的行业黑话与隐性假设如何翻译，避免被新团队误读？

A 翻译黑话并明确隐性假设与适用条件 ✓ 正确答案

B 保持原样

C 让对方自己理解

D 只讲结论

#

14. 请说明你是否使用文档 / Wiki 沉淀经验，跨公司后是否仍可访问

A 公司 Wiki 可带走

B 经验无法带走

C 不沉淀

D 公司系统不可访问，但可携带通用方法论 ✓ 正确答案

#

15. 你过去一段经验在新岗位场景中的"可迁移比例"估计是多少，依据是什么

A 报一个高比例

B 分类评估底层能力与具体知识，并说明依据 ✓ 正确答案

C 报一个低比例

D 不评估

#

16. 请说明你跨行业 / 跨公司迁移时，原有经验里哪些被高估、哪些被低估

A 高估具体技术经验，低估底层软能力 ✓ 正确答案

B 高估软能力

C 技术经验完全无用

D 无需反思

#

17. 你是否会把个人沉淀的经验贡献到公司知识库（如 Confluence）

A 主动贡献并保持文档质量与可维护性 ✓ 正确答案

B 无需贡献

C 只贡献别人要的

D 贡献后不维护

#

18. 可迁移性的提炼中如何把一次项目经验抽象成方法论（如选型框架、排障流程）并说明适用边界？

A 无需边界

B 防止方法论被误用 ✓ 正确答案

C 让方法论更复杂

D 只讲步骤即可

#

19. 跨领域迁移中如何证明经验的复用价值？

A 用类比+实际数据/结果证明 ✓ 正确答案

B 空谈方法论

C 只讲结果

D 只讲类比

#

20. 你的方法论在新团队被质疑“不适用”时，你如何判断是“迁移方式问题”还是“方法论本身失效”？

A 直接认定方法失效

B 先排查迁移方式，再用数据验证是否方法失效 ✓ 正确答案

C 直接怪团队

D 放弃方法论

#

21. 失败经验（踩坑清单、反模式）的可迁移性如何，你会用什么形式沉淀负面经验？

A 只口头提

B 只写正面经验

C 不沉淀

D 踩坑清单、反模式文档 ✓ 正确答案