zoukankan      html  css  js  c++  java
  • 对于技术岗位而言,开发岗累还是算法岗累呢?

    最近由于校招如火如荼,一些小伙伴在后台以及知乎上问我,在开发和算法之间犹豫,不知道如何抉择,想要问问究竟哪一个岗位更好?

    恰好我之前在知乎上回答过“对于技术岗位而言,开发岗累还是算法岗累呢?”的问题,于是将它搬运了过来,希望能给大家一点启发和帮助。

    了解我的朋友可能都知道,2015年的时候我在阿里妈妈的算法岗位实习,然而找工作的时候我阴差阳错地去了某公司的开发岗位。做了一年之后,由于各种原因,有点后悔当初的选择于是又想办法转回到了算法岗位上。所以说这两个岗位我都待过,所以就各自来谈谈它们的缺点。有的时候我们不知道我们想要什么,但往往清楚我们不能接受什么。

    这两个岗位虽然说起来都是工程师、技术岗,但是两者的工作内容和性质差得真不是一点半点。从业当中,也都有心力交瘁的时候,但是体验和触发条件都不太一样。简单说一说。

    首先说开发,我个人在做开发的时候,蛋疼点主要有以下几个。

    开发篇

    on call

    on call可以理解成随时等待召唤的意思,一般来说重要项目的开发人员都是7 x 24小时on call的。

    只要线上有问题,一定会有电话打进来。凌晨两三点也不是没有可能,而且很多时候,这些问题未必是你的锅,很有可能只是因为某某项目的负责人上有你的名字。

    这点我想应该大小公司都有,之前和蚂蚁的同事聊天,他给我吐槽说他凌晨起夜已经成了习惯。因为好像蚂蚁到了晚上还有很大的流量,经常hbase抖动,每次抖动都会有电话打过来。还有什么烧烤吃了一半突然线上GG了,狂奔回公司查问题的,都不算是事。

    不仅工作日如此,周末、假期都必须响应。所以基本上电脑随身携带是肯定的,哪怕是过年回家、出国旅游基本上也都要带着电脑。而且根据墨菲定律,千万不要有侥幸,我侥幸过两次,都中招了。最夸张的一次,在香港太平山上拿着手机看代码。。。

    什么?线上故障的时候,你睡得太死了没听到电话?

    Emmmm,轻则被leader说上几句,重则,可能你需要准备一下简历了。

    大促熬夜

    **只要是电商公司,没有不大促的,只要大促,没有不要熬夜的。**所以可以简单理解成只要是电商公司,那么一定会有熬夜。

    大促意味着巨大的流量,自然对系统的稳定性是一个顶级的考验。就拿双十一举例,你以为只要在双十一当天多准备几台机器就好了?too young,在真正大促到来之前我们需要做很多轮的模拟流量检测,怎么模拟呢?就是搞一堆虚假的请求过来发送到服务器,看看服务器能不能抗住。这种模拟测试在行内称为压测,也叫压力测试。

    一般来说每次大促至少两轮压测,由于压测可能导致系统问题,所以不能放在流量高峰期,也就是白天,只能晚上夜深人静的时候搞压测。那么你想嘛,熬夜就是必不可少的。

    就算两次压测好了,两次压测加上大促当天的值班,至少每次大促都需要熬三天夜。每次熬夜,至少要两三点才能睡觉。

    来来来,你告诉我,这样的大促一年有几次?

    光数的出来的大促就有四次,321, 618, 11.11, 12.12……而且现在这个大促的次数还有明显地增加的趋势。

    并发工作

    工作当中最令人感受不好的就是并发工作,也就是一件事情你还没忙完,甚至刚刚做出一点眉目,立刻就被其他更加紧急的事情打断。

    比如你在查一个bug,刚刚锁定了大概导致bug的代码区域,还没有具体检查出来,突然测试就告诉你她发现了新的bug。或者是产品过来跟你聊一个新的需求,或者是有人找你问一些关于你们系统的问题。这种连轴转的感觉是最痛苦的,只要很短的时间就会让人心力交瘁

    当然这个问题并不只是在开发岗位出现,其实任何岗位都有可能出现这个问题。但是相对来说,开发岗位出现这种情况的概率更高。因为开发往往负责的是一个或者多个系统,系统大了可能出现的各种各样的问题就很多。并且还会有很多使用系统的人问你问题,很容易出现这种情况。

    其他问题

    除了上面三点之外,其他蛋疼的点也很多。不过相比之下没有那么严重,所以我就放在一起说了。

    比如大多数公司文档都不健全,对于开发来说接收陈年项目非常容易踩坑。而且很多时候需要直接去读源码,如果碰到之前的工程师代码能力不行的话,会导致代码非常难读,就跟眼睛被针扎了似的。

    还有就是肝deadline的现象非常严重,每一个产品提的需求总会给你设一个deadline。有时候总会有各种各样的意外发生,导致你需要爆肝才能赶得上进度。比如线上出了故障排查了两天,或者是临时加了一个紧急的需求等等,无休无止地爆肝真的会让人崩溃。

    另外一点是经常重复性工作,今天增删改查,明天改查增删。面试的时候高并发、分布式,进去工作之后curd。经年累月没有成长,如果是大公司的话,很多人干几年也没有过从0开始真正搭建项目的经验。

    有时候产品或者运营或者是老板不好沟通也是一个问题。要么是不懂技术沟通成本很高,要么就是无脑强势,不懂装懂,我不管你觉得,我要我觉得。

    算法篇

    SQL boy

    很多人被算法岗吸引,就是觉得算法岗高大上,机器学习,人工智能。但其实真正从事之后,会发现根本不是那么回事。

    如果在小公司,整天为数据发愁,不是这个数据没有,就是平台或者工具稀烂。如果在大公司,数据、平台、工具都有了,但是每天当SQL boy。你和业务谈算法,业务说明天上线,先统计上一版。老板整天告诉你,我想看这个、这个和那个,你去帮我跑一下。

    你想说抽空能把某个模型优化一下,结果发现手上排的SQL根本写不完。机器学习、深度学习的模型我明明会一堆,但是眼下的事情永远只有SQL和数据。

    问题难定位

    做算法的过程,很多时候是一个和自己较劲的过程。

    因为模型和开发的代码不同,开发用代码实现的功能结果是明确的,原因是可追溯的。但是模型不是,经常在别人场景下效果好的方法到你这里一团稀烂。特别是你老板报以期望的方法,你很难解释……太多的可能性导致模型性能不好了,可能是训练数据有问题,可能是特征有问题,有可能是流程有bug,但是老板不管这些,他们需要的是确定的结果。

    并且很多人觉得查问题很简单嘛,你找几笔数据来看一下不就知道了?还有一些不懂装懂的路人,哎呀你用这样这样不就可以了?

    大数据时代,只有相关性,没有因果性。几笔数据能够代表全部吗?我抽了几笔看了没问题,就能代表全部数据没问题吗?换句话说几笔数据有点小问题,就能代表这个是导致模型不行的原因吗?千万别信,信了就是大坑等着你。

    我最头疼的就是老板让我去查某个问题,简直是玄学,如果是明显的问题还好,如果不是,你可能跑一堆SQL,看一堆数据还是一无所获。更蛋疼的是,可能一切都没问题,但就是效果不好,你也不知道为什么,毕竟神经网络是个黑盒。

    忽悠和大忽悠

    算法行业的忽悠很多,心态不好的人很有可能会扛不住。

    也是因为现在算法太火了,很多不明就里的人会用仰望的目光来审视。某些时候这个是好事,比如当和投资人聊钱的时候。但大部分情况下,则未必。

    比如某些决策者会有错觉,会有幻想,比如会提出一些他们自己都不信的口号。喊口号不是问题,但问题是口号里的指标要你去落实。你会发现你很有可能忍不住想要打人的冲动,其实老板也不是白痴,他们心里也门清,可能也是为了应付更高层的老板或者是投资人而已。有点像是晚晴鸦片战争时期的官员,从上到下都知道打不过英国人,但是总得想出点办法来去写篇“捷报”,不然怎么升官发财?

    以前遇到过这么一档子事,说是公司的日活用户一直在降低,公司希望用机器学习的模型来筛选一批贪财的用户,给他们发5块钱红包。这样他们为了贪这5块钱就会一直活跃,也就带来了日活的增长,这样就可以和更高层的老板交差了。看起来这个逻辑非常清晰,毫无破绽。

    但问题是,当时的日活有三百万,每天发多少红包呢?只有几万个。你说应该怎么办,即使算法选出来的每个用户都不流失了,那难道就能增长了?入不敷出的成语学过没有?老板才不管,你只管去做,做不好就是你能力不行。这种情况怎么办?

    同样,这行吹逼的情况非常严重,简直章口就来。反正别人不知道你到底怎么做的,面试的时候有些人吹得那叫一个天花乱坠。当很多人都这么做获得好处,而你坚持底线,一直默默无闻的时候。你很难不对你的信念产生怀疑,究竟错的是你呢,还是这个世界?

    以上,只是我一家之言,如果言中,请勿对号入座。

    最后,世上没有完美的职业,总要有所得有所失。如果你能明白可以忍受什么,不能接受什么, 我想,你一定可以做出不后悔的选择。

    今天的文章就到这里,衷心祝愿大家都能找到称心如意的工作。如果还喜欢今天的内容的话,请来一个三连支持吧~(点赞、关注、转发

    原文链接,求个关注

    本文使用 mdnice 排版

  • 相关阅读:
    cf D. Vessels
    cf C. Hamburgers
    zoj 3758 Singles' Day
    zoj 3777 Problem Arrangement
    zoj 3778 Talented Chef
    hdu 5087 Revenge of LIS II
    zoj 3785 What day is that day?
    zoj 3787 Access System
    判断给定图是否存在合法拓扑排序
    树-堆结构练习——合并果子之哈夫曼树
  • 原文地址:https://www.cnblogs.com/techflow/p/13934940.html
Copyright © 2011-2022 走看看