招聘面试的套路与原则 进入八月，开启了夏季的社招季。近期集中的招聘、面试，形成了一些心得体会，或者说叫套路，而隐藏在这些套路背后的其实是一些更通用的原则。 所以，这一篇其实是写给招聘者的，不过

进入八月，开启了夏季的社招季。近期集中的招聘、面试，形成了一些心得体会，或者说叫套路，而隐藏在这些套路背后的其实是一些更通用的原则。

所以，这一篇其实是写给招聘者的，不过，所有的应聘者也有可能有成为招聘者的一天，也可以参考。

套路

一次集中的扩招需求，有点像每年一度的晋升评审，都需要对大量的候选人进行定级评审，因为每一个新招聘的人员都会对其有一个定级的过程。

在我们内部的晋升评审中，考察点有下面一些维度：

• 通用能力：考察其沟通表达、学习成长等
• 专业知识：考察其知识的掌握、深度、广度等
• 专业能力：考察其技能应用的能力和结果
• 工作业绩：考察其工作成果、产出、创新点等
• 价值观：考察其认知、理解、行为等

晋升采用的是工作述职与评审问答形式，其实也很像一次面试过程。只不过晋升用的是述职报告，而面试用的是简历。

在明确了这几个维度之后，为了保持晋升和招聘的统一性，我自己摸索采用了一套结构化的面试思路，也叫套路吧，整个面试过程会包括下面几个部分：

自我介绍
一开始的简短自我介绍，考察点在于对自我的总结、归纳和认知能力。观察其表达的逻辑性和清晰性，有个整体印象。

项目经历
一般我不会专门问一些比较死的专业技术点之类的知识，都是套在候选人的项目经历和过往经验中穿插。通过其描述，来判断其掌握知识点的范围和深度，以及在实际的案例中如何运用这些知识与技能解决真正的问题的。

所以，不会有所谓的题库。每一个我决定面试的候选人，都是提前细读其简历，提炼场景和发掘需要问的问题，相当于面试前有个二三十分钟的备课过程，组织好面试时的交互过程与场景，以顺利达到我想要了解的点。

团队合作
通常还会问候选人其所在团队中的角色，他们的工作模式、协作方式，并给出一些真实的场景化案例观察其应对的反应。评价一下关于他周围的同事、下属或领导，了解他在团队中的自我定位。这里的考察点是沟通协作方面的通用能力。

学习成长
这个维度考察的关键点包括：成长潜力、职业生涯规划的清晰度。人与人之间成长速度的关键差距，我自己观察得出的结论在于：自驱力。而路径的清晰性，也是产生自驱的一个源动力，否则可能会感觉迷茫，而陷于困顿。

这一点，曾在晚上看到一篇采访微信面试委员会团队的文字记录，提及：

人才一定需要 “自驱力”；“聪明” 很重要但很难定义，我认为应该从努力程度和专业度两方面来考察，聪明的人在面对技术问题时不仅只有苦力，他会有解决问题的章法，既明白业界解决此问题的方式，也能清楚知道自己是在什么水平，并且逐一描述清楚。

在程序技术这个领域，一个人现在会的东西，会随着时间流逝价值逐渐变低。所以一个人才如果缺乏足够强的 “自驱力”，成长性不足，随着时间其价值是变低而不是变高。

文化匹配
这算是价值观的一部分吧。其实，这是最难考核的，我没有什么好方法，基本靠感觉。曾经有过好几次碰到经历和技能都不错的人，但总是感觉哪里不对，但又着急要人，就放进来了。但最终感觉是对的，合作很快就结束了，人也走了。

那有没有过感觉不太对，但招进来后却合作的很好的呢？暂时还没有。每次遇到这种感觉问题，我觉得一个人的判断可能不够，我现在想到的一个方法是，多找几个将来会与这个候选人有直接合作关系的同事作为面试官一起来感觉下，都问自己一个问题：我愿意和这人长期合作一起工作嘛？独立作出选择判断后，再来看看大家的判断是否能达成多数一致。

综合评价
总结点评候选人的优势、劣势并进行技术定级，定级也没有绝对标准，而是相对的。我一般就是和周围觉得差不多级别的人的平均水准比较下，大概就会有一个技术级别的判断。

