@1 个人基本能力

操作、知识、经验、能力(双向)

• 操作：知道是什么、知道怎么用。
• 知识：八股文问题。
• 经验：一个人的知识范围、一个人经历的事情。
• 能力：做事情的一种态度，性格，想法，思路，行为，方法和风格。
  • 对新手来说，知识和经验不足，不代表能力有问题。
  • 对老手来说，知识和经验不足，大概率就是能力问题。

应试者的素质模型

面试的重点：经验、技能、潜力和动机。

• 经验：包括专业经验、管理经验和行业经验等等。
  • JD 中一般包含如“做过 3 年以上 Java Web 开发”“负责过 50 人以上规模的团队管理”等。
  • 一个智力中等的候选人，在一个技术拓展速度适中的工作中，3 年就可以达到独立、熟练工作的程度；如果是“5 年”，那就能带领别人完成工作了。
  • 需要注意，经验不与时长挂钩。
• 技能：包括专项技术能力、管理能力、沟通表达能力、协作能力等等。
  • JD 中一般包含如“使用 MySQL、Redis”等。
  • 产生 idea 的技能：针对问题，基于经验，收集、理解、分析和制定新的方案，涉及理解、思考、沟通等过程。
  • 执行 idea 的技能：运用工具，把方案应用到实践，从而解决问题。除了用到理解、思考、沟通，还需要协作团队、管理资源，甚至领导和影响他人。
• 潜力：学习、创新和精益能力。
  • 学习-不会到会的过程；创新-创造新事物的技能；精益-事情越做越好的技能。
• 动机：做事的内因、稳定性、工作意愿。
  • 自燃(自我驱动)、点燃(需要激励)、阻燃(拖后腿)。
  • 了解动机方式：1️⃣ 品质(诚实守信、认真负责、坚毅勇敢) 2️⃣ 个人经历(职业发展趋势、跳槽频率) 3️⃣ 职业价值观(喜好轻松/挑战、个人/团队利益、按要求做事/自由做事) 4️⃣ 职业性格(内向/外向等 MBTI)

管理能力考查

做工程搞开发，不仅需要良好的技术技能，同时也需要良好的计划性和时间管理能力，当我们做中大规模的项目，或者是作为管理者带团队的时候，这种能力就显得格外重要。
不管之前有没有做过项目管理或者是团队管理，我都会问侯选人你是怎么管理你的时间和项目的？你每天 / 周 / 月 / 年是如何做计划的？自己有没有一套完善的计划和时间管理系统？比较可惜，只有非常少数的侯选人能够清楚说明自己的计划和时间管理系统，这也可以说明为什么能从程序员成长为架构师甚至管理者的人少之又少。
怎样提高产品研发效率，怎样让技术支撑业务快速增长，怎样建设技术人才梯队，对企业文化是如何理解的，诸如此类。

架构师考察

• 能力模型是我们对架构师的能力要求，或者说是考查的职责描述；
• 面试地图考查的是具体的知识和能力图谱；
• 面试题库是我们的宝藏，是整个架构师团队在实际工作中提炼和积累出来的，大部分都是网上找不到的。

能力模型，我们的架构师能力模型包括三个部分：一个核心两个基本能力。一个核心指的是德，这个是最基本的要求，主要包括诚信、担当和品格，两个基本能力指的是硬实力和软能力，二者的比重七三开（7:3）。
架构师在研发团队中会同时扮演技术大咖和老师的角色。作为老师，你要让别人能很容易地听懂你的观点和思路，要形成技术影响力，这就需要具备较强的表达和展现能力。同时架构师在日常工作中需要和研发同学紧密协作，保证技术轨道的有序与目标达成，所以协作能力也是至关重要的。

面试地图就是供面试官参考的一个知识和技能图谱，基本涵盖了作为一个架构师需要掌握或者具备的知识和技能，主要包括基础技术能力、架构能力和发展能力。

我习惯从简历开始，先让候选人做个简单介绍，然后从他最近参与的项目或者说是他认为做得最好的项目出发，让他介绍下项目情况、架构方案以及项目的技术难点和解决思路。

介绍架构方案时，我会要求他边讲边画架构图，这样做有几方面考虑：一是有助于自己理解；二是能比较好地考查他的架构理解力、逻辑性、条理性、结构化思维和表达能力；再就是有了架构图，接下来可以结合图考查更细的技术点。

了解了项目情况，又有了架构图，接下来我会围绕整个架构方案，结合我们的面试地图一块一块深入挖掘了解候选人的技术能力。

先从 OSI 模型的应用层开始，通过负载均衡方案考查他对 CDN、DNS、VIP、HTTP、LVS、HAProxy、Keepalived、Apache、Nginx 的理解和熟练程度，中间也可以穿插问几个技术细节来考查他的理解深度，比如 Nginx 高并发的技术原理、Nginx 和 LVS 分别工作在 TCP/IP 协议栈的第几层，等等。

