我为什么反对提“全栈工程师

我为什么反对提“全栈工程师”?

最近参加一个技术社区活动,在讨论到“CTO的技术深度和广度哪个更重要”的话题时,我想起社区里面常常提到的“全栈工程师”的事情,于是表达了一些观点。临场未必能够清晰表达,所以下笔,希望能够引起一些讨论,避免年轻工程师误入歧途。

长期以来,社区就有人在提“全栈工程师”,还有一些公司直接挂出名为“全栈工程师”的招聘职位。那什么是全栈工程师?

百度百科的解释是:全栈工程师,英文叫Full Stack Developer,是指掌握多种技能,并能利用多种技能独立完成产品的人。说白了就是啥都懂的人,左青龙右白虎老牛在腰间,人挡杀人佛挡杀佛。想想,一个项目从前到后要包含多少技术?就拿TalkingData来说,就至少有H5、JavaScript、CSS、Java、Kafka、MongoDB、Redis、MySQL/MariaDB、Vertica、Hadoop、Spark、Tychron等等,这些研发目前需要数据可视化团队、计算平台团队、存储平台团队、数据挖掘团队和运维团队来共同完成。要是出现这么一个全能王,把活一揽子全部接下来,那要省掉多少沟通代价和薪资成本?——这简直就是救世主!

想到这里,我顿觉惭愧,十几年的技术算是白搞了,要是刚毕业即以此为目标,每个月学一门,学完一门换一门,那用不了两年就能转职“全栈工程师”这个终极职业,站上技术巅峰,俯瞰芸芸众生——是不是有一种游戏开挂的快感?想想做个架构师都需要四五年的辛苦积累,现在能两三年速成,岂不是很爽?

终于,在这样自我催眠,加上一些舆论的刻意引导下,大批有志青年开始走上全栈工程师的自我修炼之路。没有多少人愿意脚踏实地积累自己的技术经验,或者潜心去研究开源技术的底层代码,或者做更深入的性能对比分析。很多人闪电般的在不同公司之间跳来跳去,走马观花,狂热浮躁。

这几年,因为大数据需求的不断成熟和数据业务的持续发展,TalkingData研发团队一直保持高密度的招聘,我们对这个现象的感觉是比较明显的。因为我们在面试中越来越多的发现,年轻人的简历写得愈发琳琅满目,这也“精通”,那也“擅长”,数量不等的“多年经验”或“长期从事”……恨不得2年工作经验比干10年的简历还要长,几乎称得上当代常用技术巡展。不要太强!只看简历就想赶紧招进来,再开掉现在这些“尸位素餐”的非全栈员工,世界肯定清净了吧?

但是情况真的是这么好吗?

在面试中,我们会通过问答,检验候选人在技术上思考的深度、理解能力、学习能力和解决问题的能力。所以研发人员面试一般会遵循以下流程:

1. 介绍一下背景和职业经历。

2. 选择一个你最熟悉或擅长的项目,详细描述一下整体架构和你做的工作。

3. 讨论一下你遇到的挑战以及怎么去解决的。

4. 然后从这一步开始,我们就会不断地挑战,不断追问“为什么”,直到通关或者回答不出来为止。

在这个流程中,每一步都有大批候选人失败,比较典型的失败原因包括:

1. 跳槽频繁

最常见的理由是“我想学习新的东西”。想学新东西是值得赞赏的,但是我很难想到正常人在短时间就能把一门新的技术学通。尤其是开源技术,基本属于入门容易精通难,很容易找到一些教程101,帮你5分钟学会安装部署,但是一旦用上生产系统,就很容易出现各种各样的突发问题,配置的、架构的、网络的、代码的、甚至还可能有硬件的——逼迫你绞尽脑汁上各种论坛找各种谷哥度娘去解决。经验就是从不断填坑的过程中积累起来的。只会安装部署,距离真正掌握还差八千里。

最夸张的见过2年换了6个公司。所以到后来,只要一看到简历中最近3次工作经验中没有超过2年的,直接就略过了。

