为什么招聘高级前端开发这么难？

旧城等待， 2022-12-17 15:59 188阅读 0赞

腾讯、阿里、网易 这种级别的我不敢说，以我个人的经历来分享一下吧。

先交代背景：上海的创业公司，成立快十年，团队规模近百；主力是自己的产品，有时也作为技术合作方帮合作伙伴做一点外包；前端团队10人以内，目前主要技术栈是 React。

负责招聘工作也有 2 年了，题主给出的要求，别说这些大厂，我们这些普通小厂基本也都这么要求。但从以往的情况看，大部分应聘者都是：

> 1-5 年工作经验，专科 > 本科，跨专业 > 计算机专业。
> 
> 大部分是一毕业就从事前端的；排第二的是 UI 转前端；然后是其他更远的行业转过来的。
> 
> 项目做过不少，但技术含量普遍不高，体现不出什么。
> 
> 会 Vue 的比会 React 的多，全家桶做 SPA 都会，服务端渲染基本没接触过。
> 
> 基本功勉强及格，但提到规范、标准了解非常有限。
> 
> Node.js 最多跑过 Demo。
> 
> Webpack 用过但不会配置，Git 会基本操作但不懂 Git Workflow。
> 
> ESLint 之类的基本都听过，坚持做的没几个。
> 
> 鲜有自己博客或者 Github 有可展示的内容的。
> 
> 英语水平普遍很糟糕。  
> 总的来说就是能干活，但知识结构不够系统，规范性太差，需要团队里有人带。

有人说是不是你要求太高了，有本事的都去大平台了，能来你这儿的质量不会太高。这话有一定道理，但说真的，我的要求已经很低了。给大家看一些我面试经常聊到的话题，个人认为都还是很基础的，如果这个水平都达不到的，我是真的不放心把项目交出去：

Q：简单介绍下 React / Vue 的生命周期

A：几个钩子函数基本能报出来（如果不讲究按顺序、按挂载/更新区分、能把单词用英文念出来并且念对的话），稍微深入一点问下各个阶段都做了什么，一半以上就“不太清楚”了。更有甚者我问 React，对方回答 created、mounted，提醒之后还觉得自己没错的。

Q：【React】定义一个组件时候，如何决定要用 Functional 还是 Class？

A：简单的用 Functional，复杂的用 Class。（不能算错吧……但也不能算答到点子上）追问怎么界定“复杂”，答不上来。

Q：【React】HOC、（非）受控组件、shouldComponentUpdate、React 16 的变化

A：不清楚、没接触过。

Q：【Vue】介绍一下计算属性，和 data、methods、watch 的异同

A：基本都能巴拉一些，说的大部分都对，但就是说不到最关键的“当且仅当计算属性依赖的 data 改变时才会自动计算”。

Q：【Vue】为什么 SFC 里的 data 必须是一个函数返回的对象，而不能就只是一个对象？

A：我承认这个问题有点小难，有一定的区分度，不是每个人都有关注过，但是官方文档有说明这一点，但凡看过的肯定有印象。即便没完整看过文档，在初次学习的过程中难道就不觉得奇怪吗？“学而不思”的人和“学而思”的人，区别还是挺大的。

Q：CSS 选择器的权重

A：经典问题了吧？背都能背出来吧？伪类、伪元素分不清楚，只知道内联、!important、ID、Class 之间的顺序，加上其它的就懵了，而且只说谁大于谁，讲不出具体的计算方法。单层选择器比较还行，几个叠加起来就迷糊了。

Q：JS 有哪几种原始类型

A：基础题，能说上来几个，答不全，主要问题集中在 null 和 undefined 没考虑进去、对象和数组算不算原始类型、以及 Symbol 很多人不知道。

Q：ES 2015+ 有哪些新特性

A：这题可以说的很多，根据应聘者的回答去展开，可以很容易地看出应聘者有没有系统地学习过这方面的东西，以及有没有持续地去跟进语言标准的发展。但这一题能回答的比较好的，寥寥无几，大部分是遇到问题然后零零散散现学的，不够全面、也不够深入，简单用过，但稍微问点细节就只有“尴尬而不失礼仪的微笑”了。

Q：工程化工具的使用（Webpack、ESLint、Yarn、Git、……）

A：基本都有所接触，但只是“用过”，算不上“会用”，一切顺利还好，真遇到问题了，立马就懵。

Q：Node.js

