被阿里P8面了两个小时，技术、业务有来有回......

上一篇：4 种主流的 API 架构风格对比

我平时偶尔会参加其他公司的面试，主要是为了检验自己的水平和能力。今天给大家分享一篇阿里面试过程记录的文章。
看完之后你会发现在 P8 的这一轮面试中，其实具体的技术问题问的并不多，都是围绕着项目进行展开的。
这种面试的体验和收获会比直接干巴巴的考察技术点好的多。而且作为面试官来说，也并不想问你干巴巴的技术点，关键是你得有拿得出手的项目和业务知识储备，才能在技术之外的地方和面试官进行缠斗，从而增加自己面试通过的几率。
这次分享就是一次非常成功的在业务领域和技术领域都有来有回的面试，只是在业务领域交互的更多。
原文链接：https://www.cnblogs.com/Tiancheng-Duan/p/15868364.html

背景这次面试流程足足横跨三个部门，其中既有侧重业务的部门，也有侧重技术的部门。在省略三次面试的前提下，实际面试轮次有七次。
整个过程的心理压力还是比较大的，毕竟每多一次面试轮次，就多一份落选的可能。尤其转战三个部门还都是由于公司方面的原因...
面试范围广。由于涉及多个部门、多个面试官，所以面试内容涉及方方面面。技术、管理、业务、个人规划等等均有所涉及。其中技术也涉及基础、中间件、架构，以及应用等。
这里非常感谢我的原二级主管，在我面试过程中提供的帮助。他多次帮我梳理业务、梳理思考逻辑等。
这篇文章主要分享和 P8 级别的面试官 battle 的过程。问的粒度也比较大，整体发挥也比较完整。
所以，我经过整理，直接按照面试核心模块进行拆分，进行了总结，分享给你。
应聘方式：原二级主管，内推。
应聘岗位：技术专家-Java-零售Saas
面试时长：两个小时左右
面试核心：55%业务（新零售）、35%技术、10%人生
面试结果：面试通过，面试官很是认可，并让我准备后续的P9面。
面试形式：线下（因为原二级主管表示，我线下表现力强很多，结果也证明确实如此）
面试地点：阿里西溪园区B区
面试内容1.介绍一下门店数字化作业项目（简历项目）
面试准备中，一定要有一个核心项目，可以用于展现自身价值的实际例子，而且一定要足够硬。大厂P6及以上，一般都是需要的。
简单来说，就是说清楚项目背景、项目价值、然后再到自身贡献，以及最后的效果&复盘。可以参考STAR法则。

• 项目背景，要说清楚这个项目从何而来。比如作业这个概念是零售行业一直存在的。而之所以数字化，是因为盒马支撑线上业务，所以数字化是必要的。而数字化作业系统，可以完成信息流转、提高效率等等。这其中比较擅长的点，就多说两句。甚至可以引导面试官去询问。

• 项目价值，要从商业价值，到业务价值，最后到实现的价值指标。比如价值流中，如何拉新、增加用户粘性。再到如何提高业务流转效率，最后到开发成本节省等。但凡项目，必然是有价值的，否则过不了商业论证的。

• 自身贡献，一定要体现自己在项目中的价值。即使项目再大，自己没有参与其中也是白搭。比如负责整个项目的项目管理、整个系统的技术方案设计、核心模块的编写等。这个过程，可以先强调* * 工作的难点，让面试官切实认同难点，再提出解决方案。这样比较容易获得面试官对自身价值的认可。比如，你和面试官说，这个系统要求10W的TPS。面试官立马就有兴趣了。如果，你能提供一个切实可行的解决方案。那么面试官对你价值，就十分认同了。

• 效果&复盘，效果要体现项目完成度，而复盘则体现了自我反思提升的能力。很多人对大厂说的潜力，不太明白。而自我反思提升的能力，就是潜力的一种表现。比如我实现了一个10WTPS的系统，根据最后的落地效果。你认为哪里还有提升的空间，比如优化某处的技术选型，可以降低成本等。又比如，如何设计架构，可以有效支撑业务后续的快速发展。

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

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

