如何在阿里技术面试中脱颖而出？（内部资料）

招聘是团队管理者工作中的重要一环。本文会结合自己亲身经历以及接受的招聘培训，综合分析怎么找到我们要的人，也希望可以通过招聘这面镜子照亮自己，怎样成为一个更好的工程师。

招聘的目的

当今社会，技术已经成为影响商业成功的关键因素，工程师成为了这些公司最宝贵的财富，没有优秀的人组成团队来完成商业目标，公司根本不可能有今天的成就。所以招聘，就是选择最优秀的人。

招什么样的人？

招优秀的人显然是一个很模糊的概念，我们来度量的时候，我个人认为三个因素是最关键的：

技能

工作项目经验，以及解决疑难问题的能力，毕竟招来的人首先必须很好的完成工作，这是最基本的要求，注意，是很好的完成，不是仅仅完成。

潜力

这个概念看起来比较模糊，其实还是比较容易评价的，对计算机相关的专业的知识体系是不是完整，基础是不是扎实，平常是不是喜欢钻研，对这个世界充满好奇心，这几年走下来，沉淀的速度如何，都是判断一个人的潜力的方式，注意我们看潜力主要是基于候选人的之前的成长经历实事求是来看，过去的优秀经历才能给未来背书。潜力和技能的重要性一样重要，我们不能只看眼前，团队是需要不断发展和前进的，所以我们招人应该面向未来。

软实力

软实力这里其实包含了性格，执行力，领导力等方方面面，它代表了候选人是否能快速融入团队，拿到结果，带领团队攻城拔寨，激励和影响身边的人变得更加优秀等等，软实力一般HR肯定会考察，虽然技术面不会特别去关注，但是从面试的过程中可以看出候选人的沟通能力，以及性格相关的特点，也值得我们注意。

说了这么多，其实在招人上有一个对比的标杆，就是你招的人是不是比团队中同一等级中50%的同学优秀，如果你觉得没有他们优秀，那不用纠结，这个候选人不要了，团队必须不停加入更好的同学，才能变得更加强大。

面试的方法

这里结合之前的培训以及自己的真实经历，讲解面试的一些方法。

面试不要做的事

问一些知道性的问题比如问知不知道这个API干什么的，怎么调用，这个命令怎么用的，知道性的知识，google一下或者认真看下文档就应该知道。
问一些特别复杂的问题比如问一个特别复杂的算法，问一个很抽象的大问题，短时间内很难给予回答。
问一些假设性的问题假设你参与了这个项目，你觉得哪几个地方需要优化。

之所以说这些问题不应该问，我认为主要是因为这些很难考察到面试者的真实能力，45分钟的时间本来就很短，有些问题有可能比较偏，有些问题又过于庞大没法一下子描述特别清楚，还有一些问题缺乏上下文，让人摸不到头脑，所以尽量避免这么问问题，另外把握一个重要原则，不要在面试中试图证明别人不如自己，毫无意义，人无完人，总有覆盖不到的地方，按照这个规则招聘，会错过很多优秀的人才。

面试应该做的事

问已经发生的事情

比如面试移动开发者，面试官应该认真看下其做过的App，具体的工作是什么，准备一些相关的问题，这里就可以看出来之前工作中的积累是什么，有多深。

问题解决思路

针对项目经验和一些学习的经验上面，应该问拿到问题以后解决思路是什么，在什么场景下为什么这么做，这里根据面试者的方案，分析的方法论，就可以大致了解面试者是否聪明，知识面是不是够广，遇到问题时会不会举一反三。

具体可以举个简单的例子，很多同学说自己做过架构，然后都会讲自己做了一个解耦和分层的框架，其实这类框架iOS很多，外部github上就有各种方案。在阿里内部手淘早先做的bundle拆分时沉淀的容器规则，天猫开源出去的beeHive，闲鱼内部的Xframework，抑或是服务端的spring mvc，其实都实现了IoC，但实现和思路上都有一些差异，到底为什么这么做，其实是有区别的，这里面就可以看出知识广度，总结和思辩能力，在关键路径上的技术判断。

又比如说，我们总在强调性能稳定性怎么做，业界也有很多方案，到底哪个方案更好呢？答案没有绝对的对错，取决于某个时间点和场景下哪个问题是最核心的突破点，而你的选择标准和落地的技术方案是不是合理（考虑成本，收益，以及后续的风险是什么）。一般来讲，我们更倾向于用系统化的思维看待一个问题，也就是说，相比根据人的经验去识别性能瓶颈，我们更希望能通过自动化，智能化，数据化的方式去解决问题。

少问多听

一般刚开始做面试官的同学很喜欢以问为主，但因为大家的知识体系不太一样，成长环境也不同，直接这么问起来很难就找到面试者的优点，所以尽量让应试者自己陈述，然后以学习和交流的心态针对陈述中存疑的地方再进行发问，会更容易让应试者放松，也更容易让应试者更全面的表达自己。另外，问的差不多的时候，结尾的时候可以补充一句：您觉得刚才的面试中还有哪些我没问到的，您想再补充一下的内容？末了，再问下：我的问题问完了，您有什么想要问我的吗？

