聪明在技术面试中被低估了

对于面试标准，还有人专门出过书，比如技术界曾经最好的blogger，Joel Spolsky就专门写过一本小册子Smart and Get Things Done，专门讲他认为怎么能够找到聪明(Smart)并且能够搞定事情(Get Things Done)的人才，据说这个是当年微软的标准。然后Joel Spolsky自己又加了一条叫做“Don’t be a jerk”。我个人是比较认同这个标准的。能搞定事情这条其实大家都比较容易接受，另外两条相对多少都会有些争议。比如“Don’t be a jerk”这条在Steve Jobs和Apple收到全球追捧之后，肯定很不受很多傻货待见。特别是大概有些人还以自己是Jerk为荣，然后来一句“和聪明人一起共事最大的好处就是不需要考虑他们的自尊”，不过很可惜聪明人不喜欢傻货Jerk。

我个人觉得”Don’t be a jerk”还是必须的标准，虽然团队里都是聪明人。但是聪明人也都是普通人，而且通常反而个性比较直接。有个Jerk在团队里破坏性很大，好一点的情况是大家都无视他，差一点的情况就是团队冲突不断，啥也不干，从内部崩溃。至于Steve Jobs，你又不是代表董事会找CEO。

至于聪明，很多人的感觉是有当然好，没有也不要紧，事实上在我们的文化里某种程度上是轻视智商鼓励勤奋。我的观点是恰恰相反的，聪明(Smart)和能够搞定事情(Get Things Done)在技术团队同样重要。而勤奋和相关经验其实没有太多必要考察，一方面，如果这个人是擅长“Get Things Done”的，多半是勤奋可靠努力的。而相关经验，由于技术本身发展很快，很多工具在快速演变中，好的技术基本功（很大程度上决定了是不是能Get Things Done）远比特定工具或者平台的经验重要。说简单一点，挑篮球运动员你也会挑长得高弹跳好跑得快的，那么对于这种智力活动有什么理由不重视天赋呢？

很多时候，各个团队都低估了智商的重要性，一个原因是大家通常都容易觉得写Code没那么难。事实上，没错的，写Code没那么难，但是实际上不同人，不同团队的生产力差别很大。因为困难的并不在于我们已经在非常明确的需求下写Code，而是面对一个实际的非技术问题，将问题映射分解到技术空间上去解决。这个过程中，最影响效率的一部分，就是怎么将具体问题抽象化。这个光说我对技术框架很熟悉，没有用。因为每次工程师都是面对的不同的问题，因为如果是相同的问题，之前的产品或者Code都已经解决了。而这个抽象过程，能不能做好，能不能快速做好，一方面是要有好的方法论，另一方面，就是需要聪明。工程师是不是能够快速联系自己知道的各个业务信息和上下文信息，确认实际的需求，确认问题如何映射更合适。这个的效率差别，很多时候不是多个10%-20%，而是做出来的东西能不能用，会不会做了白做推倒重来了。

最后，这个聪明与否，还不像专业的技能能够在半年一年内训练出来的，面试基本上是你唯一可以选择控制团队智力的机会了，你说该不该重视这个呢？