2. 缺乏对架构的感觉

先不说一个技术人员(尤其是大数据技术人员)必备的好奇心或逻辑性,也只有对整体架构有清晰的认识,才能更加准确的了解自己要实现的需求对整个业务线的意义,从而在功能边界定义和技术选型上有相对合理的判断。如果对于自己熟悉项目的整体架构缺乏了解或者描述不清晰,我们认为这样的研发人员比较缺乏整体感和全局观,成长一般都会比较有限。

实际上画不出整个产品线技术架构图的大有人在,能画出来但是各个模块画的稀里糊涂的也不在少数。

3. 技术浮于表面

说起遇到的挑战时,很容易能够看出候选人对于技术掌握的深度。说不出挑战的情况,要么是任何技术都挡不住的大牛,要么就是没有经历过比如计算瓶颈、数据淤积、磁盘爆满、内存不足、架构调优这样的战斗洗礼。对于后者,面试官辨就一定要小心,因为这样的人即使用过的技术和框架再多,为你带来的坑也可能比填的坑还多。

想起一个印象比较深的例子,一个候选人简历上充满了说自己长于各种大数据技术的明示,然后在面试中请他找个最擅长的项目深入聊聊的时候,他说,呃…这个…那我们来聊聊之前做过的一个网站项目吧,我在里面做web前端……当时我就无语了。

4. 细节禁不住挑战

为什么要选择这个方案?和别的方案对比有什么优势?这个方案有什么问题?如果让你来研发这个方案的新版本,你准备做什么样的优化,为什么?数据量如果增大一个数量级,你觉得这个方案会出现瓶颈吗?再增大一个数量级呢?BlaBlaBla……这些都是例行问题,如果没有对技术熟悉并研究到一定程度,是很难有条理的说清楚的。

曾经遇到过一个牛气哄哄的年轻人,刚毕业工作1年就找亲戚投资创业担任CTO,瞎折腾了一年公司黄了,然后出来找工作。第一年的薪资算正常,担任CTO的时候就给自己工资翻倍,然后在翻倍的基础上期望我们再涨50%。也就是说,经过这一年创业过程,他觉得自己做了CTO,接触了好多技术,增值了,“我什么都能干”,理应比第一年涨3倍。实际问起来,每项技术都是泛泛,没什么细节,自然就fail了。

作家格拉德威尔在《异类》一书中指出,“人们眼中的天才之所以卓越非凡,并非天资超人一等,而是付出了持续不断的努力。1万小时的锤炼是任何人从平凡变成超凡的必要条件。”他将此称为“一万小时定律”。

要成为某个领域的专家,需要至少10000小时。如果每天工作八个小时,一周工作五天,那么成为一个领域的专家至少需要五年。就算是一直搞“996”,也差不多需要3年。这符合任何一个有经验的技术人员的认知:一门技术,没有两三年以上的熟悉和研究,是根本谈不上精通的。尤其是大数据行业是一个比较新的行业,很多技术和方法都在摸索阶段,需要更多的时间来积累。TalkingData也是经过了4年多和海量数据以及各种大数据技术的斗争,趟过了无数的地雷阵,到今天才可以说是有了一些积累,培养出一批在大数据领域比较有经验的技术专家。即使这样,我们从来也不认为我们研发团队里面有“全栈工程师”。

大数据行业一定是靠经验靠积累,没有任何速成的做法,所以我们始终控制研发团队能够更加聚焦一些而不是更发散一些,做的更深而不是更广一些。

那说回来,到底有没有全栈工程师存在?肯定是有的。但是我见过的能称得上“全栈”的工程师,基本都在某一个领域写过大量代码,或者解决过大量问题,积累了非常深厚的功底,然后在精深之后,把知识转化成为常识,才能真正触类旁通。这时候看起来应该就是大家说的“全栈”吧。但是这显然不适合经验较少的菜鸟工程师。

所以,希望年轻的技术人员能够更加踏实一些,不要轻信“全栈工程师”的美丽神话。只有为自己打好技术基础,才能飞得更高。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值