【年终总结】微信前端社招有感

2018-12-02 06:14:00来源：博客园阅读 ()

时间飞快，转眼间8102还差一个月就over了，顺了顺好几天没理的胡渣儿，好像已经老了不少。

不，我还很年轻！虽然年终还没到，但好像也差不多了。

几经辗转，年底前终于拿到了微信的offer，可以说是今年一大幸事了。

是一个结束，结束本命年的坎坷；是一个开始，开始新的征程。

这篇杂文就简单记录一下微信前端社招的经历，以及回顾这两年半做过的东西。

一、过七关

微信社招，老早就听说难度极大，十几轮面试的情况都有。

所以急不得，大概今年下半年开始，本菜菜就着手准备了，主要是扩充知识面以及加深对相关知识的理解与运用（暴露了平时有点懒。。。）

说实话，这半年收获颇多，熬夜也最多，应该有十来次为了理清某些东西，奋战到半夜两三点，若是失败了就过几天再战...

可能不同的岗位性质不同，要求也不同，对我而言，整体上对业务解决能力要求很高，算法方面则没有太高要求

每轮都问到了职业规划，为什么离开目前的环境

我总共经历了七轮（4轮技术、两轮GM、一轮HR），轮次可穿插并不是按顺序的。面试体验都非常棒~

当时觉得可能面不到最后，没有刻意去记录面试问的东西，所以现在也忘得差不多了，也没必要刻意去刷面试题，就算刷到了，不久之后也会忘的。

1、技术电面（1h）

这轮算是探实力吧，确认有没有前端基础和好的项目经历。

首先以在公司承担的角色作为开端，问了平常做过的一些项目，介绍其中一个，就从里头挖掘业务的问题和解决办法，同时抽取一些前端技术题。

没办法，项目说起来不够复杂呀，似乎面试官并不满意，自己就趁机把话题引向了其他有特色的项目来突围。

抽了一些博客上记录的知识点来问，期间竟然找了我四年前的文章（问了各种编码，以及BOM头优缺点适用性）和某道算法题 -_-

HTTP和HTTPS的握手过程，是否了解HTTP2的特点，以及怎么理解它的多路复用

还讲了对前端安全和性能的理解，移动端的认识等

总之第一轮感觉还好，勉勉强强，话比较多，时间不慢的。

2、技术现场（1h）

这轮感觉跟第一轮差不多，只是比较正式些，来到了广州塔旁边的T.I.T

除了栽在了iPhoneX刘海屏的相关问题和移动端适配是否需要支持高清屏的“争论”外，基本稳住了气场。

深知自己没有可以拿出手的很牛逼的项目，为了体现自己还是会一些东东的，就只能穿插着讲出几个项目了。

讲了前端优化的实践（为什么优化，怎么优化，怎么评估，还能怎么优化）

前端错误收集（怎么记录，怎么区分是不是第三方插件的问题，怎么上报，怎么分析）

问了PC端和移动端的转换，ES6常用的东西，数组方法大全等

3、技术现场（1h）

本轮是和前一轮衔接在一起的，这种方式挺好的，可以节约候选人来回奔波时间。

当时感觉是总监级别的，因为气场有点强大，短裤拖鞋很随性，判断得出来反应必须非常快才能留下好印象，后来才知道是组长

问的东西，前端方面相对少一点了，偏向于整体性

问了目前团队现状，在团队前端沉淀，技术预研上做了什么，为什么这么做，有没有起到什么作用。

列举几条前端代码检查规则，为什么这么制定

有没有做接口的统一规范，返回码之类的规定，怎么和后端协商好这些规则，怎么让新人很好地用好这些

为什么要做小程序预研，它不是很简单么

MVVW是什么，有什么优缺点

怎么实现记住登录功能（很强的整体性）

怎么实现统一登录，或者授权登录需要考虑什么（更强的整体性）

4、HR现场（35min）

直接就来到了hr面，很快吧......流程可以随意插进来

一不小心提前1h到了现场，前台那小伙子也不知怎的，直接就联系hr了，说实话我本不想打扰的

不过hr马上就下楼来接待了，进入稍许嘈杂的咖啡厅慢等，服务质量还阔以，在这里是要点个赞的

本轮面试主要考察了团队感受，过往的项目经历，技术学习能力，薪酬期望

期间面试官也很直白的说，她要知道有没有解决复杂问题的能力

直接从大学阶段问起了，从在校时期做的最好项目，到工作时期做的最好项目，

听起来似乎还是没对胃口，就只有拿出自己为解决问题不辞辛劳很有决心的不堪历史来说了 -_-

问了平时解决问题的方式，有没有从团队中学到了什么，跟谁学到的，团队中角色，觉得团队有什么问题

5、GM现场（30min）

本轮是直接连着HR面的，基本没问技术，侧重考量业务理解能力以及是否适合部门

看到面试官戴着一个佳明跑表，想必也是跑马人士哈哈哈，相对来说还是蛮轻松的，把之前的项目又说了一遍

如果要做一个数据分析系统，在前端方面可以做什么东西（涉及了需求理解、功能拆分、技术实现）

