本文共 7364 字，大约阅读时间需要 24 分钟。

作为一个技术团队管理者，面试是一项必不可少的工作；作为一个上班族，被面试也是必然会一而再再而三经历的事情。

不过在我的经验中，很多人（包括曾经的自己）不太会面试这件事，或者说不太重视这件事。面试官认为搞几道题给对方做做，做得出来就牛逼，做不出来就歇菜；受试者则认为自己反正挺牛逼的，对方能慧眼识英雄的话必然会选中我，否则此处不留爷自有留爷处。很多人都认为一旦谈技巧就有种人为造作的成分。

本文就自己作为面试官和受试者的双重经验谈谈面试这档子事（上篇从面试官角度，下篇从求职者角度），以及从面试官的角度分析作为求职者在找工作面试时需要注意些什么。

由于实际工作使用 PHP 作为开发语言，后面的叙述以招聘中高级 PHP 工程师为例。

面试官篇。

刚开始作为技术经理招人时，完全不知道怎么做，网上到处百度别人的经验。一般流程是：打印一份笔试题，给受试者 1 小时的时间做题，然后根据结果大致判断是否合适，真正的面试过程中也都是围绕着笔试题目进行的。

随着面试的人越来越多，逐渐总结出了自己的经验。

简历筛选

招聘流程中有件很繁琐（甚至是无聊）的事情：筛选简历。我们公司实际流程是人事进行初选，然后递给技术经理，技术经理再在里面选出一部分进行面试（当然技术经理也可以直接去招聘网站选人）。实际情况是，HR 一般是不懂技术的，HR 的筛选标准一般就是看对方的简历描述和公司的职位描述匹配度（这一步甚至是系统自动进行的），只要合适就会推荐给技术经理，因而一般都是整捆整捆的推。

面对大量的简历轰炸，技术经理一般都是通过“量子速读”的方式筛选简历的。就我自己来说，第一遍快速浏览一遍简历，找关键词和关键句子，看有无亮点（吸引我的），而不会逐字逐句去看简历，一份简历用时一般不超过 1 分钟。

速览的方式能过滤掉 80% 的“平庸的”简历，剩下 20% 再慢慢斟酌。

上面说了，速览的目的是找亮点。如果一份简历即无亮点，又写的“惜字如金”，会第一个被 pass 掉的。

就我们具体的招聘对象（中高级 PHP 工程师）来说，我会重点关注以下几点：

自我简介。

在冗长的简历中，自我简介是简历的整体门面，里面浓缩了这个人的方方面面，是最容易、最集中体现一个人整体面貌的地方。一份自我简介写得让人觉得可有可无的简历不会给面试官留下深刻的印象。自我简介的重要性丝毫不亚于项目介绍。

自我简介一般包含两部分：技术能力介绍与非技术能力介绍。技术方面要包括本专业技术能力（比如作为 PHP 后端开发工程师必备的技能如 PHP、MySQL 等知识掌握情况）和本行业技术能力（语言无关的能力，如对 OOP、设计模式、算法、架构、管理等能力）。

非技术能力部分每份简历可能写得都不一样（很多简历压根没有这一块），主要包括个人性格、团队协作能力、个人爱好等。

在自我简介中，我重点关注的是“高出平均”的那部分内容。举个例子，每个 PHPer 都会在自我介绍里面写上对 PHP 这门语言的掌握，一般的写法：

熟练掌握/精通 PHP、Laravel 框架；

另一种写法：

精通 PHP，熟悉 PHP 底层运行机制，熟读 Laravel 源码，自己编写过简单的基于 MVC 的 Web 框架；

我的注意力肯定会被后者吸引，前者过于干瘪无味，后者则显得饱满、有血有肉，除了传达出其技能掌握情况，还传达出一种热爱和自信。

大部分简历的自我介绍属于流水账，一句话概括了自己熟悉的所有编程语言、工具，对“行业能力”方面的介绍也是“轻描淡写”，这种简历给人的感觉是草率、不够自信、资历平平。

