背景

这次面试流程足足横跨三个部门，其中既有侧重业务的部门，也有侧重技术的部门。在省略三次面试的前提下，实际面试轮次有七次。

整个过程的心理压力还是比较大的，毕竟每多一次面试轮次，就多一份落选的可能。尤其转战三个部门还都是由于公司方面的原因...

面试范围广。由于涉及多个部门、多个面试官，所以面试内容涉及方方面面。技术、管理、业务、个人规划等等均有所涉及。其中技术也涉及基础、中间件、架构，以及应用等。

这里非常感谢我的原二级主管，在我面试过程中提供的帮助。他多次帮我梳理业务、梳理思考逻辑等。

这篇文章主要分享和 P8 级别的面试官 battle 的过程。问的粒度也比较大，整体发挥也比较完整。

所以，我经过整理，直接按照面试核心模块进行拆分，进行了总结，分享给你。

应聘方式：原二级主管，内推。

应聘岗位：技术专家-Java-零售Saas

面试时长：两个小时左右

面试核心：55%业务（新零售）、35%技术、10%人生

面试结果：面试通过，面试官很是认可，并让我准备后续的P9面。

面试形式：线下（因为原二级主管表示，我线下表现力强很多，结果也证明确实如此）

面试地点：阿里西溪园区B区

面试内容

1.介绍一下门店数字化作业项目（简历项目）

面试准备中，一定要有一个核心项目，可以用于展现自身价值的实际例子，而且一定要足够硬。大厂P6及以上，一般都是需要的。

简单来说，就是说清楚项目背景、项目价值、然后再到自身贡献，以及最后的效果&复盘。可以参考STAR法则。

面试中的项目不是最重要的，最重要的是通过项目，展现自身的价值。所以项目不是越大越好，而是越能体现自身价值越好。不要混淆目的和目标。

面试过程中，面试官会通过一些问题，确认项目是否是真实的。

系统的整体架构

面试项目，一定要会画它的架构图。现场想，容易犯错，即便你很熟悉它。

这个部分就是上述自身贡献的进一步深挖了。简单来说，就是面试官想了解你设计能力。大厂社招，基本都是p6起步。套用大佬的话，编码是基本要求。

那么从技术上拉开差距的第一块儿，就是设计能力。

这里先说一些个人的粗浅认识，后续有机会，会展开的。

编码 -> 核心编码 -> 模块设计 -> 应用设计 -> 系统设计（多应用复杂系统）

模块设计 -> 应用设计 -> 系统设计，其实都是方案设计，只是处理的复杂度是不同的。

软件工程的架构设计，本质上是为了处理，软件工程日益增高的复杂度。从这个角度，架构设计可以分为时空两个维度。空间上则类似于架构组成派，比如架构图。而时间上则类似于架构演变的规划。架构的时空维度是果，而架构决策派则是因。

这块儿还是比较容易拉开水平差距的。最直接就是项目的复杂程度嘛。不过这个是我们自身难以决定的。所以我从个人解决问题的角度来谈谈。

准备面试的小伙伴，可以就上面的四条清单，提前准备啦。

主要的业务场景

面试项目中，需要清楚项目最终产品侧表达，进而了解业务场景。

这里面试官一方面想要获取对你项目的感性认知，进而发现兴趣点（这个小伙子这个点，和我们团队xxx相近，可以深入探讨一下）。另一方面，也是看看你对业务的认识。毕竟产研的开发，都需要对业务有足够的认识，并且有足够的敏感度。

这个部分的回答，主要分为三块儿：

这部分，作为面试项目的业务部分，需要提前准备。

如果有大佬帮忙梳理，就超赞了，比如之前的二级主管花费了不少时间帮我整理业务门店营销方案步骤，真的是十分感激。

技术重构

在面试过程中，适当展现自己的主观能动性，是有必要的。

在大厂中，大部分主管还是比较喜欢有自我驱动力的同学的，更不会拒绝那些积极主动，热衷思考并实践的同学。

但是，如何展现出这一点呢？尤其一些小伙伴平时就有这样的习惯，但是却不知道如何展现。

我之前的工作中，每一个项目，我都会有文档。文档中包含项目管理、技术方案、总结、关联内容等部分。并且，作为PM，我也有足够的推动力。

当然，这都比不上，自主的技术重构来得直接。毕竟，实现技术重构，需要包括思考、总结、自我驱动、业务等多方面内容。

而且，技术重构也很容易展现自身技术深度，思考深度。

由于在之前的工作中，我有主动推动过作业系统重构，并规划了决策系统的重构。

所以，我就向面试官阐述了痛点、日常思考、解决方案、团队沟通、最终落地，以及最终的反思。

一定要有明确的重构原因（提高开发效率，降低开发成本等），切不可为了重构而重构。

技术上的难点，以及解决方案

即使是偏向业务的开发岗位，也需要一些技术上的硬菜。

如果你的面试项目体现不出技术高段位水准，或者面试官没有从你的表述中听出来项目的高技术书准的体现。那么面试官大概率会有两类问题：

前者，需要大家了解架构设计，并对架构设计中的最佳实践（如秒杀系统、会员系统、搜索系统等）比较熟悉。

后者，则需要大家的面试项目中确实有存在技术难点，并有过思考与解决。就算是虚构，也需要有能够进行技术嫁接的地方。

我在这个部分，主要讨论了异步。

先是简单讨论异步的概念，然后阐述了Java的FutureTask框架&实现原理，最后就是应用了。

这一切都丝滑度过，结果P8大佬觉得没有压榨出我的极限，就可以玩花活了。

