本文是《谈谈应聘阿里全流程》的姊妹篇,《谈谈应聘阿里全流程》发布后,收到了很多读者的积极反馈,但其中也反映出读者普遍的困惑:清楚了应聘流程,该如何有针对性地做应聘准备呢?这个问题从正面并不好回答,那么,不妨逆向寻解:本文将详细介绍那些导致应聘者被回绝的系列因素,并基于这些因素有针对性地阐述应对方案;同时解读应聘准备和面试环节需要注意的事项。内容概要如下:
应聘如考试,却又不同于考试。考试至少可以通过回顾试卷知道自己哪里出错,并有针对性地订正,从而避免再犯同样的错误;然而应聘失败往往只能得到一个 “被回绝” 的结果,甚至是“石沉大海”,没有人会跟你解释原因。
关于回绝应聘者的原因,我与同为面试官的很多同事进行了探讨,总结得出了几个普遍的因素:基础差,项目经历简单,无思考,无沉淀,无亮点。
在应聘的过程中,基础考查是在 “一面” 中进行的,面试形式通常为 “电话面”。基础考查由浅入深,起初,面试官会根据岗位要求问一些技术相关的基础问题。当然,“基础” 二字的含义并不是简单,如果没有充分的准备和足够的积累,也是很容易挂掉的。根据我的面试经验,超过一半的应聘者在这个环节挂掉,表现特别差的应聘者可能会被面试官打上一个 “基础不扎实” 的标签记录在案,再次应聘阿里时,面试官会参考之前的面试记录,有这样的“差评”,成功率就很低了。
基础知识的考查有一个心照不宣的规则:回答正确不会加分,错误则会减分,某种意义上这是一个 “粗筛” 的过程。如下图所示,是一个 Java 工程师岗位的要求,可以看出,基础考查涉及的内容很广泛,“裸考” 并不可取。此外,基础考查的题目大都是常规的,网上有大量的面试 “刷题” 攻略可供参考,正是基于这个原因,对那些连基础问题都回答不好的应聘者,面试官通常会以 “基础差” 回绝掉。
业务平台事业部-大财务平台-技术专家/高级java工程师-杭州&上海
所谓简单与复杂都是相对的,对于阿里、腾讯这种用户规模达十亿级的互联网企业,通常,工程师要面对的是大规模分布式环境中高并发、海量请求下的安全、稳定、高性能问题。为了应对这些问题,工程师不仅要有娴熟的业务研发技能,而且需要业务建模、架构设计、框架研发、技术攻关等能力。这些能力几乎不可能通过刷题、看书、培训获得,而是需要在实际的项目中不断地学习、实践、思考、总结才能逐渐形成。正是这个原因,在面试中,项目经历是必问内容,面试官据此可以评估你是否已经具备相应岗位所需的能力。
经常听到同为面试官的同事感叹:这个应聘者其它方面都挺好的,就是项目经历太简单了。这并非面试官有意 “装 X”,事实上,大多数应聘者过往的工作经历可能都是一些小公司的项目,或者大公司的小项目。这类项目的系统复杂度普遍较低,同时鲜有设计上的亮点,因此,在评估应聘者的工作经验时,这样的项目经历是不会加分的。
不过,有意向应聘阿里系(或者其它大型互联网公司)的读者也不必过分担心,毕竟面试是一个综合考量的过程,面试官不会仅仅因为项目经历简单就直接回绝应聘者。很多时候,项目经历简单并不是应聘者本身能力的问题,而在于机遇,优秀的设计、独具匠心的思考也可以通过简单的项目承载。
无思考可以说是工程师的 “大忌”,互联网行业不同于传统行业,一方面,技术变化非常快,不同领域技术之间的边界正逐渐模糊、走向融合,埋头搬砖而无思考的工程师将难以跟上节奏;另一方面,大型互联网公司时常会面临一些前所未有、无可参考的问题和场景,只能自力更生,这些年阿里打造了很多著名的开源项目,如 RocketMQ、Dubbo、Ant-design、arthas、Fastjson、Druid、Ice 等等,并成为国际顶级开源组织核心成员,这背后凝聚着大量工程师的思考和创新。
回归正题,在面试的时候,面试官通常会问一些“观点型”问题,这类问题一般是没有明确的答案的,主要看应聘者是否有自己的思考,比如,可以问应聘者对于一些常见的编程和软件工程理念的看法,比如 OOP、SOA、API、SPI,微服务等等,以考察应聘者平常对于这些问题是否有思考和总结。也可能是对于最近的一些技术热点的关注,等等。
对于这类问题,合格的面试官不会期望应聘者的回答与自己的观点一致,更不会同应聘者争论,而是尽量引导应聘者完整地表述自己的逻辑,了解其观点背后的内容,考察应聘者对于概念的理解和实践的程度,看看应聘者是否有比较严密的能够自圆其说的逻辑。
诚然,在判断应聘者是否属于“无思考类型” 时,面试官的主观意志是非常重要的因素,他很难做到绝对客观,也会出现误判,进而影响应聘者的面试结果。因此,作为应聘者在面试之前一定要做足功课,须知 “求其上者得其中”。
工程师在经历一系列项目实践的洗礼后,通常会形成自己的一套 “方法论”和 “最佳实践” ——具体而言,拿到一个新项目,在很短的时间内便能勾勒出一个大概的系统框架,进而结合应用场景进行细节填充。对于这样的工程师,我们通俗地称之为 “有沉淀的人” 。
在大、中型项目中,一名工程师通常只负责某个模块的设计和实现,这样的分工协作模式在提升效率的同时,也容易让人产生惰性,逐渐退化成 “螺丝钉”—— 只关注自己的“一亩三分地”,囿于局部,缺乏对项目全局的洞察;随着时间的推移,只会做自己擅长的,或者只被安排做擅长的。缘于这类因素,很多工程师虽然参与过很多项目,但趋于同质化,技术视野局限,给人一种 “没有沉淀” 的感觉。
回归实践,到底如何才能显得 “有沉淀” 呢?首先,要转变观念,一名优秀的工程师,即便只负责项目中的某个模块,也应保持对项目全局的好奇心并投入时间去琢磨,这样的项目经历才能助力于形成体系化的 “方法论” 和完整的“最佳实践”。
其次,要善于总结,将自己从实践中得来的经验经思考加工后 “持久化”,具体方式因人而异,个人比较推崇技术博客的形式。通过技术博客,用文字、图片记录实践经验,分享技术思考,日积月累,也就 “沉淀” 下来了。
应聘者各方面都不错——基础较好、有思考、有沉淀、项目经验尚可,但没有特别突出的点,这是最令面试官纠结的情况。如果应聘者在各方面都不错的基础上能有一个亮点加持,通过面试要容易得多。
那么,通常哪些因素可以作为亮点呢?1.过往工作经验与所应聘岗位强相关;2.上家公司在业界有一定知名度;3.在所应聘岗位相关的领域有一定成果,如专利、论文、书籍等;4.教育背景良好 (一流学校,高学历);5.英语口语水平优秀(阿里正在走向国际化,很多岗位涉及国际合作);6.沟通表达能力特别好,性格好(自信、乐观、谦逊等)。
在准备应聘的过程中,很多人都会刷题,网上也充斥着很多面试题攻略。那么,刷题真的有用吗?回答是肯定的,有用,只不过作用没那么大。既然没有很大作用,是不是可以不刷题呢?当然不可以,大牛除外。
互联网公司的技术面试一般都是好几轮,阿里系通常是三轮,每一轮面试都有不同的侧重点。第一轮面试通常侧重于相关技术栈基础知识的考查,涉及面比较广,还有一个不成文的规则:面试官所提的问题,回答正确不加分,错误则减分。这并不奇怪,既然考查的是基础,默认应聘者是掌握的,没掌握自然是减分的。
为了平稳地通过技术初面,刷题还是很有必要的。一方面,通过刷题可以梳理自己的知识体系,查漏补缺;另一方面,可以快速地掌握一些知识点,比如你可能完全不了解 Redis,但通过刷题也可以在较短的时间内掌握一部分要点。
道高一尺,魔高一丈。不要以为刷过题就万事大吉了,面试官也不是吃素的,很多时候,应聘者刷过的题,面试官也刷过,惊不惊喜?意不意外?刷题得来的知识点与实践经验总结出来的知识点还是有区别的,通过提问,面试官不难判断。一旦意识到应聘者 “有备而来”,面试官通常会停止一般性提问,而拿出自己收藏的问题集,或者直接问应聘是如何掌握某个知识点的,举几个例子:
例1:
面试官:工作中遇到过堆内存溢出的问题吗? 应聘者:遇到过。 面试官:那你给我详细介绍一下你定位的过程吧。 应聘者:....(刷题得来的知识,经不住细节追问的)
例2:
面试官:了解 jdk-1.7/1.8 中 HashMap 的区别吗?(挖坑) 应聘者:了解的,jdk-1.7 采用的是数组加链表的结构,jdk-1.8 采用... 面试官:为什么要采用红黑树呢? 应聘者:可以加快检索速度,提升效率。 面试官:效率如何评估,具体复杂度是怎样的? 应聘者:在链表中查询的时间复杂度是 O(n),如果转换成红黑树,时间复杂度降为 O(lgn)。 面试官:这个 O(lgn) 是怎么算出来的,能解释一下吗? 应聘者:...
鉴于上述情况,即便是刷题,也一定要认真刷,刷出水平,做到知其然且知其所以然。当你达到这种水平,知识点是否来自刷题也就没那么重要了。
面试并非单纯的知识点问答,它也是一场交流,面试官通过提问考查应聘者是否符合岗位要求,应聘者也可以通过提问了解公司的一些情况,某种程度上,这是一个双向选择的过程。对于应聘者,面试有一些事项需要注意,它们会影响面试官对你的判断,进而影响面试结果。
时间约定:
每一轮面试,面试官都会通过电话与应聘者约定面试时间,在接到面试官电话时,不要紧张,如果自己尚未准备好面试,或者时间不方便,可以将时间约靠后一点,留下足够的时间缓冲。
基础复习:
基础考查在 “一面” 进行,考查面通常是比较广的,切勿 “裸考”。应聘者可以根据岗位要求列一个复习提纲,然后有针对性地查漏补缺,同时可以参考网上的面试 “刷题” 攻略,进行 “恶补”。但是要注意,即便是 “刷题” 也要 “刷” 出水平,知其然且知其所以然。在我看来,“刷题” 攻略提供的是知识点的集合,是领域知识的精华,完全可以作为一个复习提纲,据此深入了解知识点背后的原理,思考、总结,形成自己的理解。
项目梳理:
对于那些写在简历上的项目经验,一定要提前整理好,确保面试时能有条理、重点突出地介绍。参考以下原则:1.从整体到局部,先介绍项目系统架构,再介绍局部(这一点很重要,如果是现场面试,可能会让你画出系统架构图);2.重难点突出,项目所采用的优秀设计,遇到的困难及解决方法;3.重要指标参数明确,如 QPS、DAU 等;4.提前试讲,让自己的同事、朋友提提建议,力求完善。
阅读与思考:
工程师并不意味着整天埋头写代码,也有自己的业余爱好和兴趣点,面试官通常会通过两个问题来观察应聘者的学习方式、兴趣和习惯:1.最近有看什么书吗?如果有会让你介绍一下印象深刻的章节,并谈谈自己的看法;2.工作之余都做些什么?一个技术狂的业余生活也很有可能和技术有很大的关系,比如做些开源的软件,DIY一些设备等等。
最差的情况是:最近没看书,业余时间没干啥,这个话题也就没法继续了。建议应聘者提前准备一下,阅读几本书(不局限于技术相关书籍),写点自己的思考,最好能够保持阅读的习惯,不是为了面试,而是为了让自己不要太无趣(这句话也许会冒犯到你,但并非我的本意,请见谅)。
关心的问题:
面试过程中,通常会有一个应聘者提问的环节,应聘者可以向面试官问一些自己感兴趣的问题。建议提前想好感兴趣的问题,不要浪费提问的机会,比如福利待遇、加班情况、团队氛围、个人成长等,都可以问,不必担心什么禁忌。
如果面试前做好了充分准备,面试过程会顺利很多,但还是有一些需要注意的问题。
为什么要换工作
没有无缘无故的离职,既然应聘者选择离职,一定有一个核心原因,这通常也是面试官感兴趣的。大多数情况下,导致离职的原因是令人不悦的,甚至是糟心的。如果面对的是朋友,你可以尽情地吐槽、宣泄;但是,当你面对的是面试官时,请收起你的负面情绪,心平气和地叙述。离职的真正原因只有你自己最清楚,至于要不要和盘托出,需要你慎重考虑,笔者并不是鼓励说谎,只是建议应聘者把握好一个度,“直言有讳”。
知识盲点
即使应聘者做了充分的准备,仍然可能 “万有一失”。如果面试官的问题完全不在自己的知识域内,毫无思路可言,就不要勉为其难了,不妨直接如实回应。通常,面试官也会根据应聘者回答问题的情况调整提问方向,避免就应聘者不知道的领域提问,毕竟认知型的问题不是能力决定的,而是经历决定的。
开放性问题
有些面试官可能会问一些开放性问题,这类问题一般是没有明确答案的,比如对 DDD、ServerLess 的看法,考察应聘者对于一些设计思想、热门技术等是否有思考和总结。
遇到这类问题,应聘者无需过度紧张,面试官不会期望你的回答与自己的观点一致,更多的是考察应聘者对于概念的理解和实践的程度,看看应聘者是否有比较严密的能够自圆其说的逻辑。鉴于此,不妨先整理一下思路,如果是电话面试,甚至可以拿出纸笔简单地拟定要点,以便更有条理地回答。
思路卡壳
算法题并不是算法岗的专利,很多面试官喜欢在面试的最后问几个算法题(笔者也有这个 “不良” 习惯)。算法题通常具有以下的 “题效”:
不要急于问面试结果
在面试结束后,尽量不要急于向面试官询问面试的结果,没有什么意义。其一,面试官通常是不会直接告诉你结果的,避免违规之嫌;其二,根据面试回答问题的情况,应聘者完全可以大致预计结果。
不妨听听面试官的建议
如果是电话面试,在面试结束后,不妨向面试官寻求一些 ”建议“——这其中隐含了面试官对你的评价,特别是在他看来你有哪些不足需要完善,这些建议通常是相对客观的,对你提升自己也许会有指导作用。对于应聘者,不妨谦逊一点,把每一次面试都当成一次 ”客观看待自己“ 的机会,知不足而后勇。
关注自己的应聘进展
如果应聘者是通过 “内推” 应聘阿里,那么,可以向推荐人询问应聘进展(当应聘者的应聘状态(简历评估中、简历评估通过、第一轮面试中、...、待发 offer、...、已入职)发生变化,推荐人会收到邮件通知,此外,推荐人也可以直接查看应聘进展。
准备下一轮面试
通过推荐人可以准确地获取应聘进展,如果顺利,应抓紧时间投入到下一轮面试的准备中。为什么要强调准备下一轮面试呢?原因如是:第一轮电话面试通过后,第二轮面试通常不是电话面,一般分为两种情况,其一,如果应聘者在岗位所在的城市,则会安排现场面试;其二,如果应聘者不在岗位所在城市,可能通过视频面试;其三,如果应聘者定级(应聘岗位的职级)较高,不论应聘者是否在岗位所在城市,都会安排现场面试。
我曾经的主管跟我说过一句话:一个人获得晋升,不是也不应该是他在原职级优秀地完成了本职工作,而是因为他已经具备了更高职级所需的能力。
这句话令我至今印象深刻,作为工程师,不管当前处于什么技术层次,都不要满足于做好本职工作,永远保持向上进取,多思考、总结、沉淀,方能取得突破。
对于技术人才,通常企业的要求可以归为四点:技术深度、技术视野、技术见解、技术判断。而技术人对技术掌握的程度则可划分为三个层次:
简单解释一下:
技术深度和技术视野与我们掌握技术的层次密切相关。如下图所示:
作为一名技术人,深度和视野可谓立身之本。技术深度可以让我们避免“踩坑”,得到高质量的结果;技术视野可以让我们找到更好的解决方案。
提升技术深度和技术视野,需要我们不断地扩展上面两个层次。具体而言,一方面,通过实践逐步的掌握你所了解的技术,吃透它;另一方面,通过学习逐步了解更多现在还不了解的技术,扩展自己的知识面。直观来看,如下图所示:
上一节讲了技术深度和技术视野,某种程度上还属于 “战术” 层面,而本节要介绍的技术见解和判断,则属于 “战略” 层面。
见解即看法,技术见解是对技术的理解和看法,本质上是技术人的思维模型,具体而言,一个技术人如何做技术规划、技术选型就可以归为技术见解。
技术判断则是对技术的选择,这种选择是在充分评估当前技术和未来技术发展方向后作出的。技术判断是技术见解进一步深化的结果。技术见解和技术判断可以让我们把握好技术趋势,避免方向性的问题。
四个技术的关系
凡事不可一蹴而就,没有足够深度和视野,谈何技术见解和判断?关于技术深度、视野、见解和判断之间的关系,可以用下图来直观描述:
对于技术人,技术深度和视野是基础;基于此,可以沉淀为技术见解;基于技术见解做出技术判断;通过在实践中检验技术判断的正确性,进一步对技术见解进行优化,形成一个“闭环”。在技术进阶的过程中,没有“银弹”:技术深度源自实践,技术视野源自学习,技术见解源自思考、总结,技术判断则是基于前面三者进一步深化的结果。
“我们为勇敢的尝试鼓掌,但只为结果买单”——这是阿里内部的一句“名言”。“拿结果” 可谓技术人最核心的使命,鉴于此,上面的四大要素最终的服务对象——结果,即技术项目高质量落地。
关于保持竞争力,个人认为因人而异:对于工作年限较短的技术人,重点应放在增加技术深度和扩展技术视野方面;对于已经有一定经验(三年以上)的技术人,应多思考、总结,形成技术见解,并不断地在实践中优化,强化技术判断能力。
从可操作性角度来讲,技术深度和技术视野是较为直观的,通过学习、实践便可不断地取得进步。但是,技术见解和技术判断却相对抽象,或者说 “虚幻”,它们是基于丰富的经验思考、总结的产物,是一种难以量化的能力。上文中曾提及,技术深度和技术视野属于 “战术” 层面,而技术见解和技术判断则属于 “战略” 层面。没有 “战术” ,“战略” 便没有根基,无法落地;忽视 “战略”,迷信 “战术” 便会囿于局部,无法把握技术走向,难有质的提升。
最近读了一本书——《服务端开发:技术、方法与实用解决方案》,大为受用,在此推荐给大家。该书作者曾获得阿里第二届技术讲师课程大赛年度冠军(由阿里 CPO 和 CSDN CEO 共同颁奖),在阿里和蚂蚁内部所授技术课程口碑甚好。全书分 14 章,约 30 万字,正文 373 页,共 389 页,由机械工业出版社出版发行。内容分为上下两篇。上篇 1~6 章,主题为技术和方法;下篇 7~14章,主题为解决方案。书中列举了大量实用案例,为了便于读者理解,作者还绘制了超过 200 幅插图,可谓图文并茂。
无论技术如何演进,其背后的方法往往大同小异,经典解决方案历久弥新。因此,掌握方法和实用解决方案尤为必要。不同于一般的 IT 技术书籍,这本书不局限于任何一种具体的编程语言、框架、容器、中间件或编程思想,而是致力于全景式、体系化地解读服务端开发的流程和重难点。
该书共 14 章,内容从逻辑上可以分为两大部分。
第一部分为第 1~6 章,主题是技术和方法。首先概述服务端开发的职责、技术栈、核心流程和进阶路径,然后从需求分析、抽象建模、系统设计、数据设计、非功能性设计 5 个方面逐一展开,结合案例深入解读服务端开发的实操方法和重难点,为读者清晰呈现服务端开发的全景图。通过学习本篇内容,读者可以快速、体系化地掌握服务端开发的相关知识和方法。
第二部分为第 7~14 章,主题是解决方案。针对高并发、高可用、高性能、缓存、幂等、数据一致性等服务端开发的典型问题,结合业务场景进行系统性分析并给出解决方案。此外,就接口设计、日志打印、异常处理、代码编写、代码注释等实施细节给出行业案例和规范。本篇内容如同一本服务端开发问题手册,当读者在实践中遇到问题时,可以从中查找解决方案。
目前,本书已经在京东、淘宝、当当、拼多多等电商平台发售。在电商 APP 搜索关键词 “服务端开发”、“服务端开发技术”,即可搜索到该书。