比如：

熟悉 PHP、MySQL、HTML、CSS、JavaScript、Laravel 框架、ThinkPHP 框架、Swoole 框架等；

熟悉常见设计模式、数据结构和算法；

熟悉分布式架构、微服务架构；

是不是似曾相识？是不是乍一看感觉很牛逼？

看了太多的这种写法，我就产生审美疲劳了，我想其他人肯定也是。

之前我看到这种流水账不以为意，觉得应该是对方不知道怎么样写简历？叫过来一聊，发现大部分人对其罗列的技术都是蜻蜓点水、一知半解。

于是我得出一个结论：这种流水账式的自我介绍源自简历作者的内心矛盾：一方面自己对这些知识并未熟练掌握，有些只听过名字而已，内心不够自信；而另一方面他觉得这些流行的、“高大上”的技术写上去能给自己添几分光彩，如果不写，倒是反映自己“孤陋寡闻”。

于是后面的简历筛查中，我会重点关注那些具体的、能反映作者真正水平的内容（我称之为“高出平均”的东西。当然这里说的“反映真正水平”是假设简历本身内容是真实的）

项目经验。

项目经验这块，我最感兴趣的是“求职者对项目的贡献”。

很多简历花了大量篇幅去写每个项目本身是个什么东西，有哪些模块，至于自己在项目中的角色、贡献则是轻描淡写。比如“维护公司 CRM 系统”，然后花了大量篇幅介绍这个 CRM 系统有哪些模块，每个模块都是干什么的。

就算这个系统是公司最核心、最复杂的系统，而你仅仅是维护了几行代码，又如何？

如果求职者在所有的项目中扮演的角色都是“维护者”，这份简历基本就会被 pass 掉，因为从他的介绍中我看不到激情、思考，看到的仅仅是一个会写代码的机器。

好的简历在每个项目介绍中会简明扼要地描述项目本身，然后重点提出项目中遇到的问题以及自己是如何解决的，以及自己对项目的其他方面的贡献（如主导系统设计、重构）。

其它加分项。

如果简历中有求职者的博客、开源项目，我会很感兴趣地去看看，这部分很可能直接让简历通过海选（所谓物以稀为贵，绝大部分人都没有自己的博客）。

学历、学校。

这部分会引起我的好奇，但不会作为筛选简历的标准（因为实际工作中遇到过很多学历和学校都挺不错的，但由于各方面原因，在团队中永远只能做配角的那种）。

综上，我一般根据简历的自我介绍和项目经验中“高出平均”的东西去速选简历，进行第一轮面试。

笔试

实际中，我们有时候会有笔试环节，有时候（项目紧急缺人，面临大量面试的时候）没有笔试。

对于笔试题目，我的原则是：

1. 不考很偏、但实际没有什么技术含量的题目（比如 goto、with）；
2. 不考需要大量记忆、实际工作中基本都是要问度娘的题目；
3. 考题中会包含一定比例的专业基础知识考查（如 PHP7 相比 PHP5 有哪些优化、PHP 数组相关、PSR 规范等这些几乎每个称职的 PHPer 都需要掌握的知识）；
4. 包含一定比例的数据结构、算法、设计模式的考查，这部分的考查一般具有一定自由度（比如让求职者自己选定几种设计模式并说明其作用、应用场景，而不是考某个特定的设计模式）；
5. 大部分的题目具有一定的灵活度，求职者有自己发挥的空间；
6. 允许当场问度娘。这符合实际工作场景，而且这些笔试题目在面试环节还会拿出来聊，如果求职者的答案完全是搜出来的，自己却没有理解，面试环节一样通不过的。

笔试题有两个考查目的：

1. 受试者专业基本功——专业素质；
2. 受试者的态度——为人素质。有些受试者有种自负心里，觉得这些题目太简单了，不屑于回答，每道题都是草草一两句了事，有些甚至会写“结果见百度”这样的话。自负者往往较自我，对于团队尤其是初创公司的团队并不合适。

面试