A：写过 Demo 的水平。

Q：未来 1~2 年的职业规划、下一步最想学的技术、最希望往什么方向发展、怎么看待XXX技术

A：大部分人对自己没有一个明确的态度和规划。说白了就是还没从学校里出来，什么都等着别人来安排。

难吗？

以 3 年为例，差不多也算是职场上一道分界线吧。优秀的人不会担心没处去，不那么优秀的人各有各的理由。个人感觉这个阶段的人大部分都还缺少一些“职业性”，对自己在职场上的“人设”没有很好的关注过，只知道风往哪儿吹自己就往哪儿去，对自己的未来完全没有规划。很多人的技术成长都依赖于公司的业务，学不到东西全怪公司太小接触不到技术难点，然后就想着跳槽，寄希望于新的环境能有牛人带。殊不知技术的积累和公司做什么项目一点关系没有，完全是靠自己对行业的理解，以及空闲时间的安排。

我自己工作年头也不算太长，到今年年底算整 3 年。多的咱不说，毕竟没经历过的没有发言权，分享一下我所理解的1 ~ 3 年，3 ~ 5 年应该有的样子吧。

第 1 年：

以自己经历来说吧。16 年入行，Bootstrap + jQuery 实现功能没问题，但代码设计功力还很浅。我入行的时候 React 和 Vue 刚火起来，Bootstrap + jQuery 还是主流，ES2015 已经出来，我也学了一半了，但 Gulp、Webpack 还一样都不会。接手的第一个项目是 Angular.js 的，之前没学过，第一天就让改东西，只能现学现卖，接下来一周自己花时间把 Angular.js 基本用法搞懂。同年自学了 LESS、SCSS、Stylus、PostCSS，工具方面把 Gulp、Grunt、Bower、npm、Yarn、Webpack 都学了一遍。刚入行时候最大的感觉就是整个行业都在往组件化走，同期有一大堆的工程化工具需要掌握，整天活在一堆听不懂的名词里，所以当时的目标就是尽快把这些不懂的东西弄懂，能跟同行说上话。

第2年：

头一年的目标还是顺利达成了，到年底，我已经全面采用 ES2015+ 开发了，相关的工程化工具也都基本掌握了，但到框架层面还是只会 Angular.js，而主流市场好像已经有了新的选择。看网上评论说 Vue 上手简单，于是从 Vue 入手，开始学习新的技术栈，做了几个项目觉得比较稳了，就开始挑战 React。这一年 Angular 也开始了大改版，到下半年的时候，我找了一个相对不重要的项目，试水了一把 NG4，并实践了 TypeScript。至此，主流的技术栈基本都掌握了，满足常规业务需求不成问题。

第3年：

18 年开始公司迎来了一个高速发展期，单个项目的规模光靠一个人已经顾不过来了，需要团队协作。既然是团队协作的项目，那么就要考虑大家的能力差异，不能再像以前那样随心所欲了，需要给团队制订一套技术选型方案，以及必要的开发规范。好在之前对主流的几大技术栈都有过了实践，因此这时候也才有了选择的权利，一番权衡之后，为团队定下了现在的技术方案，并整理了一套开发规范，包括开发环境、代码风格、开发流程、最佳实践等等。这一年也是我第一年真正以一个 Team Leader 的身份去带团队，身份的转变也打乱了我原本的学习计划，我很难再有比较连续的时间可以用来系统地学习一些技术，经常会被一些杂事打断，可能是各式各样的会议，可能是团队成员遇到的技术难题，我从一个主攻手的位置，变成了一个辅助型的角色，游走在几个项目之间，哪里需要就去补位。当然，即便如此，我还是会在晚上、周末，给自己留出时间去做技术积累，前两年主要是在弥补广度上的不足，现在开始就需要往深度去走，例如设计模式、语言标准、代码规范、内核原理、算法优化，当然一些常规的技术也还是需要花时间去学习的，像 RN、Electron 都是非常值得投资的东西，包括一些服务端的内容，想做 CTO 的话这些都跑不了。

