面試造核彈的童話

面試造核彈的童話

　　小王回想起了本身的面試之旅：爲了拿到 offer，他必須在電話裏完成一個很是複雜的代碼挑戰。他表現得很好，走到了下一輪面試。通過一輪又一輪艱難無比的面試，他就像孫悟空護衛着唐僧同樣，披荊斬棘，文體兩開花，最終成功拿到了 offer。

　　但在加入公司後，他發現他所作的工做與預期相去甚遠。他的主要任務就是爲運行在虛擬機上的遺留系統構建基本的 CRUD。這就比如取經時他是無所不能、望風披靡的孫悟空，取完經後他就成了一個桌案上的供奉，天天只能吃點香燭貢品。

　　其實在招聘中，這類狀況一直在發生。企業讓工程師經過嚴格的篩選程序，問他們一些有挑戰性的問題，但在把他們招進公司以後，只是讓他們作一些枯燥乏味的事情，好比負責由五六個服務組成的系統，或者讓頁面看起來更漂亮些。固然，並非說這些任務就不須要技能，只是這些任務所須要的技能與大多數面試涉及的內容根本不同。

　　入職擰螺絲的管道工做業

　　軟件是由於可以提供業務價值，因此才被建立出來。

　　雖然閱讀有關軟件開發的書籍而且在軟件技術上追求卓越對小王們來講頗具吸引力，但歸根結底，若是不能造成業務並從中賺到錢（或省錢），小王們的工做就毫無心義。

　　所以，軟件行業的現狀自有它的道理。就像管道工同樣，他們得到報酬，是由於他們瞭解本身所使用的工具，並知道如何使用它們讓設備運轉起來，而不是讓他們從新發明技術，或者花 80 個小時去優化只有 5% 的用戶會用到的東西。

　　中小型企業不多會去處理與規模擴展或優化相關的問題——一部分緣由是硬件變得愈來愈便宜，一部分緣由是基礎的開源軟件已經作得很好了。

　　因此，企業一方面想網羅最優秀的人才，以便在重大的時間節點、關鍵時刻可以物盡其用（但一般沒有這種狀況），另外一方面只派給這些優秀人才以增刪查改的平常工做，最終每一個優秀的小王都成了 Crud Boy。

　　某一天，小王被開發經理叫去了辦公室，他敏銳地意識到這應該是他職業生涯中的轉折點，公司必定出了什麼問題，須要像 Jeff Dean 那樣的技術人才來拯救公司，而他，就是那樣的人！

　　「小王吧？公司最近業績很差，虧損嚴重，要裁人了，實在是很差意思哈，你去找下 HR。」

　　公司的確出了一些問題，但卻不是 Jeff Dean 能解決的，也不是他能解決的。他只是在推開門後回頭罵了一句：「你才小王八，你全家小王八。」

　　技術實力的迷思

　　不少人以爲，本身確定不會成爲小王。由於本身是獨一無二的，特別的那種工程師，而全部現狀的不如人意，必定都是時候未到、伯樂未到，畢竟本身的技術實力擺在那兒。

　　可技術實力到底是什麼呢？

「咱們組內的 XX 技術實力不如我，居然他晉升經過了，我卻被刷掉了，評委真的是~！@#￥」……

「面試官問的都是什麼鬼問題，我知道的基本沒問，我感受他根本不會考察個人技術實力」……

「據說算法和數據結構最能體現程序員的實力，我要好好啃啃《算法導論》」（然而啃完又忘記了）……

　　當咱們聊技術實力的時候，咱們到底在聊什麼？

有的人認爲：技術實力就是指算法和數據結構很厲害……

有的人認爲：研究過 Linux 內核源碼和看懂《深刻淺出 MFC》的纔是技術牛逼的人……

有的人認爲：會寫 C++ 的纔是真正的技術高手，由於 C++ 的對象初始化有 N 種寫法……

有的人認爲：技術高手必須對業務很熟悉……

有的人認爲：貢獻了開源項目代碼的纔是技術牛人……

有的人認爲：只有架構師纔是技術大牛……

