如何快速判断一个前端工程师的能力？

德雷福斯模型将人的技能水平分为五个等级:新手、高级新手、胜任、精通、专家。

不同技能等级的鉴定是这样的:

新手:看指令单，一定要一步一步来。要给出详细具体的操作细则才能奏效。比如你做一道以前没做过的菜，你需要看菜单的说明，第一步怎么做，第二步怎么做等等。，直到烹饪结束。

资深新手:情景洞察力有限，平等对待工作的方方面面。我对整体的、系统的东西不感兴趣。这就是苦力的水平。比如他可以跟师傅做一些工作，帮助别人。可以通过反复搜索搜索引擎和StackOverflow来解决具体的小问题。

胜任:能够独立解决领域内的各种问题。这是一般的企业招聘，更希望招聘到级别。招聘的话，稍微适应一下就能胜任工作，省心省力。

精通:经验丰富，自我修正，自我提高。这个层次的人可以向内思考，通过反思和反馈提高自己的技能。这种企业可以算是高手和大师，培养起来不容易。

专家:凭直觉工作，不需要解释或理由。其实你让他解释，他不一定能告诉你为什么，但直觉给出了答案，他还是对的。专家数量稀少，需要长时间的培训和实践。通常的说法是10年专家出来，10000小时定律。

这是理论上的学习，在实践中缺乏可操作性，很难快速判断考生的实际情况。我不信你打开很多简历，刚毕业的学生，每个技能名词上都盖着一堆“熟练”——你信吗？但可以作为判断职业技能水平的参考标准。

于是，各个企业开始了各种“笔试”“机考”，多轮面试，对学历、院校出身都有严格要求，企图过滤掉不理想的候选人，留下合格的候选人。当然可行，但是效果一般，容易出错，错过有想法有水平的人。否则也不会催生各种“推荐”招聘。

关注学历和学校当然有它的好处:是一种快速过滤的手段。毕竟能考上好学校的人智商都不会太差。不过有个在大数码公司的朋友说，有初中毕业一直在研究安全领域的人，技术能力也很优秀。如果后台处理的比较苛刻，这些人会怀念的。因为人的生活是多样的，有各种各样的历史背景因素影响着他们的经历。有些人的经历和有些人不一样，但并不妨碍他们变得优秀。招聘，其实就是建立信任关系。如果有足够的资料证明申请人足够优秀，那就足够了。规章制度只是辅助，不是目的。

推荐招聘其实靠谱多了，因为很容易让人知道熟悉的人的水平。这是由推荐人的信用背书的。大家平时在交流中说了什么，每天看了什么书，关注了什么领域，思考过什么问题，熟悉了什么东西，这个经常聊天的熟人往往都知道。但这种招聘有很大的局限性:范围窄，靠机会。推荐能招到几个好选手？好球员往往是各家争抢的对象，窗口期有限，基本不缺活。

说了这么多，我们还是需要一个更高效的方法来判断技能水平，招到合适的人。

回到开头的德雷福斯模型，既然人的技能是分等级的，那么在处理不同的工作要求时，我们也应该侧重于不同的视角。如果招聘流程一样，很容易出错。比如你找的是“硕士”，但是一上来就让人家有一堆笔试和机考就不合适了。对方会很烦。体现高级技术能力的不是“字符串算法”。相反，刚毕业的人占便宜，因为只学了很短时间，印象很深。我不信你让工作了10年的人跟计算机专业的应届生比写排序算法，真的不一定能赢。不过没关系——不看手册不查文档不工作吗？聪明人从不死记硬背。重要的地方在于对问题域的准确而深刻的理解，对各种技术优缺点的评估和把握以及各种条件的平衡。

和新手打交道，重点是基本功是否扎实，专业成绩是否过硬。更重要的是他对事业的热情，学习能力和研究精神。有些人想谈谈技术。他们充满热情和热情，对未知的、新的概念和技术非常好奇。这种人很难往坏处想。因为他会自我驱动，不需要督促就能学习进步。相反，认为这个职业待遇好，只想糊口的人，很少能走远。这些初学者大多是毕业生和工作年限较少的人。测试和考核，可以通过笔试来检查对基本概念的理解是否准确以及知识领域的大致范围。甚至，安排一个有点挑战性的任务，让他试着去解决，解释他的想法。