第一印象很重要。

第一印象包括对方的精神面貌、礼数。虽然 IT 界不太讲究礼数这玩意，但起码的见面问候语和微笑是要有的。当然，有些面试官不太在意礼数，但大部分都会比较在意对方的精神面貌（阳光、自信还是萎靡、茫然？）

第一部分是求职者的自我介绍环节。

很多人的自我介绍和其简历上一样是干瘪的流水账，从第一家公司开始，到最后一家公司，将做过的项目几乎一个不漏地说一遍，从中听不出哪个项目是是他重点负责的，也不知道哪个项目给公司带来了巨大收益。从这种流水账式的介绍中，你能感受到一个毫无激情、毫无拥有感的人的漫长职业生涯是多么地无聊，这些事情一件一件地发生着，对于他而言却几乎毫无意义——或者说他几乎从来不去思考其存在的意义。

我期望从这些自我介绍中听到陈述者的价值存在感。哪些事情是你主导的？你为什么做这样那样的设计决策？这些项目给公司以及给你自己带来了什么样的收获？

求职者没有必要把生平所有的项目都陈述一遍，管中窥豹，一叶知秋即可。

第二部分是项目问答环节。

接着求职者的介绍，我会从中挑出一些问题点提问。如果刚才的介绍过于流水而抓不到问题点，我会让求职者再从中挑选一个做详细介绍。

一般我问得比较多的是就某个项目中的某些设计决策的理由，比如如果对方提到做过秒杀系统，而做秒杀的基本绕不开高并发和库存超卖问题，每个人的解决方案可能都不同，比如有人将所有的商品库存放到消息队列中，有人将库存做成原子计数器，也有人将用户请求放到队列中。这里没有所谓标准方案，我更关注的是你的方案是否能满足你们的目标，因为方案长什么样完全取决于要实现什么目标，如果你们的目标很小很简单，而你的方案确实一个非常复杂的耗时耗力的“大厂”、亿级的解决方案，我倒认为这不是一个好方案，这种人做出来的设计往往需要仔细掂量。

另外，我会就项目中用到的一些技术进行渐进式追问。比如大部分人都会提到用 Redis 做缓存来解决数据库压力，那么你对 redis 本身了解多少？它和 MemCached 在对请求的处理、数据存储、内存管理上有何不同？PHPer 有个普遍现象是底子太薄，限于工作实际，绝大部分人的工作都是做些业务开发，涉及不到底层，很多人连什么是 TCP 三握手都不知道，也照样开发了十几年。在这种“刁难式”追问上走得越远，给我的印象越好。不过当我问这些问题时，还有另一个潜藏的目的：我想看看对方在答不上问题后的表现。有些人心态不好，一个问题答不上来，整个人就蔫了。

回答问题需要聚焦。这涉及到今后团队沟通问题，也侧面反映一个人的思考力、办事效率。没人喜欢听别人啰嗦，特别是听了半天还听不出对方想要表达什么的时候，基本就是面试结束的节奏了。有些人啰嗦是因为习惯使然，平时说话就啰里啰嗦，有些人是觉得说多点能给面试官更深刻的印象。殊不知，如果你能三言两语就切中要害，入木三分，面试官定会对你刮目相看——因为只有思考足够深入、理解足够透彻才能一句话抓住问题本质。

第三部分是专业问答环节。

这部分不再涉及具体的项目（这不是说对方不能就问题关联到某个项目，而是说我不再就具体的项目发问），而是“纯专业知识”问答互动。

我的问题清单包括 PHP 基础知识、数据库、缓存、网络基础、面向对象、设计原则、设计模式、算法，类似下面：

