阿里面试经验分享：从被回绝到Offer，详解应聘阿里技术岗位注意事项_阿里社招可以问面试结果吗

本文是《谈谈应聘阿里全流程》的姊妹篇，《谈谈应聘阿里全流程》发布后，收到了很多读者的积极反馈，但其中也反映出读者普遍的困惑：清楚了应聘流程，该如何有针对性地做应聘准备呢？这个问题从正面并不好回答，那么，不妨逆向寻解：本文将详细介绍那些导致应聘者被回绝的系列因素，并基于这些因素有针对性地阐述应对方案；同时解读应聘准备和面试环节需要注意的事项。内容概要如下：

1. 前车之鉴：哪些因素容易导致应聘者被回绝
2. 知己知彼：如何结合自身特点和岗位要求有针对性地做应聘准备
3. 题海泛舟：如何刷题，刷题得来的知识点到底能起多大作用
4. 技术无涯：做一个有思考、有沉淀的技术人
5. 面试指南：面试前、中、后需注意的事项
6. 后记：推荐一本书

1. 哪些因素容易导致应聘者被回绝？

应聘如考试，却又不同于考试。考试至少可以通过回顾试卷知道自己哪里出错，并有针对性地订正，从而避免再犯同样的错误；然而应聘失败往往只能得到一个 “被回绝” 的结果，甚至是“石沉大海”，没有人会跟你解释原因。

关于回绝应聘者的原因，我与同为面试官的很多同事进行了探讨，总结得出了几个普遍的因素：基础差，项目经历简单，无思考，无沉淀，无亮点。

1.1 基础差

在应聘的过程中，基础考查是在 “一面” 中进行的，面试形式通常为 “电话面”。基础考查由浅入深，起初，面试官会根据岗位要求问一些技术相关的基础问题。当然，“基础” 二字的含义并不是简单，如果没有充分的准备和足够的积累，也是很容易挂掉的。根据我的面试经验，超过一半的应聘者在这个环节挂掉，表现特别差的应聘者可能会被面试官打上一个 “基础不扎实” 的标签记录在案，再次应聘阿里时，面试官会参考之前的面试记录，有这样的“差评”，成功率就很低了。

基础知识的考查有一个心照不宣的规则：回答正确不会加分，错误则会减分，某种意义上这是一个 “粗筛” 的过程。如下图所示，是一个 Java 工程师岗位的要求，可以看出，基础考查涉及的内容很广泛，“裸考” 并不可取。此外，基础考查的题目大都是常规的，网上有大量的面试 “刷题” 攻略可供参考，正是基于这个原因，对那些连基础问题都回答不好的应聘者，面试官通常会以 “基础差” 回绝掉。

业务平台事业部-大财务平台-技术专家/高级java工程师-杭州&上海

1.2 项目经历简单

所谓简单与复杂都是相对的，对于阿里、腾讯这种用户规模达十亿级的互联网企业，通常，工程师要面对的是大规模分布式环境中高并发、海量请求下的安全、稳定、高性能问题。为了应对这些问题，工程师不仅要有娴熟的业务研发技能，而且需要业务建模、架构设计、框架研发、技术攻关等能力。这些能力几乎不可能通过刷题、看书、培训获得，而是需要在实际的项目中不断地学习、实践、思考、总结才能逐渐形成。正是这个原因，在面试中，项目经历是必问内容，面试官据此可以评估你是否已经具备相应岗位所需的能力。

经常听到同为面试官的同事感叹：这个应聘者其它方面都挺好的，就是项目经历太简单了。这并非面试官有意 “装 X”，事实上，大多数应聘者过往的工作经历可能都是一些小公司的项目，或者大公司的小项目。这类项目的系统复杂度普遍较低，同时鲜有设计上的亮点，因此，在评估应聘者的工作经验时，这样的项目经历是不会加分的。

不过，有意向应聘阿里系（或者其它大型互联网公司）的读者也不必过分担心，毕竟面试是一个综合考量的过程，面试官不会仅仅因为项目经历简单就直接回绝应聘者。很多时候，项目经历简单并不是应聘者本身能力的问题，而在于机遇，优秀的设计、独具匠心的思考也可以通过简单的项目承载。

