今天想换个口味，写一篇关于技术人员招聘的帖子。一来，是照顾一下俺读者群的那些 IT 从业人员——毕竟他们是俺博客最早的一批订阅者；二来，俺也很久没写管理方面的内容了。
本系列介绍的主题是招聘经验。虽说讲的都是 IT 人员招聘的事儿，但大伙儿完全可以举一反三，把某些经验应用到其它行业的招聘中。如果你是一名求职者，或许也能从中了解到某些（和俺类似的）招聘者的思维方式。
俺在两年前写过一篇“招聘的误区”，谈的是整个招聘过程中，一些常见的弊端和误解——也就是“不该如何做”。（那篇帖子侧重于宏观、战略层面）。而本系列主要讲是“该如何做”（偏重于微观、战术层面）。因此，没看过“招聘的误区”的同学，建议先去看看，然后再来看本系列。
为了方便阅读，把本系列帖子的目录整理如下（需翻墙）：
1. 面试 vs 笔试
2. 考察技术 vs 考察非技术
3. 开放性问题 vs 封闭性问题
4. 通过笔试答题能看出啥？
5. 面试前的准备工作
6. 面谈的技巧
7. (未完待续)
推荐阅读：
![俺的招聘经验[5]：面试前的准备工作](https://www.panda.tw/../content/uploadfile/202503/4b1c1741259010.jpg)
3 个月前
俺的招聘经验[5]：面试前的准备工作 文章目录 ★面试官的选择★面试的时间安排★面试的氛围和环境★面试记录★其它注意事项 又有好心的网友到博客留言，提醒俺尽快把招聘系列这个坑给填平。看了一下日期，本系列上一篇距今已13个月。赶紧补上。今天先讲面试之前的准备工作，下一篇再介绍面谈时的技巧。 ★面试官的选择 在企业管理领域，【人的因素】往往是最关键的因素。招聘过程中的面试阶段也是如此。所以本文先从面试官的选择说起。 ◇从“职能”角度考虑 很多人有一个误解，以为面试过程只要考察技术能力就行啦。其实捏，“非技术能力”远远比“技术能力”重要（为啥“非技术能力”更重要，俺在本系列第2篇《考察技术 vs 考察非技术》已经介绍过了，此处不再啰嗦）。所以从职能角度来看，面试官必须同时具备考察这两方面的能力。 对“技术能力”的考察，要求面试官必须非常熟悉应聘岗位所需要个相关技术。这方面大伙儿应该好理解，俺就省点力气，不多费口舌了。 对“非技术能力”的考察，则要求面试官必须善于“阅人”。所谓的“阅人”，就是说面试官要善于察言观色，能够在沟通中洞悉对方的内心活动，能分析出对方说话的动机，甚至能猜测对方说的话包含多少水分。“阅人”的能力，往往需要锻炼足够长的时间，而且要有一定的悟性，才能掌握。 一般来说，很少人有人能够同时兼具这两方面的能力。如果找不到这类人，可以考虑派两个面试官，分别负责“技术能力”和“非技术能力”的考察。 很多软件公司的岗位设置是分“管理线”和“技术线”两个维度的。如果你的公司也是这样设置，那么可以让管理岗位资深的人去考察“非技术能力”，让技术岗位资深的人负责“技术能力”的考察。 ◇从"工作关系"角度考虑 说完“职能”的角度，再来说说“工作关系”方面的考虑。 以俺的经验，面试官最好选择【和招聘岗位工作关系密切的人】来担任。比方说有个 Team 要招人，那么该 Team 的 Leader 最好是面试官之一。 ◇面试官的人数 面试官人数的考虑，主要是基于时间成本。因为能够去当面试官的人，往往是管理上或技术上比较资深的。这类人的时间成本往往也比较高。因此，对初级岗位（由新手担任的岗位）的面试，通常只要1到2个面试官即可。 反过来，如果招聘比较高级的岗位（比如资深工程师、主管、经理），则可以考虑3个或更多的面试官。因为越资深的岗位，不但工资成本更高，而且一旦招了不合适的人，对公司造成的损失也越大。对这样的岗位，面试的把关也越发重要。多一个面试官，就多一个观察的角度，容易发现应聘者自身的问题。 ◇面试官的主从安排 如果面试官 ＞= 2 人，最好事先指定以某个人为主，其他人为辅。主要的提问和沟通由主面试官进行，辅助面试官则侧重于从旁观察应聘者。 一般而言，都让最有经验的家伙做主面试官。不过也有例外。比如俺有时候想让手下某个人（比如张三）锻炼一下，就会叫上张三一起去面试，然后让张三做主面试官，俺做辅助面试官。 ◇面试官的备份 在指定面试官的时候，要考虑备份人选。当应聘者来面试的时候，万一某个面试官正好有事（在开会、出差、请假......），那备份人选就可以顶上。 ★面试的时间安排 ◇笔试和面试的间隔 能够通过笔试的应聘者，通常会比较抢手——这样的人往往也容易被其它公司相中。如果面试距离笔试的间隔太久，有可能这个应聘者已经到其它公司报到了。 俺个人建议，笔试和面试的间隔【不要】超过3个工作日。 ◇面试的轮数 假如某个岗位比较重要，面试官的人数 ＞=4，那么就不要放在同一轮面试，而要考虑安排2到3轮面试。同一轮面试中，当面试官太多，可能会有如下问题：1. 人数越多，面试官的时间利用率越低2. 人数越多，凑齐这些人就越难 ◇多轮面试的间隔 刚才说了，笔试和面试的时间间隔不宜过长。同样的道理，（如果存在多轮面试）轮次之间的间隔也不宜太久。 俺通常的做法是：把两轮面试一起搞定。也就是说，前一轮结束立即开始下一轮。这么做除了有利于快速决策，对应聘者也有好处——省得多跑一趟。 即使无法把两轮面试一起搞定，其时间间隔最好也【不要】超过3个工作日。 ★面试的氛围和环境 ◇场所 由于面试官加上应聘者，通常不会超过4个人，所以面试最好在一个比较小的会客室（会议室）进行。如果在一个太大的会客室进行面试，显得太空旷，应聘者心理上的感觉不太好。 另外，太大的会客室，往往桌子也很大。这会导致面试官与应聘者间隔太远，不利于观察应聘者的某些细微的表情变化（下一篇会聊如何“察言观色”）。 ◇氛围 另外，面试官营造的氛围也很重要。有时候要根据招聘的岗位，刻意营造某种特定的气氛。 假如招聘的岗位是售前工程师或售后工程师，由于这类岗位需要面对最终用户的刁难。所以对这类应聘者，面试官可以故意营造具有压力的气氛，以此来测试应聘者的抗压能力。 反之，如果招聘的是普通的研发人员，则最好营造宽松的气氛。通过让应聘者放松，避免他/她太紧张导致发挥失常。 ◇道具 进行面试的会议室最好有个白板。当聊到某个特定话题时，可以立马让应聘者在白板上涂涂画画。 有条件的话，还可以再配一个笔记本电脑。当然啦，这台电脑必须要装若干必备的软件。比方说，如果面试程序员，那就装若干常见的开发环境（编辑器、编译器、调试器 ...）；如果面试测试人员，就准备若干测试工具/测试环境。 ★面试记录 管理比较完善的公司通常会为面试官准备一个面试记录的表格。面试官可以一边面谈一边记录，也可以面试结束后再填写。 ◇内容 面试记录至少包括如下信息：1. 该应聘者在非技术方面有哪些优点、缺点2. 该应聘者在技术方面有哪些优点、缺点3. 是否录用 关于最后一项“是否录用”，俺专门强调一下。这一栏是【必填】的，而且只能有两个选项：“Yes / No”。如果面试官对某个应聘者犹豫不决，吃不准是否要录用，那么就填【No】。 俺再啰嗦一次，面试过程的一个重要原则就是宁缺毋滥。 ◇用途 面试记录有如下好处：1. 如果对某个应聘者的面试 >= 2轮，那么前面轮次的面试官所做的记录可以留给后续轮次的面试官看，有利于信息共享并提高面试效率（比如避免问重复的问题）2. 当应聘者通过面试并入职，通常还有一个试用期。对这个新员工的试用期考核可以结合“面试记录”来进行，这样会更有针对性。3. 面试记录还可以用来对面试官进行考核。当面试的次数足够多之后，通过面试记录的准确程度可以判断面试官“阅人”的功力。 ★其它注意事项 ◇简历和笔试答卷 面试官去见应聘者之前，一定要先把该应聘者的简历浏览一遍。另外，能够进入面试环节的应聘者，往往之前已经通过笔试了。所以面试官最好也把此人的笔试答卷先过目一下。 通过事先浏览这两样东西，接下来的面谈可以有针对性地提一些问题。 ◇不要让应聘者等太久 来面试的应聘者通常会先在会客室等待。俺个人建议，不要让他/她等太久（最好不超过10分钟）。这是对人起码的尊重。很多招聘者总觉得自己是强势方，不太尊重应聘者。这种风气很不好。 另外，如果让应聘者等的时间太长，应聘者对这家公司就会有不好的第一印象。一旦这个应聘者被录用，这个不好的第一印象可能会产生消极影响。回到本系列的目录 版权声明本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2012/12/hiring-experience-5.html
![俺的招聘经验[4]：通过笔试答题能看出啥？](https://www.panda.tw/../content/uploadfile/202503/4b1c1741259208.jpg)
3 个月前
俺的招聘经验[4]：通过笔试答题能看出啥？ 文章目录 ★笔试的目的★笔试题的形式★思路/想法★规范性★细心★严密性★条理性★结尾 前两天，有好心的网友在博客和Google+留言，催促俺赶紧写招聘系列的下一帖。被这一提醒，猛然发现这个招聘系列已经中断半年之久。今天赶紧补上。按照原先的计划，本帖应该开始聊面试的话题，但俺觉得笔试的话题还缺了一块，今天就继续聊俺在笔试方面的经验。 ★笔试的目的 在前面的帖子，已经跟大伙儿聊了笔试和面试的优缺点以及这两者该如何搭配。考虑到很多网友比较健忘，再略微回顾一下。笔试的成本（这里指时间成本）比较低，所以应该安排在第一轮。通过笔试，至少要能淘汰掉80%以上的应聘者（还记得《无处不在的二八原理》吗）。这样一来，面试官才有足够的时间和精力，去筛选剩下的这些人。 因此，笔试题目要有足够好的区分度——能够比较明显地体现出应聘者的差别。否则的话，笔试就起不到筛选的效果。 ★笔试题的形式 俺出的（针对开发人员的）笔试题，大都只有问答题和程序题，没有选择题或填空题。因为选择题以及大多数的填空题都属于封闭性问题。封闭性问题不但区分度很差，还有诸多缺点（《开放性问题 vs 封闭性问题》一文已介绍过，此处不再啰嗦）。 为了让大伙儿有一个直观的认识，俺后面谈的话题，都会拿同一个例子来说事儿。这个例子就是：求质数。（质数也叫素数，小学数学就教过了，俺就不解释了）。为啥要拿这个例子捏？因为这是一个老掉牙的面试题目，貌似国内外很多软件公司的面试题都有它的身影。想必很多人对它都不陌生，俺就不必浪费口水多作解释了。 ★思路/想法 说到思路和想法，俺发现不少招聘者在给笔试题打分的时候，都有一个毛病："只看对错，不管其它"。其实，"思路和想法"往往比"对错"更重要——它可以反应出一个人的知识面、创造性等多种素质。而这些素质对于一个开发人员是很重要滴。一个富有idea的程序猿会有更多的发展前景；而一个缺乏idea的程序猿，则会逐渐沦为码农，只能做一些重复性的体力活。 举例说明： 假如有两个应聘者A与B来做这道"求质数"的题目。A用最普通的"试除"来判断质数并且程序实现正确无误；B使用"筛法"来求质数（没听说过筛法的同学，请看"这里"的介绍），总体思路对头但程序有些小Bug。那么，俺会更看好B同学。为啥捏？ 假如B同学之前就听说过筛法，那说明此人数学的知识面应该比较广；如果B同学之前没听说过筛法，是自己独立想出来的，那这个人应该很有才。反之，用"试除"求质数的思路，太过于普通，小学生都能想到。 顺便说一下：某CSDN网友居然在留言中说，求质数这道题没啥意义。这让俺情何以堪啊！所以，俺干脆又写了一篇《求质数算法的N种境界》，让大伙儿（尤其是菜鸟程序猿）瞧一瞧求质数有多深的奥妙。 ★规范性 俺拿到应聘者的答卷时，总是先花几秒钟时间，粗略扫一眼程序题。因为从一个人写的代码，可以很容易地判断出：此人是否养成良好的编码习惯。在筛选程序猿的时候，俺宁可要那种虽然技能差但是习惯好的，也不要那种习惯差但是技能好的。因为"习惯"是一种很顽固的东西——很难通过培训加以改变的；而技能相对来说，比较容易通过培训加以提升。 关于编码的规范性，大致有如下几个方面： ◇排版是否规范 比如：应该缩进的地方是否有缩进？该留空格或空行的地方，是否留出来？ 假如某个应聘者写的程序，连最基本的"作用域缩进"都没有体现出来。那么，大致可以判定此人的基本素质很成问题。 ◇命名是否规范 比如：命名变量名的时候，是用无意义的单字母变量名，还是用具有可读性的英语单词。说到英语单词，顺便提一下：有些应聘者写的程序里，居然用拼音来命名，真是让人大跌眼镜。 ◇是否有恰当的注释 前面2条，大多数人都会留意到。但是很多人都忽略了注释。 通过代码注释，可以看出代码作者的编码功底。新手写代码，要么不写注释，要么注释里尽写些废话，犹如画蛇添足；而优秀的程序猿写的注释言简意赅、恰到好处，有画龙点睛之妙。 ★细心 和刚才提到的编码习惯类似，细心也是很难通过培训加以改变的。要看出应聘者是粗心还是细心，只需在面试题目中留一些隐蔽的陷阱即可。 俺在招聘"初级软件工程师"的笔试题中，也用了"求质数"这道题，题目是这样说的： 请实现一个函数，对于给定的整型参数 N，该函数能够打印出自然数中的头 N 个质数。 请大伙儿把题目仔细看喽！然后，大伙儿猜猜看，有多少人审题出错？据俺保守估计，大概在95%以上！绝大多数的答题者，都把题目错误地理解成： 请实现一个函数，对于给定的整型参数 N，该函数能够打印出头 N 个自然数中的质数。 列位看官扪心自问一下，你是不是也属于看错题目的那95%的人？ 这两句话，只不过有3个字挪了一下位置，意义全然不同（再次感叹，汉语真是一门模糊的语言）。俺当初设计这道题目的时候，就是故意留个坑，但是没想到有这么多人掉坑里。 ★严密性 可能有同学认为严密性和细心是一回事，其实两者有点区别（当然，细心的人通常也比较严密；反之亦然）。对于软件工程师而言，严密性体现在：编写出的代码是否尽可能地考虑到各种非正常的情况。 一个严密的程序猿，写出来的代码自然也比较严密。严密的代码会带来两大好处：其一，代码的Bug率通常比较低；其二，代码通常比较安全，不易被入侵。关于Bug率，搞开发的应该都晓得；但是代码的安全性，貌似很多开发人员不太清楚。俺简单聊一下。 大概是在安全界混的时间比较长，俺对代码安全性的好处深有体会。大部分入侵者对某个软件系统（比如Web服务器，数据库服务器）的攻击，都是利用了软件代码中隐含的漏洞。而这些漏洞往往是因为编写代码的人考虑问题不严密而留下的安全隐患。 大伙儿不要误会，以为代码安全的问题很遥远，跟自己无关。其实这是一个很普遍的、跨行业的问题。无论是放在互联网上的网站、还是企业的内部系统，或者是大众化的桌面软件，都存在被入侵的风险。因此，编写安全的代码是每个程序猿都面临的问题。 说了这么多，就是想让各位明白，严密性的重要所在。那么，如何看出应聘者是否具有严密性捏？俺继续以"求质数"作为例子。 在"求质数"的题目中说了：函数参数N是一个整型。那么，一个严密的程序猿，会在函数开头，就检验该参数的有效性。一旦发现参数有问题（比如说，N为0或者N为负数），就给出相应的处理（比如，断言失败、抛出异常、等等）。因为在这个场景里面，N<=0 是没有意义的，而且有可能引发程序崩溃。 顺便说一下，要编写出足够健壮且不易被入侵的代码（行话叫做"防御性编程"），是很有讲究滴，称得上是门学问。如果有读者感兴趣，俺以后找个机会聊一聊。 ★条理性 最后，再稍微说一下条理性。在笔试中，不论是问答题还是程序题，都可以看出一个应聘者的条理性。 有条理的程序猿写出来的代码，层次清晰，条理分明——很易懂且看了很爽；反之，缺乏条理性的程序猿写出来的代码，就像一团乱麻——看起来很吃力且让人抓狂。 由于"条理性"大伙儿比较好理解，俺就不举例了。 ★结尾 从应聘者的笔试答题中，还能看出很多其它的信息。不过上述这几条，是俺认为比较重要而且也具有可操作性的。 本系列的下一个帖子，俺来聊一下面试过程有哪些讲究？回到本系列的目录 版权声明本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2011/11/hiring-experience-4.html
3 个月前
招聘的误区 文章目录 ★人力资源部（以下简称 HR）包办一切★错误的筛选条件★只考察技术因素，不考察其它因素★只注重死问题，不注重活问题 上次在“二八原理系列”中谈到了“如何找到优秀的开发人员”。当时主要是结合“优秀人员”的稀缺性来谈优秀人员的招聘问题。今天打算换一个角度，抨击一下当前很多软件公司在招聘方面的弊端。 ★人力资源部（以下简称 HR）包办一切 有些公司从招聘网站登职位说明、到筛选简历、到面试、到决定是否录用、到录用后给什么样的待遇，统统都由 HR 来一手操办。留给用人部门的，只剩下出笔试题和批改笔试题（因为笔试题 HR 确实搞不定）。 这是今天要介绍的弊端中最荒唐的一种。把如此关键的工作托付给无力胜任的人，其糟糕的程度可见一斑。假如你所在的公司就是这么干的，那得赶紧考虑跳槽换公司了。 在俺看来，用人部门对于人员招聘必定是居于【主导】地位的。从确定岗位描述、到筛选简历、到筛选笔试结果、到面试、到决定是否录取、到确定工资待遇，基本上都应该由用人部门主导进行。 说到这里，有同学会问了：那 HR 不是白吃干饭，啥事也不用干嘛？那倒也不是，HR 部门需要在招聘过程起一个辅助的作用（说难听点就是打杂），比如：到招聘网站登广告啦、分发简历给用人部门啦、打电话约人来面试/笔试啦、打印笔试考卷啦、录用后填写各种表格啦，这些琐碎的活都应该让 HR 来完成。 ★错误的筛选条件 另一个比较糟糕的弊端在于使用不合适的筛选条件。典型的有如下几种： 必须是对口专业的（比如要求计算机相关专业）必须是名牌/重点大学的必须是有某学历的（一般是：至少本科、研究生更好）必须是在某个年龄段的（一般是：30太大、20太小）必须是某性别的（一般是：只要男的，不要女的）...... 很多公司会根据上述这些条件来决定应聘人的待遇；还有一些公司甚至对达不到这些条件的，一概不予考虑。 其实符合上述条件的，未必是优秀开发人员；而优秀开发人员，也未必符合上述条件。两者之间，既非充分条件，也非必要条件。所以，根据这些条件筛选，并无助于找到优秀开发人员，甚至有时候反而会【淘汰】优秀的开发人员。（至于为什么这些条件不合适，以后咱专门开个帖子聊） 比如我部门的【骨干】开发人员，就没有人能完全达到上述要求（俺自个儿就有三个没达到）。如果非要拿上述条件作为硬指标进行过滤，指不定猴年马月都见不着一个满意的。 所以俺自个儿在写招聘要求时，都会特地强调：专业不限、学历不限、年龄不限、性别不限。 ★只考察技术因素，不考察其它因素 很多公司在面试开发人员的时候，光考察了应聘者的技术能力。但是却忽略了一些更加重要的【非】技术因素。下面就把我认为很重要的【非技术因素】简单介绍一下。 ◇正直（诚信） 正直是我认为【最重要】的一条。关于这条的重要性，大伙儿可以看看巴菲特的名言：当你雇用某人，要看他是否具备三种品质：正直诚实、聪明能干和精力充沛。如果缺少第一种品质，那后二种品质会要你的命。他老人家都已经把话说到这份上了，我也无需再多说啥了。一旦在招聘过程中发现应聘者有诚信问题，就必须立即放弃。要记住：【长痛不如短痛】。留下一个诚信有问题的人，那是后患无穷啊！ ◇兴趣和热情 一般来说，兴趣和热情是密切相关的。当你对某事情有兴趣了，也就容易产生持久的热情；有了持久的热情，那工作的效率和质量也就有望得到提升。 （俺后来又写了一篇专门谈兴趣——《什么是【真正的】兴趣爱好？以及它有啥好处？》。大伙儿可以去看一下） ◇学习能力 关于学习能力的重要性，在之前的帖子也已经阐述过了，大伙儿可以参见“这篇博文”，此处不再啰嗦。 ◇团队协作能力 除非你要招聘的岗位是单枪匹马搞研究，否则团队协作能力是一项不容忽视的因素。很多不良的习惯都可能影响到整个团队的协作，随便举几个例子：比如有些技术能人自持功力深厚，看不起周围技术比他差的人；比如有些人自行其事，不注意别人的感受；比如有些人喜欢贪天之功，据为己有。诸如上述这些不良习惯都会大大降低团队的凝聚力，造成人心涣散。因此在招聘过程中，要注意观察应聘者是否具有类似的陋习。如果有的话，也应尽早放弃。 前面说了这许多因素，咋样才能在招聘过程中鉴定出捏？这个说来就话长了。限于篇幅，咱下次单独聊一下（请翻墙看“这里”）。 ★只注重死问题，不注重活问题 很多公司在笔试或面试时，都过于注重考察某些【死】的东西，而忽略了【活】的东西。那啥东西算是“死”的，啥东西算是“活”的捏？所谓【死问题】，就是那些单纯靠死记硬背就能够回答出来的问题；所谓【活问题】，则是那些需要有一定的理解能力、分析能力、归纳能力、推理能力才能够解答的问题。 大伙儿如果还是琢磨不透“死活问题”的区别，可以去看看俺在“学习技术三部曲”里面提到的“WHAT、HOW、WHY”。一般来说，和 WHAT 相关的问题，大都属于“死问题”；和 HOW、WHY 相关的问题，则大都（但不绝对）属于“活问题”。 由于“死”问题一般都比较容易临时抱佛脚，所以应聘者可以通过短期的突击准备来搞定，从而在笔试/面试中蒙混过关；相对而言，“活”问题则需要有相当时间的积累和相当的悟性方能掌握。所以，考察“活”问题更有利于找到那些真才实学的家伙。俺博客上，和本文相关的帖子（需翻墙）：俺的招聘经验（系列）什么是【真正的】兴趣爱好？以及它有啥好处？硅谷 CEO 们的教父——分享安迪·格鲁夫的管理经验如何成为优秀开发人员（系列） 版权声明本博客所有的原创文章，作者皆保留版权。 转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2009/04/defect-of-hire.html
3 个月前
俺的招聘经验[3]：开放性问题 vs 封闭性问题 文章目录 ★什么是开放性问题？什么是封闭性问题？★教育体系导致的偏差★如何设计开放性问题？★总结 在本系列的"前一个帖子"，已经强调了“非技术能力”的重要性。那么，在笔试/面试中，如何看出应聘者的非技术能力捏？很关键的一点就是要能够提出好的问题。所谓好的问题，不光可以考察出应聘者的技术能力，还可以考察出非技术能力。这样，就能更准确地推测出，此人胜任相关岗位的概率有多大。 怎样才算是好的问题捏？这可是见仁见智，众说纷纭啊。关于问题的好坏，在不同的维度下有不同的标准。今天，俺就从“开放性/封闭性”这个角度来进行阐述。 ★什么是开放性问题？什么是封闭性问题？ 所谓的开放性问题，就是说问题的答案不是唯一的（通俗地说就是：没有标准答案）。比如说：“如何翻墙？”反之，封闭性问题都有唯一的标准答案。比如说：“三角形的内角和是多少？” ★教育体系导致的偏差 为了让大伙儿更好地体会这两类问题的差异，请允许俺先来恶毒地攻击一下天朝的教育体系。 根据俺的亲身经历，中国大陆的教育体制，是一种极端的应试教育。在这种教育体制下，负责出考试题的人，显然都希望出封闭性问题（因为有唯一的标准答案，容易打分嘛）。而教师为了让学生能考得好成绩，就拼命培养学生解答封闭性问题的能力。 有些理工科的考试用封闭性问题，也就罢了。最恶心的是，有些文科的问题，居然也能搞成封闭性问题（真是不服不行啊）。记得俺初中上政治课，有一道题目是为什么要坚持四项基本原则？，政治老师写了洋洋洒洒几百字，然后让我们一字不差地背下来...... 在天朝之下，虽然各位同学懂得如何应对封闭性问题。但遗憾的是，在进入社会，参加工作之后，很多同学都会发现：工作中碰到的问题，几乎都是开放性问题。光凭这点，天朝的教育制度实在是非常的失败！ 费了这么多口水谈教育体制的弊端，俺还想说明一点：天朝的学校里培养出来的好学生，在工作中未必就能力强；甚至是学习成绩和工作能力成负相关的关系。所以，俺在招聘时，通常不关心应聘者的学校、专业、学历。 ★如何设计开放性问题？ 既然开放性问题如此重要，那如何才能设计出开放型问题捏？可以从如下几个角度来考虑。 ◇提问实践性的问题 所谓的实践性问题，就是给定某个需求，询问应聘者该如何实现。通常，给定的需求往往有不止一种的实现方式，因此这类问题通常属于开放型问题。 这类问题往往和应聘者今后所从事的工作内容息息相关，因此是最有效的考察方式。好比你要招聘一个厨师，你当然得询问他/她，某某菜该如何做。 俺招聘软件开发人员时，通常会在笔试阶段，让应聘者完成某个程序。很多人以为，写程序仅仅是考察技术能力，其实不然。俺除了看这个程序本身是否符合需求，还会看程序的代码风格、注释、错误处理等等细节。通过这些细节，可以从侧面了解应聘者的性格。 ◇提问理解型的问题 所谓理解型的问题，顾名思义，就是无法依靠死记硬背来回答的。那些单纯靠死记硬背既可搞定的问题，俺称为“记忆型问题”。俺在“学习技术三部曲”（需翻墙）里面提到的“WHAT、HOW、WHY”，可以帮你判断一个问题是理解型的还是记忆型的——WHAT型的问题通常是记忆性的，WHY型的问题通常偏重理解性，HOW型的问题则两者兼有。 考虑到本系列帖子不仅仅是面向IT开发人员，所以俺举一个小学数学的例子（大伙儿应该都上过小学）来说明：如果问：3的倍数有什么特征？很多人都能回答：3的倍数就是各位数之和能被3整除。（比如，27是3的倍数，因为2+7能被3整除）但是问：为什么各位数之和能被3整除，就是3的倍数？就少有人能答得出来了。 显然，大部分理解性的问题都是开放性问题。它需要被提问的人对问题的领域有一定的理解，才能回答。而且不同的人，理解的角度不同，所以是没有标准答案的。 另外，或许有些擅长背题库的人，也能回答出WHY型的问题。但是由于他/她是机械记忆，并没有真正理解。所以你只要在他/她背完答案之后，针对答案中的某个环节再问一个“为什么”，对方就歇菜了。 ◇提问个性化的问题 所谓的个性化问题，就是该问题和被提问者本人密切相关。既然问题特定于某人，显然不会有标准答案（属于开放性问题）。 比如俺在面试XX程序员时（XX表示某编程语言或某个IT领域），经常问：你最近看了什么XX方面的书籍、资料、文章？ 假如对方一个都说不出来... 俺会想：此人很可能对该领域没啥兴趣且没啥学习热情。 假如对方说了某本书的名字... 俺就会接着再问：请介绍一下这本书里面，你印象最深的章节。 假如对方支支吾吾说不出来... 俺会想：连印象最深的内容都说不出来，多半是忽悠！ 假如对方流利地说出了某个章节的内容... 俺会针对他/她说出的内容，再追问一些WHY型的问题，以考察对方是否真的理解了。...... 经过上述的连番盘问，那些只会背题库，肚子里面没啥货色的，就很难蒙混过关了。 类似的个性化问题，还有如下供参考： 你为什么离开前一个公司？你为什么到我们公司来应聘？你今后有什么职业规划？你业余时间都干些啥？...... 很多应聘者在回答个性化问题时，往往不会说出真实想法——最典型的就是关于你为什么离开前一个公司这个问题。所以，主考官要根据对方的回答，针对性地问出一连串的后续问题。通过不断的追问，如果对方在一开始说谎了，后面就会露出破绽。 ◇提问主观性的问题 所谓的主观性问题，就是让应聘者对某些问题发表看法。因为人与人之间是千差万别，所以这类主观性问题也是没有标准答案的开放性问题。 举几个主观性问题的例子： 你理想中的工作环境是什么样的？为什么？你喜欢用哪种编程语言，哪种开发工具？为什么？你希望从事哪个方面（UI/网络/数据库/算法/等）的软件开发？为什么？...... 通过主观性问题，首先是了解应聘者的喜好；进而可以了解其价值取向，看问题是否深刻/全面；最后，可以分析出应聘者的一些性格特征。 和个性化问题类似，有些精明的（狡猾的）应聘者在回答主观性问题时，会投其所好，故意迎合主考官。为了不被这种人蒙蔽，主考官一定要多问几个“为什么”。 ★总结 上述介绍了4种常见的开放性问题。一般来说，实践性问题和理解性的问难，既可以考察技术能力，也可以考察非技术能力；而后面两种，则偏向于考察非技术能力。在安排方面，头两种可以用于笔试和面试；而后两种偏重于面试。 本系列下一篇，谈一谈如何通过笔试题来筛选应聘者。回到本系列的目录 版权声明本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2011/05/hiring-experience-3.html
3 个月前
俺的招聘经验[2]：考察技术 vs 考察非技术 文章目录 ★综合素质的构成★非智力因素的重要性★面试题/笔试题的现状★结尾 前一个帖子介绍了笔试和面试的优缺点。今天聊的话题是——招聘应该考察技术还是考察非技术？ 之所以把这个话题单独拿出来，写一个帖子，是因为俺注意到：很多公司在招聘时，光考察技术能力，而完全忽略了非技术能力（俺在“招聘的误区”中提到过）。今天，俺来解释一下，考察“非技术能力”的重要性。 ★综合素质的构成 无论是面试还是笔试，最终目的都是筛选出综合素质（综合能力）较高的人，然后再从这些人当中，找出性价比最好的。而要评估综合能力，首先就得搞清楚综合能力包含哪些方面。 综合素质有许多种分类法，俺个人比较喜欢把它分为智力部分和非智力部分。 ◇智力因素 智力因素，就是通常所说的是否聪明。智力的构成，简单来说可以分为：观察能力、记忆能力、思维能力。观察能力负责获取信息；记忆能力负责存储信息；而思维能力则负责处理信息。 显然，思维能力是最重要的。而思维能力，又可以再分为：理解、判断、分析、概括、抽象、推理、创造、......在这几种思维能力中，最值钱的，应该属“创造”。 ◇非智力因素 那非智力部分，又包含哪些玩意儿捏？这个说来就话长了，俺把主要的列举一下。非智力因素【至少】包括了：性格、意志、心态（心智模式）、情绪、兴趣、等。 ★非智力因素的重要性 为啥说非智力因素很重要？俺挑几个来解释一下。下面这几项，在招聘过程中需要着重考察。 ◇性格 俺很喜欢一句俗话，叫【性格决定命运】。这句话彻底道出了性格的重要。虽说性格很重要，但性格没有好坏与否，只有合适与否。招聘的时候，要特别关注应聘者的性格与招聘岗位是否相匹配。假如说你要招一个销售，那性格过于内向的，显然就不太合适。 ◇意志 意志力是克服惰性的关键。意志力越强，就越能够克服惰性。 那什么是惰性呢？俺把它理解为对痛苦的逃避，可以分为生理惰性和心理惰性两种。比方说在冬天的早晨，很多人都不愿意离开温暖的被窝，这就是生理惰性在起作用；再比如一些内向害羞的人，不愿意和陌生人沟通，这就是心理惰性。 显然，在招聘时，尽量找意志力强的人。 ◇兴趣 当一个人对自己干的事情充满兴趣，那惰性也就会自然消失。因为在这种情况下，痛苦已经被兴趣所引发的激情给压抑掉了。比如一个热衷于打游戏的人，可以通宵达旦，而不觉得疲劳。 所以，招聘时要尽量筛选那些对所从事的工作充满兴趣的人。（关于兴趣的重要性，还可以看看俺刚开搏时写的“老帖子”） ◇心智模式 关于“心智模式”，俺写过另一个帖子“认识你自己——有关心智模式的扫盲介绍”。看过之后，或许你会明白这玩意儿的重要。限于篇幅，此处不再啰嗦。 ★面试题/笔试题的现状 前面费了很多口水，聊了综合素质的构成以及“非智力因素”的重要。现在来分析一下，眼下很多面试题和笔试题的现状。 ◇先看几个例子 Java 的考题final、finally、finalize有啥区别？String和StringBuffer有啥区别？C++ 的考题指针和引用有啥区别？sizeof(bool) 是多少？OO 方面的考题面向对象的4个要素是啥？算法方面的考题列举你知道的排序算法？二分查找的时间复杂度是多少？ ◇弊端之一 看完这几个例子，你是否发现它们的共同点？那就是纯粹【考验记忆力】。前面已经阐述过，智力因素中，重点是“思维能力”。而“记忆能力”的重要性远远不如“思维能力”。如果在面试/笔试中，大部分的题目都是这种类型，直接导致的后果就是——便宜了那些擅长死记硬背的家伙，而让那些擅长思考的人吃亏（同样的问题，也出现在国内的应试教育体制中）。 ◇弊端之二 除了“无法考察思维能力”这个弊端，上述这些考题也根本无法考察出非智力因素（比如性格、兴趣、心态、等）。拿这样的题目来筛选应聘者，招来的人可能不合群、可能缺乏激情、或许还不能吃苦、或许还眼高手低...... ★结尾 那应该用什么样的题目，才能比较全面地考察智力因素及非智力因素捏？请听下回分解。回到本系列的目录 版权声明本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2011/03/hiring-experience-2.html
3 个月前
俺的招聘经验[1]：面试 vs 笔试 文章目录 ★面试的优点（笔试的缺点）★笔试的优点（面试的缺点）★笔试和面试如何搭配★结尾 直到现在，还有很多软件公司在招聘程序员时，仅仅搞面试，而没有搞笔试。其实，面试和笔试都很重要。两者各具优缺点，互相不可替代。下面俺大致总结一下，面试与笔试，都有哪些优缺点。 ★面试的优点（笔试的缺点） 面试有如下几个明显的好处，是笔试所没有的： ◇可以察言观色 所谓察言观色，就是面试官通过对应聘者的谈吐、表情、神态的观察，从而加深对应聘者的了解。有经验的面试官，可以在几句话之内，就大致了解对方的性格、心态、自信度、等各种信息。（本系列后面的帖子，会具体介绍一下此技巧） ◇可以随机应变 有经验的面试官在提问时，会随机应变，根据应聘者的回答，动态调整要问的下一个问题。这样一来，面试的效率会高很多。而且，由于问题是动态变化的，没有固定的套路，应聘者较难作弊。 ◇可以制造压力 还可以通过面试，制造压力，从而考察应聘者对压力的承受度。有时，俺会找1-2个同事一起去面谈某个应聘者——首先在人数上制造某种压力。然后在交谈的过程中，有人唱红脸，有人唱黑脸。这样一来，就能看出抗压能力了。 ★笔试的优点（面试的缺点） 说完面试的优点，再来对比一下笔试的。 ◇可以节省面试官的时间 笔试和面试有一个显著的差别，就是无需单独沟通。所以笔试能为招聘者节省不少时间精力。 假如你招聘的职位比较吃香，可能一下子来了好几个应聘者。如果每一个都单独面谈，会忙不过来。而笔试不需要一对一面谈，可以同时进行，在“并发性”方面优于面试。 ◇可以考察动手能力 在面试中，经常会碰到夸夸其谈的程序员。这些人说起某个技术领域，那是口若悬河、滔滔不绝。咋一看好像很牛X。但如果给他/她一个具体的问题，让他/她写个程序出来，那些没有真本事的家伙，一下就露馅了。 举例：眼下有些计算机系的应届生，问他/她冒泡排序或者二分查找，都能说出个一二三。但是让其写出具体程序（无论是纸笔或上机），很多人就歇菜了。 ★笔试和面试如何搭配 既然面试和笔试，都不可或缺，那两者该如何搭配捏？俺的做法是分为如下几个阶段（人事部门的面谈通常放在最后，本文不提及）。 ◇第1阶段 - 纯粹笔试 如果每个来公司应聘的人，都一一面谈，会把面试官累趴下的。所以，头一轮要利用笔试来过滤掉80%的应聘者（还记得《无处不在的二八原理》吗）。为了达到这个目的，笔试题必须很有讲究。“好的笔试题”，才能够把不同能力的人，明显地区分出来。而且，好的笔试题，还可以避免应聘者作弊。 肯定有同学会问：怎样才算是“好的笔试题”捏？其实在《招聘的误区》一文，俺已经稍微谈到了（参见“只注重死问题，不注重活问题”）。本系列后续的帖子，会更详细地分析这个话题。 ◇第2阶段 - 面谈为主（偶尔夹带笔试） 笔试过关的人，会安排进行第2轮面谈。 在此，有必要说明一下。所谓的面试，不是纯粹动嘴皮子，偶尔还是要动手的。比如面谈中聊到了设计模式，应聘者号称对XX模式很熟悉，那俺会顺手把简历的背面翻过来，让对方在上面画出XX模式的类图（结合具体的使用场景）。 还有，面谈中该问哪些技术问题，与出笔试题目一样，是有讲究的。要尽量问【好的问题】。这道理前面已经聊过，此处不再啰嗦。 ◇第3阶段 - 上机实战 并非所有人都需要进行到第3阶段。通常，如果俺要招聘的是一个高成本的开发人员，并且此人顺利通过了头两关，那就会安排进行第3阶段“机试”。 上机实战相对于纸笔写程序，会更加真实，更加能看出一个人的实力。关于上机实战的注意事项，俺后面单独写个帖来介绍。俺猜测，会有同学质疑“上机实战”的必要性，俺会在那个帖子里一并解答。 ◇小结 总的来说，越往后的阶段，（对招聘方的）时间成本越高。所以，招聘中低端的人才，侧重用前面几轮（笔试和面试）；招聘中高端的人才侧重于后面几轮（面试和实战）。 ★结尾 俺不喜欢一个帖子写太长（俺写着累、大伙儿看着也累），所以今天暂且说这么多。下一个帖子，聊一下招聘过程中，非技术因素的重要性。回到本系列的目录 版权声明本博客所有的原创文章，作者皆保留版权。转载必须包含本声明，保持本文完整，并以超链接形式注明作者编程随想和本文原始地址：https://program-think.blogspot.com/2011/03/hiring-experience-1.html
3 个月前
今天想换个口味，写一篇关于技术人员招聘的帖子。一来，是照顾一下俺读者群的那些 IT 从业人员——毕竟他们是俺博客最早的一批订阅者；二来，俺也很久没写管理方面的内容了。 本系列介绍的主题是招聘经验。虽说讲的都是 IT 人员招聘的事儿，但大伙儿完全可以举一反三，把某些经验应用到其它行业的招聘中。如果你是一名求职者，或许也能从中了...
臺灣ICP000000001
您好站长，申请贵站收录 网站名称：...
提交链接
@5ZN2liXC：您好，已经添加了哦！...
提交链接
您好站长，申请贵站收录 网站名称：...
提交链接
@5ZN2liXC：您好，已经添加了哦！...
提交链接
类别：博客站点 名称：小报童专栏 地...
提交链接
类别：在线工具 名称：夸克搜 地址：...
提交链接