软技能与方法论

一、知识体系

1. 项目经验表达(STAR法则) ★★★

1.1 STAR结构

STAR 的标准回答骨架

• S（Situation）
  • 只交代和决策相关的背景：业务场景、规模、时间压力、已有问题。
  • 背景控制在 2-3 句，重点回答“为什么这个项目值得做、为什么这个问题必须解决”。
• T（Task）
  • 讲清你承担的职责边界，而不是泛泛说“参与了项目”。
  • 最好带量化目标，例如“把 TP99 从 800ms 降到 300ms”“把发布失败率从 5% 降到 1% 以下”。
• A（Action）
  • 这是面试官最关注的部分，至少覆盖：分析过程、关键方案、取舍、推动落地、风险控制。
  • 回答顺序建议是“先定位问题，再讲方案对比，再讲最终动作，再讲落地难点”。
• R（Result）
  • 必须有结果、数据和业务影响，不要只说“项目成功上线”。
  • 数据至少准备三类：技术指标、业务指标、组织指标。

1 分钟项目介绍模板

• 开场模板
  • “这个项目发生在 <业务背景>，当时核心问题是 <核心痛点>，我的角色是 <角色>，目标是在 <时间/资源约束> 下完成 <量化目标>。”
• 中段模板
  • “我主要做了三件事：第一，<分析与定位>；第二，<方案设计与取舍>；第三，<推动落地与风险控制>。”
• 收口模板
  • “最终结果是 <量化结果>，同时带来了 <业务价值/团队收益>。如果重做一次，我会优先优化 <改进点>。”

检查点

• 能否在 1 分钟内讲完一版，在 3 分钟内讲深一版。
• 是否能明确说出“你负责什么、不负责什么”。
• 是否有至少 2 组量化数据和 1 个取舍决策。
• 是否能自然回答“为什么这么做，而不是别的方案”。

常见失分点

• 背景讲太长，讲了 2 分钟还没进入你的动作。
• 把团队动作说成个人贡献，追问后容易失真。
• 只有“做了什么”，没有“为什么这么做”和“结果如何”。
• 结果只有上线，没有业务收益、稳定性收益或效率收益。

1.2 准备2-3个深度项目 ★★★

项目选择标准

• 优先选你主导度高、技术决策多、结果可量化的项目。
• 三个项目尽量覆盖不同类型：
  • 一个偏架构升级或稳定性治理。
  • 一个偏业务增长或核心链路优化。
  • 一个偏疑难问题、故障处理或跨团队协作。
• 如果项目很多，宁可少而深，不要多而浅。

每个项目必须准备到什么程度

• 讲得出：
  • 背景、目标、方案、取舍、结果、复盘。
• 画得出：
  • 核心架构图、关键链路、主要依赖关系。
• 扛得住追问：
  • 为什么选这个方案。
  • 最难的技术点是什么。
  • 上线风险怎么控。
  • 失败过什么、怎么补救。

项目备战模板

• 项目名
  • 一句话定义项目价值。
• 背景与目标
  • 业务背景、核心指标、时间约束。
• 我的职责
  • 我主导、我参与、我协同的边界分别是什么。
• 关键动作
  • 技术方案、选型对比、推进动作、风险预案。
• 结果
  • 技术指标、业务指标、组织指标。
• 复盘
  • 做对了什么、做错了什么、如果重做怎么改。

检查点

• 至少准备 2 个主项目和 1 个补充项目。
• 每个项目都能拆成 3 个高频追问点。
• 每个项目都能拿出 1 个“失败/教训”案例。

1.3 常见追问方向

高频追问清单

• 为什么选这个技术方案？对比了哪些方案？
• 如果重新做，你会怎么改进？
• 项目中最大的挑战是什么？
• 你做了哪些取舍？为什么？
• 项目上线后有没有出过问题？怎么处理的？

追问应对顺序

• 先回答结论
  • 例如“我最终选 Redis + MQ，而没有直接上数据库行锁，核心原因是峰值流量和可削峰能力的要求。”
• 再补依据
  • 约束条件、指标、候选方案对比、风险。
• 最后补复盘
  • 哪个判断后来被验证正确，哪个判断现在看还可以更好。

常见失分点

• 被问“为什么”时只重复方案本身。
• 被问“如果重做”时说“我还是这么做”，显得没有复盘能力。
• 所有追问都落到执行细节，讲不出判断标准。