最后，闲聊几句，再问问候选人是否有问题想问，一整套就算打完了。套路讲完，下面讲讲背后的原则。

原则

关于招聘面试套路背后的原则，给我带来最大启发的还是 Ray Dalio 那本叫《原则（Principles）》的书。

招聘面试，其实是一个对人的筛选，而筛选的本质是匹配 —— 匹配人与职位。第一，你得非常清楚地理解，这个职位需要什么样属性的人。第二，确定你的候选人是否拥有这个职位要求的必须属性。那么，首先回答第一个问题，一般的职位需要什么样的属性？

属性，又可以进一步拆解为三个层次。第一层次是「技能（Skills）」，技能是你习得的一种工具，就像程序员会用某种语言和框架来编写某类应用程序。第二层次是「能力（Abilities）」，能力是你运用工具的思考和行为方式，用同样的语言和框架编写同样程序的程序员能力可以差别很大。而第三层次是「价值观（Values）」，价值观是一个人根深蒂固的信念以及驱动行为的原因与动力所在。

一个职位越是临时，对第一层次技能的要求最多，而越是长期固定的合作关系，对价值观的要求最多。至此，我们回答了第一个问题。而 Ray Dalio 给出的原则也是：

In picking people for long-term relationships, values are most important, abilities come next, and skills are the least important.
在选择与人建立长期关系时，价值观最重要，能力次之，而技能的重要性最低。

所在，在找人时，经常要抵挡住一种诱惑：赶快弄个拥有合适技能的人，填补上某个空缺的职位。当你需要大量招人时，一时间招聘市场就是一个买方市场，这种抢人的诱惑会更大。但记住一点，招一个人很难，付出的成本和代价不低；但招错一个人，再想把人弄走，会更难而且付出的成本和代价只会更高。

记得以前读到一本书讲一个成功的创业者，他说他最早的一百号员工全部都经过了他亲自面试，但后来公司发展太快，没法再亲自一个个面试。解决这个问题的办法就是，挑选你信任的面试官，你信任他们的判断。而背后的原则是，人通常会有一种潜意识的倾向去挑选像自己的人。这一点，我一直在观察和体会，并且确实感觉到它在起作用。

曾经感觉周围环境变得不好了，觉得在公司工作不开心了，那肯定是周围人的环境发生了变化。我选择去逃离，感觉自己无能为力，换一个环境再试试。但不管哪个环境总也有让人不满意的地方，但如今是明白了，最终环境还是人塑造的。

公司的人总是来来去去，与你一起工作的人和公司本身也是在不断的发展演变进化中。所以，最后若说还有什么最重要的原则的话，我觉得是这条：未来很长一段时间，为了一段共同的使命与价值，我愿意和一个人分享一段共同的生命吗？

别不承认，和你一起工作的人，有时甚至比你的亲人分享了更多你的生命与生活。

...

最后，总结下。

套路，面试的六个维度：

• 自我介绍：自我认知、归纳、总结、表达
• 项目经历：知识掌握、技能运用、能力证明
• 团队合作：团队角色、沟通协作
• 学习成长：职业规划、成长潜力
• 文化匹配：团队成员接受度感知
• 综合评价：点评优势、劣势、定级

原则，找人的三个属性层次：

• 技能：现在掌握的技能能解决现在面临的何种问题？
• 能力：面临未来未知的问题，有能力去应用已有或学习新技能去解决吗？
• 价值：驱动行为的根源与动力

说了那么多，无非就是找到对的人，去做对的事，行远路长。

程序员，你为什么值这么多钱？

听说一段时间不加薪，人就会开始思考起和工资有关的问题。消费水平又提升了，能力也进步了，经验也更多了，怎么还没涨工资呢？

近两年，有了点余钱就开始考虑起投资来，比如：投资股票首先需要判断的就是关于公司价值和价格的关系。回到个人身上，似乎工资也就是个人价值在市场上的一个价格。那我们的工资是如何被定义或确定的？

因为我的程序员职业背景，下面就以这个职业为例来分析下这个问题。