1.3 无思考

无思考可以说是工程师的 “大忌”，互联网行业不同于传统行业，一方面，技术变化非常快，不同领域技术之间的边界正逐渐模糊、走向融合，埋头搬砖而无思考的工程师将难以跟上节奏；另一方面，大型互联网公司时常会面临一些前所未有、无可参考的问题和场景，只能自力更生，这些年阿里打造了很多著名的开源项目，如 RocketMQ、Dubbo、Ant-design、arthas、Fastjson、Druid、Ice 等等，并成为国际顶级开源组织核心成员，这背后凝聚着大量工程师的思考和创新。

回归正题，在面试的时候，面试官通常会问一些“观点型”问题，这类问题一般是没有明确的答案的，主要看应聘者是否有自己的思考，比如，可以问应聘者对于一些常见的编程和软件工程理念的看法，比如 OOP、SOA、API、SPI，微服务等等，以考察应聘者平常对于这些问题是否有思考和总结。也可能是对于最近的一些技术热点的关注，等等。

对于这类问题，合格的面试官不会期望应聘者的回答与自己的观点一致，更不会同应聘者争论，而是尽量引导应聘者完整地表述自己的逻辑，了解其观点背后的内容，考察应聘者对于概念的理解和实践的程度，看看应聘者是否有比较严密的能够自圆其说的逻辑。

诚然，在判断应聘者是否属于“无思考类型” 时，面试官的主观意志是非常重要的因素，他很难做到绝对客观，也会出现误判，进而影响应聘者的面试结果。因此，作为应聘者在面试之前一定要做足功课，须知 “求其上者得其中”。

1.4 无沉淀

工程师在经历一系列项目实践的洗礼后，通常会形成自己的一套 “方法论”和 “最佳实践” ——具体而言，拿到一个新项目，在很短的时间内便能勾勒出一个大概的系统框架，进而结合应用场景进行细节填充。对于这样的工程师，我们通俗地称之为 “有沉淀的人” 。

在大、中型项目中，一名工程师通常只负责某个模块的设计和实现，这样的分工协作模式在提升效率的同时，也容易让人产生惰性，逐渐退化成 “螺丝钉”—— 只关注自己的“一亩三分地”，囿于局部，缺乏对项目全局的洞察；随着时间的推移，只会做自己擅长的，或者只被安排做擅长的。缘于这类因素，很多工程师虽然参与过很多项目，但趋于同质化，技术视野局限，给人一种 “没有沉淀” 的感觉。

回归实践，到底如何才能显得 “有沉淀” 呢？首先，要转变观念，一名优秀的工程师，即便只负责项目中的某个模块，也应保持对项目全局的好奇心并投入时间去琢磨，这样的项目经历才能助力于形成体系化的 “方法论” 和完整的“最佳实践”。

其次，要善于总结，将自己从实践中得来的经验经思考加工后 “持久化”，具体方式因人而异，个人比较推崇技术博客的形式。通过技术博客，用文字、图片记录实践经验，分享技术思考，日积月累，也就 “沉淀” 下来了。

1.5 无亮点

应聘者各方面都不错——基础较好、有思考、有沉淀、项目经验尚可，但没有特别突出的点，这是最令面试官纠结的情况。如果应聘者在各方面都不错的基础上能有一个亮点加持，通过面试要容易得多。

那么，通常哪些因素可以作为亮点呢？1.过往工作经验与所应聘岗位强相关；2.上家公司在业界有一定知名度；3.在所应聘岗位相关的领域有一定成果，如专利、论文、书籍等；4.教育背景良好 (一流学校，高学历)；5.英语口语水平优秀（阿里正在走向国际化，很多岗位涉及国际合作)；6.沟通表达能力特别好，性格好（自信、乐观、谦逊等）。

2. 题海泛舟：如何刷题？刷题得来的知识点到底能起多大作用？

在准备应聘的过程中，很多人都会刷题，网上也充斥着很多面试题攻略。那么，刷题真的有用吗？回答是肯定的，有用，只不过作用没那么大。既然没有很大作用，是不是可以不刷题呢？当然不可以，大牛除外。

