Kano春招实习
面试官问你还有什么问题吗?
询问面试官的一些问题
注：比较基础的问题就不列举了，根据需要想问的就多问一点，下面列举一些工作之后反思的一些可以询问的点，也许会减少踩坑。询问的问题后续可能会更新补充，对于视频和文档，以文档为主。
询问组内技术栈
虽然说这个是老生常谈的问题了，但是我们问的是面试官，很有可能就是入职之后的组长级别的。提前了解组内技术栈还是比较重要的，在正式实习之前能够自己学一学。
想必在工作之前大家可能对于技术还是抱有好高的兴趣，无论技术栈是怎样，只要能够学到知识都可以，我当初就是这样的，但实际情况和想象还是有点差距。
大家在问面试官的时候可能会得到 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 头像。