表象与实质

工资的高低给我们的感觉似乎和你的技能、经验呈一个正比关系。毕竟每次找工作面试的时候，考察的都是候选人的技能、经验相关水平，然后给予一个相应的级别，最后确定一个工资范围。而且一般有正规工资体系的公司，都会按照专业水平划分能力级别，以此对应不同的工资等级。

这个对应关系是我们能观察到的一个现象，且有切身的体会。所以很直觉的就会把工资高低和我们的技能水平、经验值关联起来。工作初期的很长那么一段时间内我都是这么以为的。

因而，当刚工作了两三年后，技能水平迅猛提升、经验值飞速增长，这个阶段属于《两种增长类型》中的对数增长初期。上升曲线特别陡峭，而工资的增长呢，则属于指数增长的初期，几乎感觉不到增长，自我感觉是技能和经验已经翻倍，但工资似乎还在原地或就涨了 20%。

其中有个例外就是校招，校招刚毕业的同学的工资有可能比毕业工作了两三年的同学更高，出现倒挂现象。这在大公司的校招比较常见，这里决定工资高低的，和经验技能无关，只和公司的人才储备、市场竞争、品牌宣传有关。

所以，工资和技能经验的直观关系仅仅是一个表象，那么它的实质是什么呢？曾经读到刘润的一篇文章，其中写道：

工资不是用来支付给技能的，不要以为技能越高、工资自然应该越高。
工资是用来支付给责任的，责任越大，工资越高。
涨工资，是因为承担了更大的责任。

上面所说正是工资的实质。所以，站在公司的角度，它会设计很多不同的岗位，有管理岗、有各种专业系列岗，而每个岗位又对应不同的职责。而岗位职责对技能和经验的要求决定了该岗位的工资范围，也决定了整个公司的人力成本范围。

搞清楚了工资的实质，就明白涨工资是怎么回事了。涨工资，一种是岗位职责工资范围内的调节，毕竟如果长时间不涨，也不利于人员稳定。另一种是，升级到更高级别岗位，这种除了当下领到的工资涨了，而潜在的可涨的工资范围也提高了。所以，有时你的技能提升后，但公司业务发展没那么快，不能提供更高级别的岗位职责，工资也就涨不上去了。

另一个误解是，工资跟我的表现有关。今年工作很努力，表现很好，年底了公司业绩也很好，就会预期涨工资。但前面说了工资是支付给责任的，不取决于你的表现。这种情况一般通过发奖金来奖励突出的业绩，这属于短期激励，当然也有公司会在岗位职责工资范围内适当调节提升以保持长期激励。

对于管理岗位，因为经理人不属于个人贡献者，所以其工资的一部分通常和团队绩效绑定，称为“绩效奖金”。这个奖金一般在管理岗的全部薪酬中的百分比会随着薪酬的增加而增加，比如：高层可能占到 50%，而中层占到 20%-30%。前 Intel CEO 安迪·格鲁夫说过：

每一份工作所包含的最大价值都是有限的，不管一个人在这个职位上待了多久，最后总会达到薪资的上限。

这个上限就是岗位工资范围的天花板。而外部市场会提供一些工资立即涨 50% 甚至翻倍的机会。面对这种机会时，先不要自大的以为你的价值被低估了，心想你看外面市场给了翻倍的价格。很可能是这样的，外部公司出现了岗位空缺，考虑到公司业务正快速发展的时间和市场机会成本，所以会开出一个高于一般市场价格的工资水平来迅速补缺。另外，空缺的岗位职责实际可能比你在当前公司的职责更大，你还要考虑自己能否承担得起。别通过了面试，最后却过不了试用期，仅领了三个月或半年的翻倍工资，实际是得不偿失的。

认清自己，认清工资的本质。

价值与价格

程序员提供的是软件开发这种技术服务，而为了提供这种服务需要相当长时间的知识、技能和经验的积累。获得具备提供这类服务所需的学习和实践的时间构成了我们的「技能成本」，这形成了价值的一部分。

而公司支付给程序员的工资就是提供技术服务的市场零售价。既然提到了「市场零售价」这个概念，想一想，市场上有没有同类的，成本差距不大的商品，零售价却可以差距巨大，这是为什么？

