# Question & Answers

# Algorithm vs SDE

  • 行业多年来不变的东西一定要烂熟于心,行业变化很快的东西要能够迅速上手
  • 低头看路,偶尔抬头看天
  • 我更像是在河边湿了湿鞋,即使未来这个行业产生了漩涡,竞争激烈,工作压力大,与其他行业比有挫败感,倘若我有了理论基础,编程基础,比赛经历,论文经历,我在河里游了泳,即使溺死,我也不遗憾
  • 技能获得的门槛决定岗位的报酬水平,要想保持较高收入,只有提升在学校完全学不到的能力(团队管理能力,大项目设计与实战经验等,编程精通度,算法精通度)才行

# MLE vs Backend


  • MLE最终最好的结局就是在大厂里面帮忙把metrics从99.8%提高到99.9%.

    ML本质就是个提高效率的工具,是个从1做到10的工具。ML不具备那种从0做到1的特质。
    优点:
    1 技术新颖,说出来逼格高,容易唬人。
    2 还有很多探索空间,上可以研究新算法发paper,下可以当调参侠。
    3 工资还不错,但高端的MLE和高端的SDE工资不会差太多。

    缺点:
    1 坑比较少,因为MLE不像SDE那样是labor intensive的类型。现在供大于求,内卷严重,国内现在已经需要各种顶会paper或者phd等。
    2 没有特别大的技术壁垒,牛逼的算法往往都发paper或者直接开源了。最牛逼的算法即使是闭源,作为用户能感受到的提升也有限。(比如推荐)
    3 严重依赖于数据和算力,算法倒是其次,所以小公司或者startup做的算法很难干的过大公司。
    4 技术更新换代迅速,技术很快就过时。5 难以debug,不好解释为什么效果好或者差,有点玄学,不像SDE有一说一。

    我认为一个从0做到1能火的产品,靠的并不是ML,而是靠产品设计,玩法打法,市场营销,掌握用户需求
    所以我觉得做一个产品的priority不应该是ML,而是上面说的那些因素。即使需要一些ML算法,也可以用一些非常简单的算法先上马,之后优化时候再招几个MLE来做的更好。

  • 太纠结于算法的MLE/DS/AS就像只愿意钻研性能最好的index/sorting的SDE, 技术上可能很有趣, 但商业和职业发展上其实价值不大. SDE以前内卷也很严重, 后来见识到商业化的红利后大家发现与其跟自己人纠结c code怎么写才能少allocate 40bytes, 还不如专注在用最简单的代码去实现最大的商业价值.

    我个人比较推荐你出去看看其他的ML运用场景, 找那些你随便一天鼓捣个prototype都能让vp/cto 赞不绝口的领域. 虽然在某些领域里ml的运用已经是登峰造极, 大牛忙活一年也只能提升0.1%. 但在很多其他领域里的ml的运用才刚刚开始, 稍微有点技术的人用个简单的算法就能给用户带去巨大的价值. 而且新的ML运用场景一般需要很多domain specific的知识,你积累的多了, 就算大厂来一个L8 IC大佬也很难直接在你熟悉的场景里打败你.

  • 某大厂做recommendation的表示ML特别心累,要工程落地的话指标,算法,工程实现,稳定性通通都要考虑,而且每次一个idea出来后做的都特别忐忑,生怕出不了效果。每次A/B TEST也都是N个实验组拉出去测,只要有个比对照组高就算成了,编个故事然后launch。而且现在基本都用NN模型了,可解释性特别差,出效果就是不停的试,感觉就是门实验学科。现在如果想转ML的话建议三思而后行,不出意外实际工作会和你想象的差很大,如果不是特别感兴趣的话还是建议稳稳当当选后端!

  • 曾经也做过一段时间recommendation system. 感觉特别玄学...先魔改算法, 然后扔去做a/b test. 如果结果不是特别难看, 就各种metrics挖一下, tell story. 如果结果不好看, 就再改改看.

  • CV确实有很多非常具体的应用,但是像物体识别这样的核心算法,都是Research组搞得比较多,毕竟这东西是跟全世界科研工作者竞争,MLE还是偏实践,没有这个时间去沉下来两三年不出成果就为了赌一个突破性成果,最后大概率还是implement一下最新的科研成果用在自己的产品里,当然这也是很好的创新,有时候还很publishable。

    所以我觉得有passion而且能找到CV的工作当然万岁了,但是CV的落地场景还是比较少一点,业界的坑有限,大部分人还是去做推荐或者广告系统的MLE,这两个领域就稍微有点无聊,而且实验结果经常是碰运气。

    我最近在看一本深度学习推荐系统的书,里面各种架构各种深度算法飞起,让我感觉怎么才两三年没关注推荐系统,业界已经变了天了。但是跳脱出书的内容,想想我最近在Netflix/Hulu/DisneyPlus/HBOMax找视频看的体验,又觉得,这些算法真的有用吗,为什么我还是闹剧荒,还是首页翻来覆去找十分钟找不到想看的东西?

  • 传统机器学习那一套,就是数据清洗,特征工程,调模型包,evaluate,monitor,再部署一下,我觉得是没有什么技术含量,主要靠清洗和特征,也就是domain knowledge和soft skills。未来这类工作应该是每个领域的专家也掌握一些模型知识然后并不需要太多ds来做,并且这类ds工作会很无聊。有些领域这几年建立了大量新模型,接下来更多的是如何将已有的模型continuous improve还有integration, 而不是盲目建新的,谁都知道improve一个别人的模型有多难,所以这个又是个坑,也是需要规范化的
    ML真正有技术含量的还是那些需要human perception的领域,比如图像,nlp。开源的模型再牛,也不一定适合公司具体的业务,还是需要一些人来实现模型本身,并且还要做性能优化,比如模型压缩(应用到手机,汽车),比如模型内部结构优化也不是瞎尝试是有一定topology guideline的,而这就需要经验,比如模型在GPU层面运行优化。这类工作机会太少了,门槛高

  • 还有一点就是,做了sde的提升的实践技能非常多,小到各种编程语言,大到高并发各种系统设计,做MLE/DS提升的那些soft skills相比之下让人挺心虚的

  • 我怎么觉得和楼里的思路相反,这个还蛮好玩的
    放下可能期待的光环,这个领域这么活跃,永远有新的idea和新的architecture可以玩,划水可以去大厂product提高metrics,有干劲可以去小的startup或者自己创业找个好的business idea落地

  • 你想想CEO有啥实质性的技能?不就是tell stories吗?tell stories的同时还能motivate其他人这就是leadership。我觉得你可以扩展一下自己的思维,然后锻炼你说的metrics提高了找故事说故事的能力

  • 归根结底取决于你想要通过这份工作得到什么.任何领域做到top都很难难道做了sde就能随随便便principle?

  • 每个人都对自己的能力和界限有着好期待,然后现实里面公司有自己的运行规则,大多数的每个人都是螺丝钉,这可能都会与你之前的预期有差异。
    而且各个职位都是围城吧……

  • 能在工作中学到新的知识和新的data insights,比如一个产品的用户群体画像,用户行为规律等等,这个是其他类型的岗位不太能接触到的。还没遇到过被PM追着屁股催的情况,感觉自由度稍微高一点点。

