一篇很有价值的阿里面试经验
在博客园看到一篇阿里面试经验，感觉内容有很多值得学习的地方，不仅适用于面试，也适用于述职或给其他人讲明白一件事情。
logs.com/Tiancheng-Duan/p/15868364.html
一、背景
标题很嚣张，但事实确实就是如此。这次面试流程足足横跨三个部门，其中既有侧重业务的部门，也有侧重技术的部门。在省略三次面试的前提下，实际面试轮次有七次。
整个过程的心理压力还是比较大的，毕竟每多一次面试轮次，就多一份落选的可能。尤其转战三个部门还都是由于公司方面的原因。。。
面试范围广。由于涉及多个部门、多个面试官，所以面试内容涉及方方面面。技术、管理、业务、个人规划等等均有所涉及。其中技术也涉及基础、中间件、架构，以及应用等。
这里非常感谢我的原二级主管，在我面试过程中提供的帮助。他多次帮我梳理业务、梳理思考逻辑等。
原计划是一篇文章写完，内容上只是对面试问题的记录，以及少量的思考。但在写作过程中，还是忍不住写详细了，并给出了许多对面试的总结。所以最终决定以多篇文章，进行阐述。
二、A部门
应聘方式：原二级主管，内推。
应聘岗位：技术专家-Java-零售Saas
原本不想放出来岗位的。但是看到有人比较质疑前一篇文章的真实性，这个岗位最终也没去，所以就放出来了。岗位放出时间，与我之前二方的离职时间，是一致的。
1.P7面
按道理来说，应该会有一轮P7面试，进行技术基础的沟通。但是这边公司直接从流程上给我跳过了。猜测是因为之前在团队的技术表现得到了二级主管的认可，所以就给我省略了这一轮次面试。
然而在后续其他部门的面试中，还是没逃过Java基础面试。囧
2.P8面
a.简介
面试时长：两个小时左右
面试形式：线下（因为原二级主管表示，我线下表现力强很多，结果也证明确实如此）
面试地点：阿里西溪园区B区
面试核心：55%业务（新零售）、35%技术、10%人生
b.面试内容
1.介绍一下门店数字化作业项目（简历项目）
面试准备中，一定要有一个核心项目，可以用于展现自身价值的实际例子，而且一定要足够硬。大厂P6及以上，一般都是需要的。
简单来说，就是说清楚项目背景、项目价值、然后再到自身贡献，以及最后的效果&复盘。可以参考STAR法则。
项目背景，要说清楚这个项目从何而来。比如作业这个概念是零售行业一直存在的。而之所以数字化，是因为盒马支撑线上业务，所以数字化是必要的。而数字化作业系统，可以完成信息流转、提高效率等等。这其中比较擅长的点，就多说两句。甚至可以引导面试官去询问。
项目价值，要从商业价值，到业务价值，最后到实现的价值指标。比如价值流中，如何拉新、增加用户粘性。再到如何提高业务流转效率，最后到开发成本节省等。但凡项目，必然是有价值的，否则过不了商业论证的。
自身贡献，一定要体现自己在项目中的价值。即使项目再大，自己没有参与其中也是白搭。比如负责整个项目的项目管理、整个系统的技术方案设计、核心模块的编写等。这个过程，可以先强调工作的难点，让面试官切实认同难点，再提出解决方案。这样比较容易获得面试官对自身价值的认可。比如，你和面试官说，这个系统要求10W的TPS。面试官立马就有兴趣了。如果，你能提供一个切实可行的解决方案。那么面试官对你价值，就十分认同了。
效果&复盘，效果要体现项目完成度，而复盘则体现了自我反思提升的能力。很多人对大厂说的潜力，不太明白。而自我反思提升的能力，就是潜力的一种表现。比如我实现了一个10WTPS的系统，根据最后的落地效果。你认为哪里还有提升的空间，比如优化某处的技术选型，可以降低成本等。又比如，如何设计架构，可以有效支撑业务后续的快速发展。
PS：面试中的项目不是最重要的，最重要的是通过项目，展现自身的价值。所以项目不是越大越好，而是越能体现自身价值越好。不要混淆目的和目标。
面试过程中，面试官会通过一些问题，确认项目是否是真实的。
2.系统的整体架构
面试项目，一定要会画它的架构图。现场想，容易犯错，即便你很熟悉它。
这个部分就是上述自身贡献的进一步深挖了。简单来说，就是面试官想了解你设计能力。大厂社招，基本都是p6起步。套用大佬的话，编码是基本要求。囧
那么从技术上拉开差距的第一块儿，就是设计能力。
这里说一些个人的粗浅认识，后续有机会，会展开的。
编码 -> 核心编码 -> 模块设计 -> 应用设计 -> 系统设计（多应用复杂系统）
模块设计 -> 应用设计 -> 系统设计，其实都是方案设计，只是处理的复杂度是不同的。软件工程的架构设计，本质上是为了处理，软件工程日益增高的复杂度。从这个角度，架构设计可以分为时空两个维度。空间上则类似于架构组成派，比如架构图。而时间上则类似于架构演变的规划。架构的时空维度是果，而架构决策派则是因。
这块儿还是比较容易拉开水平差距的。最直接就是项目的复杂程度嘛。不过这个是我们自身难以决定的。所以我从个人解决问题的角度来谈谈。
最基本要说清楚多个关键点的决策理由，如这块儿的设计重难点是什么、为什么采用策略模式、怎么实现策略模式等。
进一步要对整个方案的设计思路，有全局思考的整体观念。比如秒杀系统的难点就是读写峰值高，还要保证用户体验。那么解决的要点是缓存、一致性等等。识别问题核心->解决思路->具体方案。
再进一步就是自身的方案要有方法论支撑。要从方法论中找到实际问题解决，再从实际问题回归到方法论中。比如大到利用DDD解决业务领域划分、识别核心领域模型等，小到二八原则落地到缓存方案中。
再往后，要么向上，考虑到业务，甚至商业模式等。比如支撑业务的快速扩张，以及商业模式的快速转变等。要么向下，精细化每块的设计方案，比如精准估算应用水位等。
准备面试的小伙伴，可以就上面的四条清单，提前准备啦。
3.主要的业务场景
面试项目中，需要清楚项目最终产品侧表达，进而了解业务场景
这里面试官一方面想要获取对你项目的感性认知，进而发现兴趣点（这个小伙子这个点，和我们团队xxx相近，可以深入探讨一下）。另一方面，也是看看你对业务的认识。毕竟产研的开发，都需要对业务有足够的认识，并且有足够的敏感度。
这个部分的回答，主要分为三块儿：
如何精炼地描述业务场景。建议可以参照5W1H分析法。这样有利于在准备阶段就理清业务场景。实际面试往往由于临场发挥等问题，表现还会缩水一些。比如门店效期管理平台是面向运营同学，用于管理商品效期限balabala。
明确“主要”的由来。能够说清楚真正主要的业务场景。并指导为什么它是主要业务场景。比如是归属业务价值流的生产链路。比如是直接关联资金的业务等。
串联各个业务场景。能够将业务场景串联起来，使之不再是一个个孤立的点。这需要小伙伴对关联业务有足够高的认识，有的还需要小伙伴了解公司相关战役的始末。
这部分，作为面试项目的业务部分，需要提前准备。如果有大佬帮忙梳理，就超赞了。比如之前的二级主管花费了不少时间帮我整理业务，真的是十分感激。
4.技术重构
在面试过程中，适当展现自己的主观能动性，是有必要的。
在大厂中，大部分主管还是比较喜欢有自我驱动力的同学的，更不会拒绝那些积极主动，热衷思考并实践的同学。但是，如何展现出这一点呢？尤其一些小伙伴平时就有这样的习惯，但是却不知道如何展现。
我之前的工作中，每一个项目，我都会有文档。文档中包含项目管理、技术方案、总结、关联内容等部分。并且，作为PM，我也有足够的推动力。
当然，这都比不上，自主的技术重构来得直接。毕竟，实现技术重构，需要包括思考、总结、自我驱动、业务等多方面内容。而且，技术重构也很容易展现自身技术深度，思考深度。
由于在之前的工作中，我有主动推动过作业系统重构，并规划了决策系统的重构。所以，我就向面试官阐述了痛点、日常思考、解决方案、团队沟通、最终落地，以及最终的反思。
有关技术重构部分，我后面应该会有专门的文档进行说明。
这里只说一点，一定要有明确的重构原因（提高开发效率，降低开发成本等），切不可为了重构而重构。
5.技术上的难点，以及解决方案
即使是偏向业务的开发岗位，也需要一些技术上的硬菜。
如果你的面试项目体现不出技术高段位水准，或者面试官没有从你的表述中听出来项目的高技术书准的体现。那么面试官大概率会有两类问题：
自主系统设计：简单点的，将面试项目中的某个需求改一改，比如并发量从100，到100W。难一点的，直接让你从零考虑某个场景。比如让你设计一个秒杀系统，或者设计一个火车订票系统。
自问自答：面试官让被面试者谈谈项目中遇到的难题，以及解决方案。
前者，需要大家了解架构设计，并对架构设计中的最佳实践（如秒杀系统、会员系统、搜索系统等）比较熟悉。
后者，则需要大家的面试项目中确实有存在技术难点，并有过思考与解决。就算是虚构，也需要有能够进行技术嫁接的地方。囧
纯技术上的技术难点与解决，可以参照我之前的系统质量治理。起码常见的性能、扩展性问题都有分类与基本解决思路。囧
我在这个部分，主要讨论了异步。先是简单讨论异步的概念，然后阐述了Java的FutureTask框架&实现原理，最后就是应用了。这一切都丝滑度过，结果P8大佬觉得没有压榨出我的极限，就可以玩花活了。简单来说，就是定量分析。在给出上游各个接口的延迟、并发量、以及各个接口间的依赖关系，要求我尝试计算当前接口的最大并发量、最小延迟等具体数值。后续还添加了CPU核心数、网络延迟、内部异常等各种条件，还各种修改前提条件。最后由于两个白板都写满了，条件都有些混淆了。差不多二三十分钟的狂轰滥炸，我也开始有些晕晕乎乎了。只好表示有点晕乎，记不住前提条件了，P8大佬才收手。末了，我问P8大佬，最后问题的最优解是什么？P8大佬表示他也不知道，他就想看看我的思路。看着他乐呵乐呵的，我也不好说什么。。。囧
6.项目管理
大厂的技术也需要懂项目管理。而且项目管理也是接触管理的最佳入口。
大厂中，各种需求都是按照项目的方式进行推进的，而技术侧是需要有人担任技术PM的。而且担任技术PM是熟悉业务非常好的方式（个人成长小诀窍）。所以技术开发需要对项目管理有一定的认识，尤其是大厂开发。
如果可以，我推荐大家学习一下PMP，至少可以买一本pmbok看一看。
而在落地过程中，最重要的反而不是什么项目管理的十大知识体系，而是裁剪这个只出现在pmbok开篇的概念。如果每个项目都按照完整项目管理流程走，那么花费在项目管理上的资源，将远超过花费在项目成果上的资源。所以这就需要PM根据实际情况，对项目管理流程&工具进行适当的裁剪。说白了，追求项目管理落地的ROI。
比如，我的项目管理文档，一般分为：
项目背景：简单介绍业务背景，以及项目核心干系人（业务、PD、PM）等。
项目基线：主要就是范围、资源（多指人力资源）、进度三条基线。其中大厂的进度，并不需要甘特图，里程碑就可以了。
项目风险：主要针对可能存在的风险，以及对应解决方案。比如某个项目团队成员是新人，可能存在工时判断错误。那就需要判断他负责的项目内容是否在项目关键路径上，项目活动时间是多少，是否需要额外的帮助。比如额外资源投入。并且可以通过每日确定进度，确保其个人偏差在接受范围内，不会扩大影响面。
项目验收：这部分依据具体情况，可以收录测试、产品、业务的验收情况。并补充作为PM，对项目上线的后续追踪。
项目总结：对该项目过程中，遇到对问题、思考、总结都收录在这儿。
附录：其中参考，则是整理项目相关的所有资料，如PRD、技术设计方案等。
面试过程中，面试官往往会提出一些实际可能遇到的问题。比如项目资源不足、项目进度很赶、PD频繁修改需求等。而这就需要各位就自己对项目管理的认识，给出自己的答案。这其中没有标准答案。回答的过程，就是展现你对项目管理的认识。
比如项目资源不足（我的面试问题）。你可以有这些选择：
通过对PD、业务、TL施压，或者利用自身的PY能力影响力，尝试获取更多资源。这个部分可以简单展开。比如个人影响力怎么来的（平时就有帮助别的团队）。
通过与PD、业务沟通，获取更多的开发时长。这个就需要PM有较好的沟通能力了。沟通不好，打起来都可能。
通过关联团队协调，交换项目资源，获取在该项目更有经验的开发。这里涉及到项目组合管理。有点超纲了。但确实是解决思路。
通过与PD、业务沟通，缩减项目范围。这个对PM要求比较高。不过就算不成功，也可以为下一条铺路（原因看《优势谈判》）。
通过与PD、业务沟通，对项目范围内的需求进行优先级拆分。进而将整个项目拆分为多个阶段进行。这个事儿，我在效期项目上就这么做过。
如果大家真的对项目管理不太熟悉，就直接面试官直言，也算是一种解决方案。毕竟不是每个人都有这方面的积累。
7.团队管理
大厂的团队管理占管理者考核的一半。
一般来说，大厂的P7，以及及P7+的面试，都会问到团队管理。如果你只是面试一个P6，却被问到这个问题，那么不排除面试官把你看作预备役P7。/doge
我目前没有接受团队管理的专项学习&培训。所以存在不足，希望大家多多包涵。也欢迎大家对我的想法提出意见。
我认为，管理是整合资源（人、时间、钱等），提高整体效率的方法论/学科。而团队管理，则是利用团队，通过一系列事务，达成特定组织目标。这其中会涉及团队人员管理、目标拆解、团队战斗力提升等一系列模块。
这里简单就人员、事务、目标三者进行简单阐述。
目标：无论是政府、企业、团队，还是个人，都会有目标。这里再次重申，有别于于目的，目标是完成目的的手段。在组织结构中，目标会层层拆解下来，最终落地到执行层面。身为TL，一定需要明确自己的目标。如果目标整错了，即使后面做得再好，对于公司而言，这个TL也是失败的。但是，目标是为了目的而服务。如果对上层的目标拆解存在疑问，则需要积极进行沟通。目标确定前积极沟通，目标确定后积极执行。
事务：排除团队战斗力，为什么团队间的产出依旧存在较大差距，就是因为目标拆解存在问题。类比而言，就是复杂系统在进行功能域拆解时，可以有多种拆解方式。可以按照组织结构，可以按照价值流、甚至可以按照字母顺序（开个玩笑）。但是合理的拆解方式自然是追求高内聚、低耦合，这样可以使得不同功能域内部更加自治、减少与其他域不必要沟通，进而降低协同成本等。另外，目标拆解还需要考虑到团队成员成长。比如我在安排事情的时候，并不是完全按照完成事情去进行目标拆解。而是花更多的心思，考虑到团队每个成员的当前能力、未来成长等。这是为了团队长远战斗力提升。
团队：有别于项目管理，项目管理的核心是事、而团队管理的核心是人。所谓“兵熊熊一个，将熊熊一窝”，团队的战斗力，很大程度上受TL的风格影响。团队成员的成长、定位、忠诚都是需要TL去关注的。我之前带过几次团队。核心理念就是真诚待人，懂得换位思考。这直接使得团队文化就是大家比较真诚，懂得理解彼此，进而更好地进行团队协作。优秀的团队协作，意味着团队的高效产出。
小结一下：优秀的团队可以提高内部沟通效率，优秀的目标拆解可以降低内部沟通的总量，两者结合就是团队实现目标的高效。而正确的目标则可以提高团队价值转换率，配合前者则可以获得团队的高效价值产出（有别于高效产出）。
身为TL，不要用战术上的勤奋，去掩饰战略上的偷懒。 我的工作经历比较。。。嗯，丰富多彩。身为TL，经常由于思想与行动的差距，造成两种情况：眼高手低与无用努力。前者多表现为整天谈各种高端概念、名词，但是缺乏落地，多出现在公司中上层管理。这类TL，我“有幸”接触过，只能说挺心累的。真的上面拍个脑袋，下面跑断腿，末了发现无法落地。后续有机会谈谈这个经历，并给出解决办法。后者多表现为整天吭哧吭哧在忙，年底感觉忙了不少东西。但一拧，发现整年都是散弹枪，没有聚焦点，或者聚焦点不够强。这种情况多出现在公司中下层管理。这类TL，我也“有幸”遇到过。年底看看自己这一年做的，如果无法凝聚为有限的几大块儿，那说明就是这样的情况。
8.闲聊人生
闲聊是沟通者三观的碰撞，也是对面试者个人素质（如潜力等）的重要考量。
说实话，面试聊人生一直是我最放松的环节。一方面是之前的经历中，经常和公司Boss、团队一二级主管沟通，另一方面是自己平日里对自己是有不少反思&总结&规划的。
更重要的，我可以通过这个环节，去了解&借鉴那些大佬如何沟通、总结、规划，并得到那些大佬对我思考&规划的建议。这都是难得的学习机会，只能说很多人没有充分利用上。
这个环节，我基本都是临场发挥。唯一需要注意的是说话要过脑子，明确什么话可以说，什么话不可以说，什么话要婉转说。
所以，各位可以对标我的表现，去准备面试的这个环节。/doge。开个玩笑而已。
简单就面试而言，你需要表现出以下三点：
态度积极&乐观：很多人简历上写着积极、乐观、开朗，却没有任何有力支撑点。你可以在闲聊中表示喜欢和朋友爬山，平日里有在健身、遇到某些人生问题保持乐观态度等。
巨大能力&潜力：有些深层次能力，可能某些面试官没有挖掘到，还有隐性的潜力等。这都需要你来主动展现（展现价值，才可以获得更好认可）。比如你可以表示自己在解决某个问题时体现了解决问题能力，自己的体系化认识（专业、认知等）、自己的日常思考（业务、技术等）等
渴望公司&团队：面试官有千万个应聘者选择，你也同样有千万个公司选择。你需要表现出你对该公司&团队的向往。文化的倾向，意味着你在团队的稳定性、以及适应性等，并不是无用的。比如你可以主动咨询目标公司&团队的愿景、业务等，并进行沟通与认同等。
而这其中，又可以展开很多。不过因为闲聊人生环节而被拒绝的小伙伴比较少，这里就不再赘述。
c.面试结果
过了两天，就收到原二级主管的电话。通知面试通过，面试官很是认可，并让我准备后续的P9面。
d.小结
虽然只是一轮面试，但是足足两个小时的狂轰滥炸，也算是干货满满。
3.P9面
其实面试前，我已经知道了大概的面试方向和问题。是的，有一位大佬真心带你，就是这么爽。囧
不过，P9面由于HC问题，一直卡着。我直到最后也没有真正接触与这位P9进行沟通，挺遗憾的。
这位P9大佬算是这些面试中最关心业务的P9大佬，所以我还是谈谈他的面试方向和问题，供大家参考。
当时的面试会有两个方向，一个是新零售业务（因为当时目标团队有这个痛点），另一个是业务稳定性。这里就谈谈后者。
其实聊到稳定性，大家都或多或少知道一些，比如最基本的高可用三剑客（限流、降级、熔断）。但是如果强调技术之外呢？或者说只是技术侧会不会太狭隘了？
这里简单谈一下，后续有机会，再专门整一个文档。
抛开技术，业务本身也有稳定性需求，信息技术在这里只是实现手段。我们可以通过时间线来分析：
事前：核心是预防。业务&产品上的预防手段，可以是在规则发布窗口添加影响面校验。技术上可以是高可用三剑客（涉及依赖分析，可以深入展开，体现技术造诣）。
事中：核心是监控。业务&产品上的监控手段，可以是现场数据大屏、业务指标监控等。技术上可以是各类基础监控等。技术设计上可以有幂等&重试，以及超时。甚至可以是冗余（数据库挂了，通过缓存提供继续查询能力）、N版本程序设计等。
事后：核心是兜底。业务&产品上的兜底手段，可以是人工兜底方案、业务妥协方案等。技术上可以是资源隔离，进而降低影响面。
至于故障发生后的事后复盘，那是必须的，这里不再提及。
PS：业务优先级 = 影响面 x 发生概率
三、总结
这次面试主要是P8面，问的粒度也比较大，使得发挥也比较完整。所以，我经过整理，直接按照面试核心模块进行拆分，进行了总结。
而大家比较关心的技术问题细节与HRG面试，在后面的两个部门面试，体现得比较多，到时候会管饱的。尤其到时候，就可以展现我面试横着走的JVM了。/doge