我想到得是：女士皮包。曾经看到过一个案例：

北京新光天地的某著名奢侈品专卖店遭遇盗窃，据说一个零售价好几万的包包被偷了。店长报警，但最终警方并没有刑事立案，因为那个包包的成本进价不过几百块钱。

而在程序员提供技术服务的市场上也存在类似情况，技能经验水平差不多，但工资（零售价）差别巨大的个体。思考下包包的例子就明白了，奢侈品包包除了材料成本，还有什么成本？客户之所以要买这个奢侈品包包，最大的成本不在材料，而是在客户的头脑中建立起关于这个包包的品牌信息并形成一种对客户有独特价值的认知，这属于另一种成本：「传递成本」。

那么，程序员也有两个成本：

• 技能成本：专注于提供技术和服务本身所占用的时间和注意力。
• 传递成本：让你潜在的“客户”知道你所能提供的技术和服务的价值占用的时间和注意力。

这里有个案例很形象的说明两者的关系：

2003 年，一群海洋科学家历时三年，花费了三百万美元研究经费，完成了一份关于美国海岸环境状况的报告。这份报告反映了巨大的环境问题，可以说是触目惊心，所以参与研究的科学家都认为此报告一出必然石破天惊，成为每晚电视新闻主题，登上《时代周刊》的封面，等着被记者采访轰炸。结果除了纽约时报在二十二版给了个报道，报告几乎没有引起任何反响，这件事就这么结束了。

花费了三百万美元研究经费，但仅有 3% 用于宣传，所以毫无影响力。这个案例之中，97% 的研究经费相当于「技能成本」，而用于宣传的 3% 相当于「传递成本」。当二者差距悬殊时，即使很有价值的东西也很难被市场所知晓，无法实现价值最大化。传递价值也需要成本，而且成本不低，正所谓酒香也怕巷子深。

所以，有人总是感觉自己被低估，因为他正巧知道了另一个和自己技术差不多的人，似乎只是人际关系更好反而获得的零售价更高。而程序员这类技术人员倾向于高估自身的价值，而认为市场低估了自己的价格，往往是因为对传递价值部分的成本没有足够的认识。

这两个成本最终都会成为你价值的一部分，而且市场上确实会为此埋单。两个技能水平相当的程序员，一个在市场上默默无闻，一个在市场上拥有相当的影响力并占据了潜在客户的头脑。当后者要去市场上出售时，零售价通常会更高。

搞清楚了价值的两个成本，就能很好的理解其价格了。思考下，为什么程序员在一线城市的人力和生活成本高居不下，企业还是要在一线城市最贵的写字楼扎堆？

我的理解就是这两个成本的原因。程序员的技能成本大量依赖一线城市的高校教育资源。而程序员群体的普遍特性是忽视传递成本，那么企业只好在其扎堆的地方以最小化传递成本。因为考虑市场的时间和机会成本足以覆盖一线城市相对二三线城市的人力成本差价的。

市场上的商品有两种销售方式：

• 卖的更多：大型卖场，薄利多销。
• 卖的更贵：奢侈品，相对成本一百倍的毛利。

程序员提供的技术服务因为无法卖的更多，所以只有一种选择，像奢侈品一样卖的更贵，前提是学会像奢侈品牌一样思考。

发展与变化

有时价值没变化，但工资也可能会一直涨。从现在起你即使停止技能增长，只是维持技能不被市场淘汰。在可预见的未来十多年，你的工资还会翻好几倍。这有两个原因：

1. 货币是保持贬值趋势的
2. 人口抚养比变化

人口抚养比，是一个国家非劳动的人口占总人口的比率。来自国家信息中心的数据，2011 年是中国人口红利发生转折的一年，从这年开始，总抚养比由降转升，2011 年为 34.4%，2012 年为 34.9%。这是劳动年龄人口相当长时期第一次出现了绝对下降，这意味着中国 15 岁以上不满 60 周岁的劳动年龄人口，在 2030 年以前将稳步地有所减少，中国已经面临“人口红利”逐步消退的压力。