考察有能力的人和精通的人的策略是不同的。笔试的题做了也没用，原因前面说了。这种招聘是重头戏，公司喜欢找，能干活。所以考核的地方很多。我觉得可以分为几个方面。意识是否先进，是否会反思思维；他是否善于解决问题，富有创造性；是否有深厚的积累和广博的知识。

行业的发展思路也在不断变化，工具链也在不断创新。聪明人不需要蛮力，喜欢用工具提高效率，喜欢自动化操作解放人力。要看大家用什么开发工具链，用什么开发环境，解释一下为什么？好的开发者会及时关注新兴的工具，了解它能解决什么问题，并尝试吸收解决自己的需求。没有这种思想，工作效率就会降低。因为你会落后于行业发展水平。善于自我反省的人会督促自我改正，这是精通者的特点。参考:优秀的开发者为什么要学习新的编程语言？

解决问题的能力是重头戏，也是企业招聘人员的主要原因。人要善于解决实际问题，学会聪明地解决问题。解决问题靠的是思维、手段和创造力，这才是真正考验人的能力。一个好的开发者会考虑很多可能的选项，预估各种利弊，给出更好的解决方案。遇到困难时，他们会用各种方法去尝试。有经验的人经常使用多种技术的组合来解决困难的问题，而不是到处使用一种语言和一种工具。所以要查过去项目经验中遇到的问题和困难，怎么解决，怎么思考。据说有些公司不招不会用谷歌的工程师。谷歌打不开？嘿嘿，这就是你要克服的困难。如果这个都解决不了，你还搞什么研发？谷歌是人类最全面、最新知识的总索引，充分利用事半功倍。

考察知识的深度和广度，是否对重要领域的概念有深刻的理解和掌握，以及从各种工作经历中获得的认知。问他读过什么书，学过什么。说白了，你懂的多吗？有的公司喜欢用清单模式来考核，列出一堆领域的知识点和概念，问人家懂不懂，懂就是好，不懂就是差。事实并非如此。人的工作过程是独立的。如果没有工作机会去接触和解决一些事情，那么一些难得的问题就永远不会遇到。我当然不知道。但你能说没做过就一定没做好吗？

另外，人的技能树其实是“参差不齐”的。你什么意思？技术领域非常广阔，你真的不可能精通每一个领域。其实你在这个领域做的多，知道的多，在那个领域用的少，知道的少。这个时候要看具体的知识领域，是什么样的。是否需要复杂难懂的背景。门槛高的技术需要的配套技能要多得多，比如AI、机器学习等。但是，一般的产品应用领域却不是。了解核心概念和设计意图，并查看手册和最佳实践，就可以开始了。暂时不会出现这种情况。这其实并不重要。好好学习一段时间就好了。但是在门槛高的领域，需要很长时间的学习。这是本质区别。

我看过一个公司发布的员工技能树，包罗万象，IT领域的知识技能几乎都在里面，还号称要求“全部精通”。不知道它是怎么定义“精通”的。按照德雷福斯模型的定义，能做到的是上帝，不是人类。这纯粹是吹牛。我根本不相信。如果有这样的人，出来让我拜。因为每一个稍微大一点的领域都足够你研究一辈子了，因为他们也在飞速发展。业内有一种说法叫“全栈工程师”，主张全栈的人往往是前端工程师。研究后端工作领域的技术专家，往往会鄙视这样的人:你真的以为点Node.js就能解决一堆后端事务吗？我也知道一些前端，也可以叫“全栈”，但是我很清楚不同领域的专业程度是什么样的。前端也有很多复杂的地方需要解决。全栈其实是反专业化的，在人力资源稀缺的情况下，这是一种低成本的选择。

更高的层次是考察人本身。一个人的视野够开阔吗？你了解其他领域吗？有些问题的答案不在问题域本身，而在域外。所谓“功夫在诗外”。公司强调团队合作，总是面临分工合作的不同问题。比如产品和运营方提出需求，能不能设身处地为他人着想？合作意识强？没人想招他们的眼中钉，对吧？把团队的氛围和人际关系搞得一团糟，大家都不开心，不开心。怎样才能安心做好工作？最后只会降低团队的效率，甚至崩溃。