聊聊技術面試 | 掘金技術徵文

前言

最近做爲面試官，參與了多場專場面試，短時間內大量的面試，面對不一樣風格，性格迥異的面試者，讓我對面試這件事自己產生了一些思考，結合本身的一些理解和技術領域特有的定級制度，咱們不妨來聊聊技術面試這回事。

何爲技術面試

我所理解的面試，是一場圍繞着兩個角色 - 面試官 & 面試者 之間的一場「對接之旅」， 如何在短短的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…