我從編程面試中學到的

在 2017 年，我參加了 『計算機行業中的女性』 的Grace Hopper 慶祝活動。這個活動是這類科技活動中最大的一個。共有 17,000 名女性IT工作者參加。

這個會議有個大型的配套招聘會，會上有招聘公司來面試會議參加者。有些人甚至現場拿到 offer。我在現場晃蕩了一下，注意到一些應聘者看上去非常緊張憂慮。我還隱隱聽到應聘者之間的談話，其中一些人談到在面試中做的並不好。

我走近我聽到談話的那群人並和她們聊了起來並給了一些面試上的小建議。我想我的建議還是比較偏基本的，如「（在面試時）一開始給出個能工作的解決方案也還說的過去」之類的，但是當她們聽到我的一些其他的建議時還是頗為吃驚。

為了能更多的幫到像她們一樣的小白面試者，我收集了一些過去對我有用的小點子，這些小點子我已經發表在了 prodcast episode 上。它們也是這篇文章的主題。

為了實習生職位和全職工作，我做過很多次的面試。當我還在大學主修計算機科學時，學校每個秋季學期都有招聘會，第一輪招聘會在校園裡舉行。(我在第一和最後一輪都搞砸過。)不過，每次面試後，我都會反思哪些方面我能做的更好，我還會和朋友們做模擬面試，這樣我就能從他們那兒得到更多的面試反饋。

不管我們怎麼樣找工作: 工作中介、網路，或者學校招聘，他們的招聘流程中都會涉及到技術面試：

近年來，我注意到了一些新的不同的面試形式出現了：

• 與招聘方的一位工程師結對編程
• 網路在線測試及在線編碼
• 白板編程（LCTT 譯註： 這種形式應該不新了）

我將重點談談白板面試，這種形式我經歷的最多。我有過很多次面試，有些挺不錯的，有些被我搞砸了。

我做錯的地方

首先，我想回顧一下我做的不好的地方。知錯能改，善莫大焉。

當面試者提出一個要我解決的問題時， 我立即馬上立刻開始在白板上寫代碼，什麼都不問。

這裡我犯了兩個錯誤：

沒有澄清對解決問題有關鍵作用的信息

比如，我們是否只用處理數字或者字元串？我們要支持多種數據類型嗎？如果你在開始解題前不去問這些問題的話，你的面試官會有一種不好的印象：這個人在我們公司的話，他不會在開始項目工作之前不問清楚到底要做什麼。而這恰恰是在工作場合很重要的一個工作習慣。公司可不像學校，你在開始工作前可不會得到寫有所有詳細步驟的作業說明。你得靠自己找到這些步驟並自己定義他們。

只會默默思考，不去記錄想法或和面試官溝通

在面試中，很多時候我也會傻傻站在那思考，什麼都不寫。我和一個朋友模擬面試的時候，他告訴我因為他曾經和我一起工作過所以他知道我在思考，但是如果他是個陌生的面試官的話，他會覺得我正站在那冥思苦想，毫無頭緒。不要急匆匆的直奔解題而去是很重要的。花點時間多想想各種解題的可能性。有時候面試官會樂意和你一起探索解題的步驟。不管怎樣，這就是在一家公司開工作會議的的普遍方式，大家各抒己見，一起討論如何解決問題。

想到一個解題方法

在你開始寫代碼之前，如果你能總結一下要使用到的演算法就太棒了。不要上來就寫代碼並認為你的代碼肯定能解決問題。

這是對我管用的步驟：

1. 頭腦風暴
2. 寫代碼
3. 處理錯誤路徑
4. 測試

1、 頭腦風暴

對我來說，我會首先通過一些例子來視覺化我要解決的問題。比如說如果這個問題和數據結構中的樹有關，我就會從樹底層的空節點開始思考，如何處理一個節點的情況呢？兩個節點呢？三個節點呢？這能幫助你從具體例子里抽象出你的解決方案。

在白板上先寫下你的演算法要做的事情列表。這樣做，你往往能在開始寫代碼前就發現 bug 和缺陷（不過你可得掌握好時間）。我犯過的一個錯誤是我花了過多的時間在澄清問題和頭腦風暴上，最後幾乎沒有留下時間給我寫代碼。你的面試官可能沒有機會看你在白板上寫下代碼，這可太糟了。你可以帶塊手錶，或者房間有鐘的話，你也可以抬頭看看時間。有些時候面試者會提醒你你已經得到了所有的信息（這時你就不要再問別的了），「我想我們已經把所有需要的信息都澄清了，讓我們寫代碼實現吧」。

2、 開始寫代碼，一氣呵成

如果你還沒有得到問題的完美解決方法，從最原始的解法開始總是可以的。當你在向面試官解釋最顯而易見的解法時，你要想想怎麼去完善它，並指明這種做法是最原始的，未加優化的。（請熟悉演算法中的 O() 的概念，這對面試非常有用。）在向面試者提交前請仔細檢查你的解決方案兩三遍。面試者有時會給你些提示， 「還有更好的方法嗎？」，這句話的意思是面試官提示你有更優化的解決方案。