2.1 为什么要刷题？

互联网公司的技术面试一般都是好几轮，阿里系通常是三轮，每一轮面试都有不同的侧重点。第一轮面试通常侧重于相关技术栈基础知识的考查，涉及面比较广，还有一个不成文的规则：面试官所提的问题，回答正确不加分，错误则减分。这并不奇怪，既然考查的是基础，默认应聘者是掌握的，没掌握自然是减分的。

为了平稳地通过技术初面，刷题还是很有必要的。一方面，通过刷题可以梳理自己的知识体系，查漏补缺；另一方面，可以快速地掌握一些知识点，比如你可能完全不了解 Redis，但通过刷题也可以在较短的时间内掌握一部分要点。

2.2 不要迷信刷题

道高一尺，魔高一丈。不要以为刷过题就万事大吉了，面试官也不是吃素的，很多时候，应聘者刷过的题，面试官也刷过，惊不惊喜？意不意外？刷题得来的知识点与实践经验总结出来的知识点还是有区别的，通过提问，面试官不难判断。一旦意识到应聘者 “有备而来”，面试官通常会停止一般性提问，而拿出自己收藏的问题集，或者直接问应聘是如何掌握某个知识点的，举几个例子：

例1:

面试官：工作中遇到过堆内存溢出的问题吗？ 
应聘者：遇到过。 
面试官：那你给我详细介绍一下你定位的过程吧。 
应聘者：....(刷题得来的知识，经不住细节追问的)

例2:

面试官：了解 jdk-1.7/1.8 中 HashMap 的区别吗？（挖坑） 
应聘者：了解的，jdk-1.7 采用的是数组加链表的结构，jdk-1.8 采用... 
面试官：为什么要采用红黑树呢？ 应聘者：可以加快检索速度，提升效率。 
面试官：效率如何评估，具体复杂度是怎样的？ 
应聘者：在链表中查询的时间复杂度是 O(n),如果转换成红黑树，时间复杂度降为 O(lgn)。 
面试官：这个 O(lgn) 是怎么算出来的，能解释一下吗？ 应聘者：...

鉴于上述情况，即便是刷题，也一定要认真刷，刷出水平，做到知其然且知其所以然。当你达到这种水平，知识点是否来自刷题也就没那么重要了。

3. 面试指南：面试前、中、后需注意的事项

面试并非单纯的知识点问答，它也是一场交流，面试官通过提问考查应聘者是否符合岗位要求，应聘者也可以通过提问了解公司的一些情况，某种程度上，这是一个双向选择的过程。对于应聘者，面试有一些事项需要注意，它们会影响面试官对你的判断，进而影响面试结果。

3.1 面试前的注意事项

时间约定： 

每一轮面试，面试官都会通过电话与应聘者约定面试时间，在接到面试官电话时，不要紧张，如果自己尚未准备好面试，或者时间不方便，可以将时间约靠后一点，留下足够的时间缓冲。

基础复习： 

基础考查在 “一面” 进行，考查面通常是比较广的，切勿 “裸考”。应聘者可以根据岗位要求列一个复习提纲，然后有针对性地查漏补缺，同时可以参考网上的面试 “刷题” 攻略，进行 “恶补”。但是要注意，即便是 “刷题” 也要 “刷” 出水平，知其然且知其所以然。在我看来，“刷题” 攻略提供的是知识点的集合，是领域知识的精华，完全可以作为一个复习提纲，据此深入了解知识点背后的原理，思考、总结，形成自己的理解。

项目梳理： 

对于那些写在简历上的项目经验，一定要提前整理好，确保面试时能有条理、重点突出地介绍。参考以下原则：1.从整体到局部，先介绍项目系统架构，再介绍局部（这一点很重要，如果是现场面试，可能会让你画出系统架构图）；2.重难点突出，项目所采用的优秀设计，遇到的困难及解决方法；3.重要指标参数明确，如 QPS、DAU 等；4.提前试讲，让自己的同事、朋友提提建议，力求完善。

