一个宇宙条前端练习生的秋招阶段性总结

时间:2021-2-20 作者:admin

秋招步入尾声,我开始正式实习已经半年多,这半年我经历了三段实习,从海康威视,到有赞,到字节,过程比较坎坷,想以这篇博客为我的大学 & 实习生活做个阶段性的小总结。

先介绍下个人情况,双非渣本,大四,数字媒体技术(工科工科工科,专业真的是是对口的 😭),是个妹子,比较菜。

大学

入门

我选择做前端这个过程没走什么弯路,还是比较直挺挺的,只是学前端的路比较曲折,一开始什么都不懂学的太浅了,只会用不知道原理。

大二觉得自己可强了,有项目,有省奖,还是绩点第一,参加了下学校的秋招(作为双非渣本,我们学校的校招招聘要求可想而知)一上来面试官问,你讲讲AOE?

我:啥AOE,群攻吗?

当然挂了,之后就闭门开始学习了,我的大二到大三,简历上几乎没有变化,但是我觉得自己站的更扎实了。

然后就是大三,我开始找实习了。

我找实习道路也比较一言难尽,今年年初开始准备,二月底开始面试,投四家拿了三家offer,挂了的那个是阿里,最后四月去了一家国企,想着秋招算了。

然后被身边大哥们喷醒,五月面过了有赞,七月底拿到字节提前批offer,九月底到字节实习,秋招就结束了。

我的面试经验不是很丰富,一共上述六次,但是有丰富的阿里面试经验(算上 hr 面了 7 轮,反复鞭尸),所以还算能讲一讲。

准备面试

  • 简历

这里需要关注点可能是技术面试官和hr对于简历的关注点可能会不一样。比如hr可能会关注你的结果(绩点、奖项、项目成果),技术面试官可能更会关注你的技术广度和深度还有解决问题的能力。在简历中最好这两块的内容都关注到。

有学弟问过我,绩点在求职中重要吗。

我觉得重要,也不重要。它就像人的颜值,要是这个人优秀,颜值差了点,可能会想,虽然长得一一般般,但问题不大,毕竟能力强。

要是这个人能力不够,长得再好看,可能也不能挽回。

  • 基础知识

我补基础知识的方法很粗暴,就是刷题,牛客网的客观题我全部刷完了,碰到不会的就是MDN搜,然后补到我的思维导图里,这个过程花了一个月左右的时间。

准备面试的时候真的是基础知识储备的巅峰,上班后就停滞不前了,所以趁大学,大家还是把基础打好,不然后面debug会很痛苦,这个不知道怎么回事,那个不知道怎么回事的。

  • 项目准备

项目主要是大一大二积累的,主要有PC、移动端和原生安卓,我为了讨巧还开发了一个简历小程序,用图文展示自己所有的项目和奖项。

当时还没开始面试,有小姐姐从内推群加我了解情况,我发了小程序二维码,虽然还没开始准备简历,但是你可以从我开发的这个小程序了解我,当时看小姐姐反应觉得很稳。

还有一个万能的项目点就是登陆,别看他简单,讲清楚单点登录、token、cookie、跨域等等其实并不简单,能讲清楚这些还是很加分的(有被问过如何设计一个登陆场景)。

  • 其他

    1. 源码。

      我读了vue和react的源码,并跟着写了demo和博客。读过源码之前和读源码之后看待bug的问题会不一样,因为我们对数据 -> 视图的全链路有一个更清晰的认知,所以更清楚可能是哪个环节出了问题。

      还有就是面试的时候可能可以加点分,有一轮面试官问我读过哪些源码,在我叭叭叭的时候,面试官已经默默通知HR可以安排下一轮面试了。

    2. 品质。

      在面试的反问环节,我几乎都会反问,您觉得实习生最应该有哪些品质 / 您更希望找到什么样的实习生,得到的很多回答是“聪明”。

      这个聪明就很灵性了,我总结了一下可能有这两方面,第一,希望你有解决问题的能力,碰到问题有一套自己的排查方式,并且能够沉淀复盘;第二,学东西快,举一反三,理解能力强,表达能力也强。

    3. 心态。

      一定要自信,我大三春招的时候就是因为不自信而且害怕面试,所以大厂只投了阿里,走了两个月流程,耗到最后 hr 挂了,错过了很多很多很多机会,有机会大家尽量海投,不去也可以积累面试经验。同时,如果面试中你表现的很自信,对面试官来说(尤其 hr 面)是很加分的。

实习

我一共有三段实习经历,分别是海康威视,有赞,字节,这三段实习经历明显的感受就是,工资随工作时长直线上升,妹子数量随工作时长直线下降。

接下来我想从这几个方面谈谈我的思考和感受(当然可能有一定以偏概全的情况,毕竟我实习的时间不长,欢迎讨论)。

成长

我想从技术和业务两个方面谈论我的成长,因为在实习的半年里,增长最快的不是技术,而是我的业务水平。

在业务上,一开始我陷入一个误区,我很少关注除了技术以外的事情,我从来没有参加过的业务分享会,每天只完成PM分配的需求,以支持需求数量为自己工作质量的自评。

在有赞的时候TL跟我说,他不会以”支持需求数量和速度”来评价实习生,因为组里每一个前端都能做的很好。

在字节我的mentor跟我说,所有的技术基建都必须是落地在业务上的,没有基建可以脱离业务的落地。

这两句话我对我影响是比较大的,刚实习的几天我很焦虑,因为感觉大家都在疯狂输出技术,我啥也想不出来,但是这个情况在我实习几个月之后迎刃而解,因为我接触了更多的业务,我才能感受到他们的共通点,我才有能体会到可以优化的空间在哪里。

保持思考,是我作为一个实习生学到最多的,当然不仅在于思考技术,还有业务本身,这点在宇宙条体会很深,每次周会我们都需要同步本周业务线GMV、PV、UV等数据,在需求评审会议上,RD们也会因为交互、功能设计提出自己的想法。

基建

除了有赞规模在3000-5000人,其他两个公司规模都是上万的,但反而我觉得有赞的基建是最完善的,这个完善可能不在于技术多强多好,而是整个公司的技术架构和基建是最统一的。

在技术上,有赞很少出现,不同业务线工作流和技术架构有很大的gap,这也使得我可以很快上手任意一条业务线,当然这也很大取决于有赞的规模适中且业务集中。

反观宇宙条,业务方向多,开发团队多,每个团队用的东西就开始五花八门,当然这个一般情况下问题也不大,因为核心是差不多的,适应了之后发现这些gap是因为需要适应不同团队的具体情况。

技术

对于代码质量,字节是要求最严格的,可以很明显的感受到每个人对于代码的追求极致。

其实这也很大原因在于字节的用户体量,体量越大,服务稳定性要求更高,在这一方面我个人感觉可以有以下两点感触比较深的

  1. 复杂逻辑运用设计模式

举个例子,之前碰到一个场景,大概有AB两个变量会影响结果,A有三种枚举值,B有两种枚举值,排列组合一共六种,当然我一开始就是用很朴素的方法写,类似于 ⬇️

render() {
  const { A, B } = this;
  return (
      {A === EnumTypeA.a && (<span>UI A</span>)}
      {(A === EnumTypeA.b && B === EnumTypeB.b) && (<span>UI B</span>)}
        ....
  )
}

丑陋,但能跑。但是如果需求有变要改逻辑,稍有不慎就会改错。

CR的时候,大哥给我提的思路类似于工厂模式,这样可维护性和可读性就大大提升了,需求怎么改其实都不怕。

uiMap = {
  [EnumTypeA.a]: {
    [EnumTypeB.a]: renderUIA,
    [EnumTypeB.b]: renderUIB,
  },
  [EnumTypeA.b]: {
    [EnumTypeB.a]: renderUIC,
    [EnumTypeB.b]: renderUID,
  },
  [EnumTypeA.c]: {
    [EnumTypeB.a]: renderUIA,
    [EnumTypeB.b]: renderUIA,
  },
}

render() {
  const { A, B } = this;
  return this.uiMap[A][B]();
}
  1. 谨慎技术改造

特别是如果这个板块原来不是你负责,要进行重构或者改造,那可太容易出错了(血的教训),因为对这些业务不熟悉,很可能漏掉原有的逻辑或者重新踩一遍原来的坑,最后发现还真的只能那么写,我个人的做法是:

a. 现状梳理:复杂板块产出技术评审文档梳理现有业务&代码逻辑,尽量覆盖原有的逻辑

b. code review:每一次 commit 前都仔细 CR,有的改动全局搜一下改动到的变量或者组件,看是否影响到了别的业务

c. 自测:测试尽量覆盖到所有功能,有些理论上不会影响到的模块,可能也会因为改动,产生有意想不到的问题

后记

大概就写到这里,有不同的理解和补充欢迎讨论,希望大家都工作顺利~

声明:本文内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎进行举报,并提供相关证据,工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。