从技术招聘的若干问题谈起

本文转自公众号“余晟以为”，其中关于技术招聘的观点，我们很是认同，和大家分享。

上海的很多朋友可能已经知道了，最近我们正在大力招聘架构师和Java工程师。招人过程在紧锣密鼓进行的同时，我们内部也在不断总结数据，收集反馈，提高效率的同时尽力照顾候选人的感受。

我们也注意到，候选人的部分反馈是比较有共性的。经过仔细分析，我们确认这些反馈是可以理解的，但是我们更确认在技术招聘中必须有所坚持，最终才能得到好的技术团队和系统。所以今天我想“私器公用”一把，讲讲我对技术招聘和技术人员成长及评价的若干观点。

首先，对于重视技术的公司来讲，技术招聘一定是有门槛的。

优秀技术人员的开发效率，通常要远远超过普通的技术人员，五倍十倍或许有夸张，但两三倍常常是有的，这还不包括开发成果的维护成本差异，以及出现问题时迅速定位和解决的效率差异。如果对技术工作有足够的领悟和观察能力，一定不会否认这一点。既然我们选择做技术工作，既然我们选择相信技术带来的力量，就应当持续追求获得优秀的技术人员，让优秀的技术人员在一起工作，互相促进和成长。如果现有团队还不够优秀，就更应当抬高招人的门槛，让高于平均水平的新人来影响和激发原有团队的成员。相反，如果新加入成员达不到现有团队平均水平，又没有很好的潜力，他不经意的一点疏忽，反而可能严重的结果。

其次，写代码是每一个技术人员应当具备的基本功，而不是头衔升级就可以抛弃的苦力活。

无论现代的框架和工具多么先进，软件还是需要通过代码一行行地写出来。随着软件日益复杂，功能日益多样，任何一行代码的问题，都可能引起严重的灾难。而且，软件开发仍然更像“手艺活”，长久不操练，不但自己手生，失去感觉，也会失去和其它开发人员的共鸣基础，造成沟通的壁垒。所以，我完全不赞成“成为开发经理/架构师就不用写代码”的想法。架构师必须写代码，这是责无旁贷的。在面试中有一些候选人提到，公司的“架构师”只做PPT，根本不着手解决具体问题，开发人员内心是很反感的。这样的情况，其实值得每一家IT公司重视。

再次，架构师必须对“复杂性”有充分的认识。

“软件开发的难题之一就是控制复杂性”，这句话可能很多人已经听到耳朵起茧子了，不幸的是，真正理解的人并不多。架构师的重要价值，就是判断分析可能性，并通过合适的架构设计来安排和控制复杂性的分布。举例来说，如今互联网上已经有非常多的开源项目，可以用来解决许多类型的问题。但是，如果架构师只是具有“听到某某问题就想到某某项目”的条件反射，那么他很可能并不称职。称职的架构师解决问题的思路一定是先问题的本质，了解限制条件，然后才能设计解决方案，如果要用现成的解决方案，必须评估其适用程度和运维复杂性，最后才能决定。在生产系统里随便起个服务，没有监控没有报警没有任何保障，这样的随处下蛋的“走地架构师”并不罕见，结果却是系统运行的噩梦。还有很多架构师一提起“搜索”就是Solr和ElasticSearch，但是使用Solr导致系统复杂性无端增加，以及不用Solr或者ES却能稳定高效完成“搜索”的例子，我都亲眼见过。

此外，算法和理论技术也是不容忽视的。