# Java vs Python

  • Python 写的巨快,但是总要跑起来报错再改。Java 是写的时候一堆错,都改好之后一运行一点问题没有。Java 静态检查很强

  • JAVA 强大的背后不是语言的特性,而是设计模式,设计原则,这些在大型系统开发中必不可少,但是小程序,写个脚本什么的,很少用 JAVA 去做。学 JAVA 本身的语法其实用处不大,Spring 思想(设计模式),微服务架构之类的才是精华。想深入了解可以先看微服务架构的书,然后 IPC (进程间通信)学了之后看 MIT 6.824 ,这些比学 JAVA 而言更有用

  • 因为 J2EE 本身就是大型企业的框架,使用了多层架构模式,一般都有 DAO,SERVICE,CONTROLLER 三层,而 FLASK 的 DEMO 我看了一些都是 CONTROLLER 和 MODELS 。
    我举个简单的电商下单例子:
    控制层:基本的参数校验,防止缓存穿透的基于 Redis 的参数校验,库存校验(依赖 Redis )
    业务层:RPC 调用促销服务,会员服务,商品服务以及支付系统来组成一个完整的下单逻辑。并通知库存系统,以及物流系统做发货。(这里面设计了多少个系统间的依赖?)
    DAO 层:订单数据库的更新。

    你可以尝试一下用 Flask 写一下逻辑,如果不用依赖注入,每个服务间的 RPC 调用,需要写多少代码。因为是微服务架构,需要每个服务都集群部署,每个服务可能都依赖了多个其他服务,这之间的代码不用依赖注入,需要写多少行,多少个类。之后如果需要变更业务逻辑,需要改变几个服务项目的代码?

    不要拿轻量级应用场景去对比复杂的应用场景

  • 我爱Engineering

# Java Springboot vs Java SSM(Spring, SpringMVC, Mybatis)

就内容容量而言,spring boot 属于 app 级的容量。ssm 属于体系级的容量
学完 app 级的东西可以做 toy app,但是无法为 “巨型 app” 排错 它需要体系级的容量的知识与经验
app 级的东西其实应该在至少了解一遍体系级的东西之后再接触(否则各种 hands on 的 tutorial 即使跑起来了 你的感性认识只停留在环境搭建与排错了,折腾半天 实则在 app 级的评判标准之下是成功通关,在体系级的评判之下是连没门都没入)。app 级的东西其实应该是学完 ssm 之后再碰也无妨,若先跑起 spring boot 最后还是得学:无它,因为你的工作岗位里你天天打交道的是 “巨型 app”
巨型网站后台有自己的业务逻辑( context ),这是巨型 app 和 toy app 的不同。反观做客户端的东西( iOS 、Android 、Web 客户端 / 前端),基本上不用和复杂的业务逻辑打交道
相比之下,一个水浅,一个水深:做一个 Android toy app 和一个 Android production app 差别很小,做一个 Spring toy app 和一个 Spring production app 的差别很大 因为后台水深,前台水浅

# Resources

  • Competition List
  • News, annual reports, reports from consulting firms
  • Informal interviews
  • short term assignments
  • hackathon and case competition
  • microblogging
  • entrepreneurship
  • vmock
  • cfg sites
  • international mathematics for university students
Last Updated: 5/14/2021, 5:21:55 PM