接下来可以根据各功能模块展开考查 Java 基础技术。Java 基础技术涉及面就广了，每次面试中不可能面面俱到，但是一些关键技术点必须考查，比如容器、JVM、数据结构、序列化、异常处理、Socket、多线程 / 并发、NIO 等等。在 Java 体系中，JVM 是最基础也是最重要的考查点，我们的系统最常出现的 OOM 异常都跟 JVM 有关，架构师必须深入了解 JVM 的内存模型、字节码、垃圾回收（GC）策略等原理，才能去优化 JVM 相关的性能问题，才能快速定位 OOM 类异常。除了 Java 基础技术，常用框架和相关概念也是需要考查的，比如 Spring、SpringMVC、Mybatis、ORM、IOC/DI、AOP 等。

结合候选人提到的某个功能模块，考查他在面向对象上的设计能力和建模能力。面向对象设计主要考查的是设计思想。类与类之间的关系是我比较喜欢问的，因为这是最基本的概念，如果他对这些概念都很清楚，我会追问聚合和组合的区别，一般能答上来的都是对面向对象理解比较深入的。

有了面向对象的概念和思想，还可以结合候选人的项目，让他详细说说某个功能模块的设计，画画 UML 设计图，这样能考查他对面向对象的理解程度和领域建模能力。领域建模能力对于架构师而言至关重要，业务域抽象得是否合理，是否高内聚，领域边界是否清晰，这些都是影响系统可扩展能力的关键要素。除了这些，我也会结合项目考查几个比较常用的设计模式，比如单例模式、工厂模式、策略模式、模板模式，等等。

以上都是基于应用层展开的一些技术点，接下来可以围绕存储层去展开。存储层主要考查存储架构、数据库选型、数据库调优等。存储架构要看候选人是否能根据系统的并发量和数据量的需求设计适当的存储架构，是否需要做数据库分片，分片的原则和技术方案，是否需要引入 KV 引擎，是否需要做读写分离，是否需要做缓存，缓存需要做几层等等，这些都是基本的存储架构问题。

数据库选型也是和具体的数据量和并发量有关，是用关系型数据库还是用 KV 引擎，还是要二者结合，等等。考虑到我们的系统大多还需要强依赖关系型数据库，所以一般都会考查一些关系型数据库的基础技术点，比如 MySQL 的架构、存储引擎、索引的数据结构、事务隔离级别、索引最左前缀原则等。

还有就是要考查一些数据库端的性能优化技巧，比如 Explain 的用法、索引优化、SQL 语法优化、参数配置优化、数据模型优化、缓存优化等等。

在我们的架构师能力模型中，除了基础技术能力，还包括架构理解和发展能力部分。架构理解部分也是有别于程序员的部分，这部分可以根据候选人提供的架构方案，重点考查高并发和高可用设计、服务设计、服务治理、缓存设计等方面。

系统的高并发设计涉及系统的应用层、存储层和网络层。从网络 IO 到数据库 IO、数据库服务器的负载，CPU 和内存使用情况，再到应用层的负载均衡、反向代理、缓存、事务和锁、并发防重，以及应用服务器的负载，CPU 和内存使用情况等等，都是高并发设计的知识点。

高可用设计方面，重点考查他对负载均衡、SOA、微服务、服务治理的理解，所设计的服务接口其粒度、依赖、位置是否合理，服务是否设计了分组、动态管理、限流、降级和监控，整个架构方案中各模块之间的强依赖是否有降级方案等。

在整个过程中，我们可以通过候选人对一些开源组件的理解程度判断其对技术的热爱程度，一般对技术敏感、挚爱且有追求的架构师往往喜欢研究开源技术，时刻关注新技术并去实践，有的还会持续为开源社区贡献代码，这样的架构师是我们所喜爱的。

此外，优秀的架构师应有自己的时间任务管理心得，懂得识别风险、控制范围、估算时间和成本、把控质量，以及擅长多任务并发的管理与执行。

最后，架构师还需要有一个清晰的自我认知和职业规划，十分清楚地认识到自己的优势和不足，能充分发挥自身优势，不断补齐不足，知道自己追求的“和”不那么重要的，认识到为了达成目标的关键路径应该如何管理。

聊了这么多，能力模型中的软能力和核心部分还未提及。其实在以上面试过程中，候选人的沟通、表达能力基本上已经能判断出来，在他描述方案和回答提问的过程中，逻辑是否清晰，思路是否闭环，结构化思维是否完整，根据这些基本能判断出来。

对于协作能力，我一般会设计一些场景让候选人回答，比如他自己所负责的线上系统出现故障之后作为架构师应该如何处理，性能测试团队测试出系统某功能性能无法满足需求该如何处理，等等。面对这样的问题，对于有协作精神、有担当的架构师，一定会回答主动去分析原因，分析原因过程中主动协同开发和测试同学，找到原因之后设计出解决方案，并指导开发同学实施落地，最终从根本上解决问题，而不是将问题甩给开发或者测试。

