我的職業生涯的最初幾年是在緊張的學習中度過的。
軟體工程師的工作不好做，我就遭遇了這一現實，是以不得不努力掌握很多我根本都不知道我需要掌握的技能。
在很多開發者工作的最初幾年，我以導師的身份，對他們進行過輔導。我自己在這方面經曆頗豐，我的一些同僚也有相應經曆。是以，基于這些經驗，我撰寫了本文，希望幫助那些需要幫助的人。
本文涵蓋以下内容：
如何在面試中脫穎而出
如何在軟體工程師崗位上生存（并壯大）
需要持續改進時，應當尋找何種資源
面試
在你的軟體工程師職業生涯開啟的那一刻，你不得不面對一個不争的事實：面試真操蛋。
面試對于身處其中的每個人都是夢魇。我既做過面試官也做過應聘者，我可以作證，面試是一件很浪費時間的事情，壓力超級大而且并不能很好地反映未來工作表現。盡管如此，面試還是必要之惡，你最好帶着精心修飾的履歷好好準備。
備戰
如果你正在考慮選擇軟體工程師行業，請確定掌握那些程式設計面試中最常問的問題，比如 FizzBuzz：
程式設計列印從 1 到 100 的數字。如果數字是 3 的整數倍，列印 Fizz；如果數字是 5 的整數倍，列印 Buzz；如果數字既是 3 的倍數又是 5 的倍數，列印 FizzBuzz。（來源：Coding Horror ）
聽起來足夠簡單，對吧？
然而，很大一部分應聘者都沒能通過這道簡單的測試，更不用說其他的複雜衍生版本了。
我個人曾經眼睜睜看到過很多進階崗位的候選人，在可以自由上網的情況下，沒能解出這道題目。是以，如果你的履歷上展示了某種程式設計語言，你得確定自己可以用這種語言解決 FizzBuzz 問題。否則，你就隻是在浪費大家的時間，包括你自己的時間。
當然了，要從面試中勝出，你還需要知道遠多于 FizzBuzz 的知識。你同時需要確定你知道：
基礎資料結構和算法，比如連結清單、數組、樹和排序
你選擇的程式設計語言中常見的問題，例如字元串是否不可變，以及如何管理記憶體
面向對象程式設計的概念，比如類和對象，以及繼承
在你的職業生涯伊始，你需要格外重視這些問題，因為你沒有經驗可以證明你的工作能力。對于在準備面試的人，我總是推薦兩種資源：
Cracking the Coding Interview 是一本很神奇的書。書中包含了大量的程式設計問題和相應解法，并彙總了解決此問題需要知道的知識。
CodeWars 是個網站。這個網站羅列了大量的程式設計問題，你可以在浏覽器中求解這些問題，可選擇的程式設計語言範圍也十分廣泛。
其中最有用的部分是，你可以看到其他使用者是如何解決同一問題的。你可以看到同一問題的不同解法，并學到關于你選擇的程式設計語言的新的工具。
賦予自身額外優勢
有幾件事情是你可以提前準備的，它将賦予你特殊的優勢。
首先，學會向他人展示你的經驗成果。用連貫而引人入勝的簡述總結你的履歷内容，就像電梯演講一樣。
另外，熟知你自己的履歷！這聽起來很傻，但是我卻看到過很多應聘者掙紮着說不清楚他們履歷上的某個特定細節。你應該有能力回答有關你履歷上的經曆的任何問題，并講清楚這一經曆如何讓你更加适合應聘的崗位。
其次，展示你在 GitHub （或者其他代碼倉庫）的示例代碼。
眼見為實。有機會親自看到你的代碼的面試官都會忍不住想看一眼的。另外，這也表明你對于版本控制系統是有一定了解的。
這些示例代碼不必太複雜，但是要整潔并展示良好的程式設計習慣。這是你展示無現場程式設計面試的時間壓力下的程式設計習慣的好機會。
一旦你完成了以上兩步，就需要考慮參與開源項目了。這将展示你可以在已有代碼基礎上工作，并且可以和其他程式員協同。
這将是你在尚未真正身處工業環境時最接近工業環境程式設計的了。這是迄今為止最難的也是最耗時間的項目，是以如果沒有完成我前面提到的低難度任務，先不要做這個。
反過來面試你的面試官
在匆匆忙忙、緊緊張張的找工作過程中，很多應聘者忘記了面試是個雙向通道。在公司試圖搞清楚你是否是這個崗位的合适人選的時候，你也應該搞清楚這個公司是不是适合你。
確定自己要提出以下問題中的幾個，就算是郵件面試也要提。要記得，大多數情況下，公司都不會像遵守最佳工程實踐一樣給員工清晰的定位，是以要逐字逐句的閱讀。
以下是一些你可以提出的問題：
“對這個崗位而言，一個典型工作日是怎麼樣的？”了解特定崗位的需求是很重要的，因為軟體工程師崗位千差萬别。比如，你可能需要長期維護伺服器或者直接和客戶溝通。
紅色警報：“我不太确定”→意味着面試你的人不和你在一個團隊，或者他們沒有想清楚為什麼要聘用你。
“你們如何做軟體測試？”理想狀況下，要檢測代碼品質，需要綜合使用單元測試、人工測試和自動測試。
紅色警報：“哈哈，我們寫的代碼沒有 bug。”→這麼回答的人，就是那些寫出 bug 的家夥。
“你們采用何種版本控制系統？”版本控制系統（Version control systems）對團隊協作是極其有用的，在專業團隊配置中，沒有任何理由不采用版本控制系統。
紅色警報 No.1：“呃……什麼是版本控制系統？”→趕緊跑，跑得越遠越好。
紅色警報 No.2：“< insert obscure or custom VCS > ”→ 這意味着他們基本上已經落伍了，很長時間沒有更新過他們的基礎設施了。
“你們做 peer review 嗎?”Peer reviews，或者在你的代碼并入代碼庫前請其他人審閱你的代碼，是檢查低級錯誤的高效方式，也是在職業生涯初期的重要的訓練機會。
紅色警報：“我們互相信任！”→很可能進階工程師們對自身的代碼十分“護食”，也不樂于接受回報。
“對于員工的持續教育，貴司有什麼項目支援嗎？”随着新科技的出現、成熟和過時的速度越來越快，身為軟體工程師就意味着要持續學習。是以，很多公司都有相應的教育訓練預算，支援員工參加大學課程、線上課程、會議或室内講座。
紅色警報：“你指的是下班後在網上自學嗎？”→公司要麼是現金流緊張，要麼就是将開發者視為可替代品而非長期投資。
“你們采用何種軟體開發流程？”不論實際細節如何，流程對軟體工程都是至關重要的。關于什麼是最優軟體開發流程的細節還存在激烈的争論，但是，僅僅存在一種商定的工作方式就能最大限度地減少混亂并確定所有人都在同一個頻道上。
紅色警報：“我們的流程是受自由爵士啟發而來的。”→很可能整個部門都是在戰火紛飛的狀态，沒有清晰目标的情況下應對一個又一個的突發緊急狀況。
“你們如何解決技術債問題？”技術債是代碼庫中的過時技術和糙快猛解決方案的長期累積造成的。強調技術債對于代碼庫的長期健康是重要的，并且應該持續的改進。
紅色預警：“我們特别關注新功能。”→他們的代碼庫亂成一團，或者馬上就會亂成一團。
“貴司的企業文化是怎樣的？”企業文化可能是十分虛無的概念，但是開放式工位 VS 格子間這樣的小細節都可以極大地影響到你和同僚的日常接觸。這裡并沒有通用的紅色預警，但是要確定，他們回答的内容是你可以連續數年下來每周在其中工作 40+ 小時的環境。
軟體工程師的職業生涯
在這個階段，如果你在面試中表現不錯，并且也喜歡面試官回答你問題的方式，你基本确定被錄用了。
恭喜恭喜。你終于成為一名正式的工程師了。
然後呢？是時候重新學習這些關于編碼和工作的繁文缛節了。因為我們是程式員，是以就從代碼開始讨論吧。
良好的工業級代碼
良好的工業級代碼具備以下特性：
可讀性。代碼隻需寫一次，卻需要閱讀和維護遠不止一次。在寫完代碼之後若幹年，對于其他開發者而言，代碼意圖依舊必須清晰明了。
防禦性，也就是防禦性程式設計最佳實踐。防禦性程式設計是個獨立話題，但是其要義在于，你要確定未正确使用的類和方法不會導緻軟體崩潰。
最優化。這是清單中排在最後的，是以不用過于擔心這個。這并不是說，存線上性解的情況下，還可以寫出複雜度是 O(n³) 的破爛代碼。但是，工程師通常急于試驗并且在根本不必要的情況下過度優化，結果往往損害了代碼的可讀性和防禦性。你需要随時可以證明，損害這二者而做的那些優化真的是值得的。
既然你已經知道了什麼是良好的工業級代碼：
你沒有多少時間寫代碼！
這可能會令你大吃一驚，不過大部分時間你都不是在寫新的代碼，而是在
debug
閱讀已有代碼
開會或者寫郵件
看看做些什麼才能夠不寫代碼
是以寫代碼以外的技能對于你的職業生涯相當重要。
測試代碼、研讀代碼
用 print 語句 debug 是最省時間的方式。所有廣泛使用的程式設計語言和技術棧都包含大量的有力工具，學會使用他們，debug 将變得小菜一碟并為你節省大量時間。
了解代碼庫。大多數技術棧都有代碼圖表序列工具，可以幫助你了解代碼庫結構。企業級 IDE 一般都有内置功能。你可以借用外部工具，諸如 ReSharper , grep 或者 Sourcegraph 。
了解産品。如果你知道在“修複”系統前，多少開發者并不清楚軟體如何運作，你絕對會大吃一驚的。多讀文檔就是了。
理清自身思路
因為你要在在交流、研究和多任務處理上花費很多時間，是以你需要一些工具，幫你讓一切保持井井有條。
TODO 清單 / 任務：你所在的公司應該已經有某種任務管理軟體了，這卻不妨礙你擁有自己的個性化配置。可以使用便利貼或者 Trello 或 Todolist 這樣的軟體。
筆記：會議一定記筆記，堅持改善已有文檔并提升自我知識基線。就像過去一樣，使用 Evernote、OneNote 或者筆記本。這看起來有些落伍，不過當你在一年後花了三天時間才找到當時的潦草記錄的時候，你會感謝當年記筆記的你。我認識的優秀的軟體工程師，沒有一個不是做了詳實筆記的。
圖表 / 可視化工具：人類是視覺化的動物，建立流程和結構圖表有助于幫助你和他人了解複雜的話題。在與非技術背景的同僚交流時，表格是極其有用的。推薦使用 Lucidchar、Visio 或者白闆。
知道何時使用其他庫
一言以蔽之：一直用。
詳細說明：99% 的時間，你都不應該重複造輪子。在大多數軟體工程崗位中，重新撰寫某一種排序算法都是徹頭徹尾的浪費時間。這并不是說，你不必知道所用的算法和資料結構如何運作。知曉這些内容，将有助于你決定何時采用什麼。
作為一位高效的軟體工程師，你需要了解你手頭當下可以用的庫。大多數流行程式設計語言的标準庫都是特别有用并且遠超你想象的。此外，代碼庫還可以使用其他專門的庫。你需要熟讀其文檔，并知道何時使用。
如果使用額外的庫可以節省時間，你也不必為此戰戰兢兢。但是，您需要確定選擇工業級别的優秀的庫。一個優秀的庫應當具備以下特點：
開源，這樣你才能檢查代碼品質并修複對你的應用緻命的潛在 bug 。
使用相對寬松的許可證，如 MIT 和 BSD，這樣你的公司不會是以擔上任何官司。要小心 GPL 許可，除非你想不小心開源你的全部代碼。
成熟，也就是已經面世一段時間并具備豐富的功能。
持續維護，常有新功能問世。
其他公司或項目在用，這可以作為例證，并確定其具備工業應用的持續更新。
持續改善
你需要學習那些是你的日常工作更加出色的技能，此外，你也需要持續提升你的技能并學習新的技能，這樣才能為你自己不斷創造新的職業機會。
學習機會多如牛毛，其中很多都是觸手可及的：
線上課程：你不應該錯過向你所在領域的最頂尖教授學習的機會， 而且形式很靈活。在 Coursera 、 Udacity 和 edXps://www.edx.org/ 等網站上，你可以找到很多補充你現有技能的課程。
線上碩士學位：在世界頂尖大學中，線上碩士學位是繼續接受正規教育的一種靈活方式。和在校課程相比，線上碩士學位通常也不太貴，大部分課程的學費都在 1 萬美元左右。Georgia Tech 、 UT 以及 UC San Diego 都提供此類學位。我個人推薦佐治亞理工學院線上碩士（ Georgia Tech’s Online Master’s），我今年剛剛從這裡畢業。
部落格：部落格是開發者社群一個重要組成部分（這個不足為奇，因為你現在正在閱讀的就是我的部落格）。諸如 Coding Horror 、 Joel on Software 甚至更加幽默的網站比如 The Daily WTF 都可以提供作為一位軟體工程師哪些該做和哪些不該做的建議。浏覽 Medium、r/programming、HackerNews 和其他 feed 流網站，你都會找到很多有益的文章和部落格。
會議：最後但并非最不重要，會議是一個及其有用的學習機會，你應該充分利用公司的教育訓練預算去參加會議。以下是高價值會議（含會議主題）推薦的不完整名單：GOTO; (General)、 Strange Loop (General)、 PyCon (Python)、 CPPCon (C++)、 DEF CON (Security)、 Fluent (Web dev)。YouTube 上有以上所有會議的（大部分）演講的視訊，是以就算你不能親臨現場，也能夠學到東西的。我希望這篇文章為你提供了軟體工程師職業生涯伊始需要的知識，并提供了激動人心的旅程中表現卓越所需要的工具。