• PHP7 相对 PHP5 做了哪些改进？
• 如何求两个数组的交并差集？（以及类似的问题。因为数组是 PHP 中最常用、最强大的功能，但不是每个人都能熟练掌握这些功能，因而在实际项目中经常充斥着各种蹩脚的实现，各种嵌套循环满天飞，其实就是一个原生函数调用的事情）
• 你都了解哪些 PSR 规范？（考察对方对编程规范的关注，大部分人只能回答出编码规范、命名空间规范，有些甚至连 PSR 是什么都不知道）
• 一次 Web 请求的执行步骤？（属于网络基础知识，不同人的理解深度不同，此处能看出对方处于那个级别，如果能说出 局域网 ARP、HTTP 协议解析、TCP/IP 封包、DNS 分层解析的，定能让人刮目相看）
• MySQL 中一条 SQL 语句的执行过程大致是怎样的？（考察对 MySQL稍底层的了解）
• 什么是聚簇索引？什么是索引覆盖？什么是回表？InnoDB 如何保证数据正确性？（考察对 MySQL 较深层次的理解）
• Redis 是单线程还是多线程的？采用单线程的原因有哪些？单线程如何处理高并发问题（考察对 Redis 稍底层的了解以及 I/O 多路复用的了解）
• 你是如何理解面向对象和面向过程的区别的？面向对象编程都有哪些特性？（大部分人被问到这个问题时会同时有两种截然相反的内心活动：操，问这么低级的问题；咦，我好像回答不上来）
• 你都知道 OOP 的哪些设计原则？（实际中大部分人一个都不知道，每当我给予提示后，对方会表现得恍然大悟，不过再加以追问时，又是一脸懵逼。对设计原则的理解本是仁者见仁的事情，而真要说出个所以然，没有实际的面向对象经验与思考是答不上来的。所以，如果这个问题回答得让我印象深刻，我对其的定位一般都是“高级”）
• 你都了解哪些设计模式？在哪里用过或者见过？（这个问题的“平均水平”回答一般有两种：一种是只知道单例、工厂；另一种是能说出一大串，但真从中抽一个细问时又是一脸懵逼）
• 你都了解哪些排序或者查找或者其他算法？挑一个说说其大致实现方式？（由于各种原因，PHPer 普遍算法较弱，能说出个快排实现方式的都能让人刮目相看）
• PHP 数组底层的实现机制是怎样的？（这是一个较底层的问题，需要了解其 C 代码实现。问这个问题的目的是探测对方技术深度，问的前提是对方其他问题都回答得较好）

上面的问题有几个特点：

• 偏原理，追根问底，回答者平时须有思考、探究的习惯才能答得出来；
• 貌似平时用不到，跟实际开发没什么关系；
• 大部分问题的答案并不固定，可以有不同的回答深度；

那么，针对不同级别的工程师招聘，我都是用同一套问题吗？

答案是肯定的。我的目的不是要对方都能回答得很完美，而是要通过问题甄别出对方的真实水平。不同水平的人的回答会截然不同，比如对设计模式、设计原则的理解，初级工程师可能只会背出来，却说不出所以然，更别提在实际项目中应用，高级工程师则能结合自己的实际项目谈他的理解。

很多人会抱怨面试官总是问些实际项目中用不到的知识，我以前也是这样认为的，觉得他们这样做无非是为了显示自己知道得比别人多而已。直到我自己去面试别人。如果面试官问的都是所谓“工作中用得到的”东西，那绝大多数人都能答得上来，你让面试官去选哪个？

另外，我个人会给那些对面向对象、设计原则和设计模式理解得比较好的人更高的权重。这些看似很虚的东西在实际项目中却真真切切起着重大作用。很多人的代码写出来只有机器能看得懂，可读性、可维护性、可扩展性一塌糊涂。这些人拿着面向对象语言做着全是面向过程的开发，心里根本没有设计原则、设计模式那回事，开发中也谈不上设计，觉得开发这档子事完全是个人的事情，怎么乐意怎么搞。

第四部分是技术无关的互动环节。

这部分的前提是前面部分进行的比较顺利。

这部分我会问些诸如平时都看些什么书啊，有没有写过博客啊，都有什么兴趣爱好啊，上一家公司离职都原因啊，从更多维的、立体的角度接触下这个未来可能的同事。

第五部分是受试者提问环节。