最后要回归到能力模型中的核心：诚信、担当、品格。在我看来，这是本质，硬实力和软能力再好，没有核心也是达不到我们的要求的。任何一个人，品格有问题，工作一定好不了。对于核心的考查在面试过程中捎带就考查了，比如当问到一个候选人不是很了解的技术点时，如果是支支吾吾，想方设法找各种理由，那我认为他在诚信上是存在问题的，我更喜欢不懂就不装懂，坦诚、谦虚的人。对于品格，可以从候选人的言谈、举止，或者一些细节之处窥得一斑，也可以通过 HR 面试等环节得到补充。

这里的“数据模型优化”指的是什么？
编辑回复: 数据模型优化指的是领域模型优化，比如表结构是否合理，表和表之间的关系是否合理，各业务域是否高内聚，低耦合等

个人能力体现

学习能力：你怎样把不会的事情做出来。
精益能力：你怎样把事情越做越好。
协作能力：你怎样配合大家一块把事情做好。
领导能力：你怎样带领大家互相配合把事情做好。
解决问题的能力：更综合的能力，看你“成事”的能力有多大。

学习能力

学习：接受、理解、练习、应用。

学习要素可以从内在因素和外在环境两个角度来看：内在因素包括好奇心、逻辑性、操控力，与学习者自身相关；外在因素包括挑战、榜样、反馈。

好奇心的检查：

• 看你遇到不懂的问题时的第一反映。如果是先自己研究，而不是去问别人。
• 看思考深度。当被问到“为什么会这样” “它俩的本质区别是什么”等问题，进行思考。
• 看关注的问题，当被问到“你最近在思考什么问题”“你有什么困扰么”“你问我一个你不明白的问题吧”，有回复。

逻辑性：丢给你一篇文章，看你 10 分钟后能讲出多少内容，是按什么逻辑组织的。前面提到的那个实习生，我就曾让她在 10 分钟内上网学习冰壶的比赛规则，然后讲讲致胜策略，除了考验她获取信息的能力，还有逻辑思维和表达的能力。

操控力：你用 15 分钟，上网找一个方案，让我们 20 人的全球团队能顺畅地做一次头脑风暴。这个题目针对的是不清楚头脑风暴怎么做的应聘者，是道综合题目。既考验他能否快速了解什么是头脑风暴，又考验他为异地同步做头脑风暴如何做工具选型。如果他能找到多个方案，并能简单比较出优劣，那就相当不错了。

榜样：

• 找身边杰出的程序员做榜样、做师傅。一定要找跟自己拉开档次的人，因为只有把你这个发展阶段看得很清楚的人，才能给你高屋建瓴的意见。如果有的大牛忙于“大事”，没时间带你，那就跟他一起吃饭，或者“顺路”上下班，总之，只要你愿意“追”他，总能找到机会。
• 看优秀的代码和书籍文章。去 GitHub 上找优秀的开源项目，找兴趣相投的同学搭伴读代码，并研讨心得，是提升编程能力的好方法。书籍和技术牛人的博客文章也会让你大有收获。
• 我经常问应聘者，“工作中有谁值得你学习”“你都读过哪些专业书籍”“常逛哪些牛人的博客”“讲一段让你印象深刻的开源代码或者设计思路”……经常有一些精彩的回答，能让我们几个面试官眼前一亮。

自媒体和知识付费的兴起，对知识传播的颠覆在于：降低了精华知识的共享和学习门槛。每一位资深人士，都可以快速分享自己多年的经验和感悟；而每个人都有机会，随时随地接触到这些精华。这导致两个结果，一是年轻人的职业成熟度成长加快，使得职场老人压力巨大；第二个结果是年轻人的职业成熟度分化提前发生，爱学善学的人，将很快把那些进入职场就停止学习的同龄人甩在后面。原来工作十年才能显出的职业成熟度差异，现在也许五年就能分出高下了。

向你推荐 Coursera 的热门课 Learning How to Learn（中文名：学习之道）

• 你身边有什么人，“值得”你学习么？你请教过他什么？
• 在编程或者其他工作过程中，还有哪些有益的反馈？你是如何利用这些反馈的？
• 你擅长给别人讲东西么？还是你更希望别人讲给你听？

工作做得好

精益能力：让个人更优秀，让工作更卓越

想到设计 asr 评测程序的时候，最开始只有中英文的内容，当时设计为中文 Evaulator 和英文 Evaluator。每个 Evaluator 是对应的评测函数。因为中文和英文的语句是不一样的，中文是按字分割，英文是按空格分割。后来拓展到多国语言的时候，比如阿拉伯、日语、西班牙、俄语等等。不能每个都写一个 Evaluator，而且大部分语言的评估方式是相同的。所以后来进行了重构，还是一个大重构。