简单说，就是 2016 年，14 亿人有 5 亿无法工作，人口抚养比 5/14=35.7%。如果 60 岁退休政策不变的话，2030 年大概会反过来，5 亿人工作养 9 亿无法工作（未成年、退休）的人。按这个趋势和经济规律，好消息是劳动力供给减少价格自然会上升；坏消息是，劳动强度和压力会更大，毕竟一个劳动人口差不多要养活两个非劳动人口。

另外一个值得关注的可能就是人工智能的发展，需要多少年，对人的替代因素能达到一个不可忽视的比例？这一点暂时只能且行且看吧。

...

关于工资，我们从表象到本质，从价格到价值，从当下到未来逐步看清了其中的真实。那么就只需客观面对这个真实，按照经济规律行事，理解市场定价原则。再积极一些，尽可能高效率的提高个人价值产出率，但也要认识到工资的“玻璃天花板”。

还记得前面提及的《两种增长类型》吗？不幸的是工资增长符合对数曲线，但价值增长是可以有办法走指数曲线的，跨过了指数增长的拐点再兑现价值，收入就会突破工资增长的天花板。

至于如何做？还没有清晰的思考认知，倒是觉得和菜头这句话很有道理：

因为只有真正认识你价值的人，最终才会成为你价值的一部分。

当然，如果你还在对数增长的陡峭期，那么就简单了，先让工资增长到天花板附近吧。

程序员都讨厌开会？

据说程序员都讨厌开会，不知道是不是都，但我确实也不喜欢。「小道消息」的 Fenng 曾经写过在阿里的后两年，他负责数据库团队时，每周会议也是多到让其感觉无法忍受。程序员讨厌写文档是出了名的，但讨厌开会的程度是讨厌写文档的立方，以上推论来自漫画《神秘的程序员》，如下：

有哪些会？

当我打算写这个主题时，反思了下过去都参加过哪些会议，发现有时会莫名其妙的就参加了一些完全无意义的会议。下面我们先看看一般程序员都会碰到哪些会议。

需求会

这类会议一般是产品或项目经理召集，组织参与项目的程序员一起讨论需求并确定排期。这类会议容易出的问题是，程序员到了会上才第一次知道需求，并陷入到需求细节的无休止讨论中。更好的方式是提前让程序员详细了解需求，会上只需敲定排期并让互相有协作依赖的程序员之间达成一致和形成承诺。

讨论会

这类会议的场景比较广泛，比如：项目进行过程中同组程序员之间就设计或实现的讨论，或与其他组项目合作人之间的讨论等等。这类会议容易出现的问题是临时把一堆人拉到会上，然后陷入混乱的自由讨论，失去焦点。

还有一类讨论会叫头脑风暴会，也是容易把一堆人拉到会上，开动头脑风暴。如今遗憾的领悟到这是最没效率也没效果的方式。头脑风暴会需要就待解决的问题让参与人员提前准备，搜集或阅读材料，不同人从不同角度各自提出自己的观点或方案，然后到了会上将所有观点和方案列出来，再开动头脑，碰撞连接一下，看看能不能风暴出一些新的观点或方案去有效解决问题。

周例会

一般来说一个部门或小组都会每周开个例会，例会容易被当作日常的例行工作而不被重视。例会应该有固定的时间和议程，而且例会是一群经常一起工作并熟悉的人开会。虽然开例会的人都在同一个部门，但并不意味着他们都会相互合作完成同一个项目或事情。所以，例会是通过了解各自工作来完成了解整个部门或小组工作进展的机会，而不是每周固定的休闲时光。当然我们也可以在每周的例会留出一段自由讨论时间，可以畅所欲言，增加工作之外交流。

除了周例会，有些实施敏捷方法的团队也会开每日站立会，每日站立会的一般内容是：

• 昨天干了什么
• 今天计划干什么
• 遇到了什么障碍

每日站立会议的主要目的是让团队成员互相交流互通工作情况，而不是为了让经理们了解情况而召开的会议。每日站立会不是一个团队的人站一圈各自说下工作情况，因为曾经发现彼此并不关心对方工作内容的人站一圈开这个站立会，其意义何在？

