面试一个5年的前端，却连原型链也搞不清楚，满口都是Vue，React之类的实现，这样的人该用吗？ 第1页

面试应该搞清楚「为什么」而不是停留在「是什么」。不懂 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