有一个 Evaulator 工具类，里面有各种评估函数。传入的参数是 Context 对象，调用 Context 暴露出的函数，获得要比对的句子等信息。返回的就是这个评估函数要评估的指标结果。
然后将不同的地方基于 Context 中的 lang 进行拆分开。比如进行 CER（词错率/字错率）的时候，需要进行 tokenizer，就是基于 lang 进行，按照空格还是直接 split。

还有，比如讨论 asr 的 f1 指标还是啥指标，要探究对齐程度。虽然后来讨论了很多种，但是探究的都是极端情况，对于极端情况打分没有必要。后来就舍掉这个指标。

• 动机：想不想持续提高
  • 成长性思维：我经常听到应聘者一些有缺陷的答案，大部分时候我因为时间有限不会指出来，但有时会扔出一句评论性的话，类似“你 XX 地方没有考虑到”，然后观察应聘者的反应：有人会陷入思考，然后讲补救的方法；有人会解释为什么不用考虑这点；还有人则辩解已经考虑到了。
• 如何找到持续提高的目标
  • 梳理产品问题，对于糟糕的问题中，抓住重点问题。什么样的问题是重点？根据管理层对于项目的指标，如关注用户价值、或降低运营成本、或性能问题、可用性问题、数据问题、基础设施问题等等。
    • (我)提出排队机制优化。刚开始配置 pod 优先级，后来又针对一个人可以大量提交的行为进行限制，背景是有团队一天提交一百个，甚至 automl 榜单，有人想通过调参来获得第一名，后来由产品联系对方进行不必要的清理，此处需要多方案比较。
  • 识别重复动作，将其自动化。
    • (我)自己有很多比赛平台的脚本，因为之前一直是在 postman 上进行操作。比如我要修改一个榜单的逻辑，在 CI 运行完成后，我需要调用“上传评测程序”接口上传该榜单需要的 harbor 链接并获得程序 ID。然后再调用“修改榜单信息”接口将程序 ID 进行替换。而现在通过脚本，只需要在文件前面更新 harbor 链接和榜单的英文名称，就会将上述都做了。更新的时候，比如榜单名称，将所有名称按行列出来并注释掉，只讲需要的名称进行取消注释。这个在批量替换的时候尤其方便，比如语音识别的多语言榜单。
  • 发现工作需要等待。等待是资源浪费的一种主要表现形式。比如，你提交代码之后，需要等待另一个 team 做代码构建和部署，往往几个小时之后才能开始测试。只有识别了等待，事情才有优化的可能。
    • (我)比赛平台测试方式，同集群、不同命名空间，减轻排队问题。
  • 建立指标体系，找到平庸点。
    • (我)当前以业务开发为主，这个不是主要关注地方。

如何提高

应聘者找到要提高的点之后，接下来就考查他如何实现提高。一般有两种思路，一个是打补丁，一个是翻新。

打补丁，或许不能解决长期问题，但是对紧急问题是个短平快的解决办法。而且对于一些老旧的维持类项目，在没有更多资源投入的情况下，大改核心结构不现实，打补丁是不得已的办法。

翻新，是需要勇气和投入的，建造一个新世界容易，改造一个旧世界难。对于复杂的系统，既要保证业务的正常运行，还要尽快从底层翻新成功，对技术和管理都是很大的挑战。我面试中碰到这样的项目，会如获至宝般问下去，这也是我学习的好机会。

面试官考查精益能力，会从三个方面着手：

• 一是精益的动机，这里最难的是允许别人说你不对，也就是成长型思维，你能做到“有则改之，无则加勉”。

• 二是看你如何找到提高的点。我提到了四种方法：梳理产品问题、识别重复动作、识别等待、建立指标体系找到平庸点。

• 三是看你如何做出提高，是通过打补丁，还是翻新？如何通过守破离的过程，引入新的方法？又是如何跃迁到“提高曲线”中的新阶梯的。

• 糟糕项目，全是问题。从哪里着手，把它变好呢？

• 已经想办法把生产力提高了一大截，还有必要做得更好么？好像也没有提高的空间了呀。

• 工作单调无聊，没有挑战，很难做出成绩，可怎么做得更好呢？

协作能力

影响团队中个体的协作效果的，既有个人因素，也有团队因素。具体来看，主要是个人的认同感、责任感和信用度，再就是团队方面赋予的目标、责权与流程、沟通环境和协作工具。

如何考查应聘者的认同感呢？其实方法很多。

