面試一個5年的前端，卻連原型鏈也搞不清楚，滿口都是Vue，React之類的實現，這樣的人該用嗎？

最後還是拒絕。還有其他的原因。一個問題，輸入m.n參數，獲取一個m長度的都是n的數組，不能用循環，他不會寫。問他他們公司項目的webpack配置entry有幾個，他一會說1個，一會說很多個，不知道他到底懂不懂。

---

面試應該搞清楚「為什麼」而不是停留在「是什麼」。不懂 prototype chain 屬於「是什麼」，你應該去深挖「為什麼」，答案有可能是因為別人已經改用 ES6 class。在知道「為什麼」以後你才能結合職位需求分析這個人是否適合。（我已經很久沒碰過 prototype，因為在 Facebook 我們覺得 decorator pattern 比繼承要好，所以大家看到 React 組件都是一層一層封裝上去的但很少做繼承。）

此外面試不應該問概念題或太過偏離實際應用的題目，只有實際應用會遇到的題目才能真實反映面試者解決問題的能力。這方面我超喜歡 Facebook 的前端面試題，無論是考 coding 還是 system design 的題目都是基於實際應用場景的。（可惜我不能舉例，否則就漏題了。）

---

五年不知道原型鏈，可以判斷這個候選人是一個典型框架熟練工，如果我要是找幹活的，react，vue，angular有一個確實用的熟，ok，進來幹活。老闆給的預算就那麼多，只要價格合理，作為找個幹活的沒有任何問題。但是如果是找大牛，或者希望找個長期培養的，那不知道原型鏈確實是不合格。

面試這個東西，尤其是前端面試很多時候就是一個互相覺得對方是傻逼的相親。我面人的時候，曾經遇到過一個不用框架能填坑填到IE6的，他直接問我你們用那麼多css3動畫，怎麼兼容低版本的IE，我說我們不考慮IE9以下瀏覽器。這哥們就開始一臉不屑了。我被面的時候，有次人家問：你用過redux嗎？知道啥叫FLUX嗎？我說我沒用過，實際工作都是MVC，那些都是簡單了解，或是自己寫寫demo，之後各種被鄙視。還有遇到過因為沒有用過gulp被鄙視的。也有D3大神出門被人當美工的。前端世界的面試很多時候之所以是關公戰秦瓊，是很多面試官把面試的本質搞錯了。面試是要了解候選人哪些地方強，哪些地方弱，哪些地方不知道，他強的地方是否匹配我公司業務，弱的地方是否有潛力通過努力彌補。而不是小爺我今天總有一題懟到你。

---

這讓我想起了幾年前面試我現在的組。我的老闆說他手下的人大多都做XAML，問我會不會？我說GUI該知道的我都知道，唯獨XAML的語法基本沒學習過。

XAML在UWP裡面的作用就跟JavaScript在前端的地位一樣重要。然而我不知道XAML的細節有沒有問題？工作會不會做不出來？

沒有問題，都能做出來

（逃

---

這又涉及到我之前講過的面試官技巧，面試，是對一個人的能力系統性評價，搞清楚一個人擅長什麼不會什麼，所以問知識性問題，為了避免誤判，一定要大量問、系統化地問。

不會原型很能說明問題，至少他在庫的設計方面會有極大劣勢，而且可能學習習慣上是有問題的，也有可能他根本就不太會JS語言，但是這不意味著憑藉一個問題就可以判定這個人不能用。

---

面試的時候我通常我幫助面試者，在腦袋裡畫一個他的技能樹。

很多時候我還會努力幫他們證明，他們可以勝任這個職位。

還會根據他工作時間長短，和對應的技能樹大小和顏色來判斷他的學習能力怎麼樣。

不斷提醒自己，不要因為他和自己的領域知識有偏差而對候選人有偏見。

所以，你既然對你自己想要的人有了明確要求，如果不想浪費時間，最好的做法就是在jd里描述更準確，同樣，候選人也儘可能的把自己的簡歷，描述更多的技能樹。

如果不匹配，簡歷篩選就能做出來了。

---

發現評論一直出錯，直接接著 @73.F 的回答好了

茴香豆的新寫法之一：

function shit5(m, n) {
return [...Array(m).keys()].map(e =&> n)
}


新寫法之二：

function shit6(m, n) {
return (f =&> f(f))(g =&> (m, n) =&> m === 1 ? [n] : g(g)(m - 1, n).concat(n))(m, n)
}


---

瀉藥

那就問問他懂的唄，看他懂的東西到底掌握到什麼程度了再說。

面試是找亮點不是找缺點的，缺點多容易找啊，挑毛病誰都會。

然後亮點缺點綜合考慮再決定要不要。

============== 分割線 ================

剛才看微信群里聊這個問題，補充下吧。

我這麼回答並不是說完全不會考察原型相關的知識點。

它只是眾多考點中的一個，而且絕大多數情況並不會很直白的問原型會不會啊之類的，而是問一些涉及到原型相關的基礎方面的、或者與個人簡歷里項目需求相關的點，這些問題會涉及到原型相關。

通常這些問題是在聊簡歷項目、簡歷里寫的技能點時候帶出來的。

除非十分無奈，才會很直白的問原型鏈是怎麼怎麼樣的問題。這說明相關點的問題候選人沒聽明白，只好直接指出。

這個問題是否答的出來以及答的好，並不是一票否決的點。

還是要綜合個人的項目亮點、技術亮點、基礎優勢劣勢後得出最終結論。

---

hi, 我們團隊已經將對原型鏈的考核移出了面試範圍；但閉包還在考核內容之中。

為什麼要將原型鏈移出考察範圍？

第一、不會再用到了

第二、理解了原型鏈，對我們寫es6程序沒幫助；因為es6設計就是要去掉原型以及原型引申出來的N種設計模式的原型實現（見《高級js程序設計》）， 非常複雜，可讀性差。 應該去理解es6-class。 從語法上講，es6-class和原型已經沒有關聯。

另外也說說我的經歷

5年前我用angular.js，用原型很少。 3年前，用es6就沒再用過原型。翻react.js的源代碼，現在也只有一些舊代碼還在用prototype，新代碼基本都是基於es6了。 我認為前端程序員不一定要掌握原型，如果說一點也不知道， 肯定有問題，那是知識邊界的問題，就好像c++程序員不知道虛函數表，肯定有問題，但如果面試官一直問虛函數表，那也沒什麼意義。

為什麼閉包還在考核範圍中？

因為閉包是我們javascript實現各種各樣的封裝的基礎，函數式編程的基礎，將長期使用。

我認為我理解原型鏈的時間白費了。 （純個人觀點，不代表58團隊）
同理： es6裡面我不會考： let 和var 的區別；因為var不用了，知道區別有什麼意義呢？
學習原型-原型鏈-掌握原型相關的設計模式， 需要很多小時，同樣的時間，足夠學習一類演算法了， 如學習學習有趣的&

下面說說面試：

我前端面試通常注意這麼幾個方面：

1. 溝通能力

2. 基礎知識

3. 解決實際問題的能力

4. 知識邊界

溝通能力面

看面試面試者對所有問題的視角，闡述是否準確容易理解。 這是我們團隊非常重要的一個指標。

基礎知識面

具體基礎知識方面，我會重點考察：

• 閉包
• es6 - class

比如說： 類的靜態成員和動態成員的區別？ 重點考察多態和類型的設計。比如說mixin和decorator等。

• map/reduce/filter/find這些常用的函數
• promise和async/await
• 基礎演算法（比如說什麼鏈表，如何實現一個hash演算法， 歸併排序的複雜度）
• 前端常用設計模式（比如說subscribe,observable等）
• 進程和線程的區別（什麼線程同步）

解決問題面

具體到解決實際問題的能力， 我會涉及：

