本文由Yurii原创,转载请注明来源: Life Sailor

本文链接 技术招聘的若干问题


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

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

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

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

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

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

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

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

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

有些面试者说,自己工作了一些年,以前在学校学的算法和理论基础,基本都忘光了,并把这视为一种正常现象。但是在我看来,这并不算正常现象。学校教材的理论或许与实践脱节太远,但优秀的技术人员一定可以在工作中不断结合理论去思考,深化对理论的理解,同时更好地应用理论来认识世界——这是技术能力增长的关键因素。比如我们都知道评价算法的时间代价,如果你不理解它到底是什么意思,不理解“算法渐进增长率”中的“渐进”,你很可能没有办法评估迅速增长的数据给系统带来的影响。但是在互联网开发里,业务的迅速发展导致系统负载的迅速增长是技术人员不得不应对的重大挑战。同样,如果你不理解TCP/IP的四层模型,就很难决策(也很难理解),在不同的网络环境下到底要采用哪种部署和沟通方式,才能保证最高的效率。

最后,优秀的技术人员离不开好奇心和探索精神。

我刚工作的时候,面试官告诉我:“任何一家公司,你的技术新鲜感都只能保持半年,因为对公司来说,用熟练工和稳妥技术的风险是最小的,然后就只能靠自己”,我印象很深,也深以为然。所以面试的后面环节,我通常会问“你一般看哪些书或者技术网站”。这种问题一般是很难敷衍的,因为下一个问题就是“在这些书或者网站上,你收获了什么,请举一到两个例子”。优秀的技术人员往往都能很好地回答这个问题,哪怕他的答案看起来并不稀奇,但只要是自己真正用心学习过,就必然有思考、探究、鉴别、证实的过程。只要有这种能力和习惯,以后的很多技术问题就可以迎刃而解。有时候,面试官甚至可以和候选人交流解决不同问题的共同思路,或者解决共同问题的不同思路。我见过最有意思的候选人,是个非常年轻非常有潜质的小伙子,在连续几个问题之后,他反将我一军说“你总是问些我答不上来的题目,那我来问一个看看”。果然我的解释并不到位,但这并不妨碍后来他和我密集交流各种技术问题,也让我认定这个小伙子未来一定是可造之才。