阅读与思考： 

工程师并不意味着整天埋头写代码，也有自己的业余爱好和兴趣点，面试官通常会通过两个问题来观察应聘者的学习方式、兴趣和习惯：1.最近有看什么书吗？如果有会让你介绍一下印象深刻的章节，并谈谈自己的看法；2.工作之余都做些什么？一个技术狂的业余生活也很有可能和技术有很大的关系，比如做些开源的软件，DIY一些设备等等。

最差的情况是：最近没看书，业余时间没干啥，这个话题也就没法继续了。建议应聘者提前准备一下，阅读几本书（不局限于技术相关书籍），写点自己的思考，最好能够保持阅读的习惯，不是为了面试，而是为了让自己不要太无趣（这句话也许会冒犯到你，但并非我的本意，请见谅）。

关心的问题： 

面试过程中，通常会有一个应聘者提问的环节，应聘者可以向面试官问一些自己感兴趣的问题。建议提前想好感兴趣的问题，不要浪费提问的机会，比如福利待遇、加班情况、团队氛围、个人成长等，都可以问，不必担心什么禁忌。

3.2 面试中的注意事项

如果面试前做好了充分准备，面试过程会顺利很多，但还是有一些需要注意的问题。

为什么要换工作

没有无缘无故的离职，既然应聘者选择离职，一定有一个核心原因，这通常也是面试官感兴趣的。大多数情况下，导致离职的原因是令人不悦的，甚至是糟心的。如果面对的是朋友，你可以尽情地吐槽、宣泄；但是，当你面对的是面试官时，请收起你的负面情绪，心平气和地叙述。离职的真正原因只有你自己最清楚，至于要不要和盘托出，需要你慎重考虑，笔者并不是鼓励说谎，只是建议应聘者把握好一个度，“直言有讳”。

知识盲点

即使应聘者做了充分的准备，仍然可能 “万有一失”。如果面试官的问题完全不在自己的知识域内，毫无思路可言，就不要勉为其难了，不妨直接如实回应。通常，面试官也会根据应聘者回答问题的情况调整提问方向，避免就应聘者不知道的领域提问，毕竟认知型的问题不是能力决定的，而是经历决定的。

开放性问题

有些面试官可能会问一些开放性问题，这类问题一般是没有明确答案的，比如对 DDD、ServerLess 的看法，考察应聘者对于一些设计思想、热门技术等是否有思考和总结。

遇到这类问题，应聘者无需过度紧张，面试官不会期望你的回答与自己的观点一致，更多的是考察应聘者对于概念的理解和实践的程度，看看应聘者是否有比较严密的能够自圆其说的逻辑。鉴于此，不妨先整理一下思路，如果是电话面试，甚至可以拿出纸笔简单地拟定要点，以便更有条理地回答。

思路卡壳

算法题并不是算法岗的专利，很多面试官喜欢在面试的最后问几个算法题（笔者也有这个 “不良” 习惯）。算法题通常具有以下的 “题效”：

• 应聘者完全不知道如何解决，思路卡壳，这时候一定要冷静，不妨先试试 “暴力解法”，而后再去想复杂的、效率高的解法，实在想不出，至少还有个兜底的；
• 应聘者大概知道怎么解决，有思路，但是想不出具体的解法。在过往的面试中，我发现很多应聘者就 “杵” 在那里转着眼睛思考，实在看不下去了，我会提醒他们——拿出纸笔"划一划"，不要凭空想。建议应聘者，在面试算法题的时候，准备好纸笔，不要一紧张啥都忘了。

3.3 面试后的注意事项

不要急于问面试结果

在面试结束后，尽量不要急于向面试官询问面试的结果，没有什么意义。其一，面试官通常是不会直接告诉你结果的，避免违规之嫌；其二，根据面试回答问题的情况，应聘者完全可以大致预计结果。

不妨听听面试官的建议

如果是电话面试，在面试结束后，不妨向面试官寻求一些 ”建议“——这其中隐含了面试官对你的评价，特别是在他看来你有哪些不足需要完善，这些建议通常是相对客观的，对你提升自己也许会有指导作用。对于应聘者，不妨谦逊一点，把每一次面试都当成一次 ”客观看待自己“ 的机会，知不足而后勇。