简单来说，就是定量分析。在给出上游各个接口的延迟、并发量、以及各个接口间的依赖关系，要求我尝试计算当前接口的最大并发量、最小延迟等具体数值。

后续还添加了CPU核心数、网络延迟、内部异常等各种条件，还各种修改前提条件。

最后由于两个白板都写满了，条件都有些混淆了。

差不多二三十分钟的狂轰滥炸，我也开始有些晕晕乎乎了。只好表示有点晕乎，记不住前提条件了，P8大佬才收手。

末了，我问P8大佬，最后问题的最优解是什么？P8大佬表示他也不知道，他就想看看我的思路。看着他乐呵乐呵的，我也不好说什么...

项目管理

大厂的技术也需要懂项目管理。而且项目管理也是接触管理的最佳入口。

大厂中，各种需求都是按照项目的方式进行推进的，而技术侧是需要有人担任技术PM的。

而且担任技术PM是熟悉业务非常好的方式（个人成长小诀窍）。所以技术开发需要对项目管理有一定的认识，尤其是大厂开发。

如果可以，我推荐大家学习一下PMP，至少可以买一本pmbok看一看。

而在落地过程中，最重要的反而不是什么项目管理的十大知识体系，而是裁剪这个只出现在pmbok开篇的概念。

如果每个项目都按照完整项目管理流程走，那么花费在项目管理上的资源，将远超过花费在项目成果上的资源。

所以这就需要PM根据实际情况，对项目管理流程&工具进行适当的裁剪。说白了，追求项目管理落地的ROI。

比如，我的项目管理文档，一般分为：

面试过程中，面试官往往会提出一些实际可能遇到的问题。

比如项目资源不足、项目进度很赶、PD频繁修改需求等。而这就需要各位就自己对项目管理的认识，给出自己的答案。

这其中没有标准答案。回答的过程，就是展现你对项目管理的认识。

比如项目资源不足（我的面试问题）。你可以有这些选择：

如果大家真的对项目管理不太熟悉，就直接面试官直言，也算是一种解决方案。毕竟不是每个人都有这方面的积累。

团队管理

大厂的团队管理占管理者考核的一半。

一般来说，大厂的P7，以及及P7+的面试，都会问到团队管理。如果你只是面试一个P6，却被问到这个问题，那么不排除面试官把你看作预备役P7。

我目前没有接受团队管理的专项学习&培训。所以存在不足，希望大家多多包涵。也欢迎大家对我的想法提出意见。

我认为，管理是整合资源（人、时间、钱等），提高整体效率的方法论/学科。而团队管理，则是利用团队，通过一系列事务，达成特定组织目标。这其中会涉及团队人员管理、目标拆解、团队战斗力提升等一系列模块。

这里简单就人员、事务、目标三者进行简单阐述。

小结一下：

优秀的团队可以提高内部沟通效率，优秀的目标拆解可以降低内部沟通的总量，两者结合就是团队实现目标的高效。而正确的目标则可以提高团队价值转换率，配合前者则可以获得团队的高效价值产出（有别于高效产出）。

身为TL，不要用战术上的勤奋，去掩饰战略上的偷懒。

身为TL，经常由于思想与行动的差距，造成两种情况：眼高手低与无用努力。

前者多表现为整天谈各种高端概念、名词，但是缺乏落地，多出现在公司中上层管理。

这类TL，我“有幸”接触过，只能说挺心累的。真的上面拍个脑袋，下面跑断腿，末了发现无法落地。

后者多表现为整天吭哧吭哧在忙，年底感觉忙了不少东西。但一拧，发现整年都是散弹枪，没有聚焦点，或者聚焦点不够强。这种情况多出现在公司中下层管理。

这类TL，我也“有幸”遇到过。年底看看自己这一年做的，如果无法凝聚为有限的几大块儿，那说明就是这样的情况。

闲聊人生

闲聊是沟通者三观的碰撞，也是对面试者个人素质（如潜力等）的重要考量。

说实话，面试聊人生一直是我最放松的环节。一方面是之前的经历中，经常和公司Boss、团队一二级主管沟通，另一方面是自己平日里对自己是有不少反思&总结&规划的。

更重要的，我可以通过这个环节，去了解&借鉴那些大佬如何沟通、总结、规划，并得到那些大佬对我思考&规划的建议。这都是难得的学习机会，只能说很多人没有充分利用上。

这个环节，我基本都是临场发挥。唯一需要注意的是说话要过脑子，明确什么话可以说，什么话不可以说，什么话要婉转说。

简单就面试而言，你需要表现出以下三点：

而这其中，又可以展开很多。不过因为闲聊人生环节而被拒绝的小伙伴比较少，这里就不再赘述。

P9面

其实面试前，我已经知道了大概的面试方向和问题。是的，有一位大佬真心带你，就是这么爽。

不过，P9面由于HC问题，一直卡着。我直到最后也没有真正接触与这位P9进行沟通，挺遗憾的。

这位P9大佬算是这些面试中最关心业务的P9大佬，所以我还是谈谈他的面试方向和问题，供大家参考。

当时的面试会有两个方向，一个是新零售业务（因为当时目标团队有这个痛点），另一个是业务稳定性。这里就谈谈后者。

其实聊到稳定性门店营销方案步骤，大家都或多或少知道一些，比如最基本的高可用三剑客（限流、降级、熔断）。但是如果强调技术之外呢？或者说只是技术侧会不会太狭隘了？

抛开技术，业务本身也有稳定性需求，信息技术在这里只是实现手段。我们可以通过时间线来分析：

至于故障发生后的事后复盘，那是必须的，这里不再提及。

最后，业务优先级 = 影响面 x 发生概率