2. 技术决策能力 ★★★（P8+核心）

2.1 技术选型方法论

标准决策步骤

1. 明确需求和约束
   • 把功能、性能、成本、团队能力、交付周期写清楚。
2. 列候选方案
   • 至少准备 2-3 个备选，不要只有唯一答案。
3. 做关键场景验证
   • 选择最容易翻车的场景做 POC，而不是做“最好看的 demo”。
4. 做对比矩阵
   • 用统一维度比较成熟度、扩展性、运维复杂度、学习成本、风险暴露面。
5. 拉评审
   • 对齐技术同学、上下游团队、业务方预期。
6. 记录决策
   • 用 ADR 留下背景、备选、结论、理由、回滚条件。

常用评估维度

ADR 最小模板

• 背景
  • 当前问题、业务目标、关键约束。
• 候选方案
  • 方案 A / 方案 B / 方案 C。
• 决策
  • 选了什么，不选什么。
• 理由
  • 哪些维度权重最高，为什么。
• 风险与回滚
  • 哪些假设需要验证，失败时如何收缩。

常见失分点

• 选型过程只有“我觉得”和“业内都这么做”。
• 没有备选方案，显得判断不完整。
• 讲不出成本与风险，只讲功能优势。

2.2 架构演进思维 ★★★

核心结论

• 渐进式演进通常优于推倒重来，因为系统真实复杂度往往来自数据、依赖和组织协作，而不只是代码。
• 架构不是越先进越好，而是越匹配当前阶段越好。
• 真正好的演进方案，应该同时回答“当前痛点、阶段目标、可回退路径、下一阶段预留”。

架构演进回答模板

• 先讲现状
  • 当前架构解决了什么问题，为什么开始不适用了。
• 再讲驱动因素
  • 流量增长、组织扩张、稳定性要求、交付效率瓶颈。
• 再讲演进路线
  • 哪些模块先拆、哪些能力先补、哪些债务暂时保留。
• 最后讲边界
  • 什么阶段不值得拆，什么阶段必须拆。

检查点

• 是否能讲清“为什么不是一步到位微服务/云原生”。
• 是否能给出演进阶段的触发条件，例如访问量、团队规模、故障频率。

2.3 技术债务管理 ★★

技术债务识别与偿还

• 核心结论
  • 技术债务不是“代码写得丑”这么简单，而是未来交付成本、故障概率、变更风险持续升高的部分。
• 执行步骤
  • 先盘点债务类型：稳定性、可维护性、性能、交付效率、安全合规。
  • 再按影响面、紧急度、修复成本排序。
  • 把最高优先级债务绑定到真实业务目标，而不是单独喊口号。
  • 用季度节奏追踪偿还进度，避免只在事故后短期重视。
• 常见失分点
  • 一上来就提“全面重构”。
  • 讲不清债务对业务和团队的真实影响。

3. 问题排查方法论 ★★★

3.1 线上问题排查步骤

标准排查链路

1. 止血
   • 先恢复服务：回滚、限流、降级、扩容、切流量。
2. 定位
   • 从监控、日志、链路、异常堆栈、变更记录入手，缩小范围。
3. 根因
   • 追到根本触发点，不满足于“线程满了”“DB 慢了”这类表象。
4. 修复
   • 给出修复方案、验证方案、回归范围。
5. 复盘
   • 沉淀时间线、责任动作、预防措施。

30 秒故障回答模板

• “故障发生后，我先做止血，把影响范围压住；然后按监控、日志、链路和最近变更缩小问题范围；定位到根因后做修复和回归；最后补监控、预案和机制，避免同类问题再次发生。”

现场排查检查点

• 是否先讲影响面，再讲技术细节。
• 是否能区分“临时恢复”和“彻底修复”。
• 是否有最近变更、依赖变更、容量变化的排查意识。

3.2 排查工具链

工具与使用场景

• 监控：Prometheus + Grafana
  • 看异常指标趋势、相关指标联动、是否集中在特定节点。
• 日志：ELK / EFK
  • 查报错模式、业务关键字、异常时间窗口。
• 链路追踪：SkyWalking / Jaeger
  • 看慢点在哪一跳、是否集中在某下游。
• JVM：Arthas、jstack、jmap
  • 看线程阻塞、内存泄漏、对象分布。
• 数据库：slow log、EXPLAIN
  • 看慢 SQL、索引命中、执行计划变化。