小结一下，前 2 年主要在于观察和积累，从刚入行的新人快速成长为一个能够独立负责项目的开发者，对行业内主流的技术方案足够的熟悉，常见的问题要能马上给出方案，不熟悉的问题也要有思路该怎么去解决，做到“但凡是我领域内的，不允许自己做不到”。扎实的基础在任何时候都是你说话的底气。到第 3 年，这些储备应该已经就绪，至少不能让它成为你的短板，这时候需要开始思考一些基础技能以外的东西，比如管理能力，无论往后准备走什么路线，即便是纯技术路线，也早晚会要带团队。带团队也是需要方法的，这种能力谁也不是与生俱来，面对不同的团队也需要因地制宜给出不同的方法，所以要学的东西还很多。当然技术方面也不要因此而放下，技术的更迭是永恒的，这方面的学习也是一个持续的过程，只要你还在技术圈混，技术实力永远是你服众的最佳利器。什么时候跟不上了，也就差不多要被淘汰了。

3~5 年

这一阶段我还没经历到，但是很快就会进入，所以自己也有一些打算。进入到这个阶段的人都是跳槽市场上最受欢迎的，往年一直都很安静的求职 App 开始大量地向我抛橄榄枝，各种猎头也是隔三差五的联系我，毕竟从概率上讲，3 年以下都还算新人，能淘到的宝很少，从 3 年以上的人里挑就会容易许多，毕竟到这个时候了，该经历的也都经历过了。当然跳槽并不是我们这里要讨论的问题。

到了这个阶段，市场默认你已经是个比较成熟的开发者了，没人会再把你当做应届生看待，你需要表现出足够的职业性，对技术、对行业的看法也需要有一定的深度了。从这里开始，应该开始接触一些通用工具的开发、系统设计、性能优化、新技术探索、团队管理等初级开发者做不来的事，如果你还是只做一些一线的业务开发，出个页面调个接口之类的，那么就该考虑到底是自己能力不行，还是被环境束缚了。

所以为什么招不到人，因为真就是没有那么多“野生的”符合条件的候选人。大把大把的人其实完全有潜力成为市场想要的那一种，但是需要人去点化，让他们明白自己要怎么去做才能更好的成为市场需要的样子。多年来的教育培养出了一大批“懂事听话”的孩子，现在放任他们自由了，反倒不知道怎么做决定了。都想伯乐能看到自己，却不明白自己要怎么样准备，怎么样展示。

所谓的“高级”，很多时候其实指的并不是你在某一方面的技术有多 NB，而是你做事情的方式让人觉得“专业”、“靠谱”，事情交给你之后就能放心的回去等结果了。人家要的是结果，而不是你某一点的能力有多厉害，资本方是不在意技术细节的，只有你自己在意。

能干活的有一堆，但是有自己独立思想的人，真就那么稀有。也正因为稀有，才体现出价值。如果满天飞的都是“高级”了，那么我们是不是又要重新定义什么是“高级”了呢？

====================

1）评论区有人回复说难道只要会这些基础题就可以 20-40 K 吗？网络、数据库、操作系统、数据结构、算法，这些计科的基础都不问的吗？上海的钱这么好赚的吗？

当然不是！你能问出这种问题说明你自己心里也有数。

我举例的几道题只是一部分，用来说明我的观点的，不是把我完整的面试过程全给你了，这不是开卷考……

本着实用至上的原则，我一般会先从这一类的问题开始，回答得比较好的，才会往下深入。二元一次方程都都解不来的，我跟你谈微积分有意思吗？

====================

2）评论区里有不少人（甚至一些来自大厂的朋友）认为在面试中问这些基础题没有意义，觉得这些知识点无法体现出候选人的实际能力，甚至不需要记在脑子里，用到的时候上网搜就行了。

对于这一类的观点，我一贯的态度是：不敢苟同。

前面列举的这些题，其实是在起个话题，候选人如果对这块比较熟悉的话，会有很多东西可以讲。这时候根据候选人的表现，至少可以看出：1）候选人对特定知识点的掌握程度。2）候选人的知识体系是否足够系统，能否融会贯通。3）候选人表达、沟通能力如何，有没有学傻掉。这其实是对候选人能力的综合考察。

我并不反对日常工作中上网查一些 API、语法，得道有先后，术业有专攻，有些事在所难免。这些题如果有少部分回答得不是很好，甚至完全答不上来，都是可以接受的；但如果大面积的答不到点子上，那就有问题了。这些都是非常基础的知识点，日常工作中几乎每天都会接触到，如果这些还不能脱口而出，还需要上网查，你让我怎么放心把项目交给你。