• 組件介面設計 （比如設計一個表單組件/Picker) —— 基於 react 或 vue。
• 針對面試人員原公司業務邏輯提具體的問題
• 具體的工具（gulp/webpack/rollup) 考察具體的知識點，主要是希望面試者具有：根據自身團隊的實際情況選擇工具的能力
• 給一個實際問題， 問解決方案

知識邊界面

知識邊界主要是為了確定面試人員的知識範圍。

知識邊界我會問：

• 考察一個稍微複雜一點的shell知識點（如awk，xargs等命令)
• 問一個資料庫相關知識中稍微有深度一點的（如：什麼是鎖）
• 問一個緩存先關的問題（如：什麼是緩存穿透）
• React/Vue的virtual dom實現原理
• js新特性掌握深度（如symbol-observable， 什麼是web-asm）
• 前端方向把握（pwa/electron/react-native）
• node.js的學習情況

----------------------------------

鑒於，此文爭議很大， 在這裡我補充幾個自己的幾個觀點。

1. 我認為，如果是58， 58應該不會因為僅僅【不懂原型】給面試者貼上【不堪重任】標籤，對於【滿口都是Vue/React的人】58應該針對vue/react的知識，es6知識深入提問。

判斷一個人是否勝任有很多因素，就【技術】而言， 一個人是否有學習能力，要看他學了多少知識。 有些人把時間花在學習【演算法】和【設計模式】上，沒有學原型的若干設計模式，是很正常的。有些人有思路設計非常龐大的系統，有些人編碼習慣非常好，有些人對新工具非常熟悉，所以我們在考核人才的時候， 通常要提很多問題，一般有20個左右，最終有一個綜合判斷。

單純從技術面，如果真的發現，一個自信的面試者，新東西都不會， 弱弱補一句：【如何用原型實現一個工廠模式？】也是有可能的，因為我們不想因為這個人沒有學習新技術棧就淘汰。 我們的人才考核，最注重的是基礎。 面向對象的基礎知識，函數式編程的基礎知識，演算法、設計模式，前端工程化， 組件化等等，有非常多知識。

2. 從JS的運用上講，我們傾向於去原型化

目前除了正常業務系統外，在我們內部有兩個熱門話題：

a. 使用react-native承擔app開發的工作 （目前58主app的裡面的發現頁，已經是rn實現的）

b. 如何使用node.js開發業務系統 （目前我們有大量的內部系統使用node.js開發）

原型有很多優勢，這個這裡不展開，但如果es6-class在多數情況下可以完成工作，我們傾向於用class。 學習成本低，使用容易，而沒有特別的劣勢。 原型雖然靈活，但在很多方面是非常複雜的，這個複雜度，可以和：

a. C++的模板

b. scala的implicit

相媲美了。