系统的整体架构

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

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

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

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

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

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

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

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

• 最基本要说清楚多个关键点的决策理由，如这块儿的设计重难点是什么、为什么采用策略模式、怎么实现策略模式等。

• 进一步要对整个方案的设计思路，有全局思考的整体观念。比如秒杀系统的难点就是读写峰值高，还要保证用户体验。那么解决的要点是缓存、一致性等等。识别问题核心->解决思路->具体方案。

• 再进一步就是自身的方案要有方法论支撑。要从方法论中找到实际问题解决，再从实际问题回归到方法论中。比如大到利用DDD解决业务领域划分、识别核心领域模型等，小到二八原则落地到缓存方案中。另外搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。

• 再往后，要么向上，考虑到业务，甚至商业模式等。比如支撑业务的快速扩张，以及商业模式的快速转变等。要么向下，精细化每块的设计方案，比如精准估算应用水位等。

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

主要的业务场景

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

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

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

• 如何精炼地描述业务场景。建议可以参照5W1H分析法。这样有利于在准备阶段就理清业务场景。实际面试往往由于临场发挥等问题，表现还会缩水一些。比如门店效期管理平台是面向运营同学，用于管理商品效期限balabala。

• 明确“主要”的由来。能够说清楚真正主要的业务场景。并指导为什么它是主要业务场景。比如是归属业务价值流的生产链路。比如是直接关联资金的业务等。

• 串联各个业务场景。能够将业务场景串联起来，使之不再是一个个孤立的点。这需要小伙伴对关联业务有足够高的认识，有的还需要小伙伴了解公司相关战役的始末。

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

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

技术重构

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

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

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

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

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

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

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

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

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

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

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

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

• 自主系统设计：简单点的，将面试项目中的某个需求改一改，比如并发量从100，到100W。难一点的，直接让你从零考虑某个场景。比如让你设计一个秒杀系统，或者设计一个火车订票系统。

• 自问自答：面试官让被面试者谈谈项目中遇到的难题，以及解决方案。

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

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

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

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

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

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

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

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

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

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

项目管理

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

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

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

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

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

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

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

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

• 项目背景：简单介绍业务背景，以及项目核心干系人（业务、PD、PM）等。

• 项目基线：主要就是范围、资源（多指人力资源）、进度三条基线。其中大厂的进度，并不需要甘特图，里程碑就可以了。

• 项目风险：主要针对可能存在的风险，以及对应解决方案。比如某个项目团队成员是新人，可能存在工时判断错误。那就需要判断他负责的项目内容是否在项目关键路径上，项目活动时间是多少，是否需要额外的帮助。比如额外资源投入。并且可以通过每日确定进度，确保其个人偏差在接受范围内，不会扩大影响面。

• 项目验收：这部分依据具体情况，可以收录测试、产品、业务的验收情况。并补充作为PM，对项目上线的后续追踪。

• 项目总结：对该项目过程中，遇到对问题、思考、总结都收录在这儿。

• 附录：其中参考，则是整理项目相关的所有资料，如PRD、技术设计方案等。

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

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

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

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

• 通过对PD、业务、TL施压，或者利用自身的影响力，尝试获取更多资源。这个部分可以简单展开。比如个人影响力怎么来的（平时就有帮助别的团队）。

• 通过与PD、业务沟通，获取更多的开发时长。这个就需要PM有较好的沟通能力了。沟通不好，打起来都可能。

• 通过关联团队协调，交换项目资源，获取在该项目更有经验的开发。这里涉及到项目组合管理。有点超纲了。但确实是解决思路。

• 通过与PD、业务沟通，缩减项目范围。这个对PM要求比较高。不过就算不成功，也可以为下一条铺路（原因看《优势谈判》）。

