前言
最近作為面試官，參與了多場專場面試，短期內大量的面試，面對不同風格，性格迥異的面試者，讓我對面試這件事本身產生了一些思考，結合自己的一些理解和技術領域特有的定級制度，我們不妨來聊聊技術面試這回事。
何為技術面試
我所理解的面試，是一場圍繞著兩個角色 - 面試官 & 面試者 之間的一場“對接之旅”， 如何在短短的30分鐘內， 讓彼此更多的瞭解對方， 就像兩個不同的形狀的卡口，不斷的調整彼此認知，進行思維對接，最終完成面試。由此我們大致可以將面試劃分出幾種失敗的場景。
1. 互懟型
面試官完全不看面試者的簡歷，僅從自己的技術領域出發，對面試者進行考察，面試者往往會有一種被 diss 了的感覺，脾氣不好的可能會進行反向 diss，然後一場面試就變成了帶點火藥味的攻防戰。
2. 尬聊型
面試者對自身的認知有限，簡歷上幾乎體現不出有價值的內容，缺乏經驗的面試官不知從何問起，或者面試者的簡歷雖然詳實，但所有的問題都點到為止，場面一度陷入尷尬，就像一場尬聊，這種情況下，經驗豐富的面試官可能會通過一系列問題來確定面試者的能力邊界，從而構建出面試者的能力模型，如何做到這一點，我們後面聊 ：）
3. 一邊倒
面試官或者面試者佔據絕對的主動，但是彼此溝通並沒有形成體系，往往在某個細節上進行過於深入的溝通，一方佔據優勢導致另一方疲於應付，最終形成一邊倒的局面，結果無非是
- 面試者：“這煞筆真水”
- 面試官：“這哪來的2B”
從上述的一些場景中，我們不難發現，面試失敗的原因可以歸納為2類：
- 面試者缺乏自我認知，沒有把自身的優勢體現出來，簡歷中沒有很好的勾勒自己的能力模型，給面試對接過程帶來了很高的啟動成本
- 面試官缺乏問問題的技巧和經驗，不能夠通過問題確定面試者的能力邊界，從而勾勒出面試者的能力模型，導致最終產生不全面，甚至錯誤的判斷
何為能力邊界 & 能力模型
俗話說人力有窮盡，每個的能力在任何方向上都會有盡頭，這個盡頭便是你能力的邊界，我們經常在遊戲中看到一種五邊形，每個頂點都代表一種能力，角色在這個五邊形中不同能力的數值最終構成了一個角色的能力模型，譬如敏捷型 / 力量型 / 智慧型 等等，而作為技術工程師，確定自己或者確定一個人的能力模型是及其困難的事，尤其是在短短的幾十分鐘內，通過一場面試，那更是難上加難，故而如果面試者能對自己的能力模型有很好的認知，面試官有豐富的經驗技巧和對應的知識儲備來驗證這個能力模型，那面試的過程就會非常高效。
面試者如何勾勒自己的能力模型 & 面試官如何確定面試者的能力邊界
回到面試者本身，因為不同的技術背景的公司對於同一層級的能力模型的定義可能存在偏差，譬如同樣是高階前端工程師，對於專業能力的理解，可能會因為技術棧的不同而產生變化，一個使用 React 技術棧的公司對於能力相同，但是使用 Vue 開發的工程師給出的評價可能會低於使用 React 的工程師，而這種技術變數的存在給面試本身帶來了很多的不確定性。尤其是對於面試官如果相應的知識儲備不夠，那評價可能就會更加失真了，所以作為面試者，我們應該從自身的角度出發，儘可能在簡歷中給出一個可評估的能力模型，讓面試官能夠更好的瞭解，愉快的完成對接，這裡我羅列了一些邊界的點，儘可能從相對通用的角度來定義工程師的能力模型。
基礎能力
體現技術的基礎技能的掌握情況，以前端舉例，可能包括通用計算機基礎，例如基本的資料結構和演算法，像堆疊，佇列，陣列，樹，連結串列等定義，和常規的操作等；前端技術基礎，對 JavaScript的理解，對 http 協議的理解，css / html 掌握和理解以及其底層的協議和規範的理解和掌握；業務能力基礎，包括對實際用於業務開發的技術掌握的情況，譬如對 React 的理解，對 Vue 的理解，如果是公共技術團隊則可能涉及 Webpack 打包構建方面的理解，也可能是對 nodejs 的理解；仔細觀察，不難發現，基礎能力邊界是一個層層推進的過程，面試者可能具有豐富的業務經驗，但是如果你要理解 React 的底層實現，就一定會去學習樹的資料結構和演算法，看到JSX，就會想到 babel 是如何解析的，這裡涉及到編譯原理的前端部分，而這些又繞不開對 JavaScript的理解，從而形成一條清晰的基礎能力鏈條，如果你的簡歷能體現這些，面試官就能很快的核對出你的基礎能力到底是否紮實，作為面試官，我們從業務基礎能力往通用計算機基礎方向去不斷的發問，形成一條問題鏈條，就能考察出面試者的基礎能力是否紮實，對於那些只侷限於 API 使用的情況，那基礎能力上的評價就是相當低的。
專業能力
相對於基礎能力聚焦於技術領域，考察的是技術工程師中的技術兩個字，而專業能力則考察技術工程師中的工程兩個字，一個優秀的工程師，一定具備良好的工程專案設計，管理，推進能力。一個軟體工程從無到有的過程，其最初一定是設計，如果一個技術工程師沒有任何設計一個專案的經驗，那這一項一定是不合格的，如果他有，那設計的方案是否合理，是否具備良好的擴充套件性，可維護性，就是需要考察的一個點，因為有了設計，那一定需要將設計落地，這個過程就是工程專案的推進，作為工程師，他如何推進，如何落地一個設計，這中間是如何管理的，如何控制專案風險，確保設計最終能夠被落實到專案中，這些都是考量的點，面試官可以持續的深入去了解從設計到落地的全過程，並通過工程專案的複雜性來判斷他專業能力的高低。這也是在基礎能力通過的前提下，給一個技術工程師評級的關鍵。
溝通能力
任何工作都離不開溝通，尤其是技術工程師，在團隊協作中跟不同的角色產生的溝通，更是團隊能否有效率的持續完成任務的關鍵，那如何體現自己的溝通能力 / 面試官如何考察一個人的溝通能力？
第一應該是直接感覺，在面試過程中，對方是否能夠很好的說明自己的優勢，並獲得面試官的認可，這本身也是溝通能力的體現，但光靠這個可能還不夠。所以第二點，又回到了之前的專業能力上，面試者所完成的工程專案的複雜性直接體現了他溝通能力，譬如這是個跨部門跨團隊的大專案，他能夠拿到比較好的結果，那溝通能力一定不會太差，如果一直都是做一個人的專案，或者是從沒有 owner 過一個專案，那溝通能力可能很難被評估出來，這時候不妨問些有引導性的問題，譬如：“是否遇到過工作上的難點，需要同事協助？”；“有主動去和其他部門的人溝通，完成一些工作麼？”，如果都沒有，那隻能靠第一感官了......
潛力 & 成長性
很多時候，面試者可能並沒有豐富的履歷和工作經驗，有些甚至是半路出家的“自學達人”，這時候，如果僅僅評估上述三點，也可能會錯失人才，另外即便是上述3點都非常好，但是因為人的階段的不同導致後續的表現並不如評估的那樣，為此我們需要考量面試者的潛力，即成長性
那怎麼定義潛力，或者說成長性呢？
我個人的理解，一個人的潛力來自於兩方面，一方面是這個人在早期的學習和工作經歷中的積累，即基礎是否紮實，這在基礎能力評估中可以比較準確的判斷，另一方面則是自我驅動，學習能力，善於思考，善於總結抽象等軟效能力
綜合起來看，即面試者對於自己的工作是否真的感興趣，對於技術是否有很強的好奇心，表現在行為上，一個自我驅動好，對技術有好奇心的人，往往會對工作之外的技術表現出極大的關注，即雖然這些技術目前你用不到，實際工作中可能沒有場景，但是依然會去了解，並進行嘗試，並深入去了解背後的實現原理，技術發展的前因後果，跟同類的比較等等，最後再進一步進行思考提煉加工，變成自己的東西，這個過程最終體現的其實是你的學習能力，即面試者是否有潛力，是否有成長性，就是看他是否能夠自我驅動，並擁有優秀的學習能力。
經驗
為什麼把經驗放在最後，因為我認為在整個能力模型中，經驗是萬不得已的評判標準，即一個人4項都不行，但是他有經驗啊，對於商業化的公司來說，某些場景下，我們需要的僅僅可能是一個對某一塊非常有經驗的技術工人。
總結
通過對能力邊界 & 能力模型的定義，面試官可以組合出你自己想要的能力模型， 然後匹配面試者的能力模型，讓面試的過程一開始就具備良好對接的可能，而面試僅僅是完成對接，驗證這個能力模型是否真實，是否匹配罷了。
比較極端的一個例子是外包，大公司可能會有不少苦力活需要外包，這時候其實就可以定義出外包的能力模型， 即對某一塊經驗豐富，同時熟練掌握業務基礎 API，即業務基礎能力較差，但是至少不是 0，另外溝通能力不能太差，所以至少有中等規模專案的參與，並且和不同的角色進行溝通過。這樣一個能力模型，再去匹配外包，招聘必然是事半功倍的。
掘金數徵文連結? juejin.im/post/5aaf2a…