一篇很有价值的阿里面试经验

春哥叨叨

共 8164字,需浏览 17分钟

 ·

2022-02-20 20:44

在博客园看到一篇阿里面试经验,感觉内容有很多值得学习的地方,不仅适用于面试,也适用于述职或给其他人讲明白一件事情。

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起步。套用大佬的话,编码是基本要求。囧
那么从技术上拉开差距的第一块儿,就是设计能力。

这里说一些个人的粗浅认识,后续有机会,会展开的。
编码 -> 核心编码 -> 模块设计 -> 应用设计 -> 系统设计(多应用复杂系统)
模块设计 -> 应用设计 -> 系统设计,其实都是方案设计,只是处理的复杂度是不同的。软件工程的架构设计,本质上是为了处理,软件工程日益增高的复杂度。从这个角度,架构设计可以分为时空两个维度。空间上则类似于架构组成派,比如架构图。而时间上则类似于架构演变的规划。架构的时空维度是果,而架构决策派则是因。


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

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

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

  3. 再进一步就是自身的方案要有方法论支撑。要从方法论中找到实际问题解决,再从实际问题回归到方法论中。比如大到利用DDD解决业务领域划分、识别核心领域模型等,小到二八原则落地到缓存方案中。

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


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


3.主要的业务场景

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


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

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

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

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


这部分,作为面试项目的业务部分,需要提前准备。如果有大佬帮忙梳理,就超赞了。比如之前的二级主管花费了不少时间帮我整理业务,真的是十分感激。


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

浏览 47
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报