问了自己做过什么业务，期望什么业务方向

介绍了职级体系，部门的业务特点

6、GM电面（15min）

本轮面试可以说是最惨的了，感觉面试官并不满意自己做的项目，草草就收场了，也就诞生了第七轮技术面。

团队的成员分布，各角色职责和定位，怎么进行版本迭代，一个系统的开发与维护周期是怎样的，项目延期的时候怎么做的

因为做的主要是内部系统（面向公司内部的需求），被问到为什么不尝试部门间转岗，为什么两年多了还一直在做内部系统

介绍公司其他部门团队的业务等

7、技术现场（1h）

本轮面试属于技术交叉面，即由其他部门的人来面，主要还是因为前几轮表现不佳，让面试官们犹犹豫豫的。

这小哥一直乐呵呵的，看起来很容易谈得来，也确实很容易谈得来。后面HR说他是少有的T4级前端，大大牛呀...真是随和

面到后面才知道，他一直想挖出我拆分问题的能力，如何对大的问题进行分解，逐个击破，同时思维要发散，也许还有更简便的方法。

一个难题，比如我提到了曾经想过整一个适合部门的CI/CD方案并实现，不过遇到了蛮多难题就没有做下去了

这里就缺了拆分问题模型的能力，不应想着难度太大做不了就做不了，而应该分析好从小的做起，一点一点地添加，慢慢坚持。

其实是自己作死挖了坑自己跳进去了..

说了经常写技术博客和整一些Github项目是一个非常好的习惯，挑了性能和安全方面的项目实践来问，

为什么用requestAnimationFrame来代替setTimeout

首屏太慢的问题除了SSR这种方法还有没有其他更简便的方法（在前端方面直接干）

前端规范的落地，碰到的问题和解决过程

过往业务能力与技术能力的实践

有没有看过一些源码，整理的webpack项目有什么难点，怎么进行优化的

怎么调试，sourcemap是什么东东

两颗树比对一般怎么做，React中虚拟DOM是什么，它在树对比方面做了什么优化，新版本React有什么性能上的变化

从开始到结束，进行了差不多一个月，进度好像还是蛮快的，

总之，就目前这个部门的社招面试而言，我感觉侧重考察的点是 是否具有解决复杂业务的能力，

当然，学习能力，技术专研，技术广度在两三年经验这个阶段是非常重要的。

二、出师不利

其实我在这前两周，还面了微信公众平台那个部门，一面电面就跪了，面完感觉可挂可不挂的样子

主要问题出在：

用了很久的JQ，却没认真地看过源码，被问到如何像JQ那样实现动画向左再向右不同的速度，回答得七零八乱

问了JQ中选择器的识别解析顺序是怎样的，为什么从右到左，我竟然说成了从左到右性能应该会更高。。。可能是大脑空白了吧

问了在React中事件处理回调里面，连续setState N次，会出发几次render，理解错误，以为他说的是特殊的那种自定义事件绑定，回答了这个事件不会受到事务处理的周期影响，所以是N次。我还有骨气地争论了起来。。。

问了平时有没有意识去看一些项目中用到的框架插件源码，我竟然表达出了一种并不想了解其内部实现的论调 -_-

项目中的某种解决方案太暴力了，还有更优雅的方案没有用到，联想到所做项目复杂度和技术追求应该不会很高

也不知当时是怎么了，面完就呆坐在那回想，不敢相信自己会那么回答

应该就是很久没被面试了吧，慌了神，也没有总结好自己所做的项目，分析出项目中的重要部分，技术积累还是不足。

不服呀，随之就利用了接下来的一周时间，把JQ源码完整地看了一遍，我等菜菜只看懂了八九十这样子（也算是第一次完整地看源码）

然鹅，公众平台的告吹经历，直接导致了下一个运营平台的不合适（因为是同一个大团队负责的），可以说很惨烈了

还好后面有个机遇

三、这两年半

算起来毕业差不多两年半了，毕业那会定下来的职业规划，前端规划，现在看来肯定是没实现多少的了。回想起来，还真没有什么可说的

前一年半大概过得很潇洒，大部分周末都会带着小相机外出拍来拍去的，逛了广佛附近蛮多所谓的景点（四五十个应该有了），

近一年意识到再这么下去会不会废了，就减少了周末外出的次数，想着看看书搞搞个人项目什么的，

然鹅那是不可能的，在家会不知不觉玩起了手机，还熬夜玩手机...

部门负责的是公司内部的系统，内部系统，即用户群体为内部员工

常人看来多为管理后台，外加很多奇奇怪怪的权限

权限多那是没错，但管理后台就真没几个了，内部系统也可以有各种各样的系统

就系统来说，算下来应该新开发了十来个新系统了，项目参与度都非常高，各有特色，也有蛮多有意思的技术点

对业务的理解能力应该有了一些提升，至少不会趋于局限，能经常从整体的逻辑关联上考虑问题了

其中大概有三个系统，大大锻炼了前端整体架构方面的能力（这里指的是需求整体分解，功能模块划分及通信，技术实现规划，人员分工排期）