知道了应该怎么做，那具体的提问方法有没有什么技巧呢？在招聘中有一个重要的STAR原则，可以跟大家分享。

STAR原则

处境(situation)

在什么样的环境下

任务(task)

接到了什么样的任务

行动(action)

然后具体怎么落地的

结果(result)

拿到了什么结果

我们尽量问清楚对方在什么样的环境下接到这个任务，接到以后是做了什么事情，最后的结果是什么样子的。乍一听，感觉，这不是套路嘛，是不是知道这个原则的人，只要按照这四点编故事，就能通过面试了？当然不是，在叙述过程中，我们应该分辨出STAR中的真假，那下面就举一些例子。

假的STAR

描述含糊不清

比如，我用这个方案解决了这个问题，效果很好，得到了大家的一致好评。注意，效果好是哪里好，有什么度量的标准？一致好评的体现是在具体KPI还是比如团队有个什么奖励之类的。

只表达态度和看法

我觉得线上稳定性非常重要，应该重点解决和持续跟进。如果只有这一句话，没有后面具体认为重要的解决方案的话，这部分的经验难以令人信服。

假设式描述

如果我来做这件事情，我会1234怎么怎么样。前面其实面试应该问的问题里面有提到，我们本身就不应该问假设性的问题，那作为面试者，假设没做过的事情，如果只是看思路还好，但是如果说的天花乱坠，这个时候要警惕了，毕竟说和做之前的差异是很大的。对于假设的事情，面试官是没法评估具体效果的，因为它不像过去已有的项目和工作内容，是有明显结果的，如果对过去结果存疑，后续也可以背调了解具体的情况。

针对假的STAR，我们要甄别分辨出来，引导其表达出真正的情况。

鉴别方式

更多的关心What/How/Wh

做了什么事情，具体做的方案1234几步，为什么要这么做，比如图片的优化，最早肯定什么都没有，后续加cache，cache策略又可以升级，包括cache本身的算法以及多级cache的实现，图片尺寸上面后来有做了什么裁切之类的，图片格式上面后续又做了优化等等

每个阶段不太一样，关注的重点也不一样，刨根问题问一问，会了解是不是真的做过这件事情，另外有一些可能项目做得很久说很多东西忘了，这里我分享一个观点，之前看过一句话，招聘的人中有一种人是比较好的，他总能比较清楚的记住过往项目当中的重点，这样的人在经验沉淀的过程中肯定更快一些，当然这样的同学肯定得归结在聪明一类的人了，当然能记住也说明他可能喜欢总结和回顾，平常的学习习惯应该也比较好。

细节！细节！细节！

很多关键节点的细节很重要，比如网络库的优化。如果你是一个iOS开发，一般都会知道iOS的网络协议优化常采用拦截NSURLProtocol的方式进行，然后针对传统的https协议我们会将其替换成为spdy协议或者http2协议，过程中还有一些httpdns等的优化。但如果你今天希望招聘一个有这部分网络优化经验的同学，怎么判断这个同学有实操的经验呢？你可以让他说细节上面的很多事情，比如说URLProtocol拦截request以后，针对不同的case的降级策略是什么，选择依据是什么？当时遇到了什么其他的坑没有？你自己的做法有什么缺陷？

又比如Weex的实现上面，整个渲染的流程到底是怎样的，渲染部分还有什么优化空间吗？或者说这个方案本身做了哪方面的优化？它的配套工程体系上的问题是什么，你遇到以后是怎么解决掉的，这些在了解大概思路后，都可以往深入再问一下细节的部分，认真研读以及修改过代码的同学，肯定是答得出来的。

其他Tips

你在面试别人，别人也在选择你

面试是双向的，面试官是一个团队对外的门面，不要迟到，提问和交流要尊重面试者，让面试者感受到我们的真诚。

为未来招聘而不是现在

我们永远应该为未来招聘，因为招聘的人入职也是发生在未来，不能立刻就解决你眼前的问题，所以我们招聘的时候也放长远一点，招为团队未来更有好处的人。

面试是一面镜子

以人为镜，优秀的面试者给我们能带来新的思路和新的方法，而差强人意的面试者则提高我们看人的能力，为后续的提升招聘效率找到更正确的人打下基础。

技术人如何不断成长？

招聘，培训，人才选拔晋升，我认为评价标准和方法都应该有比较多的重合的部分，我们从刚才的面试经验中，反思下，如果现在是我们去找工作，这个市场或者团队更需要什么样的人？

经验丰富，知识体系完整

经验能解决实际的问题，另外知识体系可以让你在遇到新的问题时举一反三，当然大公司和小公司要求的知识体系又不太一样，大公司更偏向一专多能的T型人才，小公司更喜欢全栈，所以到底要成为什么样的人，跟你的职业规划很有关系，是想在大公司成就一番事业，还是出去闯荡，那你点的技能树肯定是不一样的。到底应该怎么做，我自己的经验是，找到身边的标杆，向更优秀的同学学习，在阿里当然非常优秀的专业人才也好，架构师也好，都非常多，所以标杆应该也好找，业界当然也有很多成功的人，有了标杆，就努力向上吧。

保持良好的习惯，不忘总结和提升