如今越來越多的人進入軟體工程行業，偶遇乙份國外同學寫的行業生存指南，讀來感覺頗值得參考，簡單翻譯過來，分享一下。也許生存指南能更好得讓你在這個行業生存下來，並快速獲得成長與發展。
我遭遇了作為一名軟體工程師的現實：我必須去掌握當時還不知道，但我將會需要的許多技能。回首過往，如果早知道我現在知道的這些事情，肯定要好很多。
因此，我寫了篇指南，它源自早年我作為專業人士去輔導程式設計師的經驗，以及我本人和我一些同事的經驗來幫助其他人。
包括以下內容：
如何充分利用好面試；
如何在軟體工程師的工作中存活下來並茁壯成長；
以及在考慮持續改進時需要哪些資源。
當你開始你的軟體工程職業生涯時，你將不得不面對乙個不爭的事實。面試糟透了。
對每乙個牽涉其中的人來說都是可怕的。作為一名面試官和一名應聘者，我可以證明面試是乙個很大的時間無底洞，它包含極度的壓力，並且是乙個非常糟糕的未來工作表現的指標。然而，它們是必要的**，以至於你和你的簡歷都最好為此做好準備。
如果你正在考慮從事軟體工程，一定要學習一些最常見的程式設計面試問題，比如 「fizzbuzz」：
編寫乙個將數字從 1 列印到 100 的程式。對於 3 的倍數就列印 『fizz』 而不是數字，對於 5 的倍數 就列印 『buzz』。對於既是 3 又是 5 的倍數，就列印 『fizzbuzz』。聽起來足夠簡單，對吧？
好吧，絕大多數應聘者都沒有通過這個簡單的測試，更不用說其更複雜的變體了。
我個人見過許多高階職位的候選人在可以完全上網的情況下都沒能通過這道測試。因此，如果你在簡歷中列出了一種程式語言，那麼你至少要知道如何使用它編寫 『fizzbuzz』 程式。否則，你就是在浪費所有人的時間，包括你的時間。
當然，你需要知道的應不止於 『fizzbuzz』，才能在面試中倖存下來。你還需要確保你知道：
在你的職業生涯之初，你將需要在這些問題上表現出色，大放異彩，因為你還沒有足夠的經驗來證明你會很勝任這份工作。
有幾件事你可以做，這會給你一些額外的東西。
首先，學會交流你的經歷。你應該有乙個 「電梯演講」（在乘坐電梯的短時間內的推薦演講）來把你的簡歷總結成乙個連貫且吸引人的敘述。
另外，了解你自己的簡歷！這聽起來很傻，但我看到很多應聘者在艱難解釋簡歷上的某一特定專案。你應該能夠回答你在簡歷上列出的任何經歷相關的問題，並解釋它如何使你成為更好的候選人。
接下來，在 github (或其他公共**庫)上擁有**示例。
眼見為實，面試官能夠看到你的**可是會產生奇蹟的。此外，它還展示了你對**版本控制系統的理解。
**示例不必太複雜，但它們確實需要乾淨，並展示良好的編碼實踐。這是你的機會，在乙個沒有時間壓力的編碼面試中展示你會如何編碼。
完成上述所有工作之後，就應該考慮參加乙個開源專案了。顯示你可以在現有的**庫中工作，並與其他程式設計師協作。
這將是你身處工業程式設計環境之外，最接近工業程式設計環境的方法了。這也是迄今為止最困難和耗時的方法，所以先把它留到最後，直到你把前面那些 「低垂的果實」 都摘了。
在求職的匆忙和壓力下，許多應聘者忘記了面試是雙向的。當公司試圖發現你是否適合這份工作的時候，你也應該弄清楚公司是否適合你。
確保你可以問下面的一些問題，即使是在後續的電子郵件中。
下面是一些你可以問的問題：
問題 #1
「對於我來說，乙個典型的工作日會是什麼樣子？」
重要的是要明確對某個特定職位的期望，因為軟體工程的不同崗位差異很大。例如，你可能需要維護伺服器或與客戶直接交談。
紅燈警示：「我不確定。」 → 這裡的意思是面試你的人不是招聘你的團隊中的人，或者他們還沒有乙個清晰的認識為什麼要雇用你。
問題 #2
「你們是如何測試軟體的？」
理想情況下，應該使用單元測試、手動測試和自動化測試的組合來驗證**的質量。
紅燈警示：「我們通常不寫 bug，哈哈。」 → 這樣說的傢伙正是寫 bug 的人。
問題 #3
「你們使用什麼版本控制系統？」
版本控制系統對於協作非常有用，沒有任何理由在專業環境中不使用版本控制系統。
紅燈警示 #1：「啊，版本控制系統？」 → （若他們不知道）趕快逃跑，跑得遠遠的。
紅燈警示 #2：一些模糊或自定義的 vcs 系統 → 表明他們很可能跟不上時代，很長時間沒有更新他們的基礎設施了。
問題 #4
「你們是否進行同行評審？」
同行評審，或讓其他人在你提交到**庫前檢視你的**，是發現愚蠢錯誤的極好方法，也是開始職業生涯時的乙個重要的培訓機會。
紅燈警示：「我們相互信任！」 → 這種情況很可能是高階開發人員對他們的**具有自利的保護性，而不是很樂意收到反饋。
問題 #5
「你們有什麼繼續教育的計畫？」
問題 #6
「你們使用的軟體開發流程是什麼？」
無論實際細節如何，流程對於軟體工程都是至關重要的。關於什麼是最優流程的具體問題，需要進行激烈的辯論，但只要有一種商定的專案工作方式存在，就會儘量減少混亂，並確保大家達成共識，保持一致。
紅燈警示：「我們的過程是受自由形式的爵士樂啟發。」 → 表明很可能整個部門都處於消防模式，從緊急情況跳到緊急情況，缺乏任何明確的目標。
問題 #7
「你們如何處理技術債？」
技術債是**庫中的一種過時技術和快但髒的解決方案的累積。解決這個問題對於**的長期健康是很重要的，並且應該持續地進行。
紅燈警示：「我們只關注新特性。」 → 他們的**庫可能一團糟，或者它就快變得一團糟了。
問題 #8
「你的公司文化是怎樣的？」
公司文化可能是乙個非常模糊的概念，但即使是像開放式辦公室和隔間這樣的小事情，也會在很大程度上改變你與同事的日常互動。這裡沒有通常意義上的 「紅燈告警」，但要確保他們的答案可以讓你每週忍耐 40+ 小時，並持續數年。
在這個階段，如果你在面試中表現出色，並且喜歡面試官對你問題的回答，那你很可能會被錄用。
恭喜，你已正式成為一名軟體工程師了！
現在該談什麼了？是時候重新學習關於編碼和工作的很多事情了。既然我們是程式設計師，就讓我們從討論**開始吧。
好的工業級**具有以下屬性，按順序排列：
現在你已經知道如何編寫良好的工業級**了。
這可能令人驚訝，但大多數情況下，你不會編寫新**，而是：
因此，編碼以外的其他技能對你的職業生涯也同樣重要。
您需要的不僅僅是用 print 語句進行除錯。所有廣泛使用的語言和技術棧都有各種強大的工具，學會使用它們，因為它們會使除錯變得輕而易舉，並為你節省無數的時間。
理解**庫。大多數技術棧都有一些**圖形生成工具，可以幫助你理解**庫的結構。企業級 ide 通常內建這樣的功能。
理解產品。你將會驚訝的，在嘗試 「修復」 軟體之前，有多少開發人員不知道軟體應該如何工作。
由於你的大部分時間將花在溝通、調研和多工處理上，你需要一些工具來使得一切有序。
todo list / 任務列表：你的公司應該已經有某種任務處理軟體了，但是擁有乙個針對個人的軟體也是有幫助的。
注意事項：在會議上做筆記，努力改進現有文件，建立個人知識庫。使用 evernote、onenote 或紙質筆記本，就像以往的舊時光一樣。這看起來可能有點過火了，但一年後，當你重新檢視那個花了你 3 天的時間才想出來的費解的設計過程時，你會感謝自己的。我從未見過乙個優秀的軟體工程師，他不做大量的筆記。
圖表/視覺化：人是視覺動物，建立流程和體系結構圖表將幫助你和其他人理解複雜的主題。在與非技術同事交流時，圖表特別有用。
簡短答案：幾乎總是使用。
長篇大論：99% 的時間裡，你不應該重新發明輪子。在大多數軟體工程職位中，實現特定型別的排序完全是浪費時間。這並不意味著你不應該知道所用的演算法和資料結構是如何工作的，因為這將幫助你決定使用什麼以及何時使用。
為了成為一名高效的軟體工程師，你需要了解可供你使用的庫。大多數流行語言的標準庫非常有用，比你預期的要大。此外，**庫還可能利用了額外的專門庫。閱讀他們的文件，並知道什麼時候使用它們。
如果額外的庫可以節省時間，那麼你也不應憚於建議使用它們。但是，你需要確保選擇了乙個良好的庫供工業級使用。乙個好的庫是：
除了學習能讓你在日常工作中做得更好的技能之外，你還需要不斷地改進你的技能，學習新的技能，以便為自己創造新的職業機會。
學習的機會很多，其中多數都是負擔得起的。
會議：放在最後，但並非最不重要。會議是乙個驚人的學習機會，你一定要利用你公司的培訓預算去參加。
最後，希望這篇文章能讓你對作為一名軟體工程師的職業生涯的起步階段有所了解，並為你提供了在這一令人興奮的旅程中表現出色的工具。
軟體工程 軟體生存週期
與任何事物一樣，軟體也有乙個孕育 誕生 成長 成熟 衰亡的過程，這個過程稱為軟體生存週期 軟體生命週期 詳細的劃分如下圖 它們的主要任務如下 制定規劃 可行性分析 確定要開發軟體系統的總目標，給出它的功能 效能 可靠性以及介面等方面的要求。由系統分析員和使用者合作，研究該項任務的可行性，解決問題的可...
軟體工程 軟體生存期
軟體生存期即軟體的生命期，是指乙個軟體從最初的想法到最終被取代的這一整個過程！軟體生存期可以分為三個大的階段，即計畫階段 開發階段 維護階段！也可以分為六個階段 問題定義與可行性研究 需求分析 軟體設計 編碼 軟體測試 執行與維護。這個階段主要是開發商與客戶共同討論，確定軟體開發的目標和可行性！可行...
推薦乙份 Google 面試指南
其實，專案經驗固然重要，但是企業也知道，對於應屆畢業生，是很難有拿得出手的專案經驗出來的，畢竟缺乏實際工作經驗，哪怕你是優秀生，也大多是在理論知識上，所以，一般來說，企業針對應屆畢業生的面試，則主要考察基礎知識，而且越是大公司，越是注重基礎知識的考察。這就好比蓋房子，計算機方面的基礎就好比是地基，大...