也从最初的对产品毕恭毕敬到现在的产品沙比-_- 需求调整真是非常快

整了一些移动端活动页，不过也仅是活动页了，若是说移动端的系统，我还是没有太多经验的，所以后面就跟随技术的步伐，整了个移动端的适配布局，以备不时之需。

移动端的调试，部门内一直没有一个可用的方案，一碰上问题，根本不知道怎么解决。后面就整理了一个比较完整的调试方案，用得还算方便

资源文件缓存的问题一直存在，很多时候大家会忘记加上时间戳（或不知道要加，或忘了加）

为了改善这个问题，把尘封已久的Node.js拿出来玩了玩，整了一个本地监听文件改变则更改相关引用资源时间戳的小工具，在其他老项目中也一直沿用着

在requirejs项目中的去缓存配置是比较暴力的，设置urlArgs直接配置所有资源的时间戳，后来想着能不能结合Grunt和Gulp来自定义资源的时间戳，正好也可以搞起前端构建工具，然鹅都失败了，文件依赖实在不好解决。把目光投向webpack，也是想着先结合一下，差不多到成功的时候发现，一个关键的路径依赖问题实在搞不下去了，时间关系只有放弃（当时这块已经研究了一周多了，不能再浪费时间）。就放弃了对requirejs项目进行这种时间戳优化

从而也诞生了另外一个方案：使用webpack和es6（或者再加上React）作为技术栈。webpack这个东西，其实配置是蛮复杂的，好像也没有一个比较完整的构建配置例子和说明。React和Vue提供了开箱即用的脚手架，但当时觉得还是自己整一个好一点，就花了非常多精力去调试配置项，印象中最麻烦的应该就是热更新替换、jquery相关引用、编译性能、模块提取权衡、资源路径处理这几块，不过最终还是搞了起来搞出成绩，绩效拿到了唯一的一个S。多的时候会同时开十几个项目的编译进程编译，随之整了一个同步读取可用端口的npm包，防止热更新端口冲突。为了便于维护，也对开发和生产环境做了区分。

后端已经完善了一套代码规范，而前端竟然参考的还是后端的PHP规范，也只有JS有这种规范。没有规矩不成方圆，就在某个季度初期，决定把前端规范搞一搞。遂参考了大大公司们的规范，结合项目中的使用情况，整了一套适合部门的规则，看着算是比较完整的。然鹅，人是不可信的，还是应该有工具来限制好这个规范的实施，又搞起了前端代码检查工具，经历了选工具、选规则集、各编辑器配置规则集、webpack配置规则检查四个痛苦的过程，本来还想弄一下SVN的hooks来做提交前检查的，只记得遇到了蛮多问题就没有继续往下了。不过，前端规范的落地，目前来说并不是非常理想，落地这块还是蛮有难度的，还得考虑后端突然也改前端的代码。

渣渣电脑越来越卡，项目编译得越来越慢，在webpack4趋于稳定的时候，觉得应该升级升级以提升效率，果不其然，升级后速度提升了近7倍。结合日常开发的那堆项目，心想应该可以让配置更为简单，便对配置项再度抽离，核心文件抹平不同项目之间文件路径的不同，对外暴露业务关键配置部分，绩效继续拿了个A

前端安全这块也是一个很大的知识点，自己最初也是懵懵懂懂的，后来也是想着要彻底理解它，以在部门内进行分享为目标去研究它。在项目中不断地测试后，最后便整理出了之前那篇文章，因眼界不足还有很多可以改善的，得等以后慢慢去整了。

前端性能方面，完整地看了Chrome DevTools和相关官方出品的文档，早些时候也过了过那本《Webkit技术内幕》。目前进行了四个比较有意义的优化实践，两个移动端活动页的卡顿优化（主要是安卓手机呀为什么经常卡..），一个页面加载性能优化，一个页面运行时性能优化。目前正在尝试做JS运行优化的实践

前端错误记录，打点监控方面，也没有做过太多的实践，这个和前端测试一样，都算是没啥经验了。目前正在开展这块的调研

源码解析方面，完整看了JQ源码，看了React源码实现的主要部分，理解了webpack编译生成的文件规则

看书方面，看了两本小说，十几本技术相关的

个人项目方面，就写了四五个小项目

带了两个新人，第一个是个好苗子可惜后面就撤了

另外一个就差一些了，没啥基础，校招后端转过来的（也不能怪他，就怪老大骗他进来做前端）

面了十几个人，有不一样的感受，还是很感谢能有这种面人的经历的

团队管理方面，说真的，我们前端老大真是失职呀，团队基本没什么成长，没什么规划，也经常请假，我都替他忧心。找个好老大很重要

所以平时就承担了一些本该前端负责人才做的工作，也了解到并实践了一些管理者的日常

然鹅好像没啥兴趣，看起来我还是比较偏向做技术的...

最后回头看看，技术提升的曲线的是有些放缓了，可能我不算是那种Geek吧，有时会懒得写代码懒得做技术，有时又很能投入进去。

应该多回顾一下过于做过的东西，有没有价值，有没有提升，自己有没有懈怠。多看看外面的世界是怎样的。