但是c++的模板，我們不得不用，繞不開(STL庫）

scala的implicit可以不用，但如果用了收益很大(讀讀spark的源代碼就知道)

在大多數場景，js的prototype學習成本很高，但收益沒有那麼大。我們在開發node.js。react/vue/react-native的時候，基本都是es6-class。

假如，需要開發類似react.js這樣的輪子。 基本上也可以不考慮原型。除非， 要開發babel類似的東西，而babel已經很穩定了。

3. 我認為那些聲稱【es6-class】是語法糖的人，可能有一些小細節是不知道的，這個【語法糖】的複雜程度，他們可能沒有想清楚，這是其一；其二，對未來的發展我的判斷和他們是不一樣的。

舉兩個例子：

當我們沒有使用new去創造一個class的時候，會報錯，這個用原型實現OOP的時候通常不會考慮到的，原型實現的OOP函數沒有new也是可以調用的； 在沒有調用super之前，是沒有綁定this指針的，調用super之後，才有this指針，這個我們在用原型繼承的時候，可能也是不會去考慮的。

上面只是冰山一角，所以說es6-class這個語法糖，是很複雜的。

我認為未來這個複雜度還會上升，直到專門製作babel等的人才能了解全貌。

比如說，typescript中已經有private關鍵字，es7的提議中也有private關鍵字的身影。其實我認為，private關鍵字對於我們用nodejs寫業務的同學是很有意義的。

基於這個【語法糖】越來越複雜的判斷，我認為複雜到一定程度後，就不能僅僅將他看做一個【語法糖】了。

就好像c++的類編譯成彙編語句一樣， 太複雜了，細節太多，知道一點點原理，但沒有人敢用彙編寫oop。 我認為，linux源代碼用c寫oop的時代，過去了。 雖然可以寫，但也超級複雜。

我認為JS之所以這麼火， 並不是因為這門語言有多麼優秀，而是它是瀏覽器唯一支持的通用標準。

~請不要再人身攻擊，更沒有必要攻擊58，我看到58的前端技術進步很大，特別是在近幾年。

58招聘FE團隊 魏蒙

---

------------------------------------------5/24 17:00 更新----------------------------------------

對於現在的面試，我只有一句話：

面試造火箭，入職扭螺釘

----------------------------------------------------------------------------------------------------

原型鏈不會也就算了吧，畢竟工程上又不是好的實踐。前端么多內容，隨便問問，很容易看出水平。

主流語言除了js 哪個使用了原型繼承？雖然原型繼承很靈活，但是非常容易勿用，實際工程中代碼不容易維護(光是實現繼承就有不下於10種寫法也就算了，居然還可以隨意改變對象父類，這樣的代碼真的好嗎？)。至於其他答案中的es6的class是對prototype屏蔽的觀點我也贊同，但是es6為什麼要屏蔽原型？還不是因為這是js的糟粕之一，炫技用prototype沒毛病，大型項目prototype不是好的選擇

回到這個題上來，react，vue 實現能夠隨口說出，並且都是對的（題主別跟我說無法分辨對錯，那我就只能呵呵了），這樣的人完全可以用。

至於其他答案，說原型鏈這麼簡單的東西都不會，其他東西更不會；我反問一句：dw 這麼簡單的東西，當今稍微有點水準的前端誰會用？

術業有專攻，沒必要對每個人的知識要求一致，你懂原型鏈未必要求別人也要懂

這人如果真的善於 vue react，讓他去寫vue react唄。

公司要做的事是把合適的人安排在合適的崗位

至於5年工作經驗，個人覺得確實有可能謊報，但是這鍋培訓機構不背（至少在我這會重點講解原型鏈，逃）

---

不能招。

因為這人居然甘願做5年的web前端，說明沒有一點進取心。

---

以下是問答時間。

Q：什麼是原型鏈？

A：原型鏈是垃圾。

Q：在實踐中應該如何運用原型鏈？

A：避免。

Q：精通原型鏈的前端好嗎？

A：精通什麼不好，去精通這種垃圾。說明對技術的優劣沒有一點辨別和判斷的能力。

---

擇其善者而用之

他可能不懂原型鏈。但如果你要找寫業務代碼，而他對工具熟悉，遇到過各種坑，也知道解決辦法。那他就很合適了。

但如果你要招做基礎類庫、框架、工具的人，那你就要考慮清楚了。

你糾結的是「5年」。每個人的5年是不一樣的。20幾歲的5年和30幾歲的5年也是不一樣的。

---

ES 2015 之後確實可以不要管 prototype 了。那麼他前三年的經驗幹什麼去了…

---

請問覺得原型鏈不重要的人，你讀過標準嗎？ECMAScript 2015 Language Specification

Although ECMAScript objects are not inherently class-based, it is often convenient to define class-like abstractions based upon a common pattern of constructor functions, prototype objects, and methods. The ECMAScript built-in objects themselves follow such a class-like pattern. Beginning with ECMAScript 2015, the ECMAScript language includes syntactic class definitions that permit programmers to concisely define objects that conform to the same class-like abstraction pattern used by the built-in objects.

---

前端大部分人是搞工程，解決工程問題，用的是 react，vue 這些框架，用的是 babel，webpack 這些工具。如果這方面都很通，那麼他可以做事，工作上沒啥問題。

這大部分人中間也有一些人不甘『用』，想著可以用自己的方式解決業務問題，那麼他們會去研究演算法，研究基礎的框架，庫是怎麼寫的，在上面做封裝，比如 redux 生態，vue 生態。可以有這方面能力，意味著他有一定的創造力，潛力也更大。

我不會單問原型鏈，而問一個工程擴展的問題，他問什麼方法解。

---

面試不可以一刀切，招人也不是考試，不要用死的標準來考人。

面試的目的是了解應聘者的優點、缺點和與工作崗位的匹配度，以及，更重要的是是否適合與團隊成員一起工作。

prototype 還是 JavaScript 語言基礎的東西，面試者不會，說明他對 JavaScript 並不熟悉。

但是對 JavaScript 不熟悉不代表就不能在其他方面優秀，所以單憑一點，不會立即把一個人給否定掉。

不過不管用不用，最好他還是能把這塊補起來，前端還是應該熟悉 JavaScript。

---

工作5年連基礎知識都搞不明白，說明要麼是沒興趣，要麼是沒進取心，無論哪一條，都說明這個人不值得長期培養。

當然基礎知識不是只有一個點，如果能答上大部分，說明基礎還是可以的，不能根據一兩個點而否定一個人。

以上

---

好不容易看完了所有的回答，才發現我現在為什麼不敢出去面試了，因為自己只會寫Hello World！看來即將得失業。

---

既然他滿口都是React Vue，那你就問問他React Vue唄。

比如Vue，問問數據綁定怎麼做的，如何解決getter/setter不能監聽數組變異方法，監聽的回調和事件怎麼解耦的，watcher去重怎麼做的，DOM批更新怎麼做的；React就隨便問問setState背後的原理，知道Fiber嗎，怎麼用transaction做批更新的，DOM diff原理。

再問問React和Vue有什麼相同點和不同點。

如果我是面試官，他不懂原型，卻能把這些都答的差不多，我一定會讓他通過的啦！

---

工作五年，搞不清原型鏈，這說明在他的工作生涯中幾乎沒有用過原型鏈，所以你可以設計一個場景，看看他能不能給出解決方案。

如果他可以繞開原型鏈解決問題，當然也能算是過關的答案。你可以對比他的方案和使用原型鏈之間的差別，問問他有沒有覺得自己方案中哪裡可以改進，比如使用繼承可以節約很多代碼。

說一點題外話，面試官常常會陷入到自己的技術棧中，擅長的問題使勁問，不擅長的問題一筆帶過。我遇到的好多面試官問我是否了解正則表達式，我說挺了解的，然後幾乎就沒有下文了，最多是讓寫個郵箱的匹配。因為正則這個東西很多前端日常用的就特別淺，面試官不特別準備的話，可能會當場被面試者掛起來。

所以面試最怕的就是，面試者了解 react，面試官精通原型鏈，倆人怎麼都聊不到一起去，然後互相覺得對方SB ...

當然，題目補充裡面提到了一些很基本的代碼邏輯也沒有實現，的確是蠻糟糕的。不過說真的，如果基礎不好的話，吹自己精通 react 心裡不虛？

---

概念的問題，點到即止就行，正確的姿勢：讓他寫代碼，讓他寫代碼，讓他寫代碼！

是騾子是馬拿出來遛遛，沒有比能不能寫代碼更能考察一個人水平的了，少談些主義，多寫寫代碼。

補充，有很多面試官一看對方有點工作經驗就不好意思讓對方寫代碼了，這是大錯特錯！當兵打仗，會開槍不是基本功嗎？同樣的，干這行最終產出的就是代碼，有什麼不好意思問的？

每一個合格的老兵，每一個合格的指揮官，都要會開（bian）槍（cheng）。

---

推薦閱讀：