分享会

部门内、公司内或行业内都会有各类不同规模分享会，想清楚你为什么要去参加一个分享会？一般来说我只有两个原因，我对分享的内容感兴趣，这应该是大部分人参会的原因。另一个，即使分享内容我已经很熟悉，那么参会的原因一般就是对分享人感兴趣，想要去通过这个分享了解分享人。

还有一种情况可能是碍于面子参加一些完全没兴趣的分享会，恩，这种还是尽量规避吧。

临时会

总会碰到这种情况，突然有个人过来叫你临时去参加个会，然后你就一脸懵逼的去了。这种会似乎属于身不由己，不好规避，这类会议多是非计划性的任务驱动型会议。英特尔前 CEO 安迪·格鲁夫说过：

在现实中，有 20% 的情况还得靠任务导向会议来解决。但如果经理人将超过 25% 的时间用在应急的任务导向会议上，这个组织就一定有了毛病。

这种类型的会议随时召开，而且会针对具体情况产生决策，若这种临时紧急的任务驱动会议太多了，那问题肯定出在平时的工作中。

总结会

可能是项目上线或产品发布后的总结会，也可能是线上故障后的经验教训总结会。我以前开过的很多总结会都变成了领导的总结会，关于这类会大家有什么好想法吗？

参加会议

反思了上面参加过的各种类型会议，然后我得出了一个以后参会的原则：若我没有在会议上发言的潜在可能，就不需要参加。

发言的可能表明你参会是存在主动因素的，需要通过发言（建议、意见、询问、交流）去取得收获。但并不意味着每次参会都需要发言，只是说存在这种可能。比如，参加一个分享会，可能你是想去交流和询问了解一些东西，但可能在分享的过程中你已经有了答案，就没必要发言询问了。

有时你会收到一些莫名的会议邀请邮件，只是因为收件人中有你的名字，就会不自觉地在会议自动提醒弹出时跑去参会。其实在会上发现好像和自己又没多大关系，但进行到一半又不好离场，只好自顾自的玩起了手机，是不是很熟悉的场景？

即使一个临时会，看似完全被动，也可以问问通知人为什么需要你去？很可能通知人会告诉你是 Boss（老板或上司）找你，他也不知道原因？好吧，这种情况只好去了，这里的问题不在你，而在你的 Boss 身上。Boss 可能只是找你咨询一些细节情况，也可能需要咨询你的意见。总之一种完全没准备的临时会议是不利于效率和效果的。

一个正在埋头编程的程序员，突然被通知开个临时会议，程序员还可能陷在前一份编码工作的细节中没切换出来，导致后续的临时沟通讨论都比较低效。所以，若不是特别紧急，尽可能把各种会议安排在一天的开始或结束前，为程序员留出整段的集中时间来进入状态和脱离状态。

组织会议

你可能没想过，有些程序员把开会当作编程一样来设计。

模式

现在后端分布式领域流行微服务架构，所以我也主张微会议，一个会议聚焦一件事，除了分享会，不要召集太多人来参会。人越多可能越混乱和无效，效率损失也很大。

架构

设计程序时需要仔细选择组件，所以可以像编程一样设计会议，剔除多余的资源消耗，保持简洁。仔细分析每个潜在的参会人是否对本次会议有价值，我们不需要一个冗余的玩手机的参会人。如果你发现你的会议上多了一个玩手机的家伙，那不是别人的错，而是你的错误。

实现

在正式编码前，我们早已在头脑或纸上做好了设计，只是用代码将其表达出来。所以，正式开始会议前，请确保参会人都做好了准备，而不是到了会议桌前才开始想这个会议需要解决什么问题？

会议的过程也需要掌控节奏，集中主题，避免发散跑偏。代码实现时总会出现超出当初设计的一些现实问题没考虑到，会议中也可能突然冒出一些新想法，和编码不同，对这些新情况若发现有价值但又无法短时间讨论清楚，可以先记录下来，列入下次会议的议程，而避免本次会议过度发散，导致会议延时，主题分散，没有结论。

...

把开会当作一个程序问题来分析后，我发现开会其实也没那么讨厌了。