• 通过与PD、业务沟通，对项目范围内的需求进行优先级拆分。进而将整个项目拆分为多个阶段进行。这个事儿，我在效期项目上就这么做过。

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

团队管理

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

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

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

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

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

• 目标：无论是政府、企业、团队，还是个人，都会有目标。这里再次重申，有别于于目的，目标是完成目的的手段。在组织结构中，目标会层层拆解下来，最终落地到执行层面。身为TL，一定需要明确自己的目标。如果目标整错了，即使后面做得再好，对于公司而言，这个TL也是失败的。但是，目标是为了目的而服务。如果对上层的目标拆解存在疑问，则需要积极进行沟通。目标确定前积极沟通，目标确定后积极执行。

• 事务：排除团队战斗力，为什么团队间的产出依旧存在较大差距，就是因为目标拆解存在问题。类比而言，就是复杂系统在进行功能域拆解时，可以有多种拆解方式。可以按照组织结构，可以按照价值流、甚至可以按照字母顺序（开个玩笑）。但是合理的拆解方式自然是追求高内聚、低耦合，这样可以使得不同功能域内部更加自治、减少与其他域不必要沟通，进而降低协同成本等。另外，目标拆解还需要考虑到团队成员成长。比如我在安排事情的时候，并不是完全按照完成事情去进行目标拆解。而是花更多的心思，考虑到团队每个成员的当前能力、未来成长等。这是为了团队长远战斗力提升。

• 团队：有别于项目管理，项目管理的核心是事、而团队管理的核心是人。所谓“兵熊熊一个，将熊熊一窝”，团队的战斗力，很大程度上受TL的风格影响。团队成员的成长、定位、忠诚都是需要TL去关注的。我之前带过几次团队。核心理念就是真诚待人，懂得换位思考。这直接使得团队文化就是大家比较真诚，懂得理解彼此，进而更好地进行团队协作。优秀的团队协作，意味着团队的高效产出。

小结一下：

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

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

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

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

这类TL，我“有幸”接触过，只能说挺心累的。真的上面拍个脑袋，下面跑断腿，末了发现无法落地。另外搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。

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

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

闲聊人生

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

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

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

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

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

• 态度积极&乐观：很多人简历上写着积极、乐观、开朗，却没有任何有力支撑点。你可以在闲聊中表示喜欢和朋友爬山，平日里有在健身、遇到某些人生问题保持乐观态度等。

• 巨大能力&潜力：有些深层次能力，可能某些面试官没有挖掘到，还有隐性的潜力等。这都需要你来主动展现（展现价值，才可以获得更好认可）。比如你可以表示自己在解决某个问题时体现了解决问题能力，自己的体系化认识（专业、认知等）、自己的日常思考（业务、技术等）等

• 渴望公司&团队：面试官有千万个应聘者选择，你也同样有千万个公司选择。你需要表现出你对该公司&团队的向往。文化的倾向，意味着你在团队的稳定性、以及适应性等，并不是无用的。比如你可以主动咨询目标公司&团队的愿景、业务等，并进行沟通与认同等。

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

P9面

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

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

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

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

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

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

• 事前：核心是预防。业务&产品上的预防手段，可以是在规则发布窗口添加影响面校验。技术上可以是高可用三剑客（涉及依赖分析，可以深入展开，体现技术造诣）。

• 事中：核心是监控。业务&产品上的监控手段，可以是现场数据大屏、业务指标监控等。技术上可以是各类基础监控等。技术设计上可以有幂等&重试，以及超时。甚至可以是冗余（数据库挂了，通过缓存提供继续查询能力）、N版本程序设计等。

• 事后：核心是兜底。业务&产品上的兜底手段，可以是人工兜底方案、业务妥协方案等。技术上可以是资源隔离，进而降低影响面。

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

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

相关阅读：2T架构师学习资料干货分享

PS：如果觉得我的分享不错，欢迎大家随手点赞、转发、在看。