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

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

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

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

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

不管我們怎么樣找工作: 工作中介、網(wǎng)絡，或者學校招聘，他們的招聘流程中都會涉及到技術面試：

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

• 與招聘方的一位工程師結對編程

• 網(wǎng)絡在線測試及在線編碼

• 白板編程（LCTT 譯注： 這種形式應該不新了）

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

我做錯的地方

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

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

這里我犯了兩個錯誤：

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

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

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

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

想到一個解題方法

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

這是對我管用的步驟：

1. 頭腦風暴

2. 寫代碼

3. 處理錯誤路徑

4. 測試

1、 頭腦風暴

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

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

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

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

3、 錯誤處理

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

4、 測試

在編碼完成后，用你在前面頭腦風暴中寫的用例來在你腦子里“跑”一下你的代碼，確定萬無一失。例如你可以說，“讓我用前面寫下的樹的例子來跑一下我的代碼，如果是一個節(jié)點是什么結果，如果是兩個節(jié)點是什么結果……”

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

一些分類可以為：

1. 性能

2. 錯誤用例

3. 期望的正常用例

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

對于錯誤用例，想一下什么是期望的錯誤情況并一一寫下。

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

“你還有什么要問我的嗎？”

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

申請一份工作

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

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

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

換組

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

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

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

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

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