• 一次面试结束后，我对应聘者说“我们组的情况比较特殊，最近预算控制很紧，你要的薪水很高，我会尽力申请，但不一定能达到你的要求，不知道你怎么看。” 这位应聘者听我说话的时候，脸上流露出为难的表情，而不是失望、烦躁和无所谓，说明他体会到了我的难处，也正在为自己的处境胶着。这就是认同感的一种表现。
• 能评价一下你最了解的一个朋友么？（看应聘者如何认同对方的优点，理解和包容对方的缺点。）
• 你如何看待最近 XX 发表的“中国女性的堕落导致国家堕落”言论？（看应聘者是不是一味批评或者辩护，观点中是不是有先入为主的假设或偏见。）
• 能不能讲个你受委屈或者背锅的经历？（看应聘者在委屈的情绪下，是否还能用善意揣测别人，是否能保持中立地看待问题。）
• 最近受到别人批评是因为什么事？（看应聘者是不是把对方放在对立面，能否在负面情绪中理解对方的意图。）

责任感，还表现为对工作质量的追求，这不仅仅是比要求的多做一点，而是在塑造自己的个人品牌，不凑活，不怕麻烦。而且，有强烈责任感的人，往往能够表现出很好的耐心和细心，工作不挑肥拣瘦，不做好绝不放弃，面对困难有勇气去挑战。

信任度：可能追问你某项工作失败的原因，这时也有验证你的信用度的意思。通过对比你的承诺和工作结果的差异，以及你向项目相关人的交待方法，可以判断你是否重视和维护自己的信用。

面试中对目标感的考查，比较简单。在考查项目的时候，问应聘者“团队在这个任务上的目标，或者期待是什么？” “大家对这个项目要达成的结果，有哪些不一致的认识？” 通过这些问题，来了解应聘者对项目目标的认知，以及判断是否偏移目标的方法。

“你所在团队的分工和流程是什么”，目的就是考查应聘者是否清楚团队中，谁该做什么，先做什么、后做什么，怎么处理依赖关系。

怎么能看出应聘者在这方面具有良好的协作意识呢？

• 是否清楚不同角色之间的职责边界；
• 是否清楚做好该职责的标准；
• 在做好本职工作的同时，能否突破职责的限制，做到推动全局；
• 如果碰到流程的束缚导致工作低效，能不能发挥创新，变通地绕过障碍，或者改善流程。

沟通环境：我会问应聘者“最近你有被别人采纳或者忽略的建议么”，目的是看他所在的团队是否有安全的沟通环境，大家敢于发声，不怕嘲讽，勇于批评，不怕打击，而且大家把团队当成是成长的环境，愿意分享经验和技能，听取意见，做出改进。有的团队则不是，大家表面一团和气，有问题不说，导致酿成大祸；另一方面没有人愿意分享好的经验，怕“木秀于林风必摧之”。这样的环境下，信息反馈不畅，协作效果没有保证。
另外，我还会问“你在项目中用到什么加强信息透明化的工具或方法么”，目的在于看你让信息高效传递的手段或工具，以及有没有把信息可视化。用这些手段的原因，就是减少信息传播障碍，提高信息传播速度，减少失真，从而增强协作效率。

协作工具：上面说的加强信息传播和透明化的工具，也属于协作工具。物理看板、Jira 等项目管理平台，都属于协作工具的范畴，此外还有各种电话会议、视频会议、即时通信 App 等。
上一套协作工具不难，难的是大家把工具日常用起来，为项目活动服务，让它成为团队离不开的一部分。这方面的面试问题，比如“开发者、测试、产品经理在什么场景下会协同使用某一个工具？”，这其实就是通过工具，来考查这几个角色的协作。

协作模式：合作、竞争、妥协、顺从和逃避。

通过本篇的讨论，请你思考文中提到的问题：

• 文中介绍的七个要素，你的团队有没有做得好，或者不好的例子？
• 协作的五种模式，你曾经用到过哪种？

1.文中介绍的七个要素，你的团队有没有做得好，或者不好的例子？
在我的团队中，协作工具用的很好，职责边界清晰，沟通环境前期出现了一些问题，但后来还是跟大家对齐沟通原则，如为何要增加团队的信息透明度，怎么增加团队沟通信息的透明度，有什么利弊，出现一例纠正一例，有时候客户也会犯错，如某个问题只跟团队某个成员私下说，这肯定也需要我们告诉客户信息透明的重要性。认同感，责任感，信用度整体还不错，但我认为责任感还不够，真正需要我们为用户考虑，也有可能是领导放权不够，但不管通过何种方式我们都要找到解决的办法。
2.协作的五种模式，你曾经用到过哪种？
答：刚进入团队的时候试着竞争，发现效果不好，要么争来争去，要么结果不了了之，因为谁也说服不了谁。后来有过逃避，一想算了，我的一些最佳实践主张被人误解为抢功劳或者不懂项目实际业务。后来干脆先搞好关系，顺从这些刺头或者反对者，增加认同感，多站在他们的角度考虑问题，让他们知道我们是一条绳上的蚂蚱，真碰壁了遇到问题了再跟大家一起合作，经历的坑多了，大家也越来越默契，那些曾经不好说话的人也会对你越来越妥协甚至顺从。当然最终也是最好的结果是合作既争取到了利益又不影响关系，从团队的成长来讲也最有利。

领导力

领导力有几种主要的产生因素：职位权力、专业权威、个人魅力等。

领导和管理的区别。

• 领导的作用是：赋予团队目标和动力，指出更好的方向，以促成决策和推动进展。
• 管理的作用是：使计划按照既定目标和流程执行。

领导活动包括改造团队、发掘机会、定义目标、指出方向，无论技术、业务，还是管理角色，利用其专业性都可以发挥的领导力；而管理活动包括计划、执行、监控、报告等，拟定和管理流程，是特定的职位职责。

项目经理做了一个决定，但是大家觉得不合理，但惧怕他的权力，只好被迫执行，最终任务失败。还有，在大家一筹莫展的时候，有人说了几句话，使得大家茅塞顿开，局面豁然开朗。

从影响力模型，来看领导力的作用范围

• 最内层是决定圈。这里的事情，你有足够的权力和能力，去决定、控制、处理。
• 决定圈之外是影响圈。这里的事情，已经离开了你的控制区，但与你的工作有密切的关系。因为你没有决定权，就只能靠建议、协商等手段来影响该区域的负责人做出决策。比如对于一个开发人员来说，如果架构设计不是你的责任，当你发现了架构的不合理之处，可以去找架构师讨论，进而影响架构的调整。
• 最外层是适应圈。该区域涉及这个角色工作的大环境，比如政策法规、公司流程等，即使你去施加影响，也收效甚微。在适应圈中，你应该根据工作的目标和个人能力，明智地选择、适应，而不是一味地抱怨、对抗或采取其他消极措施。

哪些方面体现你的领导力

• 1.带人或影响人：激发他人的动机和能力
  • 榜样的带动作用：你以身作则，率先垂范，别人受到感染而追随。
  • 权威的指导作用：你是这个领域真正的专家，能够从根本上找到问题的原因、给出建设性意见，经过大家多次实践，树立了你的权威性，一碰到该领域的问题，大家就会自然而然想到你，你成了大家的主心骨。
  • 教练的启发作用：你不亲自上阵，也不是该领域的专家，但可以是个好教练。你相信每个人都有非常大的潜力，根据大家的困惑，通过启发性的问题，促成思考，让大家自己找到动机和解决方案。
  • 朋友的鼓励作用：你认可大家的成果，向大家澄清这些成果对用户的影响和意义，让大家意识到自己的成果有用，树立自信，加强自驱，相信能做得更好。
  • 知人善任：让合适的人，做合适的事，最大化地发挥每个人的长处和效能，加上适时适度的培养，使团队成长起来，让即使是平凡的人，也发挥出不可或缺的作用。
• 会用下面的问题来考查应聘者带人和影响人的能力：
  • 你觉得培养或者指导别人时，哪方面最困难？
  • 除了技能上给他们帮助，你还做过什么？
  • 举个实例，你们团队在讨论中如何达成一致的？
  • 你培养过别人的学习能力么？
  • 如果我给你 Offer，你回去怎么做项目交接？（这个问题同时还在看其责任感。）

情境领导力模型是管理领域的一个重要工具，用来指导不同情境下的领导风格（如下图所示）。在这个模型中，领导行为被分为两方面：针对任务的指导性行为和针对关系的支持性行为。从这两个维度出发，领导行为又被分到 S1、S2、S3、S4 四个象限内，分别对应指导型、教练型、支持型、授权型。

• S1 指导型：对于热情洋溢的初学者，比如一个能力弱但是热情高的校招员工，领导方式是尽可能地多些指导，帮助其顺利起步。
• S2 教练型：当这位初学者碰到诸多困难，热情下降，甚至有些消沉的时候，要增加支持性行为，通过鼓励和认可，让其重拾信心。同时，因为他已经具有初步的技能，但是没有帮助还是无法胜任工作，所以最好通过教练式的启发，激发他的潜力，而不是事事都手把手地教。
• S3 支持型：当初学者具有了一定的能力，变成能干的执行者时，就不再对他指手画脚了，而保持情感上的支持和认可，鼓励他尽量独立地完成工作。
• S4 授权型：当他能独当一面地工作时，就可以放心大胆地把工作授权给他了，他不再迫切需要你的指导和情感上的鼓励，因为他大概率能从成果中获得成就感，保持工作热情。

2.做事：前瞻、决策、推进和担当