关注自己的应聘进展

如果应聘者是通过 “内推” 应聘阿里，那么，可以向推荐人询问应聘进展（当应聘者的应聘状态（简历评估中、简历评估通过、第一轮面试中、...、待发 offer、...、已入职）发生变化，推荐人会收到邮件通知，此外，推荐人也可以直接查看应聘进展。

准备下一轮面试

通过推荐人可以准确地获取应聘进展，如果顺利，应抓紧时间投入到下一轮面试的准备中。为什么要强调准备下一轮面试呢？原因如是：第一轮电话面试通过后，第二轮面试通常不是电话面，一般分为两种情况，其一，如果应聘者在岗位所在的城市，则会安排现场面试；其二，如果应聘者不在岗位所在城市，可能通过视频面试；其三，如果应聘者定级（应聘岗位的职级）较高，不论应聘者是否在岗位所在城市，都会安排现场面试。

4. 技术无涯：做一个有思考、有沉淀的技术人

我曾经的主管跟我说过一句话：一个人获得晋升，不是也不应该是他在原职级优秀地完成了本职工作，而是因为他已经具备了更高职级所需的能力。

这句话令我至今印象深刻，作为工程师，不管当前处于什么技术层次，都不要满足于做好本职工作，永远保持向上进取，多思考、总结、沉淀，方能取得突破。

4.1 技术掌握的三个层次

对于技术人才，通常企业的要求可以归为四点：技术深度、技术视野、技术见解、技术判断。而技术人对技术掌握的程度则可划分为三个层次：

简单解释一下：

• “已经掌握的技术”：这一层指的是那些在工作中经常使用的、已熟练掌握的技术。
• “了解但尚未掌握的技术”：就像我们经常讨论的 AI、VR 等技术，我们知道这些技术的存在，甚至还读过相关书籍，运行过几个 demo，大概知道它们能解决什么问题。但是，我们并不会应用。
• “技术盲区”：完全不知道的技术。比如，对于一个具体的问题，可能还有很多种更好的解决方案，但是我们不知道。

4.2 技术深度和技术视野

技术深度和技术视野与我们掌握技术的层次密切相关。如下图所示：

• 技术深度：基于目前工作所涉及的技术栈，你已经熟练掌握的技术，就是你目前的技术深度；
• 技术视野：了解但未掌握的技术，就是你的技术视野。虽然你没有深入地探究过，缺乏实践经验，但你知道它的存在，了解它的基本原理、性能以及可以解决的问题。

作为一名技术人，深度和视野可谓立身之本。技术深度可以让我们避免“踩坑”，得到高质量的结果；技术视野可以让我们找到更好的解决方案。

提升技术深度和技术视野，需要我们不断地扩展上面两个层次。具体而言，一方面，通过实践逐步的掌握你所了解的技术，吃透它；另一方面，通过学习逐步了解更多现在还不了解的技术，扩展自己的知识面。直观来看，如下图所示：

4.3 技术见解和技术判断

上一节讲了技术深度和技术视野，某种程度上还属于 “战术” 层面，而本节要介绍的技术见解和判断，则属于 “战略” 层面。

见解即看法，技术见解是对技术的理解和看法，本质上是技术人的思维模型，具体而言，一个技术人如何做技术规划、技术选型就可以归为技术见解。

技术判断则是对技术的选择，这种选择是在充分评估当前技术和未来技术发展方向后作出的。技术判断是技术见解进一步深化的结果。技术见解和技术判断可以让我们把握好技术趋势，避免方向性的问题。

四个技术的关系

凡事不可一蹴而就，没有足够深度和视野，谈何技术见解和判断？关于技术深度、视野、见解和判断之间的关系，可以用下图来直观描述：

对于技术人，技术深度和视野是基础；基于此，可以沉淀为技术见解；基于技术见解做出技术判断；通过在实践中检验技术判断的正确性，进一步对技术见解进行优化，形成一个“闭环”。在技术进阶的过程中，没有“银弹”：技术深度源自实践，技术视野源自学习，技术见解源自思考、总结，技术判断则是基于前面三者进一步深化的结果。

