|
|
|
|
|
# 07 | 考官面对面：面试经验谈之校招与社招
|
|
|
|
|
|
|
|
|
|
|
|
你好，我是曲显平，目前是百度智能运维负责人。2009年我通过校招加入百度，因为工作关系，自2011年便开始参与各种类型的面试，可以说积累了丰富的面试经验。
|
|
|
|
|
|
|
|
|
|
|
|
极客时间邀约我来聊聊面试经验，十分荣幸。今天这篇文章中，我尝试将我的一些看法总结梳理，与你分享。
|
|
|
|
|
|
|
|
|
|
|
|
各花入各眼，这个词用来形容不同公司、不同业务的不同职位面试，再形象不过。每个公司都有着独特的文化价值观和业务特色，而面试官群体也是形形色色。因此，**单纯就面试而言，我们可以学习各种面试经，但千万不要因为面试官的喜好而轻易改变自己，这毕竟是一个双向选择的过程，做好本色，守住本心，希望每个应聘者都能找到最匹配自己的那个职位。**
|
|
|
|
|
|
|
|
|
|
|
|
## 面试中，哪一面最重要？
|
|
|
|
|
|
|
|
|
|
|
|
总有人问我，整个面试过程中，哪一面最重要。有人说是主管面，有人说是HR面，我反而觉得，第一面是至关重要的。
|
|
|
|
|
|
|
|
|
|
|
|
一方面，一面的通过率往往是最低的，一旦判定不通过，基本没有挽回的可能；另一方面，一面的面试过程和结论，将对后续几轮面试产生很大影响，甚至导致面试策略的调整；最后，即使后续面试官想fail掉应聘者，但一面面试官强烈支持，那么后者往往就要顶着非常巨大的压力。
|
|
|
|
|
|
|
|
|
|
|
|
## 校园招聘篇
|
|
|
|
|
|
|
|
|
|
|
|
每年的互联网公司技术类职位校园招聘，一般分为3~4个阶段。
|
|
|
|
|
|
|
|
|
|
|
|
**第一阶段是实习转正式校招Offer。**在正常情况下，我们都会优先从当前实习的同学中挑选合适的人，直接发放正式校招Offer。这个过程一般不再有面试环节，但可能会有述职和评审环节。在实习期导师的指导下，只要你的实习和述职表现符合预期，不出现重大失误，绝大概率是可以拿到正式Offer的。
|
|
|
|
|
|
|
|
|
|
|
|
**第二类是提前批校招。**顾名思义，提前批校招一般在每年正式校招开始前进行，多为暑期，时间区间是7月初到8月底。提前批校招一方面可以帮助公司更早锁定优秀的候选人，另一方面也可以帮助公司尽早判断今年的校招形势，及时调整招聘策略，同时还可以为秋季正式校招减轻招聘压力。
|
|
|
|
|
|
|
|
|
|
|
|
这部分候选人的简历一般靠师兄师姐内推，以及各业务部门在主要生源高校的BBS发布招聘帖等模式来收集。提前批校招的组织较为灵活，时间也并不固定，而且很多在暑期，所以需要候选人一方面提早联系师兄师姐内推，另外要多关注学校论坛等的招聘信息发布渠道。此外，如果收集的侯选人简历较少，校招公司会直接由目标职位所在部门的面试官自行组织面试；如果候选人简历较多，则会组织大规模集体面试，多为周末进行。
|
|
|
|
|
|
|
|
|
|
|
|
值得一提的是，提前批校招往往被很多业务团队重点关注。正式批校招是公司层面统一组织联合招聘并发放Offer，并分配候选人给各业务部门。提前批校招，多为业务部门直接组织，所以主动性更强，而且简历多为内推和目标学校收集的方式，简历质量也往往较高。
|
|
|
|
|
|
|
|
|
|
|
|
对于候选人而言，不用因为自觉准备不足而轻易放弃提前批面试的机会，因为大多数候选人在正式校招前都没有多少面试经验，大家站在同一起跑线上。另外，一些岗位如果提前批招聘效果很好，那么在正式批校招中就不会设置很多HC（招聘名额）了，所以推荐大家尽可能优先参与各公司的提前批招聘。
|
|
|
|
|
|
|
|
|
|
|
|
**第三类就是正式批校招。**大多数互联网公司的正式批校招为每年的9月上旬到10月下旬。秋招的职位多由公司HR统一安排，1次笔试＋3次面试，是百度的标准流程。这部分，相信你能获取到的信息非常多，我不过多赘述。
|
|
|
|
|
|
|
|
|
|
|
|
**还有第四类，第二年春招。**这个阶段一般适用于某些业务部门在秋招中没有招满的情况。每年都会有一些同学问我什么时候进行春招，但我只能说，如果把希望寄托于第二年春招，那就是在赌博碰运气。比如今年，互联网行业形势如此严峻，多数公司可能都不会安排大规模春招。所以，千万不要因为面试准备不充足或者“懒癌”犯了，押宝到第二年春招，面试准备还是越早越好。
|
|
|
|
|
|
|
|
|
|
|
|
## 社会招聘篇
|
|
|
|
|
|
|
|
|
|
|
|
百度的技术类社招面试，通常情况是4个轮次。第一、第二面是技术面，第三面是主管面试，第四面是HR面试。
|
|
|
|
|
|
|
|
|
|
|
|
对于目标级别在T6+的候选人，我们会增加至少一轮的跨团队Review面试，因为涉及招聘委员会（Hire Committee）的定级流程，所以要复杂一些。接下来的内容，主要针对通常情况下T3~T6的面试来介绍，大神请直接忽略。
|
|
|
|
|
|
|
|
|
|
|
|
## 技术面
|
|
|
|
|
|
|
|
|
|
|
|
#### **1\. 个人介绍和基础知识考查**
|
|
|
|
|
|
|
|
|
|
|
|
这部分算是必备技能。我个人倒是倾向于弱化基础知识的考查，毕竟每个候选人的背景不同，应该更看重聪明程度、学习能力、沟通理解力等，**基础知识只能证明他不是一个优秀的工程师，却无法证明他是一个优秀的工程师。**
|
|
|
|
|
|
|
|
|
|
|
|
#### **2\. 项目经历考查**
|
|
|
|
|
|
|
|
|
|
|
|
从这个阶段开始就格外重要了，因为面试官之前并不一定完整浏览候选人的简历，所以聆听候选人对项目的介绍是了解候选人的最主要途径。
|
|
|
|
|
|
|
|
|
|
|
|
在这个过程中，面试官试图刨根问底，这跟各公司内部的技术评审很相似。几个关键点，希望你格外注意：
|
|
|
|
|
|
|
|
|
|
|
|
1. 对项目背景的了解程度，讲不清楚需求从哪里来是非常可怕的，这说明你更多只是一个执行者，不是负责人，且缺少对于项目整体的思考。
|
|
|
|
|
|
|
|
|
|
|
|
2. 对需求的合理性进行分析，一味听从PM，不能把控需求的研发是很可怕的。
|
|
|
|
|
|
|
|
|
|
|
|
3. 对技术方案设计的调研和选型，我们更希望看到你的方案是经过充分思考、调研、对比、论证的，通过这个过程，可以看到候选人的系统设计功底，是否对业界技术有足够了解，对开源技术的掌握情况，是否愿意应用开源技术。哪怕你的项目只是一个简单的业务系统，那么仍然应该有很多亮点可寻，否则这段项目经历可能会减分。
|
|
|
|
|
|
|
|
|
|
|
|
4. 取得的成效。很多工程师只看重过程，不看重结果，这是不可取的。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### 3\. 编程技术考查
|
|
|
|
|
|
|
|
|
|
|
|
在我的团队中，我要求每一轮技术面，都至少要有1道编程题目。
|
|
|
|
|
|
|
|
|
|
|
|
一方面，我们非常看重侯选人的代码风格、优雅程度，还有对边界条件的考虑，这些都是好的程序员必须具备的素质。对于代码混乱、边界考虑不清的人，我们会认为他没有足够的编程素养和追求，在逻辑思维层面，也有所欠缺。这样的候选人进入团队，短期可能造成Bug多、项目质量差等影响，长远来看，不利于合作开发、项目传承等。
|
|
|
|
|
|
|
|
|
|
|
|
另一方面，我们非常看重数据结构、算法等的高效实现。能够快速设计出高效的程序，这体现了候选人日常的深厚积累，还有对编程的极致追求。
|
|
|
|
|
|
|
|
|
|
|
|
前不久就有一个典型案例，我们的运维同学发现一个后端模块上线后处理性能只有几十QPS，很不理解为什么性能这么差。直到我们重新review代码后，才发现是个“经典”问题，即for循环里调用sort（虽然是隔了几次函数调用），简单优化后，性能就可以提升1~2个数量级。优秀的工程师，一定会尽可能规避这类问题，几行代码的优化，就能提升用户体验、降低服务器成本、方便代码维护、减少兄弟们的工作量。
|
|
|
|
|
|
|
|
|
|
|
|
#### 4\. 设计题目考查
|
|
|
|
|
|
|
|
|
|
|
|
一般情况下，我们都会结合候选人的背景以及我们的业务特点，给出一个较为完整的设计题目。比如：
|
|
|
|
|
|
|
|
|
|
|
|
* 公司背景下的通用题目，可以是搜索爬虫系统、搜索推荐系统的设计；
|
|
|
|
|
|
|
|
|
|
|
|
* 结合自身业务特点的，比如我的团队负责公司监控平台，那么我会希望候选人设计一套从服务器性能指标采集、计算到存储、报警的系统；
|
|
|
|
|
|
|
|
|
|
|
|
* 当然，也可以是一个有意思的feature改善，比如一个分布式日志分析系统，原来只支持计算用户请求总量，现在要计算所有用户请求时间的分位值，如何实现。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这类题目，是要与项目经历考查互为补充的，给候选人一个不熟悉的场景，看下他是否可以有逻辑地思考、分析并设计解决方案，同时也希望看下他的技术迁移能力和综合素养。
|
|
|
|
|
|
|
|
|
|
|
|
#### 5\. 逻辑题目或数学题目
|
|
|
|
|
|
|
|
|
|
|
|
这类题目的核心不在于它有多复杂，需要多少经验背景，而在于，只要逻辑清晰，认真思考，大多能得出结果，虽然不一定是最优解。
|
|
|
|
|
|
|
|
|
|
|
|
我举几个例子：
|
|
|
|
|
|
|
|
|
|
|
|
1. 一个六位数字，逆时针旋转180度后与之前完全相等的概率是多少？
|
|
|
|
|
|
|
|
|
|
|
|
2. 边数是3\*4的网格，从左下角的A点走到右上角的B点，一共有多少种不同的走法？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这类题目其实很简单，可以用编程的思路解决，比如递归（当然还有很多其他方式），也可以用概率论、组合数学的方式解决，甚至一个一个“数”也是能得到答案的。在思考问题的过程中，可以看出候选人的思维习惯，也可以看出候选人的逻辑能力。
|
|
|
|
|
|
|
|
|
|
|
|
另外，这类题目其实有很多变化，如果候选人很轻松完成了回答，面试官就可以适当加大难度，比如3\*4的网格有一个点不能经过，那么会是什么结果？这类题目看似简单，实则分辨率很高，可以充分挖掘候选人的潜力。
|
|
|
|
|
|
|
|
|
|
|
|
除去上面的介绍外，候选人还应该对行业情况有所理解，包括竞品、开源项目等，这可以体现一个人的眼界和行业洞察能力，也可以看出一个人的学习态度，他是否在持续更新自己的知识储备。
|
|
|
|
|
|
|
|
|
|
|
|
## 主管面
|
|
|
|
|
|
|
|
|
|
|
|
相对于技术面而言，主管面试不会过多考查基础知识、数据结构及算法，但因为技术主管大多具备很强的技术背景，所以仍然会针对技术面过程中的一些遗漏点（可能是面试官没有考查到，也可能是候选人的回答不够完善），着重补充考查。除此之外，主管面的核心就是判断候选人除了技术能力外的其他维度，是否与团队相匹配。
|
|
|
|
|
|
|
|
|
|
|
|
**第一类维度，软素质能力。**软素质的维度很丰富，每一次面试过程不会面面俱到地考查，但一些重要的维度一定会被照顾到。
|
|
|
|
|
|
|
|
|
|
|
|
1. **逻辑思维。**与技术面的逻辑题目类似，团队可以接受不足够聪明的人，但无法接受逻辑不清晰的人。在这个环节，可以提出一些进阶的题目，比如给候选人一个很复杂的问题，希望候选人可以尝试分析、分解，让看起来一团乱麻的问题变得清晰可实现。或者，让候选人阐述一个经历过最有挑战的问题，是如何定义问题并分析解决的。当然这类问题，一般初入职场的同学都很难回答完美；不过对于工作2年+的同学，我觉得问题的分析、分解、设定目标、规划、执行都是必备素质。这个能力很难在工作中迅速培养，它更多是通过候选人过去一二十年的学习和工作经历，一点一滴积累的，所以对于社招而言，希望候选人已经具备很好的逻辑思维能力。
|
|
|
|
|
|
|
|
|
|
|
|
2. **沟通能力。**不能有效且高效地沟通，对于团队项目是场灾难。在日常工作中，经常会看到几个同学针对一个问题争论得不可开胶，但其实他们往往没有理解对方所讲的主旨是什么，甚至对于一些名词和概念的理解都不一致，就更不要说同理心了，这种无效沟通是导致会议冗长的最主要因素。这类的面试考查，一般会依附于项目介绍或者设计题目等。
|
|
|
|
|
|
如果候选人已经具备不错的沟通能力，我们一般还会考查进阶能力：**说服和影响**。这是成为技术/项目负责人的必备能力。面试官可能会和候选人进行一个简短的虚拟沟通或辩论环节，希望候选人可以说服面试官接受某个观点或技术方案。当然，在这个过程中，面试官扮演的反派可能会用一些偏激的词汇和行为，这一方面是看候选人的沟通说服和影响他人的能力，另一方面也是压力测试，看看候选人在受到刁难时的反应，是否足够职业。
|
|
|
|
|
|
|
|
|
|
|
|
3. **创新能力。**在过去的项目中，请讲述一次发现传统方法的不足，尝试新的解决问题的方法，并获得成功的经历。这类题目非常开放，但遗憾的是，在我面试过的候选人中，近半数都是在思索一会儿后回答“没有什么”。当然，一方面可能候选人很谦虚，另一方面，则很可能是候选人确实没有尝试做过什么创新。互联网行业，创新是一切之源，如果真的“没有什么”，如何给Offer呢？
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**第二类维度，文化价值观。**百度的工程师文化是务实、自驱、Follow Through（跟进到底，有始有终）。一个浮夸，不思进取，凡事不愿承担责任，不能将项目跟进到底的候选人，很难成为我们的伙伴。
|
|
|
|
|
|
|
|
|
|
|
|
这类维度，其实没有太多经验可谈，每个公司都有它的文化基因，而候选人是否与之匹配，是基因和环境使然。我只说下从我个人角度，最为看重的内容，否则我会一票否决。
|
|
|
|
|
|
|
|
|
|
|
|
* **乐观积极。**不得不承认，每个人都有积极的一面和消极的一面，职业化的思维在于将积极的一面展现出来，尽量弱化消除消极一面的影响。在日常工作中，每个人都不希望遇到一群愁眉苦脸、满腹牢骚的同事。
|
|
|
|
|
|
|
|
|
|
|
|
* **善于合作。**一位同学加入到我们的团队，他不仅需要具备优秀的个人能力，同时也需要能和其他人协同合作，起到1+1>2的效果。我们会考查候选人在过去的经历中，对待合作的态度，有没有接触过比较复杂、跨越多个角色或团队的合作，遇到过的协作困难是什么，遇到这类困难是如何解决的。有些候选人经常会无意识地表达出，在项目研发过程中，多人写代码，还要同步需求、设计、协商接口、联合调试，而且有Bug修复推动也很麻烦，如果我一个人开发早就解决了。这种思维虽然无可厚非，但希望每个人可以看得更远，大型项目是一个人完成不了的，在多人合作的背景下，如何提升合作的效率和质量才是重点，而不是过多地看到负面。
|
|
|
|
|
|
|
|
|
|
|
|
* **追求极致。**这一条很难。在我发过的这么多Offer中，具备这个素质的候选人也是凤毛麟角，但只要具备这个素质，我几乎一定会给Offer。当然，追求极致不等于钻牛角尖。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
|
|
|
|
|
|
面试的学问很多，很多方面我都无法讲到（比如HR面，我能讲的实在不多，请表现出你最积极的一面就好）。一家之言，作为参考，总之，你具备了这些，肯定能从我的手中拿到满意的Offer。
|
|
|
|
|
|
|
|
|
|
|
|
最后，还是有几句话送给你。**不用为了某个公司、职位或面试官，而在面试过程中刻意隐藏或改变什么，否则即使你拿到了Offer并成功入职，实际工作过程中也不会感到开心。面试过程，请表现得积极再积极，所有面试官都喜欢积极向上、积极表达的候选人。**
|
|
|
|
|
|
|
|
|
|
|
|
综上，希望这些内容能对你有所帮助，也欢迎你把它分享给你的朋友。
|
|
|
|
|
|
|