• 网络：tcpdump、wireshark
  • 看网络抖动、重传、连接异常。

常见失分点

• 一上来就说“我会用 Arthas”，但说不清为什么此时用它。
• 工具列得很全，但没有按照“现象 -> 假设 -> 验证”组织。

3.3 故障复盘(Postmortem) ★★

标准复盘模板

• 时间线
  • 什么时候发现、什么时候升级、什么时候止血、什么时候恢复。
• 影响
  • 用户影响、业务影响、持续时长、影响范围。
• 根因
  • 直接原因、深层原因、触发条件。
• 改进
  • 短期动作、长期机制、负责人、截止时间。
• 跟踪
  • 下次如何验证改进确实落地。

复盘原则

• 以改进系统为目标，不做情绪化追责。
• 责任必须落实到动作，但不要把复盘写成批斗会。
• 没有负责人与截止时间的改进项，等于没有改进项。

4. 技术管理(P8+) ★★★

4.1 团队管理

管理动作清单

• 1 on 1
  • 固定节奏了解成员目标、阻塞、风险和成长诉求。
• 目标设定
  • 把团队目标拆到季度可执行动作，不只停留在口号。
• 代码审查文化
  • 明确 review 关注点：正确性、可维护性、边界条件、回归风险。
• 技术分享与培训
  • 把“关键经验”沉淀为可复用模板，而不是一次性演讲。
• 梯队建设
  • 给核心同学授权，避免所有关键决策都堆在一个人身上。

常见失分点

• 只会说“带团队”“辅导新人”，没有具体机制。
• 把管理理解成催进度，讲不出人才培养和协作机制。

4.2 项目管理

项目推进模板

1. 需求分析与评估
   • 明确目标、范围、依赖、风险。
2. 任务拆解与排期
   • 拆到可验收的里程碑，预留缓冲和联调时间。
3. 风险识别与应对
   • 技术风险、资源风险、依赖风险分别列出。
4. 过程跟踪
   • 周节奏看里程碑，日节奏看阻塞。
5. 验收与复盘
   • 看结果、看偏差、看改进动作。

检查点

• 是否能讲清一个项目延期时你如何发现、如何纠偏。
• 是否能举例说明你如何处理跨团队依赖失控。

4.3 技术规划 ★★★（P8+核心）

技术规划回答框架

• 先看业务方向
  • 未来半年到一年的增长点、风险点是什么。
• 再推技术挑战
  • 稳定性、容量、成本、效率、合规哪个最关键。
• 再做路线图
  • 分季度拆成重点项目，标明优先级和收益。
• 最后定衡量方式
  • 用可用性、效率、成本、交付质量等指标衡量结果。

规划模板

• 稳定性建设
  • SLA 目标、监控告警、演练、应急预案。
• 效率提升
  • CI/CD、自动化测试、开发工具链。
• 架构演进
  • 模块拆分、容量治理、核心链路优化。
• 人才与机制
  • owner 制、review 机制、知识沉淀机制。

常见失分点

• 规划只有方向，没有优先级和指标。
• 规划像愿景 PPT，落不到季度动作。

5. 系统性思维 ★★★

5.1 架构思维

架构思维的回答重点

• 全局视角
  • 技术问题要回到业务目标和系统边界里回答。
• 权衡取舍
  • 没有完美方案，重点讲清 trade-off。
• 前瞻性
  • 说明当前设计如何支撑未来半年到一年的变化。
• 简洁性
  • 用最简单、最稳的方案解决当前最关键的问题。

5.2 业务理解 ★★★

业务理解怎么讲

• 先讲业务目标
  • 增长、体验、成本、风险，哪个是核心。
• 再讲技术支撑
  • 技术方案如何服务指标，而不是为了技术而技术。
• 最后讲反向建议
  • 你是否基于技术视角推动过业务策略或流程改进。

检查点

• 能否用非技术语言解释你做的系统价值。
• 能否说出一个技术方案改变了什么业务结果。

5.3 沟通表达

结构化表达模板

• 先讲结论
  • 先说判断、方案或建议。
• 再讲分点依据
  • 最多 3 点，避免铺陈过长。
• 最后讲风险与下一步
  • 让听的人知道该怎么决策、怎么行动。

常见失分点

• 先讲背景细节，结论拖到最后。
• 同一个回答里塞太多分支，主线不清楚。
• 技术沟通只讲实现，不讲影响和风险。