“我们为勇敢的尝试鼓掌，但只为结果买单”——这是阿里内部的一句“名言”。“拿结果” 可谓技术人最核心的使命，鉴于此，上面的四大要素最终的服务对象——结果，即技术项目高质量落地。

4.4 技术人如何保持竞争力

关于保持竞争力，个人认为因人而异：对于工作年限较短的技术人，重点应放在增加技术深度和扩展技术视野方面；对于已经有一定经验（三年以上）的技术人，应多思考、总结，形成技术见解，并不断地在实践中优化，强化技术判断能力。

从可操作性角度来讲，技术深度和技术视野是较为直观的，通过学习、实践便可不断地取得进步。但是，技术见解和技术判断却相对抽象，或者说 “虚幻”，它们是基于丰富的经验思考、总结的产物，是一种难以量化的能力。上文中曾提及，技术深度和技术视野属于 “战术” 层面，而技术见解和技术判断则属于 “战略” 层面。没有 “战术” ，“战略” 便没有根基，无法落地；忽视 “战略”，迷信 “战术” 便会囿于局部，无法把握技术走向，难有质的提升。

5. 推荐一本书

最近读了一本书——《服务端开发：技术、方法与实用解决方案》，大为受用，在此推荐给大家。该书作者曾获得阿里第二届技术讲师课程大赛年度冠军（由阿里 CPO 和 CSDN CEO 共同颁奖），在阿里和蚂蚁内部所授技术课程口碑甚好。全书分 14 章，约 30 万字，正文 373 页，共 389 页，由机械工业出版社出版发行。内容分为上下两篇。上篇 1～6 章，主题为技术和方法；下篇 7～14章，主题为解决方案。书中列举了大量实用案例，为了便于读者理解，作者还绘制了超过 200 幅插图，可谓图文并茂。

5.1 读者对象

这本书体系化地解读了服务端开发的方方面面，特别提供了针对高并发、高可用、高性能、数据一致性等重难点的行业经典解决方案，极具价值。

• IT 从业人员：服务端开发工程师、客户端开发工程师、产品经理、测试开发工程师等。
• 高校学生：计算机、软件、自动化、电气、通信等专业有志于进入 IT 行业的在校学生。
• 求职面试：不同于一般的“面试宝典”仅仅侧重对某种语言、框架、中间件等进行解读，本书立足于服务端开发的全局视角，体系化解读服务端开发的大厂规范流程和重难点，面试必备。

5.2 该书特色

无论技术如何演进，其背后的方法往往大同小异，经典解决方案历久弥新。因此，掌握方法和实用解决方案尤为必要。不同于一般的 IT 技术书籍，这本书不局限于任何一种具体的编程语言、框架、容器、中间件或编程思想，而是致力于全景式、体系化地解读服务端开发的流程和重难点。

该书共 14 章，内容从逻辑上可以分为两大部分。

第一部分为第 1～6 章，主题是技术和方法。首先概述服务端开发的职责、技术栈、核心流程和进阶路径，然后从需求分析、抽象建模、系统设计、数据设计、非功能性设计 5 个方面逐一展开，结合案例深入解读服务端开发的实操方法和重难点，为读者清晰呈现服务端开发的全景图。通过学习本篇内容，读者可以快速、体系化地掌握服务端开发的相关知识和方法。

第二部分为第 7～14 章，主题是解决方案。针对高并发、高可用、高性能、缓存、幂等、数据一致性等服务端开发的典型问题，结合业务场景进行系统性分析并给出解决方案。此外，就接口设计、日志打印、异常处理、代码编写、代码注释等实施细节给出行业案例和规范。本篇内容如同一本服务端开发问题手册，当读者在实践中遇到问题时，可以从中查找解决方案。

目前，本书已经在京东、淘宝、当当、拼多多等电商平台发售。在电商 APP 搜索关键词 “服务端开发”、“服务端开发技术”，即可搜索到该书。