也谈招聘---这个人会什么

    近日看了一篇帖子《关于最近面试的一点感想》，大家讨论的很激烈，也由此引发了我的很多感想，结合我面试别人的一些经验，谈谈我自己的一些看法，在各位大侠们的面前班门弄斧了，不对的地方，还请大家指正。

    面试一个人的目的，我认为有以下几点是需要搞清楚的：
    一、这个人会什么（以前的情况）
    二、能力如何（可发展的情况：不是技术能力,是解决问题的能力、学习能力等）
    三、我们能不能用，怎么用（将来的情况）

    今天先说第一点，这个人会什么？

    怎么才能知道一个人会什么那？通常的方法就是考试，从小学到大学，从本科生到研究生，大家一路考来，似乎已经非常认同考场上逞英雄的办法了，于是有的人找替考，有的人买答案，有的人埋头苦读，都为了能在考试中多得个几分而努力着，却忘记了考试的目的，不是如何答对考题，而是如何解决问题。高分低能的现实告诉我们，没有很好的理解怎么用而死记硬背的人，往往不能很好的解决真正的问题。

    在目前的招聘中，还是有很多以考题来定乾坤的公司，经常给你出一些个算法啦，概念啦的东西，如果你不过，很可能就没有面试的机会，更不可能进入这个公司了。可是这些个算法，概念真的能帮助你了解这个人会什么吗？这是你面试一个人的目的么，考试是发现人才的方法么？

    考试的方法，只能发现一个人不会什么，却不能完全了解这个人会什么，因为他会的你可能没考，你考的他没用过，我们要先了解一个人的能力，然后才能判断这个人是否符合公司的招聘方向，凭一些概念和算法，又怎么可能完全了解一个人那？最可笑的是，有的公司，连自己的在岗员工都无法很好的回答他们的考题，而且这些概念和算法在公司平时的项目中也并不适用，但却拿出来考比人，不知道招聘上来的人到公司后会怎么想！
   
    我认为发现人才最好的方法就是交谈，只有交谈才能在一个又一个问题当中，了解一个人的真实想法，解题思路，能力等等。就好比武林高手过招一样，行家一出手，就知有没有，光说不练那是假把式，你就是把所有的武林秘籍背个遍，也不代表你能打，有能耐就出出手，亮亮相，真刀真枪的干上一场，行与不行一目了然，功力如何装是装不出来的。

    之所以用交谈的方法，主要还是根据每个应聘者的不同经历和能力，组织不同的问题来更好的了解应聘者的能力，而不是通过试卷的千篇一律法来考核应聘者，充分尊重个体差异，制定不同的考核策略。

    例如我们可以这样开始：
    1、你以前做过什么项目？使用什么技术？
    2、在项目中是什么角色？解决过什么问题？
    3、平时都用过那些文档，是使用还是书写？
    4、就这个人做过的一个最熟练的项目展开具体讨论，让他详细描述设计思想，解题思路，改进方法等等。

    有人给我的第3个问题作答如下（先感谢一下，不好意思，直接拿来用了）：
    我写过a《需求文档》，b《用户说明文档》，c《版本历史》，a是基于工作要求写的，bc是写给别人看的。没有写过设计文档，因为属于一个人开发，所以设计大部分在脑海里构思和在草稿纸上演算，不会去写文档。
   
    由上我们可以得到很多信息：
    1、原公司应该没有很好的文档管理规范和习惯
    2、连数据库文档都没有，很难想象以后代码的维护难度，估计编码规范之类的东西也没有吧
    3、属于软件作坊式的做法
    4、对于正规的设计文档，这个人需要一定的时间来进行学习

    上面的内容可以通过问题进行进一步认证和分析，例如我们还可以提问：
    1、你们的文档是否基于某个规范，如果不是，是如何确定格式的
    2、你们员工交接时怎么做的？（数据库文档都没有，怎么交接？）
    3、你在如何在草纸上演算的？（UML还是别的什么）

    通过上面的提问，就可以进一步了解一个人的文档编写基础，直至完全勾画出这个人的整体实力，甚至可以根据他的言谈举止感觉到他在使用过程中是否有创新意识，是否会解决一些问题等等。
   
    如果我们通过试卷的方法，大家想想要怎么出题才能了解一个人的文档能力那？估计典型的问题应该如下吧：
    1、常用的文档有哪些
    2、需求文档主要是做什么用的
    3、用例文档的概念

    这样的试卷是否太抽象了些那，你会写用例文档，是否就代表你能描述它的概念，是否上面三个都答上来了就一定会写，估计刚毕业的学生也许会很有优势，毕竟刚刚背过么！

    今天先写到这里吧，上面的东西估计在真正的HR那里根本不算什么，主要是想和各位大侠们讨论一下，如何才能确定一个人才，而不是埋没他。