6. 工程方法论 ★★

6.1 代码质量

代码质量怎么落地

• 核心结论
  • 代码质量不是“个人习惯”，而是通过 review、规范、测试和重构机制共同维持。
• 执行动作
  • 设定 review 关注项、静态检查基线、核心模块测试标准、坏味道治理节奏。
• 常见失分点
  • 只说“我们很重视 Code Review”，但没有标准和例子。

6.2 DevOps实践

DevOps 的面试回答抓手

• 核心结论
  • DevOps 的价值是缩短反馈闭环，让发布更快、更稳、更可回滚。
• 可讲的落地点
  • CI/CD 流水线设计、自动化测试金字塔、蓝绿/金丝雀发布、回滚策略。
• 追问提醒
  • 面试官常追问“发布快了，怎么保证质量不下降”。

6.3 文档文化

文档如何支撑团队协作

• 核心结论
  • 好文档不是写给归档系统看的，而是用来减少沟通损耗、提升决策质量和交接效率。
• 最低文档集
  • 技术方案文档（RFC）、API 文档、ADR、Runbook。
• 常见失分点
  • 只把文档当交付附件，没有和实际协作流程绑定。

---

二、高频面试题

P7必答

1. 介绍一个你最有成就感的项目，用 STAR 法则描述。

• 30秒答法：按“背景与目标 -> 我的职责 -> 关键动作 -> 量化结果”回答，重点突出你主导的技术判断、落地动作和实际收益，不要从需求背景讲成流水账。
• 关键词：STAR、职责边界、量化结果、方案取舍、业务价值
• 追问提醒：为什么选这个方案；你个人贡献占比；如果重做怎么改

2. 你在项目中遇到的最大技术挑战是什么？如何解决的？

• 30秒答法：选一个真正复杂的问题，先讲问题现象和影响，再讲你如何定位根因、尝试过哪些方案、最终为什么这么选，最后补结果和复盘。
• 关键词：问题本质、定位过程、方案对比、落地验证、复盘
• 追问提醒：是否有其他方案；失败过什么；如何避免再次发生

3. 你是如何做技术选型的？举一个具体例子。

• 30秒答法：先讲需求和约束，再讲候选方案与评估维度，然后说明做了什么验证、为什么最终选择当前方案，以及代价和风险怎么控。
• 关键词：约束、候选方案、POC、ADR、trade-off
• 追问提醒：为什么不选 B；团队能否驾驭；最坏情况下如何回退

4. 描述一次线上故障排查的完整过程。

• 30秒答法：按“止血 -> 定位 -> 根因 -> 修复 -> 复盘”讲，先说明影响面和恢复动作，再讲工具链和判断过程，最后补预防措施。
• 关键词：止血、监控、日志、链路、根因、复盘
• 追问提醒：如果当时不能回滚怎么办；怎么判断影响范围；后续做了哪些机制改进

5. 你的职业规划是什么？

• 30秒答法：短期讲继续强化核心技术判断和复杂项目落地能力，中期讲扩大系统设计和团队影响力，长期讲清你希望走专家线、架构线还是管理线，并说明原因。
• 关键词：短中长期、成长路径、岗位匹配、影响力
• 追问提醒：为什么适合这个方向；你已经做了哪些准备；与当前岗位如何衔接

6. 描述一个你主导的技术方案从提出到落地的过程。

• 30秒答法：先讲痛点和目标，再讲你如何调研、评审、分阶段落地和控风险，最后讲结果与组织层面的推动动作，体现“判断 + 推动”而不是只会写代码。
• 关键词：主导、评审、推进、风险预案、量化结果
• 追问提醒：谁反对过；遇到的阻力是什么；你如何推动资源协调

7. 如何处理跨团队协作中的技术分歧？

• 30秒答法：先对齐共同目标，再把争议从“谁对谁错”拉回“哪种方案更适合当前约束”，必要时用数据、POC 或 ADR 固化决策，决策后统一执行。
• 关键词：共同目标、数据驱动、ADR、Disagree and Commit
• 追问提醒：如果对方级别更高怎么办；如果没有数据怎么办；如何避免分歧反复出现

8. 你如何进行技术选型决策？能举一个具体案例吗？

• 30秒答法：把案例拆成“需求约束、备选方案、关键验证、最终取舍、结果验证”五段，重点讲你放弃了什么以及为什么放弃。
• 关键词：案例化、约束条件、验证、取舍、结果
• 追问提醒：决策是否被事实验证；后续是否调整过；是否沉淀成团队方法

