都在卷后端,听说过all in前端的吗

开篇先验明正身。帖主24校招生,目前在字节国际化电商做前端。去年秋招,还拿到了百度、快手、小米、同程的offer,全都是前端。

写这篇的初衷其实很简单:又到秋招季选offer,看到无数牛牛问:后端和算法真香,前端真的还能选吗?

这是一种很奇妙的感觉,看到正在担忧焦虑的大家就好像看见了去年的自己。作为一个已经上岸前端的人,感觉可以跟大家好好聊聊我这半年的工作经历和真实感受,也许能消弭一些对「前端」的担忧和误解吧。

All in前端,后悔吗?

可能刚才已经有牛宝疑惑了:为什么只投前端?bg这么差的吗?我985硕,也不是因为自身能力有限、没得选才“出此下策”。

All in前端的理由很简单,单纯就是我喜欢。

在全押前端前也做过很多其他方向的工作。

  • 本科的时候就和导师一起开发过小程序,一人包揽前后端所有工作;
  • 读研期间,在学校网信办做过科研系统和人工智能;
  • 后来,去百度实习也做过大大小小的项目。

但秋招的时候,还是没有犹豫地选择了前端。我很确定,我更喜欢前端的「所见即所得」,页面上每一处细微的改变都是我在这份工作中留下的切实可见的痕迹,这种成就感是无与伦比的。

当然,听不见外界的声音是不可能的,「算法>后端>前端>QA」这种业内默认鄙视链也常被我们拿来自嘲。我知道有人说,你一个硕士,毕业了去干前端,入行门槛不高,但后端真就比前端高级吗?前端真的没前途吗?至少在我这半年的观察和体验中,完全不是。

1. 从岗位需求来说,前后端基本持平

正在秋招中的牛牛肯定也发现了,前端和后端的需求量是基本持平的。并不存在所谓后端就是人中龙凤、前端就是沧海一粟的情况。岗位就是岗位,没有什么真正的高下之分。

2. 从技术来说,前后端在实际工作没有悬殊差距

而在最受人诟病的技术方面,前后端在实际工作中也并没有表现出什么悬殊的差距。在字节、百度、快手这些基建成熟的公司,纯搞技术岗位少之又少,哪怕是后端的程序员,工作内容也大多由所在业务决定。在实际工作中,将需要用到的工具和技术熟练掌握、对于业务场景和需求深刻理解才是核心要义。说到底,如果是做产研,技术是为业务服务的,前后端仅仅是负责的板块不同而已。

3. 关于发展前景,很多时候,不看岗位看能力

我内心深处从来就没有相信过「前端 = 没前景」的论调。前端的可能性和灵活性是肉眼可见的,在有成熟跨端方案的公司,前端可以做服务端、客户端、大前端、Web GL、游戏,有那么多的小方向,想探索哪个都随我喜欢。我们现在就有一套完整的开发框架,能够实现用前端的语言打包生成app、小程序、H5应用。这些都是可能性,为什么不走出原有认知,去看看呢?

选offer这件事

上文提到过,秋招人品爆发,拿到了不少offer,其中就有老东家百度的实习转正。我是研二的时候进到百度实习的,当时在商业化部门做前端。拿到转正意向的时候也想过,要不就这样吧,已经非常不错了。但还是挺想看看其他互联网大厂,可能还是有点不甘心吧,因为我在百度做的内容比较细分和局限,校招生进来就做小方向,未来的可能性估计会大打折扣。抱着这种想法,还是试着投了一些公司,其中就有字节。

入节完全是意料之外的事。面过字节三个前端岗,前两个都挂了。面试的时候能感觉到要求都很高,当时也怀疑过,挂了可能是我个人能力的确不够强吧。好在最后一个岗位出奇顺利,一周速通三面,终于拿到了这个求之不易的offer。

内容电商的方向我是非常看好的,国际化这种海外业务更是如今的热门,再加上工作内容也挺有意思,选offer那会我倒是没怎么纠结,很快就接下了。我很希望第一份工作在能够提供长期发展的平台稳定下来,花几年时间在一个业务方向沉淀,真正学到一些东西。不管是公司发展、业务线、薪酬福利、培养体系还是通勤距离,字节都能满足我的要求,于是就这么顺利地入职了。

我在字节

虽然对岗位很满意,入职还是有点忐忑。毕竟外面都在说,字节校招没有进来就接的需求开发。但幸运的是,我开到了氛围特别特别好的团队。刚入职的一周多我都在慢慢landing,逐渐了解公司的新技术、基建、开发流程和环境。我个人对于脱产培训这件事没有什么需求,熟悉业务、了解过往项目的这个过程在我看来,本身就是最好的培训。