　　其實簡單來講，判斷技術實力的一個總的原則就是：技術實力就是指解決問題的能力！

　　1）不存在放之四海皆準的技術 

　　簡單來講，問題是和領域相關的，技術是用來解決問題的，所以技術也是領域相關的，不存在放之四海皆準的技術。

　　有網友說：高斯林來作 iOS 開發，分分鐘秒殺如今全部的 iOS 開發人員，由於目前 iOS 經驗最豐富的開發人員，經驗也不過 10 年。我認爲這是不可能的，iOS 開發領域面臨的問題，和開發 Java 編程語言面臨的問題差別很大，固然，若是高斯林真的作上幾年 iOS 開發，確實可能超過不少 iOS 開發人員，但一開始就秒殺哪些作了 7~8 年的 iOS 程序員，這個是不可能的。

　　2）技術要能解決具體問題纔有價值 

　　技術只有可以解決某個領域的問題纔有價值，不然光知道某個技術沒什麼用；掌握了某個技術但在當前的領域用不上，這個技術對當前領域來講也沒有價值。

　　固然，確實存在某些技術可能在當前看起來對當前領域沒有用，但後面可能會用到，所以技術人員須要本身儲備一些當前暫時沒有用的技術以拓寬技術視野，例如當前大火的人工智能和區塊鏈技術，但要注意「可能」這個詞，這須要技術人員本身進行判斷和平衡，不能拿技術儲備做爲託詞一股腦的什麼都儲備，例如數據庫開發工程師至少在這幾年是不須要儲備 VR 知識的。

　　3）問題的複雜度決定技術實力的高度

　　問題的複雜度不一樣，複雜度越高，解決起來越困難，相應的技術實力要求也越高。

　　打個比方，不少面試官喜歡讓面試者現場手寫冒泡排序、快速排序、鏈表之類的代碼，以此來判斷面試者的技術實力，但咱們用這個原則去分析一下就能夠發現，這樣並不能考覈技術實力，假如招聘了一個會手寫快速排序的面試者，招進來後你會讓他用本身寫的快速排序解決什麼問題？貌似絕大部分場景下都不可能讓一個新來的員工本身寫個快速排序來解決某個問題吧？

　　咱們該如何自處？

　　咱們生活在一個大多數「軟件工程」基本上就是管道做業的世界裏。咱們該怎麼辦？這對於咱們的職業生涯來講意味着什麼？現金流會一直持續下去嗎？

　　首先，咱們應該認識到並接受這樣的一個事實，即咱們能夠用更少的資源構建更多的東西。也就是說，咱們工做中不是那麼有價值的部分可能進行自動化，或者構建工具，讓業務人員爲咱們作這些工做。例如，每當個人團隊中有人想要修改自動電子郵件副本時，我就要去修改代碼。而如今，他們只須要在可視化編輯器中編輯模板，我甚至都不知道它們被改過了。

　　其次，咱們在設計系統時須要考慮到系統的複雜性。若是有現成的解決方案，那麼就用它，不要再從頭開始構建。咱們要學會組裝零件，這樣就能夠比那些每次在啓動項目時都要自定義構建框架的軟件工匠更高效、更快、更好。

　　第三，咱們應該設定切合實際的指望。大部分編碼工做都只要求 CS 學位，而這些工做所涉及的內容可能只比知道如何導入庫和了解 HTTP 原理多那麼一點點。不過確實有些工做須要進行微優化，但這類工做可能不多，並且離咱們很遠。你的軟件可能沒有你想象的那麼特別。

　　最後，不要陷入了溫馨區而不能自拔。這並非軟件工程師的廣泛見解，但我相信在這個領域裏，有不少人拿到的報酬已經遠遠超出了他們所從事工做的難度。有時候是由於他們是這個領域惟一知道怎麼作這些事情的人，有時候是由於他們所在的公司沒法從人才市場上招到更好的人，有時候是由於其餘工程師故意過分設計，這樣初級開發人員就須要花費很長時間才能理解它。不管如何，若是咱們想要保持高薪和不被踢出局，就不能中止學習。增強知識的廣度和深度，並學會如何將炒做從真正的突破性技術中過濾掉。