面试一个5年的前端，却连原型链也搞不清楚，满口都是Vue，React之类的实现，这样的人该用吗？
为什么这是一个危险信号？
1. 基础不牢，地动山摇： 原型链是JavaScript面向对象编程的核心机制。搞清楚原型链，意味着你理解了JS对象是如何继承属性和方法的，理解了 `__proto__`、`prototype`、`constructor` 之间的关系，以及 `instanceof` 的工作原理。这是一个非常底层的概念。一个五年经验的开发者，如果连这个都没搞明白，那么他所谓的“Vue、React实现”，很可能只是停留在API调用、组件封装、生命周期管理这样的“使用者”层面，而不是“理解者”层面。
举个例子： 当项目中出现一些棘手的继承、模块化、或者框架内部的细微行为问题时，如果开发者不理解原型链，他很可能只能靠Google、Stack Overflow，或者生搬硬套解决，而无法从根本上诊断和修复。这在维护复杂项目、进行性能优化、或者引入新技术时，会非常致命。
想象一下： 如果你让他写一个简单的继承关系，或者解释 `this` 在不同场景下的指向，如果他依赖于框架提供的便利（比如Vue的`extends`、React的`class`继承），一旦脱离了这些封装，他可能就束手无策了。
2. “知其然”但“不知其所以然”： 满口Vue、React的实现，这本身是好事，说明他有学习框架的动力，并且有实践经验。但问题在于，如果这种“实现”仅仅是停留在“我知道Vue的`vmodel`是怎么工作的”，或者“React的`useState`函数返回什么”，而不是“Vue的响应式系统是怎么实现的？它依赖了JS的哪些特性？”，或者“React的Diff算法是如何工作的？它为什么比直接操作DOM快？”，那就说明他只是一个框架的应用者，而不是一个深刻理解其原理的开发者。
深度不足： 框架的实现往往建立在JS语言特性的基础上。比如Vue的响应式系统离不开Proxy或者Object.defineProperty，React的Fiber架构离不开事件循环和调度。如果他只懂框架的API，而不知道这些API背后是如何利用JS语言特性来实现的，那么他在面对框架的升级、源码阅读、甚至是自己实现一些简单的框架级功能时，都会感到力不从心。
解决问题的局限性： 当框架遇到bug，或者需要更深层次的定制，亦或是需要与其他技术栈进行集成时，对框架内部原理的理解就至关重要。如果只停留在表层，他能提供的解决方案就会非常有限。
3. 五年经验的“水分”： 一个五年经验的开发者，如果连基础的原型链都未曾深入理解，那么这五年的职业生涯，可能是在“重复造轮子”或者“只做浅层应用”中度过的，而没有在技术深度上有实质性的积累。这意味着他可能缺乏独立思考、深入研究、解决复杂问题的能力，以及对技术演进的敏锐度。
职业发展瓶颈： 这样的开发者，很容易在职业生涯中期遇到瓶颈，难以晋升到更高级的工程师岗位，因为高级岗位往往要求对技术有更深刻的理解和更广泛的视野。
团队的隐患： 如果把他招进来，他可能在代码质量、技术决策、解决疑难杂症等方面，给团队带来不确定性。
那么，该用吗？
我的建议是：谨慎使用，或者不使用。
除非你有非常明确的、非常初级的“组件组装”类项目需求，并且对代码质量和技术深度要求极低，否则这样的人并不适合一个需要具备一定技术深度和解决问题能力的五年经验的前端岗位。
具体分析和判断流程：
1. 追问细节，而非泛泛而谈：
当他说到Vue、React的实现时，不要仅仅听他讲API。要深挖：“你是怎么理解Vue的响应式更新的？它具体利用了JS的什么特性？”“React的Component和PureComponent有什么区别，底层是根据什么来判断是否需要重新渲染的？”
引导他回到JS基础：“你能不能画一个简单对象的原型链？”“`new MyClass()`这个过程，在原型链层面是怎么实现的？”“`this`在箭头函数和普通函数中的指向有什么本质区别？”
2. 观察他的反应：
如果他被问到基础问题后，能迅速反应过来，并能结合自己的实践经验（即使是框架内的实践）来解释，那说明他可能只是在面试时没准备好，或者在描述时抓住了重点（但这种可能性相对较小）。
如果他开始闪烁其词，支支吾吾，或者转移话题，那基本可以确定他对基础概念理解得非常薄弱。
3. 考虑项目需求：
如果项目只是简单的静态页面展示，内容更新不频繁，对性能要求不高，那么他也许能应付。
但如果项目涉及复杂的状态管理、高性能渲染、长列表优化、框架级工具开发、性能瓶颈分析、与其他底层技术的集成等等，那么这样的人是绝对不合适的。
总结来说，一个五年经验的前端，连原型链这种JS最基础的面向对象机制都搞不清楚，却对框架的“表面实现”了如指掌，这说明他学习技术的方式是“拿来主义”，缺乏对事物本质的探究精神，也就难以应对真正复杂的技术挑战。
在招聘时，我们应该寻找的是那些既能熟练运用工具，又能理解工具背后原理的开发者。基础不牢，即便掌握了再多的框架，也很难走得更远，也很难为团队带来核心的竞争力。
所以，我的建议是，这个候选人，如果你希望团队有技术深度，能够独立解决问题，并且能够帮助团队在技术上成长，那么慎用。甚至可以说，在多数情况下，不应该用。一个五年经验的开发者的价值，应该体现在对基础原理的深刻理解、对技术趋势的洞察、以及解决复杂问题的能力上，而不是仅仅停留在对某个框架API的熟练运用。
网友意见
面试不可以一刀切，招人也不是考试，不要用死的标准来考人。
面试的目的是了解应聘者的优点、缺点和与工作岗位的匹配度，以及，更重要的是是否适合与团队成员一起工作。
prototype 还是 JavaScript 语言基础的东西，面试者不会，说明他对 JavaScript 并不熟悉。
但是对 JavaScript 不熟悉不代表就不能在其他方面优秀，所以单凭一点，不会立即把一个人给否定掉。
不过不管用不用，最好他还是能把这块补起来，前端还是应该熟悉 JavaScript。
- 面试爱用某个技术问题来挑人的家伙，一定会被某个刷题的培训生攻破的。
大家相爱相生。
2. 如果招个砌墙的小工，就不要强求人家读建筑学原理。
如果招个高阶的阶位，问这个问题 好象有点掉价？
面试应该搞清楚「为什么」而不是停留在「是什么」。不懂 prototype chain 属于「是什么」，你应该去深挖「为什么」，答案有可能是因为别人已经改用 ES6 class。在知道「为什么」以后你才能结合职位需求分析这个人是否适合。（我已经很久没碰过 prototype，因为在 Facebook 我们觉得 decorator pattern 比继承要好，所以大家看到 React 组件都是一层一层封装上去的但很少做继承。）
此外面试不应该问概念题或太过偏离实际应用的题目，只有实际应用会遇到的题目才能真实反映面试者解决问题的能力。这方面我超喜欢 Facebook 的前端面试题，无论是考 coding 还是 system design 的题目都是基于实际应用场景的。（可惜我不能举例，否则就漏题了。）
As multiple comments suggest that they feel uncomfortable reading Chinese mixed with English, here is the pure English answer for you (believe or not, I actually feel uncomfortable writing in mixed languages either). Enjoy.
A common problem in tech interviews among Chinese company: technical details are overly emphasized, and problem solving skills are highly overlooked.
As a multi-year interviewer worked in Amazon/Microsoft, my experience is, do not ask too many questions covering those tech details when interviewing candidates with 5+ years experience - more specifically, don't ask anything that can easily be googled or found in common docs/wikis. Makes no sense.
Instead, simply provide a real-world problem - can be coding, system design or behavioral question, or whatever that is a "real problem", and focus on how the candidate solves the problem. Try to get an idea of his/her thought process, diving deep/thinking big, and the ability to handle challenges under pressure.
Here's a problem example -
"Design a health QR code system for the entire province. Your design needs to cover both Frontend and Backend. Request type, avg/peak load and other required information are provided. How would you choose proper tech stacks? Draw architecture diagrams and explain your design choices."
And here are some follow-up questions:
"What if the peak traffic increases significantly (i.e. 1000 times)?"
"What is the bottleneck of your design from both availability and performance perspective? How would you solve it?"
"If you need to maintain same performance with 30% budget cut, how would you modify the system?"
"Are there any other improvements can you think of, if there's no budget limit?"
The candidate needs to complete everything within 1 hour, whiteboard drawing, without diving too deep into tech details.
PS: I was asked similar type of questions when I first interviewed with Azure. After being hired, I realized that the question is actually the prototype of my manager's pet project. So I took it over and built it myself.
I personally believe that this type of questions is more capable of evaluating the candidate's potential in multiple aspects within 1 hour, and way better than asking those questions that is too trivial and can easily be googled - candidates that are nominated by their problem solving skills are able to grab them later in their career without a hitch.
原答案：
国内搞技术面试的普遍的一个问题：过度重视technical details，而严重轻视problem solving skills
在Amazon和Microsoft做了n年面试官的经验告诉我，面试那些有5年以上工作经验的人，不要问太具体的技术细节，尤其是那种查查文档或者随便一google就可以知道的，没有意义
扔给他一个问题，看他现场怎么解决就行了，可以是coding，可以是system design，甚至还可以是behavior，重点在于，从他解决一个问题的思路和过程，看他的思考广度和深度，以及做事的风格
举个国内人比较容易理解的例子，要求设计一个面向全省的健康码系统，前后端都需要包含，大致需求（request类型和频率，avg和peak load等等）都给出，问：你会如何选择tech stack，说明原因，然后画出architecture diagram并解释每个workflow的流程。
然后扩展问题可以是：（1）如果突然peak traffic增加1000倍你有什么应对措施；（2）你的设计里面bottleneck是哪里，从availability和performance两方面分析，以及有没有什么办法解决？（3）如果现在告诉你预算不够，需要砍掉30%预算保持基本相同的performance，你会选择改变哪些部分？为什么？（4）如果不考虑预算限制，这个系统你还有什么改进的地方？
上述所有内容需要在一个小时内完成，whiteboard drawing，不需要过度深入tech details
顺便，我当时面Azure，就被问到过类似这样的题目，进组了我才发现那个问题的原型是老板想做但没resource的一个project，后来我就把这个project接过来当自己的pet project慢慢做了
这种问题能够非常综合地考察candidate能力，一个小时可以问出非常多的干货，远远好于问一大堆无聊的，google查一下就能知道的技术细节，从这种题目中筛选出来的人，以后再学习这些东西对他们来说简直易如反掌
有些人说，这样的面试是想盗用求职者的点子。
有以上想法的人，你的话充分体现了你的见识水平——首先，你大概从来没有在一个制度很正规的企业工作过，其次，你严重低估了这些世界级大厂的staff/principal engineer的水平
我们每次面试前，每个人要分配面试的内容，考察的方面，等等，如果面试的职位很重要，还要开Pre-brief，老板，Recruiter和Bar-Raiser会再三确认每个人准备的面试题和考察的方向是否吻合，以及复杂度和难度适不适合这个职位，以及你准备的答案是什么，是不是合理等等。但凡有自己想不出来准备盗用求职者的点子的，在这一步就会被卡掉（因为Bar Raiser一看你准备的答案就觉得你在胡来），搞不好还会被从这场的面试官拿掉，最差甚至可能取消当面试官的资格，直接回炉重新培训
每次面试后的debrief之前，要写一个完整的面试报告，报告是有一个固定模板的，每个考察的方面是否达到要求，为什么达到，都需要列举完整的证据，包括代码片段，设计样例等等。这个东西是不可能编的，因为如果你编得太离谱，debrief的时候跟其他几个面试官一对，发现求职者其他几轮表现和你这轮差太远，你这一次面试的结果就直接作废了
然后关于system design类的题目，通常是两大类，一类是比较典型的模型，这种用来考察求职者是否有基本的经验，以及考虑问题是否全面，准备是否到位；另一类是组里现成的项目，或者已经过了design review正在等人手开始做的，这种一般用来面试senior及以上级别的职位，需要一定的创造力。但是，毕竟一场面试只有1个小时，1个小时内能想到的东西，离那种由principal engineer牵头，下面几个senior搞了几个星期，返工n轮，最后才终于拿出来的design，差得不是一星半点。如果有人一个小时能拿出来的东西能够超过一群十多年经验的人搞了n个星期才搞出来的东西，那他应该去面试一个国际级大公司的首席架构，而不是来面一个普通的senior engineer
我是来抬杠的，作为一个超过5年的全栈，至少自己是这么认为的，我还真不懂你问的这些，啥闭包，啥vue实现原理一窍不通。但要说写代码，确实看了那些开源项目只能说一句靠看不懂，大神呀。问题是要说平时你用的到的业务，我也敢说至少70%能做到的我也能做到，还能做的更好。
从一个中小企业来说，也招过不少人，招来的专业前端的，或者是说朋友呆过的一些规模大一点的公司，其实很多人的技术也就那样。包括一些带过的人，人家一样能进阿里、饿了么这样的大公司（说这个的意思是一些你认为能进大厂就是很牛的人，其实真的未必有啥差距，大多数的时候跟人的选择有关系，只要你别太差，只要你就是一心要进大厂，总会有机会的，大厂也需要人做基础的活）。
不会这些知识就等于干不了活么，你要问问自己招别人来干嘛的？你要是想招一个架构回来，能像饿了么那样给开发一套组件库那你就尽情的往深了问，如果你只是要招个人回来用饿了么写业务，你不如多问问他对业务的理解，对组件封装的理解，常用到的优化技巧，一些常用的第三方组件熟不熟悉等等。只要能用、会用，未必就比你招的那些懂原理弱，学了这么多年东西，还没有真正深入了解过原理，这是弱点，但也造成了另一种极端——实用。有些人学东西喜欢拿着书慢慢啃，有些人喜欢别跟我扯这些理论，我没空，上手干它就是了。
现在企业招人，一方面感觉招不到合适的，一方面真有合适的人家也未必看的上你的工资。咱还是实用一些，有多少钱干多少事。你都是招人的Leader了，全局方向难道还要别人来帮你搞定，那公司要你来干嘛，真是公司钱多烧的么，招一个用着顺手的就行，啥原理不原理的最好别懂，因为都懂了绝对也看不上你这公司了，我都懂这些原理了我去阿里做架构不爽么。
照猫画虎，你定好项目框架，下属能在你的规范下接着实现其它的逻辑，他们实现的合不合理，你该怎么优化这些远比这个人懂不懂啥原理强的多，如果能招到一个经常能给你提点优化建议并且有能力把这个优化实现的人，那绝对捡到宝了。
说这个的意思不是说让个人以后就不要了解原理，而是说作为招人这个事你真没有必要拿原理出来说事。脱离场景讲原理就是不讲道理，你不如问个现实的某种情况下让应聘的来处理看看他是怎么应用这个场景的。
今天专门了解了一下闭包，其实这个概念在今天之前让我讲原理我也很懵逼，但之前一直也有在用，比如设计一些插件的时候，从java转过来的特别能理解这个现象，面向对象编程，默认就会考虑属于对象的属性的安全问题，防止被其它地方修改需要对外提供操作属性的方法。这就是说一直有用，但真不一定能入的了某些面试官的法眼。如果你让我给你设计一个功能插件我会，但你要让我给你讲闭包的原理我可能都不清楚原来这个东西就是闭包。
类似的话题
-
这绝对是一个让人头疼的面试场景。一个五年经验的前端，连最基础的原型链都说不清楚，上来就滔滔不绝地讲Vue、React的实现细节，这俩问题，放在一起看，着实有点让人怀疑他的技术深度和解决问题的根本能力。为什么这是一个危险信号？1. 基础不牢，地动山摇： 原型链是JavaScript面向对象编程的核心............. -
好，这确实是面试中经常会遇到的一个问题，考察你面对变化时的分析思路和落地能力。面对“最近一周拼多多成交订单量较上周有5%下降”这个情况，我的分析思路会从以下几个层面展开，力求找到问题的根源并提出解决方案：第一步：确认问题的真实性和影响范围在开始深挖之前，我会先做几件事来确认这个下降是真实的，并且了解.............
-
.......
-
这个问题，真是戳到了无数年轻人的心坎儿里。特别是当你在房价普遍在45万，甚至56万一平米的城市生活时，仰望星空，思考“未来我真的能拥有自己的房子吗？”这个疑问，几乎是每天都在脑海中盘旋。咱们得一点点掰扯开来聊。首先，这个“买得起”是什么概念？很多人对“买得起”的定义，已经从“全款”这个遥远的童话，变.............
-
辽宁省建昌县发生的一起小学生交通事故，造成了5名学生不幸遇难，18人受伤的惨剧，这无疑是令人痛心疾首的。如此严重的后果，肇事司机将面临极其严峻的法律追究。从法律角度分析，肇事司机极有可能触犯了交通肇事罪。根据我国《刑法》第一百三十三条的规定，违反交通运输管理法规，因而发生重大事故，致人重伤、死亡或者.............
-
.......
-
有些朋友在找实验室的时候，可能会遇到这样的说法：“我们实验室不区分导师”。这听起来可能有点神秘，但其实它的意思并不复杂，而且对你选择实验室来说，是个挺重要的一点。简单来说，“不区分导师”就是指这个实验室采取的是一种相对扁平化、资源共享、合作更紧密的管理和研究模式，而不是传统意义上每个学生都紧密跟随一.............
-
面试中辨识一个人的责任心，这确实是个技术活，需要你细心观察和深入挖掘。我不太喜欢用生硬的“技巧”或“问题”来拆解，更倾向于理解这个人是否真的把事情放在心上，愿意为之负责。这就好比你找一个靠谱的朋友帮忙，你不会只看他承诺得有多好听，而是看他过去是怎么做的，遇到困难时他会有什么反应。下面我试着从几个角度.............
-
作为一名面试官，要判断一个面试者在深度学习领域的深浅，我会采取一套相对全面且注重实践的方法。我不会仅仅依赖简历上那些听起来光鲜的词汇，而是要深入挖掘他们对概念的理解、解决问题的能力以及实际操作经验。一、 背景了解与基础知识摸底：首先，我会从他们的项目经历入手。这不仅仅是看他们列出了多少个项目，更重要.............
-
我明白你现在的心情，在经历了几轮面试，尤其是到了三面这个关键节点，等待结果的心情肯定是非常煎熬的。关于一个星期没有收到百度offer是否需要主动询问，我的建议是：可以，而且在某些情况下，主动询问是明智的。我们来详细地拆解一下这个问题，以及怎么做才能让你主动询问时更有效，同时尽量避免给对方留下不好的印.............
-
当然，日本的大学指定推荐校虽然有学校的“保送”性质，但并非意味着百分之百录取。即使只有一位同学参加面试，被刷下来的可能性也真实存在。我来详细说一说这是为什么，以及具体会体现在哪些方面。首先，我们要明白指定推荐校（指定校推薦）的本质。学校之所以能获得某个大学的推荐名额，通常是因为两校之间有着长期的、良.............
-
各位即将踏入职场的小伙伴们，你们好！作为一名HR，我见过太多怀揣梦想的年轻面孔，也亲手为企业输送了不少新鲜血液。看到你们即将开启人生的新篇章，我真的非常开心，也想借这个机会，给大家一些掏心窝子的话，希望能帮你们在面试这个环节，走得更稳、更顺。首先，面试前，请做好功课，而且要“用力”去做。 了解公.............
-
行，兄弟，作为和你一样，从大专院校出来的职场小白，我懂你这种心情。面试就像过关斩将，咱们手里拿着的是一把菜刀，别人可能用的是激光剑，但关键不在于武器有多牛，而在于你怎么挥舞手中的菜刀，让它看起来不那么“菜”。别想那些虚头巴脑的，说实话，招聘方也不是神仙，他们看简历，看的就是一个“可能性”和“匹配度”.............
-
“我可以学”，这四个字，在面试官，尤其是HR的耳朵里，有时候就像一颗定时炸弹，听起来既积极又飘渺。你说它积极吧，因为它表达了学习的意愿，但说它飘渺，则是因为它太笼统了，无法具体量化，也无法立刻打消HR心中的疑虑。咱们深入聊聊，为什么HR不太喜欢听这句话，以及培养一个员工的技能，到底是怎么个“贵”法。.............
-
最近，一篇关于北京大学考试研究院院长关于“面试学霸”的论述引起了不少关注。这位院长以一种颇具争议性的比喻，将一些在面试中表现出色的学生形容为“像一个模具打造出的‘家具’”。这个说法之所以能引起广泛讨论，不仅仅是因为它出自一位教育界权威人士之口，更在于它触及了当下教育评价和人才选拔中一个普遍存在、却又.............
-
.......
-
这真是一个两难的境地，让你夹在最爱的人中间，内心肯定煎熬不已。先深吸一口气，我们一点点地来捋一捋。母亲的重病卧床，代表着生命的脆弱和亲情的召唤。 你的母亲是给了你生命、养育你长大的人。现在她病重，最需要你的陪伴和支持，这是一种本能的责任和情感上的牵挂。在她最虚弱的时候，子女的在身边，即便只是握着她的.............
-
这个问题确实挺刁钻的，考察的是对市场、产品和商业模式的理解，尤其是结合中国本土的实际情况。首先，咱们得明确一点，“低价买房子”这个需求，中国人绝对有，而且是普遍需求，这毋庸置疑。 就像“吃饱穿暖”一样基本。但问题出在，这真的是一个“产品经理能独立解决”的范畴吗？咱们拆解一下，一个产品经理做产品的逻辑.............
-
你面对的是一个相当棘手的问题，长期不工作的老公，这不仅仅是经济上的压力，更关乎到你们的感情、家庭未来，甚至你个人的心理状态。我知道这一定让你倍感疲惫和无助。我不会用那些生硬的AI词汇来包装，我们就当作是两个朋友在坦诚地聊聊，说说你该怎么一步一步地去面对和处理这件事。首先，我想和你一起梳理一下，这件事.............
-
要“辩过”一个逻辑清晰、思维缜密、语言功底扎实且见多识广的人，与其说是战胜，不如说是更准确的说法是与其进行一场高水平的、互相启发的思想交锋，并且最终能够让你的观点被他理解、认同，或者至少能够让他认识到你的观点同样具有相当的价值，并且在某些方面他可能考虑得不够周全。这本身就是一种胜利。要达到这个目标，.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有