3、 錯誤處理

當你在編碼時，對你想做錯誤處理的代碼行做個注釋。當面試者說，「很好，這裡你想到了錯誤處理。你想怎麼處理呢？拋出異常還是返回錯誤碼？」，這將給你個機會去引出關於代碼質量的一番討論。當然，這種地方提出幾個就夠了。有時，面試者為了節省編碼的時間，會告訴你可以假設外界輸入的參數都已經通過了校驗。不管怎樣，你都要展現你對錯誤處理和編碼質量的重要性的認識。

4、 測試

在編碼完成後，用你在前面頭腦風暴中寫的用例來在你腦子裡「跑」一下你的代碼，確定萬無一失。例如你可以說，「讓我用前面寫下的樹的例子來跑一下我的代碼，如果是一個節點是什麼結果，如果是兩個節點是什麼結果……」

在你結束之後，面試者有時會問你你將會怎麼測試你的代碼，你會涉及什麼樣的測試用例。我建議你用下面不同的分類來組織你的錯誤用例：

一些分類可以為：

1. 性能
2. 錯誤用例
3. 期望的正常用例

對於性能測試，要考慮極端數量下的情況。例如，如果問題是關於列表的，你可以說你將會使用一個非常大的列表以及的非常小的列表來測試。如果和數字有關，你將會測試系統中的最大整數和最小整數。我建議讀一些有關軟體測試的書來得到更多的知識。在這個領域我最喜歡的書是 《我們在微軟如何測試軟體》。

對於錯誤用例，想一下什麼是期望的錯誤情況並一一寫下。

對於正向期望用例，想想用戶需求是什麼？你的解決方案要解決什麼問題？這些都可以成為正向期望用例。

「你還有什麼要問我的嗎？」

面試最後總是會留幾分鐘給你問問題。我建議你在面試前寫下你想問的問題。千萬別說，「我沒什麼問題了」，就算你覺得面試砸了或者你對這間公司不怎麼感興趣，你總有些東西可以問問。你甚至可以問面試者他最喜歡自己的工作什麼，最討厭自己的工作什麼。或者你可以問問面試官的工作具體是什麼，在用什麼技術和實踐。不要因為覺得自己在面試中做的不好而心灰意冷，不想問什麼問題。

申請一份工作

關於找工作和申請工作，有人曾經告訴我，你應該去找你真正有激情工作的地方。去找一家你喜歡的公司，或者你喜歡使用的產品，看看你能不能去那兒工作。

我個人並不推薦你用上述的方法去找工作。你會排除很多很好的公司，特別是你是在找實習工作或者入門級的職位時。

你也可以集中在其他的一些目標上。如：我想從這個工作里得到哪方面的更多經驗？這個工作是關於雲計算？Web 開發？或是人工智慧？當在招聘會上與招聘公司溝通時，看看他們的工作單位有沒有在這些領域的。你可能會在一家並非在你的想去公司列表上的公司（或非盈利機構）里找到你想找的職位。

換組

在這家公司里的第一個組裡呆了一年半以後，我覺得是時候去探索一下不同的東西了。我找到了一個我喜歡的組並進行了 4 輪面試。結果我搞砸了。

我什麼都沒有準備，甚至都沒在白板上練練手。我當時的邏輯是，如果我都已經在一家公司幹了快 2 年了，我還需要練什麼？我完全錯了，我在接下去的白板面試中跌跌撞撞。我的板書寫得太小，而且因為沒有從最左上角開始寫代碼，我的代碼大大超出了一個白板的空間，這些都導致了白板面試失敗。

我在面試前也沒有刷過數據結構和演算法題。如果我做了的話，我將會在面試中更有信心。就算你已經在一家公司擔任了軟體工程師，在你去另外一個組面試前，我強烈建議你在一塊白板上演練一下如何寫代碼。

對於換項目組這件事，如果你是在公司內部換組的話，事先能同那個組的人非正式聊聊會很有幫助。對於這一點，我發現幾乎每個人都很樂於和你一起吃個午飯。人一般都會在中午有空，約不到人或者別人正好有會議衝突的風險會很低。這是一種非正式的途徑來了解你想去的組正在幹什麼，以及這個組成員個性是怎麼樣的。相信我，你能從一次午餐中得到很多信息，這可會對你的正式面試幫助不小。

非常重要的一點是，你在面試一個特定的組時，就算你在面試中做的很好，因為文化不契合的原因，你也很可能拿不到 offer。這也是為什麼我一開始就想去見見組裡不同的人的原因（有時這也不太可能），我希望你不要被一次拒絕所擊倒，請保持開放的心態，選擇新的機會，並多多練習。

以上內容選自 《The Women in Tech Show: Technical Interviews with Prominent Women in Tech》的 「編程面試」章節，

作者簡介：

微軟研究院 Software Engineer II， www.thewomenintechshow.com 站長，所有觀點都只代表本人意見。

via: https://medium.freecodecamp.org/what-i-learned-from-programming-interviews-29ba49c9b851

作者：Edaena Salinas 譯者：DavidChenLiang 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive