作為校招面試官，我想說幾點
時間：2021-11-29 14:45:56
手機看文章
掃描二維碼
隨時隨地手機看文章
[導讀]這周參加了今年校招的面試。被安排了兩天的面試，本以為每天要面四人，結(jié)果第一天安排四人但被鴿了兩，第二天只安排了兩人，所以強度并不大。整體看，覺得這一批學生的水平比過去略遜一籌?，F(xiàn)在網(wǎng)傳今年校招薪酬都開獎了，不清楚這一輪的面試者是不是二次篩選之后的。我面試的具體題目和方式依舊，絕對...
這周參加了今年校招的面試。被安排了兩天的面試，本以為每天要面四人，結(jié)果第一天安排四人但被鴿了兩，第二天只安排了兩人，所以強度并不大。整體看，覺得這一批學生的水平比過去略遜一籌?，F(xiàn)在網(wǎng)傳今年校招薪酬都開獎了，不清楚這一輪的面試者是不是二次篩選之后的。我面試的具體題目和方式依舊，絕對難度并不大，主要考察面試者的基礎知識的運用和問題解決能力，而不是簡單考察對方知道不知道某些具體的知識點。比如，從對方的項目經(jīng)歷方面去考察端到端的技術(shù)交付能力和綜合技術(shù)素質(zhì)，從設定的題目去考察編程基本功和解決編程問題的系統(tǒng)性思維。過去的文章[1]提過這些，在此不再復述。本文從項目經(jīng)歷和編程題兩個部分簡單分享這次面試的感受。簡言之，項目經(jīng)歷的深度和代碼細節(jié)背后的編程基本功依舊是有效的分水嶺。自己在校招面試中一直重視這些內(nèi)容的考察，而且我認為在這些方面表現(xiàn)好的面試者通常能夠在面試中甚至職業(yè)發(fā)展中脫穎而出。注：這僅代表個人意見。
考察項目經(jīng)歷的時候，我主要關(guān)注面試者的端到端技術(shù)交付能力[2]，比如能否能夠清楚介紹項目背景、目的，技術(shù)挑戰(zhàn)以及個人承擔的任務，對遇到的具體技術(shù)問題能夠能夠綜合不同技術(shù)方案來權(quán)衡利弊，能否系統(tǒng)地衡量交付的效果等。簡單來說，我期待面試者能在講述why-what-how的時候展示技術(shù)深度。在這個環(huán)節(jié)，近兩三年來多數(shù)面試者都能有內(nèi)容介紹。半數(shù)能清楚地介紹項目及自己承擔的工作內(nèi)容，能舉例說明所遇到的挑戰(zhàn)和解決方案，從中表現(xiàn)對涉及的領(lǐng)域知識和具體技術(shù)的熟悉程度。表現(xiàn)優(yōu)異的人通常能夠量化地衡量自己做出的成果，對具體的挑戰(zhàn)能清楚介紹不同方案基于項目條件下的權(quán)衡利弊，甚至說清楚最后技術(shù)方案存在的不足以及后續(xù)可能優(yōu)化的思路。這個環(huán)節(jié)里，面試者必須避免讓面試官感覺自己只是一個“執(zhí)行者”，比如只能簡單介紹自己做了什么卻無法講清楚為什么做、為什么選擇這樣做、如何衡量交付的效果等。缺乏迭代的項目經(jīng)歷是另一種難以體現(xiàn)深度的情況。比如項目只是簡單一次性實現(xiàn)了一個策略或機器學習的算法便結(jié)束了，多可能是因為該領(lǐng)域問題并沒有很大的挑戰(zhàn)性，或者面試者并沒有深度地解決該類問題目前最困難的挑戰(zhàn)。?
考察編程題，我更多關(guān)注的是代碼基本功而不是特定算法，所以我出的題目并不難，雖然熟練算法能提高解題效率。
我一直用當年微軟面試被面到的一道題目。最近看了一下leetcode，里面收錄了這道題，難度為medium。今年，甚至近兩三年，越來越多的面試者能不需要討論思路便能快速完成代碼。想必學生們在刷題上都做了充足的準備。然而，多數(shù)面試者在算法上做足了功夫，卻多忽視了對代碼基本功的關(guān)注。我考察代碼基本功的方式很簡單，即代碼講解和代碼測試。
寫完代碼后，我會讓面試者逐行講解代碼，然后提問。要求逐行講解代碼可以有效且靈活地考察和編程語言和技術(shù)實踐相關(guān)的知識點，比如函數(shù)參數(shù)傳遞方式，庫函數(shù)和容器類型，錯誤/異常問題處理等等。作為面試官，這里甚至不需要刻意準備大量知識點問題。只要有代碼，通過問一些通用的問題（為什么這樣用，還有什么選擇，分別有什么優(yōu)劣，能怎么改善等）就能快速判斷對方的專業(yè)性。面試官并不需要什么方面都比面試者更懂（這通常也不現(xiàn)實），而只需要引導面試者展現(xiàn)能力，然后便能夠分辨優(yōu)劣了。
當面試者就實現(xiàn)了一個函數(shù)的時候，通常講解函數(shù)定義的時候就能有區(qū)分度了。不少人甚至直接略過函數(shù)定義就介紹實現(xiàn)代碼，似乎函數(shù)定義顯而易見地合理。然而，具體詢問函數(shù)定義的細節(jié)時總能揭露編程基本功的好壞，比如返回值類型、參數(shù)設計和類型選擇等。要知道，一個良好的函數(shù)定義或者廣義上的程序接口定義能避免大量編程中可能出現(xiàn)的問題，比如不必再實現(xiàn)一些輸入合法性驗證（防御性編程）等。感覺多數(shù)面試者在平時編程（感覺多是刷題的時候）沒思考過這些問題，因此這里我主要是希望通過提問去考察對方一些函數(shù)/接口定義的基礎知識和最佳實踐，看對方是否能夠講清楚并有針對性地改善代碼。講解完代碼后，我會要求面試者設計合適的測試用例來驗證程序的正確性?，F(xiàn)在多數(shù)人都懂得設計一些邊界類的測試用例，來表現(xiàn)自己考慮了“特殊”情況。比如面試者使用二維矩陣結(jié)構(gòu)來描述圖，多數(shù)人會快速分別列出一個1*1，1*n，n*1，n*n和m*n的矩陣。但當我問“這個3*3的矩陣能代表所有n*n的情況嗎？”，對方通常會卡殼，甚至隨口而出說再設計一個或多個足夠大的矩陣，而并不能考慮清楚測試完備性的關(guān)鍵。在工程中，我們要為自己寫的代碼負責，總是需要先設計足夠的測試數(shù)據(jù)來驗證自己代碼的正確性。做好這一步能減少大多數(shù)低級錯誤。從這些年的面試經(jīng)驗看，通過代碼講解和代碼測試的考察還是能夠非常有效地區(qū)分出編程基本功的優(yōu)劣。因此，我建議通過刷題準備面試的人還是應該適當重視代碼質(zhì)量相關(guān)問題，而不是*只*關(guān)注到算法邏輯。
如果對方表現(xiàn)良好，則能夠繼續(xù)考察問題解決能力。時間不多的時候，我會在編程題的基礎上增加難度。如果時間還比較富裕，則會單獨出另一道題去考察問題解決思維；可惜，今年面試并沒有機會問到這道題。一部分原因是這次面試時間縮短到45分鐘了。幸好，在目前校招面試中，項目經(jīng)歷的深度和編程基本功依舊是有效的分水嶺。我還不需要提升面試內(nèi)容的絕對難度。注意，上述的內(nèi)容主要針對校招。我社招面試的時候?qū)^往項目經(jīng)歷的技術(shù)考察比重會更大；職級越高，比重越大。因為我認為對方的工作經(jīng)歷應該更能體現(xiàn)對方的專業(yè)能力，而不是我預先安排的題目。
考察項目經(jīng)歷的時候，我主要關(guān)注面試者的端到端技術(shù)交付能力[2]，比如能否能夠清楚介紹項目背景、目的，技術(shù)挑戰(zhàn)以及個人承擔的任務，對遇到的具體技術(shù)問題能夠能夠綜合不同技術(shù)方案來權(quán)衡利弊，能否系統(tǒng)地衡量交付的效果等。簡單來說，我期待面試者能在講述why-what-how的時候展示技術(shù)深度。在這個環(huán)節(jié)，近兩三年來多數(shù)面試者都能有內(nèi)容介紹。半數(shù)能清楚地介紹項目及自己承擔的工作內(nèi)容，能舉例說明所遇到的挑戰(zhàn)和解決方案，從中表現(xiàn)對涉及的領(lǐng)域知識和具體技術(shù)的熟悉程度。表現(xiàn)優(yōu)異的人通常能夠量化地衡量自己做出的成果，對具體的挑戰(zhàn)能清楚介紹不同方案基于項目條件下的權(quán)衡利弊，甚至說清楚最后技術(shù)方案存在的不足以及后續(xù)可能優(yōu)化的思路。這個環(huán)節(jié)里，面試者必須避免讓面試官感覺自己只是一個“執(zhí)行者”，比如只能簡單介紹自己做了什么卻無法講清楚為什么做、為什么選擇這樣做、如何衡量交付的效果等。缺乏迭代的項目經(jīng)歷是另一種難以體現(xiàn)深度的情況。比如項目只是簡單一次性實現(xiàn)了一個策略或機器學習的算法便結(jié)束了，多可能是因為該領(lǐng)域問題并沒有很大的挑戰(zhàn)性，或者面試者并沒有深度地解決該類問題目前最困難的挑戰(zhàn)。?
考察編程題，我更多關(guān)注的是代碼基本功而不是特定算法，所以我出的題目并不難，雖然熟練算法能提高解題效率。
我一直用當年微軟面試被面到的一道題目。最近看了一下leetcode，里面收錄了這道題，難度為medium。今年，甚至近兩三年，越來越多的面試者能不需要討論思路便能快速完成代碼。想必學生們在刷題上都做了充足的準備。然而，多數(shù)面試者在算法上做足了功夫，卻多忽視了對代碼基本功的關(guān)注。我考察代碼基本功的方式很簡單，即代碼講解和代碼測試。
寫完代碼后，我會讓面試者逐行講解代碼，然后提問。要求逐行講解代碼可以有效且靈活地考察和編程語言和技術(shù)實踐相關(guān)的知識點，比如函數(shù)參數(shù)傳遞方式，庫函數(shù)和容器類型，錯誤/異常問題處理等等。作為面試官，這里甚至不需要刻意準備大量知識點問題。只要有代碼，通過問一些通用的問題（為什么這樣用，還有什么選擇，分別有什么優(yōu)劣，能怎么改善等）就能快速判斷對方的專業(yè)性。面試官并不需要什么方面都比面試者更懂（這通常也不現(xiàn)實），而只需要引導面試者展現(xiàn)能力，然后便能夠分辨優(yōu)劣了。
當面試者就實現(xiàn)了一個函數(shù)的時候，通常講解函數(shù)定義的時候就能有區(qū)分度了。不少人甚至直接略過函數(shù)定義就介紹實現(xiàn)代碼，似乎函數(shù)定義顯而易見地合理。然而，具體詢問函數(shù)定義的細節(jié)時總能揭露編程基本功的好壞，比如返回值類型、參數(shù)設計和類型選擇等。要知道，一個良好的函數(shù)定義或者廣義上的程序接口定義能避免大量編程中可能出現(xiàn)的問題，比如不必再實現(xiàn)一些輸入合法性驗證（防御性編程）等。感覺多數(shù)面試者在平時編程（感覺多是刷題的時候）沒思考過這些問題，因此這里我主要是希望通過提問去考察對方一些函數(shù)/接口定義的基礎知識和最佳實踐，看對方是否能夠講清楚并有針對性地改善代碼。講解完代碼后，我會要求面試者設計合適的測試用例來驗證程序的正確性?，F(xiàn)在多數(shù)人都懂得設計一些邊界類的測試用例，來表現(xiàn)自己考慮了“特殊”情況。比如面試者使用二維矩陣結(jié)構(gòu)來描述圖，多數(shù)人會快速分別列出一個1*1，1*n，n*1，n*n和m*n的矩陣。但當我問“這個3*3的矩陣能代表所有n*n的情況嗎？”，對方通常會卡殼，甚至隨口而出說再設計一個或多個足夠大的矩陣，而并不能考慮清楚測試完備性的關(guān)鍵。在工程中，我們要為自己寫的代碼負責，總是需要先設計足夠的測試數(shù)據(jù)來驗證自己代碼的正確性。做好這一步能減少大多數(shù)低級錯誤。從這些年的面試經(jīng)驗看，通過代碼講解和代碼測試的考察還是能夠非常有效地區(qū)分出編程基本功的優(yōu)劣。因此，我建議通過刷題準備面試的人還是應該適當重視代碼質(zhì)量相關(guān)問題，而不是*只*關(guān)注到算法邏輯。
如果對方表現(xiàn)良好，則能夠繼續(xù)考察問題解決能力。時間不多的時候，我會在編程題的基礎上增加難度。如果時間還比較富裕，則會單獨出另一道題去考察問題解決思維；可惜，今年面試并沒有機會問到這道題。一部分原因是這次面試時間縮短到45分鐘了。幸好，在目前校招面試中，項目經(jīng)歷的深度和編程基本功依舊是有效的分水嶺。我還不需要提升面試內(nèi)容的絕對難度。注意，上述的內(nèi)容主要針對校招。我社招面試的時候?qū)^往項目經(jīng)歷的技術(shù)考察比重會更大；職級越高，比重越大。因為我認為對方的工作經(jīng)歷應該更能體現(xiàn)對方的專業(yè)能力，而不是我預先安排的題目。
下載文檔本站聲明： 本文章由作者或相關(guān)機構(gòu)授權(quán)發(fā)布，目的在于傳遞更多信息，并不代表本站贊同其觀點，本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者，如若文章內(nèi)容侵犯您的權(quán)益，請及時聯(lián)系本站刪除。