• 发展前瞻。领导力的最好注解是：前瞻性思维。这体现的是你的综合实力，包括对技术、市场、行业的发展洞悉。你通过了解前沿技术，探索前沿技术解决问题；从而发现新机会、新趋势，对技术或者行业的发展前景有自己的解读。在面试架构师的时候，我会就某一项技术，问问应聘者对其发展趋势的认识。
• 创造机会。通过对前瞻性的把握，内结外联，给团队创造发展的机会。发现的新机会包括：新的业务领域、新的业务模式、好的技术应用、更高效的工具和流程，把这些变化引入团队和项目，促成团队业务和生产力的发展。
• 方案决策。根据产品所处的生命周期，以及市场环境，对问题和风险进行评估，制定合适的方案决策，包括业务方向、组织结构、技术选型等。这不仅仅是管理职位需要考虑的，身为架构师、开发者、业务分析师、运维人员，无论是谁，都可以在决策时提供意见，支撑起决策者的决定。
• 责任担当。在项目执行中，难免出现困难，无论是技术难点、人手不足、资源短缺、沟通不畅、外部依赖等，这些导致的进度延迟，甚至项目终止时，你能承担起责任，发现问题的根源，调动起大家的积极性，移除障碍，创造转机，解决问题，这种担当，表现出了干事、扛事的责任感和领导力。

面试中，我通常会通过考查在讨论、决策、问题和危机处理等场景中应聘者的行为，来分析他的领导力：他的信息改变了讨论的基调么；他的意见左右了决策的方向么；他在问题处理中是旁观者、执行者，还是组织者；他在事件中承担了怎样的压力。
在非工作的场景中，也能看出一个人的领导力。比如，他的兴趣爱好是爬山，那他是经常组织活动的那个人么？爬山线路是谁在做，出现困难时，他有什么表现等等。这能展现出他在没有工作角色赋权的情况下，自己的责任担当和领导力表现情况。

技术领导力三个方面：技术、业务、管理。

• 技术
  • 宽度意味着你懂得多少技术，就是有多 “泛” ，这很大程度上决定了你能否带领团队着手解决问题；深度预示着你在哪些技术领域有所深耕，形成了自己独到的见解，也就是有多 “精” ，这决定了你能否带领团队把问题解决好。
  • 技术宽度包含但不限于：技术领域扩展、问题域的可选技术、全局视角、技术体系、多行业的技术应用；技术深度包含但不限于：对特定技术领域的深刻理解、前沿技术的关注、特定领域的深度技术应用。
• 着眼业务
  • 这就要求我们在做技术选型时应该以此为前提，考虑投入产出比；在解决技术问题的时候，要多问为什么，搞清楚这个问题在上层看来是个什么表现，明白用户的痛点，才能解决得准。
• 懂管理
  • 技术领导者也要懂得如何调动资源、统筹规划，以及如何做分工协作等管理工作，这一是为了和管理人员紧密协作，二是很多技术工作可能需要自己主持，而远远不是一个人能简单完成的了。

在团队的技术讨论中，你起到的最大作用是什么？
说说你最近碰到的一个项目困难，你是怎么解决的？
你做过哪些项目经理或者部门经理才做的事情？

我是一个能站在产品、项目、技术多角度考虑的开发人员，最近在做一个购票抢座的小项目，运营人员给了需求和想要仿照某购票 app 的截图，而我们的项目和这个 app 还有一些区别，我作为后端开发需要提前给出前端 api 接口定义和规范，在没有产品原型设计的情况下，我自己分析需求，用 axure 规划功能模块图和业务流程图，并共享和邀请前端人员讨论页面使用详细的流程和细节，然后定义出具体的接口和规范，保证前后端同步开发。
作者回复: Wow，三言两语就把自己的担当（条件不具备就主动多做，领导力的表现）、创新（看到需求区别不盲从）、跨角色技能（业务设计）、协作（组织讨论）清楚地展现出来了。你的这段话，不仅内容上展现了个人工作能力，形式上体现了非常好的总结和表达能力，能看出你心里非常清楚面试官想知道什么。

领导力是靠影响力来驱动的，实践中有采用过指导新人熟悉项目以及开发流程和规范，对有些团队成员能力比较好的就启发引导式帮助解决问题，帮他们找到问题的根源，该申请资源的去申请资源，该跟客户确认沟通的就帮着组织会议，去更好的支持他们。

解决问题能力

问题”。我在这里把它划分为三层含义：错误、提高、未知的机会。
解决问题的能力，它体现在找到问题、找到解决方案、复盘问题三个步骤上。

找到问题
这是指发现、分析和定位问题，包括看到问题的“症状”，通过分析调查，找到问题发生的原因。

面试中，我常问应聘者：“这个项目有什么待提高的？” 答案大体可归为以下几类：
“项目质量很好，没什么特别要提高的。” 这类回答可能是怕暴露问题惹火烧身，也可能是真的没看到什么提高项。
“因为工期紧，有些技术债，需要提高下。” 这类回答提出了一些不痛不痒的普遍问题，不能展示应聘者的独到见解。
“这个社区产品用户活跃度半年不见增长，调研后发现是讨论区缺少级联回复，这个功能的实现难点在于 XX。” 这样的回答，很明显一针见血地指出了问题所在，可以展现应聘者的深度思考。