我最不喜欢被问到的问题是：”你们公司是干什么的？“

我的天！几乎所有招聘网站都有公司简介项，大部分公司也有官网和百度词条，你来公司参加面试前都不了解下？

这简直就是无理与傲慢。

求职者的提问如果表现出对公司业务的些许了解，并在此基础上提出一些他自己关心的针对性的问题，或者就团队的现状、负责的业务、团队以及成员的管理、发展等提问，我个人感觉都是比较中肯的问题。

态度

面试态度很重要。

整个面试过程中，我都一直在考察对方的态度，有时为了该考察目的，我会特意问一些刁钻的、甚至是稍带刺激性的问题。

面对回答不上的问题，受试者一般有这么几种反应：

• 拐弯抹角型。这类人为了掩饰自己对该问题的无知，会拐弯抹角、旁敲侧击，让人感觉驴头不对马嘴，却自认为能够瞒天过海。

• 自我感觉良好型。这类人一般对问题略知一二，因而不愿直接承认自己对该问题的无知，而是添油加醋、“旁征博引”，以表现得很是在行；

• 长时沉默型。这类人可能以前曾经了解过相关知识，但现在忘了，于是费劲心思在心里琢磨，给人的感觉就是长时间的沉默。

• 诚实型。这类人会对问题稍作思考，确认自己答不上来时，直接跟面试官说出实情。

我个人喜欢最后一种类型的，我想大部分面试官也是。

庄子说“吾生也有涯，而知也无涯”，一个人不可能对所有问题都知道，很大概率上面试官的问题清单中的一部分他是不知道的，而对于这一点，有经验的面试官也是心里有数的。有时候，面试官为了考察对方的性格品质，会故意问一些认为对方不知道的问题。当受试者回答不上问题时，态度至关重要。这里的关键是：保持诚实。

诚实这一品质在团队协作中非常重要，它的同义词是谦虚。相反，和不诚实相关的特质是自负。

自负者往往过于自我，在团队中过于执守己见，很难听进别人的意见，难于沟通。

在面试互动中，受试者往往会就某些问题的解决方案或意见和面试官产生分歧，面试官会关注这种情况下对方的表现。有些人无论是处于对面试官的尊重还是处于对分歧本身的认可，他会主动承认自己方案的缺陷，以及认可存在更优的解决方案。而有些人则会一路坚持自己是最优的，哪怕经过分析发现其方案存在明显的缺陷。

自负的另一种表现是在面对自己不熟悉的问题时。自负者一般不愿意显露自己的无知，会竭尽各种手段来让自己表现得好像知道答案。

自负者往往有一定的底气（能力），但其能力还不足以将“自负”转换成“自信”。

作为面试官，我们（以及我们的团队）青睐自信而谦虚的人。

面试评价模板

我会从技术功底、项目经验、沟通能力、态度四个维度对面试结果打分。

每个维度都有 0 - 10 的评分，梯度：0 - 4 不及格，5 - 6 分及格，7 - 8 分良好，9 - 10 分优秀。 每个维度有权重，总权重100%。就实际来说，我给予的权重排序是：技术功底 > 态度 > 沟通能力 > 项目经验。

• 技术功底：
  技术功底要细分本专业技术能力和本行业技术能力。对于做 Web 开发的 PHP 工程师来说，专业技术能力是指 PHP Web 开发栈所必须具备的能力，本行业则是指作为程序员所需具备的基本通识技能（如面向对象、设计原则、设计模式、系统架构、数据结构与算法等）。
• 项目经验：
  重点考察受试者主要做过哪些项目，如何解决项目中的问题，考察其思考及解决问题的能力。受试者对项目的贡献程度大于参与了多少项目。
• 沟通能力：
  表达明晰、主题聚焦。考察受试者的沟通技巧、思考力，并从侧面反应受试者处理问题的效率。
• 态度：
  诚信、积极、阳光、抗压、正向思维。

转载地址：https://blog.csdn.net/zhang0402030211/article/details/105611853 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！