成败在于细节。我们平时遇到的 Bug，很多时候其实就是一些很基础的点没注意，出了问题，这时候如果心里没点数，就很难排查出问题的所在。同样的，在 Code Review 中，我们经常会看到一些问题代码，虽然功能实现了，但实现的方法并不好，究其原因，就是对这些技术细节理解不够，导致很多问题没有考虑到。如果是新手开发者，可以理解，毕竟还在成长；但如果你顶着“高级工程师”的 title 还总干这种事，那就要好好反省一下了。事情虽小，但如果放任不管，积少成多，迟早会酿成大祸。

专业和业余的区别，在我看来，就在于各种细节。同样遇到一个问题，一个需要上网查，一个直接脱口而出，高下立判。况且，在搜索引擎的帮助下，业余开发者也可以轻松做到 60 分；如果你也只是如此，那拿什么体现你的“专业”呢？

有些人觉得我已经工作好几年了，应该去干一些更大的事，就不必再纠结这些基础的细节了，那是新手该考虑的事。再高级的上层建筑，也都是建立在良好的技术基础上的，底子不牢靠，越高越容易倒，摔得也越重。试问，是什么样的伟大事业，连这些最基本的问题都解决不了的人也能胜任？

====================

3）关于 CSS 权重的那道题

首先，这只是诸多面试话题中的其中一个，不是说这个答不上来就直接 PASS，不要见风就是雨 OK？

其次，有些朋友对这个话题的意义提出了质疑，鉴于讨论的比较多，这里就展开一下：面试中问这个问题，可以考察些什么：

很多人习惯于 LESS / SCSS 嵌套式写法后，已经不再关心选择器的权重了，甚至都忘了还有权重这回事儿，所以第一个考察点：是否知道 CSS 选择器有权重一说，这是一个 0 跟 1 的问题。

上面提到的这部分人，很多是把 LESS / SCSS 中的嵌套层级就当做权重去处理问题，所以这就带出了问题的核心：权重如何计算。一方面作为一个基础知识来考察，另一方面也考察候选人是否过度依赖某种工具，类似的经典问题还有“不用 jQuery，纯 JS 如何实现 XXX”、“不用 Bootstrap，纯 CSS 如何实现 XXX ”。到这儿都还是基础题。

id > class，内联 > 外联，!important 最大，大部分人都能答到这里，以我个人标准也可以认为 60 分了，给过吧；但其实这里可以回答得更好（接下来开始的就比较有区分度了）。元素标签呢？伪类呢？伪元素呢？属性选择器呢？后代/儿子/兄弟选择器呢？这就可以衍生出一系列问题：CSS 有哪些选择器？伪类和伪元素的区别？权重的计算规则是什么？

为什么我们要在意权重？在为应用编写样式时，我们难免会遇到新编写的样式不生效的情况，打开检查工具一看，发现是被已有样式覆盖了，这时候就需要对权重有足够的了解，才能搞清楚每一组选择器的影响范围是多大，该怎么去调整才最合理，总不能每次都简单粗暴直接加 !important 吧。

继续展开，权重的问题解决了，但计算毕竟繁琐，有没有什么最佳实践可以减少不必要的权重计算呢？这就可以考察 CSS 的设计能力、对主流规范的认知情况、对新技术的了解程度，比如尽量用 class 进行标识而不要直接用元素标签、给 class 添加前缀以避免和第三方样式库冲突，比如采用OOCSS、SMACSS、BEM等方案对 class 的命名进行规范，比如通过CSS Modules / Styled-Components等方案避免不必要的样式覆盖等。

> 如果大家对于学习前端有任何问题，学习方法，学习路线，如何学习有效率的问题，可以随时来咨询我，或者缺少系统学习资料的，我做这行年头比较久，自认为还是比较有经验的，可以帮助大家提出建设性建议，603985993这是我的web前端交流3000人裙，有任何问题可以随时来咨询我。

从一个简单话题起头，后面可以带出很多东西，能聊到哪里，就看双方的水平到哪里。

有水平的面试官，除了自身实力过硬，同时也清楚面试不是为了秀优越，而是发现和吸引优秀的人才加入团队。作为 Team Leader，我们真心希望候选人能够比我们更厉害，这样团队才会越来越好，如果 Team Leader 的水平就已经是一个团队的天花板，那这个团队的成长一定是有问题的。如果你应聘高级岗位，但技术实力连鄙视对方 Team Leader 都不够，那么即便最终给你发了 offer，你也应该清楚自己在新团队中的地位。