我在的团队对新人可以说是非常信任和看重,很快就把新开的业务交给我与另一个资深的同事一起负责。mt也对我很照顾,会为了让我更好地处理后续需求,建议我自己尝试前端工程化、搭基建,对公司整体架构形成系统的认识。遇到问题也可以随时向他求助,他会安排人和资源来提供支持。总之,截至目前的每一天我都很开心,做的是自己喜欢的事,一起做事的又是很好很优秀的人,可能多年之后我也会感到枯燥疲惫吧,但那都是后话了,谁说得准呢。

想说的话

作为还没过来多久的过来人,最想告诉大家的就是:一定要享受工作过程,自己开心最重要!不喜欢的事做再久也是不喜欢,再大再亮的光环也比不上你的热爱耀眼。

如果要说选offer的话,还是建议大家先明确自己想从工作中得到什么、最在乎哪些因素,然后再去逐一比对筛选,毕竟我们和公司是双向奔赴的关系。选岗位还是得重点关注业务、选对赛道,业务稳定性、发展前景都会对你未来的职业路径产生关键影响。

最后说回前端吧,前端不是 Plan B,如果你真的喜欢前端,all in了又能如何,大不了就是收获像我一样的快乐而已

#现在前端的就业环境真的很差吗#
全部评论
一周速通三面,佬生我梦
18 回复 分享
发布于 2024-12-09 18:20 河北
非常赞同!在前后端的选择问题上,当作一道单选题也未尝不可。根据自身情况以及兴趣特长,只要有决心有毅力,无论台前还是幕后都很耀眼,都是在为整个产品发光发热。前端的空间和发展也很大,各有各的难度,技术不分高下。只要热爱且坚持,别的都不是问题
16 回复 分享
发布于 2024-12-09 14:10 北京
好棒的心态,加油呀
12 回复 分享
发布于 2024-12-09 18:26 河北
还真是,自己开心最重要!我也在华子算法和网易游戏客户端之间,选择把华子扔掉了。。
7 回复 分享
发布于 2024-12-10 01:00 上海
大数据真的恐怖,自从接offer已经内耗半个月了......接佬工作氛围
5 回复 分享
发布于 2024-12-09 18:58 河北
你听过all in 客户端的吗
5 回复 分享
发布于 2024-12-09 17:53 北京
“不喜欢的事做再久也是不喜欢,再大再亮的光环也比不上你的热爱耀眼”真的泪目了
4 回复 分享
发布于 2024-12-09 18:30 河北
字节跳动的员工整体较为年轻化,团队充满朝气和活力,思想开放,容易接受新事物和新观念,大家在工作中会积极提出各种创新的想法和建议,工作氛围轻松活跃,没有明显的层级压制,同事之间相处更像是朋友。
4 回复 分享
发布于 2024-12-09 14:03 北京
业务真的比啥都重要,挑前后端真的抓错重点了,佬的部门还招人吗🙏🏻
3 回复 分享
发布于 2024-12-09 19:38 安徽
后端看完表示,真的很中肯!!!
2 回复 分享
发布于 2024-12-09 19:16 四川
听劝接了!!
2 回复 分享
发布于 2024-12-09 18:51 内蒙古
讲的真好
1 回复 分享
发布于 2025-12-30 20:46 广东
享受牛魔,我讨厌工作,讨厌当牛马
1 回复 分享
发布于 2025-04-27 20:52 四川
文章中的前端见解真好,为你的努力点赞。
1 回复 分享
发布于 2024-12-11 17:59 重庆
我跟楼主有点像我研二了,打算还是找前端,很多人都说我找前端还读硕士干嘛,但是我接触了科研以后才发现对算法真的不感兴趣
1 回复 分享
发布于 2024-12-10 20:27 广东
我也喜欢!说出了我的想法!
1 回复 分享
发布于 2024-12-10 15:50 湖北
上面那个顺序是错的,QA>算法>前端>后端,每次哪里来点bug都是第一时间给后端丢卡片
点赞 回复 分享
发布于 2024-12-10 11:30 广东
985211可以搞一下 其他都是炮灰
1 回复 分享
发布于 2024-12-09 21:26 广东
26届路过!正在帮学校搭小程序真的好喜欢明年也试试投前端
1 回复 分享
发布于 2024-12-09 19:27 广东
谢谢前端小白老师治好我的前端焦虑
1 回复 分享
发布于 2024-12-09 18:02 河北

相关推荐

随着ai ide工具的迅猛发展和在前端开发中的运用,网络上出现了很多吹捧ai技术的言论或者ai取代前端的论断。然而作为一个经验有限的小白,我的感受却和某些大佬们几乎截然不同,总觉得ai还是不够强,不够聪明,接下来聊一聊我的看法供参考,仅代表本人观点。实习和学习期间,cursor,Claude code,trae这些ide我都用过,我大体的结论是:对于常规业务需求,ai ide工具必须在以下几点条件下才能有较为良好的表现,但是对于企业级项目而言,前端开发本质上是企业的商业目标在技术上的实现,和任何一项工程实践一样,都面临着极其复杂的上下文环境,以及多主体的沟通协作,因此以下的要求都很难完全满足。第一,简单明确并且一次性的业务需求。显而易见,需求的复杂度在很大程度上决定了工程的复杂度,以及指令描述的清晰程度。就拿企业里面常见的支付下单链路来说,涉及十几种订单状态和流转步骤,理解业务的过程必须由开发者完成,ai仅仅是辅助。至于迭代次数大家懂得都懂,企业级项目迭代频率是非常快的。第二,低交互,短链路的界面和低性能的要求。c端业务对性能要求通常较高,即使是b端业务也会有较为复杂的交互链路。而这一点是前端开发特有的难度,毕竟前端构建的是UI界面,如果交互效果复杂(UI方面比如阴影渐变,淡入淡出,交互方面比如拖拽展开折叠等),则会非常难以用文字进行描述,对ai来讲也非常不友好。第三,有限的工作区边界和上下文规模这点前端相比后端更容易做到。后端开发常常涉及接口,数据库,中间件,路由等各种模块之间的复杂调用关系,而前端相对来讲更容易把UI组件拆的很细,进而约束工作区和上下文规模。但这项工作涉及组件拆分和数据管理和接口设计,也需要由前端开发者完成,而非完全交由ai工具。第四,命令式的指令和明确的技术规范所谓的命令式,指的是需要把开发步骤详细拆分,而非仅仅声明式地描述结果。举个例子,你不能只说“在这个组件实现登录和注册功能,”,那样的话写出的代码质量很低。你应该和他说 先实现静态约面,再添加交互,校验输入,最后提交结果,并且附上把每一步的效果。此外,请求库用哪个 请求函数是否封装 样式方案用哪个 需不需要拆分文件 开发中有哪些格式规范 函数变量命名怎么样 这些都是需要开发者去约定的。接下来举几个日常前端开发中的情景,这也是我为什么会得到以上的结论和感受。1.你刚进公司开发第一项需求,项目需要同时在web端和移动端运行,请问你如何解决手机端调试(让手机打开localhost),开发阶段跨域和登录状态共享(拿到其他域名的登录态)的问题?ai可能会给你一些常规的方法,什么webpack vite的proxy代理解决跨域,然后局域网监听,内网穿透让手机访问网址,修改host可以共享cookie等等,这些我也都不太懂。但其实公司里面大概率早已有成熟的解决方案,只需要访问一个共享的中间网站,让手机扫个码就能一站式解决所有问题,连proxy都不用配。所以你要做的是熟悉文档,判断问题和沟通提问的能力,以及一些超越前端范畴的网络知识。这些都是ai无法替你获取的信息。毕竟对ai来说,所有的问题都是你的问题,但对你来说并不是哈哈哈。2.假设你正在开发一个商品展示的详情页,现在拿到的是设计稿和prd,懒得一点点敲样式,打算把它甩给ai,直接告诉他在中让他直接生成静态代码。但很快你会碰到很多问题。首先是你要清楚你们项目样式方案要用哪一个,moduleCSS,CSS in JS还是原子化CSS,不说的话ai可能就直接把style塞到标签里了。其次是一些响应式问题,页面宽度不够时布局需不需要换一种展示方式,文字溢出怎么展示?页面宽度拉长的时候圆角比例不对了可以接受吗?页面上的icon怎么都不一样能不能统一复用?这些都需要和设计师一点点沟通甚至battle。第三是交互逻辑,用户体验以及一致的UI界面。滚动到底部有没有loading状态?滚动事件要不要节流函数?函数自己写还是用第三方库?用哪个版本?移动端支持度怎么样?商品的数据量有多少,需不需要虚拟列表?没数据的时候页面展示什么?高度是不是固定?此外,弹窗和loading 按钮是不是已经有通用的组件了,没有的话需不需要封装?需要封装到什么程度?需不需要发布npm包?这些都是由你和团队决定的,而不是完全交给ai,否则它可能用一大堆代码还原了一个你引入几行代码就能搞定的东西。AI不是不考虑这些问题,而是不符合你的预期,增加后续维护成本。有可能ai给你用antd写了一堆,但是明明你们部门之前有自己二次封装antd,也有可能它引入的包和你项目的某个框架不兼容。这要求你对部门技术有基本的了解甚至熟悉。3.进入联调阶段,你开始换账号测试,突然发现换到某一个账号后下单按钮疯狂点击没反应,开始排查。原因是这个用户在这个协议里受到了某些限制不能下单,后端数据库里拿不到数据,返回操作失败,前端也无法跳转下一步。理论上,登录之后如果他受到协议限制没权限,按钮应该隐藏,提示用户没权限。问题出现的原因,大家都应该背锅:产品: prd里面没写,逻辑和之前一样,因为默认大家都懂。没权限按钮肯定点不了啊设计: 照着prd画的,总不可能有按钮没按钮都画一遍前端: 你当时梳理业务的时候是给ai梳理的,ai打死也不知道你这按钮还会隐藏的,所以你没问产品,也没找后端加字段。后端: 只看prd,prd没写就没做。开发阶段前端也没说要加字段,就没加。现在你提出了解决方法,让后端加上一个字段hasRight,前端判断是否有权限,没有的话按钮隐藏掉。但是后端看了一下项目,发现这个字段的判断逻辑在另一个旧项目里面,所以让你去调用旧的接口拿字段。你求着后端说能不能聚合一下,后端说太麻烦不好做,而且不要重复开发,最好前端发个请求去拿就行了,所以为了一个新的字段前端要去另一个页面找请求是怎么发的。前端很委屈,但是也很无奈。新项目的页面用到老项目的接口,于是你打开线上页面,打开控制台翻请求看看参数怎么传的,发现那些参数完全没见过都根本看不懂啥意思。复制给ai它能帮你吗?恐怕不太行吧。无奈之下,你又只能去找这个项目的前端代码,在套了一层又一层的屎山里面翻来覆去,总算找到了那些请求参数的依赖逻辑,万幸的是这些参数都通过在新项目的现有数据推导计算出来,有些只是换了个名字。不过很快你又发现新的问题,这个老项目部署在a.com域名上,但是你现在开发的新项目部署在b.com上,即使你参数都准备好了,也会因为跨域拿不到数据。难道说还要在本地配置代理吗?甚至可能还要开发一个node中间层作为转发?开发阶段好说,测试和生产又怎么办?难道因为一个字段导致项目架构都要变动吗?要不还是找后端协调一下?怎么办呢? ai能帮你吗?你要是问题说不清楚,它真有可能给你本地整一个node转发层出来。。。4.提测阶段,第一天测试就拿了bug截图甩你脸上。你发现页面按钮全部挤一起,怎么回事呢?调试了半天才发现原来你习以为常的flex布局gap属性在某些安卓旧式机上不兼容。所以只能把项目里面手动把gap一个个换成margin–right和margin bottom。。。你好奇ai为什么没和你说?ai能知道就怪了。。。而且鬼知道你用什么机子测。测试的最后一天,产品突然说要加个埋点,问就是老板要,于是你只能拉回代码加埋点,本来想问ai,但是ai怎么可能知道你们部门埋点工具的逻辑呢?于是你只能去翻文档一点一点对照着写。最后看着卡着一动不动的cicd流水线感慨,为什么ai不能再聪明一点呢。以上场景都是我的亲身经历,实习几个月代码和技术没学多少,反倒是看到了不少甩锅和妥协。看到这你可能会理解,为什么我认为即使ai工具在我们日常开发中完成了大部分编码工作,它对我们的帮助程度仍然有限,大概占所有工作的30%-40%左右。我这还是个初级的实习生,对于更高级的程序员,这个比例只会大幅度降低。从最开始的业务理解,需求分析,到前期的架构设计,技术选型,旧项目的技术债务梳理,迭代成本评估,到具体的代码实现,安全性测试,bug调试,再到最后的生产上线,性能调优,前端开发涉及到产品需求提出到落地到后续迭代的全链路,在这中间很多事情是需要我们人去一点一点理解和实现的。很多时候我们面临的不仅仅是工作区的窗口那几个文件和几行代码,甚至都不是单纯的技术问题,是一个带有历史包袱和庞大上下文的复杂系统。所以我们要做的是打好地基,搭好框架,尽最大的可能缩减需求边界,明确限制条件,这样ai才能成为你得力的执行者,做好最后的搬砖工作,而不是一上来就让ai建造一整座房子。
AI Coding的使用...
点赞 评论 收藏
分享
评论
83
96
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务