P8+核心

1. 你如何评估一个系统的架构是否合理？

• 30秒答法：从业务适配度、性能与可用性、扩展性、复杂度、运维成本和团队驾驭能力几个维度评估，核心不是“先进”，而是“匹配当前阶段且可持续演进”。
• 关键词：适配度、复杂度、可扩展性、运维成本、阶段匹配
• 追问提醒：如何识别过度设计；什么时候必须重构；如何量化“合理”

2. 如何推动一次大规模的技术重构？如何说服团队和管理层？

• 30秒答法：先把当前问题转成业务影响，再给出分阶段方案、收益预估和风险控制，先选一个模块打样，用结果而不是口号去争取资源。
• 关键词：业务价值、分阶段、试点、风险控制、资源协调
• 追问提醒：如果管理层不支持怎么办；如何保证业务不停摆；重构收益怎么验证

3. 你认为好的技术 Leader 应该具备哪些能力？

• 30秒答法：至少要有技术判断力、业务理解、团队赋能、跨团队沟通和落地推动五项能力，关键不是自己最强，而是让团队整体更稳、更快、更能成长。
• 关键词：判断力、全局视角、赋能、协同、落地
• 追问提醒：你最强和最弱的一项是什么；有哪些真实案例；如何平衡深度与管理

4. 你做的最有影响力的技术决策是什么？

• 30秒答法：选一个高影响、高争议或高风险的决策，讲清背景、备选方案、你的判断依据、承受的风险和最终结果，重点体现你如何承担责任。
• 关键词：高影响、判断依据、风险承担、结果验证
• 追问提醒：如果结果失败怎么办；当时最大的反对意见是什么；你如何复盘

5. 如何在保证业务迭代速度的同时提升系统稳定性？

• 30秒答法：把稳定性建设嵌入日常交付链路，用自动化测试、灰度发布、监控告警、快速回滚和持续偿还技术债务并行推进，而不是把稳定性当专项运动。
• 关键词：嵌入式治理、自动化测试、灰度、回滚、技术债务
• 追问提醒：资源不足时如何取舍；如何量化稳定性建设收益；哪些动作最先做

6. 你如何做团队的技术规划？

• 30秒答法：先理解业务目标和未来风险，再抽出稳定性、效率、架构演进等关键主题，拆成季度路线图和可量化 KR，最后建立复盘调整机制。
• 关键词：业务目标、路线图、季度拆解、KR、复盘
• 追问提醒：如果需求变化很快怎么办；如何争取资源；如何砍掉低优先级事项

7. 如果你入职后发现系统有大量技术债务，你会怎么做？

• 30秒答法：先建立系统全景和优先级，而不是立刻重构；优先解决影响稳定性和核心业务的债务，再把剩余债务纳入迭代节奏持续治理。
• 关键词：现状盘点、优先级、稳定性基线、渐进治理
• 追问提醒：如何让管理层接受；如何防止“只还不增”；如何衡量治理进度

8. 如何设定技术团队的 OKR？

• 30秒答法：O 要对齐业务方向，KR 要可量化、可验证、可跟踪，重点聚焦稳定性、效率和关键能力建设，避免把日常工作直接写成 OKR。
• 关键词：业务对齐、量化 KR、优先级、挑战性
• 追问提醒：KR 设太高/太低怎么办；如何让团队认同；如何避免 OKR 变成报表

---

三、面试表达技巧

结构化回答模板

• 先总后分
  • 第一话先给判断或结论，例如“我会优先做渐进式演进，而不是整站重构”。
• 对比说明
  • 技术选型题优先讲“为什么选 A、为什么不选 B”，这样更容易体现判断力。
• 量化成果
  • 没有数据就至少准备区间、趋势或前后对比，不要全部停留在主观感受。
• 风险收口
  • 讲完方案后补一句“最大的风险是什么、我怎么控制”，回答会更完整。

反问面试官

• 团队当前面临的最大技术挑战？
• 这个岗位未来半年的核心目标？
• 团队的技术栈和架构演进方向？
• 团队的工程文化（Code Review、CI/CD 等）？
• 个人成长和晋升的路径？

反问检查点

• 反问前先判断岗位阶段，不要在一面就过深追问晋升和薪资结构。
• 优先问“岗位目标、技术挑战、协作方式”，比泛泛问“团队氛围如何”更有信息量。

行为面高频题

• 为什么从上家离职？

  • 30秒答法：聚焦个人成长、岗位匹配和发展空间，不攻击前公司、不输出负面情绪。
  • 关键词：成长、匹配、挑战、方向
  • 追问提醒：为什么现在的岗位不能满足；你下一步想补什么能力

• 最大的失误与复盘是什么？

  • 30秒答法：选一个真实但可控的失误，讲清背景、错误判断、造成的影响、补救动作和后续机制改进，重点体现复盘和成长。
  • 关键词：真实失误、补救、反思、机制改进
  • 追问提醒：为什么会犯这个错；如何防止团队重复踩坑

• 最大的技术挑战？

  • 30秒答法：不要选纯体力活或简单 bug，优先讲复杂问题的分析、决策和结果，体现技术深度和方法论。
  • 关键词：复杂问题、分析、取舍、结果
  • 追问提醒：如果再来一次，你会不会换方案

• 团队冲突怎么解决？

  • 30秒答法：先讲对齐目标，再讲如何把冲突从情绪问题转成事实和数据问题，必要时拉齐裁决机制，最后讲执行后的复盘。
  • 关键词：目标对齐、事实数据、裁决、执行复盘
  • 追问提醒：如果对方不配合怎么办；你如何保留合作关系

• 5年职业规划？

  • 30秒答法：用短中长期表达成长路径，核心是让面试官看到你和岗位方向一致，而不是空泛地说“未来想做管理”。
  • 关键词：短中长期、岗位匹配、成长路径
  • 追问提醒：为什么选这条路线；你已经积累了哪些基础

项目复盘方法(AAR)

• AAR(After Action Review) 四个问题：
  1. 我们预期的结果是什么？
  2. 实际发生了什么？
  3. 为什么会有差异？
  4. 下次我们该怎么改进？
• 复盘产出建议
  • 至少形成一页记录：背景、结果、偏差、原因、动作、负责人、验证时间。
• 适用场景
  • 项目上线后、重大故障后、方案落地后、跨团队协作失效后。

---

四、每日学习建议

时间分配

每日执行顺序

• 上午
  • 理论复习 1-2 小时，优先补“为什么”和“边界条件”。
• 下午
  • 实践验证 2-3 小时，做源码、案例、故障链路或场景题推演。
• 晚上
  • 复盘 1 小时，整理卡片、错答、追问点和次日计划。

每日最低产出

• 一段 1 分钟项目口述。
• 一题技术选型或故障排查口述。
• 三个最容易卡壳的追问点。

工具与资源

• 知识管理：Anki / Notion 做项目卡片、追问卡片、错答卡片。
• 实践工具：IntelliJ IDEA 调试源码，jvisualvm / MAT / Arthas 回看真实排障链路。
• 面经浏览：每天 20-30 分钟即可，目的是补题型，不是陷入信息焦虑。

进度追踪

• 每天自测 10 道题，正确率 >80% 再推进。
• 错题按四类记录：概念错、表达错、推导错、场景错。
• 每 5 天做一次阶段复盘，确认下阶段主攻项。

核心指导思想

---

五、面试准备清单

项目准备

• 准备 2-3 个深度项目，并能分别讲 1 分钟版和 3 分钟版
• 每个项目都能画出架构图和关键时序
• 每个项目都准备 2-3 个技术难点与取舍说明
• 每个项目都准备量化数据（性能、成本、效率、稳定性）
• 每个项目都准备“如果重做”的改进思考

行为面试准备

• 团队协作 / 冲突的经历
• 带人 / 导师的经历
• 失败的项目 / 决策及反思
• 推动技术改进的经历
• 跨团队合作的经历

交付前自检

• 至少录音听过一次自己的项目口述，确认没有流水账。
• 至少让别人追问过一次“为什么”和“如果重做”。
• 至少有一套自己的技术选型案例和故障排查案例。

六、学习资源推荐

书籍

• 《技术领导力》：技术管理实践
• 《架构整洁之道》：架构设计思维
• 《Staff Engineer》：高级 IC 成长路径
• 《金字塔原理》：结构化表达

博客/文章

• StaffEng.com
• LeadDev.com
• 极客时间《技术管理实战 36 讲》

视频/播客

• InfoQ 大会演讲中的架构 / 管理专题
• 极客时间《许式伟的架构课》