從編程面試中學到的這些東西值得一看

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

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

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

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

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

無論咱們怎麼樣找工做: 工做中介、網絡，或者學校招聘，他們的招聘流程中都會涉及到技術面試：

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

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

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

我作錯的地方

首先，我想回顧一下我作的很差的地方。知錯能改，善莫大焉。

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

這裏我犯了兩個錯誤：

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

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

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

在面試中，不少時候我也會傻傻站在那思考，什麼都不寫。我和一個朋友模擬面試的時候，他告訴我由於他曾經和我一塊兒工做過因此他知道我在思考，可是若是他是個陌生的面試官的話，他會以爲我正站在那左思右想，毫無頭緒。不要急匆匆的直奔解題而去是很重要的。花點時間多想一想各類解題的可能性。有時候面試官會樂意和你一塊兒探索解題的步驟。無論怎樣，這就是在一家公司開工做會議的的廣泛方式，你們各抒己見，一塊兒討論如何解決問題。

想到一個解題方法

在你開始寫代碼以前，若是你能總結一下要使用到的算法就太棒了。不要上來就寫代碼並認爲你的代碼確定能解決問題。

這是對我管用的步驟：

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

一、 頭腦風暴

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

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

二、 開始寫代碼，一鼓作氣

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

三、 錯誤處理

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

四、 測試

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

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

一些分類能夠爲：

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中國 榮譽推出

原文來自：https://linux.cn/article-10032-1.html

本文地址：https://www.linuxprobe.com/study-from-interview.html編輯：清蒸github，審覈員：逄增寶