Skip to content

春招实习

作者:Choi Yang
更新于:7 个月前
字数统计:2k 字
阅读时长:5 分钟

询问面试官的一些问题

注:比较基础的问题就不列举了,根据需要想问的就多问一点,下面列举一些工作之后反思的一些可以询问的点,也许会减少踩坑。询问的问题后续可能会更新补充,对于视频和文档,以文档为主。

询问组内技术栈

虽然说这个是老生常谈的问题了,但是我们问的是面试官,很有可能就是入职之后的组长级别的。提前了解组内技术栈还是比较重要的,在正式实习之前能够自己学一学。

想必在工作之前大家可能对于技术还是抱有好高的兴趣,无论技术栈是怎样,只要能够学到知识都可以,我当初就是这样的,但实际情况和想象还是有点差距。

大家在问面试官的时候可能会得到 vue 或者 react 这种主流框架的回答,这时候我们需要问的再具体一点,比如用的是 vue2 还是 vue3,react 是用的 hooks 语法吗?

首先说下为什么这样问,因为技术栈目前更新也比较快,过往的技术框架写法舒适度还是差一点,对比 react class 语法和 react hooks 语法,hooks 还是更香一点,编码效率也会高很多。

而对于 vue 生态,现在 vue3 的生态越来越好,我们可以看看组内技术栈是否会有人去升级,这里也可以参考一下组内是否有那种技术大佬,比较关注技术社区的动态,同理,由于组内技术栈升级了,自己也能学习,这也是一种「偷时间」的概念,在实践中学习非常锻炼自身,成长也会很快。

如果问到技术栈过于老套,其实是很影响开发效率的,很多一些新的玩意支持也会比较麻烦,根据上文也能参考一下组内的技术氛围。

对于有点技术折腾的程序员,我想应该都会出手。先不说这个开发周期的长短,首先提高自身开发效率,这样多的时间就能留给自己,咱们本身就是个工具人,正常完成需求之外的时间才是真正的赚钱,dddd。

其次,这里我再补充一点,就是不要觉得公司技术栈很多是一件好事,比如组内可能会用多个框架,比如 vue2、react、hexo、Next.js 等等,甚至还有一些奇奇怪怪你可能之前都没接触的,技术栈过多其实也是个麻烦事儿,平常处理的杂活也会比较多,这要改改那要改改。

关键是会有这种情况,比如我这个项目做了这个功能,在其它项目需要同步的时候,这时候兼容就是个大问题了,在我们技术角度,比如当时用 vue2 实现了某块页面,其实很难一下就复用到 react 项目中。

但是指派任务的一般又不太懂技术层面,所以就会存在理解上的偏差,比如产品觉得可以直接复用就行了,但自己心里清楚难搞,要花费一定时间,但往往这种事情不会给多少时间来做,毕竟之前已经做过一次了。

这就又能扯到工作中学习了,其实工作上的学习不算很多,往往都是基于你已经掌握的知识去做,如果技术栈过多,平常查阅资料的时间也会比较多,长期的处于这种开发周期的压力下,不一定能适应的过来,因此如果可以只使用某一种框架其实也是最好的,有兴趣我们自己去学点其他的。

当然,这里只是站在我个人角度来提工作中学习层面,这里仅供参考。

询问组内人员架构

我觉得这个也挺重要的,过去我其实不怎么在乎这一点,现在发觉以后自己如果跳槽了还是会问这个。

首先,技术面试官平常一定会多次与组内成员对接工作的,通过询问组内有多少人,人员是怎么分配的,我们可以获取如下信息:

  • 看看测试人员是怎么分配的,部分公司可能测试会是一个部门,也有可能测试是每个组都会有分配,组内分配其实是挺好的,大家合作习惯了,相互之前打配合效率也比较高,如果交由部门,会有这种情况,遇到事情比较多的时候,不一定能及时帮你测试,而多个测试,平常对接也麻烦,对于测试来说可能是新的需求,还得熟悉熟悉,这段过程就会需要沟通,也会花费一点时间。
  • 看看后端同学人多不多,这个有啥用呢,其实大多数组内业务复不复杂,可以参考一下后端人数,如果组内就一个后端,一般情况下,事情不会很多,业务不会很核心,算是躺平组了。大多数复杂业务还是需要多个后端相互配合的,所以这个可以作为参考。
  • 询问是否有前端组长,直接问前端组长,因为后端组长虽然有可能说是全栈,但往往在前端领域研究的不是很深入,大概懂个概念,能用一些旧的框架写写,但上文也说了,前端迭代非常快,过往的全栈还真不好说是真的全都能做的很好。对于组长这里,就涉及到话语权的问题了,我们作为一个实习生或者刚刚入职的打工人,往往没有什么话语权的,有组长在关键时刻还是很有作用的,比如遇到其他部门甩锅的情况,或者需求完全不合理的情况,组长这时候的话语权非常重要。另外就是有个技术组长,对于个人提升也很关键,多多向他学习。

询问平常的开发流程

这个开发流程我觉得也挺重要的,可以问问咱们公司用的是什么研发效能(管理)工具/平台,大多数公司都会吹一吹敏捷研发等等,那这时候就可以了解一下用的什么工具,比如 gitlab、coding、ones、tapd 等等,除开自研了,大多数公司都会购买这一系列工具来管理的,那么我们在入职之前也可以先熟悉熟悉工具的使用。

其次,问一下前端开发是否有相关规范,比如前不久我出过的 b 站视频,关于 git commit 提交规范的。

没有好的规范和 review 环节,容易留隐患,总有一天会因为某块代码没写好,导致 bug 出现等等,而这时候被甩锅背锅都有可能,在工作中也最好留一点心。

以上就是一些个人经验上的产出了,也许不一定有用,但或许能让各位换个角度去问点东西出来,当然思考也仅供参考,如果您还有更好的问题,可以提交 PR 共同探讨,参与贡献者会在首页显示 GitHub 头像。

Contributors

Choi Yang