在发现提高和机会之后，你需要将之界定成结构清晰的问题，包括目标、边界和验收标准，从杂乱的工作中抽离出低耦合、高内聚的工作块，以便于团队协作，各个击破。而问题定义的效果，依赖于你对工作细节的认知深度，还有你的项目经验和洞察力。

解决问题：
探索多种解决方案；
比较和决策；
实施解决方案。

如何探索方案。解决方案并不唯一，它可能是：
技术层面，比如修正编码或数据问题、自动化控制、引入监控工具；
流程层面，比如加强代码评审流程、改变上线审批控制、增强沟通、把线下改为线上操作等；
组织层面，比如加强人员培训、调整角色分工等。

决策，顺便提一下，我会考查应聘者对比多个技术方案的方法、维度，以及衡量标准。如何评估方案的合理性、易用性，资源消耗，次生问题，用户和团队的接受度等，这些方面都是决策中需要考虑的。

实施方案。根据问题的影响面和复杂度，解决方案可以分步实施：
快速修复，先止血；
长期修复，为使类似的问题将来不再发生，从根本上解决问题。
当同时处理多个问题时，一定要分清轻重缓急，明确主要问题和紧急问题，着重于解决那些有最大价值的方面；也一定要保持开放的头脑，勇于采用新的手段，以及探索不同的解决方案；同时，需要把问题从大化小，从复杂化简单，运用分治的思想，这有利于团队成员一起更高效地协作。

验证和复盘
也就是说，你需要验证结果是否达到了预期。通过持续监控修复后产品的运行状态和结果，以及用户反馈，来看问题解决的满意程度。

修正错误类的问题，我把效果分成以下四个层次。

• 只消除了当前影响。这种修复大多只是解决了表面问题，去除了症状，所谓“头疼医头，脚痛医脚”。比如，某种不可重现的订单金额出错，只去数据库里把金额改成正确的数值，而不去分析订单计算逻辑。这种“打补丁”的方法，只是在止血的情况下使用，而事后，你一定要找到问题根源彻底修正，否则问题还会反复发生。
• ‌彻底根除了错误。这是我们希望的长效解决方案。这要求分析足够深入，触及内部逻辑，进行有意义的修复，避免以后此类错误再次发生。
• ‌变问题为机会。这是指当我们解决问题时，发现机会，扭转局势，取得收获。举个例子，我们这个专栏的文章，有一次发现被某个公众号不合规地抄袭。极客时间的小分队在与公众号主人交涉后，不但顺利使对方撤掉不合规的文章，还和对方谈成了合作伙伴。
• ‌分享方法，教导他人。在对问题复盘的过程中，把经验教训的总结文档化，分享给相关的人和团队，供将来出现问题时参考，教导他人不要再犯同样的问题。这样一来，你的经验和能力使整个团队都受益，也是你影响力和领导力的展现。

你主导解决过哪个问题，第一次失败了？后面经过怎么样的纠正，才成功的？

解决问题的能力直接关系到项目的成败以及客户的满意度，当然还与问题的范围有关，围绕项目产品的一切都可以划分问题域，有技术工具，有开发流程，有管理职责授权。我曾经做过一个项目，复盘时把每个迭代的回顾会议内容总结要点发给团队成员，也抄送给上面领导一份，其实私下里自己还做了一份 ppt 文档想在公司分享一下该项目的得与失，如果再有类似的项目我们应该怎么做会更好。

面试需要人的能力

• 工作结果
  • 质量好，价值高
    • 代码质量 —— 命名规范
    • 项目质量 —— 特性、性能、可靠性、易用性、可维护性、安全性等等方面符合要求
  • 正向影响他人
    • 分享精力去帮助同事工作
    • 分享技能帮助同事提升技能
    • 分享自己的视野和观念，领导他人更快更好地工作
• 工作过程
  • 所在环境下达到对应产出，难度、努力、技术选取考虑。
• 信任感/置信度
  • 面试官需要推测应聘者的日后行为。
    • 工作困难时，有经验和技能去应对；
    • 技能不够时，有潜力能快速提升；
    • 事情麻烦时，有动力去认真对待
• 协作能力(能否和我一起工作)、学习能力、管理能力、精益能力
• 沟通表达能力。最简单的语言将复杂的内容表示清楚。
• 学习能力，专研精神，分析能力，沟通能力，组织能力，问题调查能力，合作能力等等。
• 沟通能力，表达能力，语言组织能力，理解能力，
• 技术角色
  • 算法思维→系统思维→架构思维→技术前瞻性把握
  • (动力)对底层细节的好奇心，愿意尝试新事物，扩充自己知识体系
• 管理角色
  • 项目经理，负责项目的成败；业务主管，负责业务开拓和发展；技术经理负责技术开拓、技术培训；部门经理负责人员绩效、部门发展。
  • (技能)优化人、财、物等资源的配置，用最小的投入，获得最大的价值产出。