＃軟體工程師面試 ＃文長慎入
面試問題好像一直以來都是一個很多人關切的環節，在各大版上也一直有人會詢問。因為之前有幫公司面試一些人，還有加上從朋友那邊搜刮來的經驗，概括分享一下。
這邊感覺可以分成幾個部分：
1. 面試的題目是否都是演算法相關題目？
2. 是為什麼實際工作內容通常都和面試考的沒有相關？
3. 我現在學的東西對找工作是否有幫助？
4. 公司招募看的到底是這個人的學經歷，能力，個性，還是什麼，為什麼有些人很感覺很厲害卻一直無法拿到offer？
其實用FB排版不太容易，但因為懶得登入部落格，想說快速地打一打，所以也請各位見諒。
＃面試的題目是否都是演算法相關題目
如果是投FANG之類的，Facebook Amazon, Neflix, Google (沒記錯應該是這幾間），反正就是這些有名的大廠，除了Netflix目前沒有遇到認識的聊過，其他都是考演算法沒錯。
當然也不只有會考演算法，根據你申請的職缺，可能也會加考一些其他的東西。
那其公司是怎樣呢？其實還是有很多公司會考演算法相關的，尤其是線上面試。
雖然在疫情下全都是線上，但一般來說，還是會有分兩種，一種是沒有真人的狀況下，就是給你像是HackRank這種網站，你點開可能有六十分鐘讓你做兩題。
做完以後你提交，你也不會知道你的分數跟分析結果之類的，看公司怎麼做設定，而且除了演算法相關題目，也可以設定選擇題之類的。
另一種就是真人面試，通常電腦自動面完以後，你可能會跟真人線上面試，真人也是會給你類似所謂的白板題，就是出一個題目讓你現場解題，然後中間可能有的會要你跟他討論，當然看面試官拉！
比較加分的還是，你編寫的時候可以邊闡述自己的想法，而不是低頭默默寫完，這樣也是有點尷尬。如果你編寫邊闡述的話，或者是少有點互動，也是展現你的溝通能力以及你對於題目的掌握能力，就像是你看到一個很簡單的題目 (2+3)*5 之類的，你可以很有自信的說，喔因為2+3在括弧裡面，所以要先算，然後再乘以5，展現底是真的有理解，而不是就是背題目之類的。
有些公司也可能是給你回家作業，叫你做一個小專案之類的，看你應徵的職缺，可能是叫你做一個UI 或者叫你建一個API 也可能叫你做一整個比較完整的東西出來。如果你是面試架構師的話，可能會叫你建一個架構，或設計一個架構出來。
然後也有的公司（像我們公司）就是需要pair programming 所以在線上面試的階段就是會有，真人跟你一起寫程式這樣。
＃為什麼實際工作內容通常都和面試考的沒有相關
這個部分一直以來都是一個難解的謎題。像是Google Facebook這種大公司其實不難理解，畢竟他們是比較類似General 的招募，不是一開始就決定好你就是要去某個Team然後永遠讓你待在那個Team。就他們招募的是他們覺得，有潛力的人才，這樣不管需要做什麼都可以自由移動他們，給他們training就可以變得很好用。加上他們一次招募的數量也是相當龐大，考演算法相關的話，可以快速篩選，也更有機會找到他們需要的人才。
因為像是Facebook或Google這種有自己開發框架，開發技術的公司，他們的確有很多時候需要寫演算法或者系統優化的工作。
那像是普通的中小企業或新創，說真的，其實就是跟風。因為覺得人家Google Facebook都是這樣找到優秀人才，那我們也要依樣畫葫蘆，這樣鐵定也能找到厲害的人。
可是這樣找到的人進去以後，發現公司好像也是不知道在幹嘛，最後可能也會待不下去。所以這個部分，近年來也越來越多公司開始改進，開始思考什麼樣的招募流程最適合自己公司。
像是pair programming也開始成為近年來的一個流行的面試，有的公司並不是真的pair 但就是你要跟他們一起工作，了解他們公司的文化，或者跟他們的工程師進行一些深度討論。或者會問你說，假設給你設計一個系統，你要怎麼做之類的。
當然，面試問題跟流程都是每間公司各有不同，不是說你現在準備一種就萬無一失。所以說最好還是盡可能的，提升自己的基礎能力。
如果真的就是打算以FANG為目標的話，就可以從刷題開始，像是Leetcode, Hackrank, codewars之類的都不錯。之前有看到一篇文章，他刷了幾百題，而且每題刷了三次以上，真的很有毅力。刷題的重點就是在於熟練那些題目，可是也不要硬背，你練習是要練那個速度感。可是該理解的還是要理解。
因為你進公司以後，你還是需要使用那些東西來工作，不是只是為了刷題而刷題，而且面試官可能也會考你變形題之類的，或者問你一些記憶體相關的問題，或者是系統設計的問題，或者單純想知道，你是怎麼想出解法的，所以硬背題目跟答案其實也是不太行。
目前我的了解是，大部分中小型企業或者新創，很多時候你學習新東西的能力是比演算法更重要的，尤其是新創你什麼都要會，假設公司是剛起步的新創，你就要變成公司主要的技術專家，什麼東西不太會也要馬上現學現賣，也不要期望公司可能會給你什麼Training 或者有人給你依靠，可能同事還要依靠你。
中型或者普通大型企業，假設公司已經有產品的話，大部分的時候可能是既有產品維護，除非你剛好很幸運地在新產品開發的Team，這樣就有機會學到很多東西，不然維護的話，很多時候只是在了解產品本身是否有Bug，改善code品質之類，也要看公司是否有想花成本在維護上面。如果公司就是打算一個產品，改一點東西就繼續賣錢，那樣好像也不太需要一直去migrate 或者搞新東西上去。
如果你剛好很幸運在獨角獸新創，那你不但可以學到很多東西，還可以用最新科技，可能還有機會遇到大神帶你。
所以說選公司其實也是有點重要，面試的時候，可以問問他們說，那你平常的daily work是怎麼樣的，公司有沒有走敏捷開發，公司有沒有用雲端，公司一個Team的規模之類，以及公司會不會提供訓練。
＃我現在學的東西對找工作是否有幫助
其實這個就要看你的未來三年五年十年規劃。
假設你就是都在寫前端，你也覺得我要寫前端寫一輩子，那好像就可以繼續一直focus在前端。如果你擔心自己會丟飯碗，是不是要學點後端，其實也是可以學，可是學了以後，你打算學得多專精？後端的東西也是會一直更新，一直進步。可能Restful API 也可能不是，DB也有好多種DB, 後端語言也很多種，所以你是想要學個大概，還是是希望，後端也問題的時候，自己可以去看code也看得懂？
前一個專案，公司有一個前端，他就是因為自己做的ticket幾乎都會碰到後端，就乾脆把整個後端也寫一寫，就變成fullstack，雖然他主要還是算前端。但也因為是.NET 所以前端跟後端可能沒有太明顯的分界，至少我相信他本來就會寫.NET了，因為幾乎有一半以上的controller都是他寫的。
如果你是寫react SPA，就是跟後端完全分開，你就只要寫到send http request 那邊的話，那好像也不太需要去了解到後端的架構，就是大概知道後端的endpoint 長什麼樣子就好，他們需要提供的文件就是需要提供。
如果說你是怕以後失業，怕公司可能覺得請全端比較划算，那的確還是多學一點好，反正多學也是投資自己。還能順便展現自己的上進心以及學習能力。
以consultancy來說好了，感覺是什麼都要學，像是公司可能就會說，啊最近我們的客人都要求要會什麼什麼，那你就趕快學一下。當然公司也不是很壞心的就叫你要馬上學會，公司最近也是有開始提供一大堆Training 之類的，還給你錢讓你去考一些證照。
目前我使用的語言主要還是Javascript 和 C＃這樣，然後公司有希望我可以好好學學Java。其實也不是不會寫Java，如果有發漏我其他文章的話就知道，其實我最一開始學的時候，第一個語言就是Java。
在台大資訊系統訓練班的時候，我就上了Java和PHP的課程，為自己來英國念研究所做準備，一年的master course也都是Java 跟PHP為主，然後有用了一點Python這樣。可是工作以後就只有使用C＃和Javascript 而已，所以說，學校學了也不一定會用到。
很多東西都是工作以後才學的，然後Python是平常自己刷題的時候會用，因為覺得不錯用。
其他的話，我覺得雲端相關的東西滿實用的，像是AWS或Azure 或GCP 有機會的話是可以自己摸摸。我自己是滿幸運的在工作上一直都有用到雲端產品，主要是AWS，前一個專案有用Azure 這樣。
DB的話，就是SQL和NoSQL可以個學一個，應該就滿好用的了，目前最流行的應該就是PostgreSQL和MongoDB 。如果對於Graphic Database有興趣也可以稍微看一下像是Neo4J之類的吧！
前端框架的話，就是React, Angular, Vue.js選一個吧！學會一個以後再去學其他的也不難，這三個我是剛好工作上都有用到，我自己是覺得Vue和React應該是比較好上手的，入門門檻比較低，Angular就一定要寫Typescript.
後端框架的話，看你用什麼語言，Java就學spring boot，
C＃就是.NET，JS的話應該是Express，Python就Django，PHP就Laravel 。
Mobile的話我沒有寫過也不知道。
如果是平常想要補充知識的話，可以多念一些像是security 相關的東西，或者是Oauth那類的，也可以看一下架構之類的。像是Microservices, microfrontend, Domain Driven Development 這些概念性的東西。
也可以看一些像是Clean Code相關的書，怎樣重構原本的爛Code或者TDD相關的書。
反正前一篇文章就說了，這個職業就是要一直學，活到老學到老，如果打算做到老的話。
＃公司招募看的到底是這個人的什麼
其實每個公司應該都不太相同。有的公司就是要招募他們覺得最聰明的人，所以就是一直問你一些很難的東西。或者就是只要找那種名校出來的人，最好有什麼數學物理奧林匹亞的。
有些公司看的是你的個性，符不符合公司文化，或者同事喜不喜歡你之類的。
有些公司就是很缺人，看你能不能馬上上工之類的。能的話就馬上錄取你之類。但通常那個可能是很雷的缺，例如公司找人找很久都找不到，終於看到一線希望。然後為什麼找不到人，可能是薪水開的偏低，或者公司名聲不好，上Glassdoor就可以查看公司的評價。也可能是職缺本身很雷，例如看起來就是個打雜缺。或者是前人都做不久就離開，所以需要一直找人。
有些公司是看你寫的code 例如看你的code乾不乾淨，可能你寫出來的code都很乾淨，設計也很好，思路也很清晰，他們就會錄取你。
有些公司看的是你有沒有某些特定的經驗，例如公司開那個缺剛好就是要找有AWS經驗的人，所以可能就是會錄取他們覺得AWS經驗比較多的人。或者是剛好想找之前有做過Serverless架構的人，或者是有碰過Kubernetes的人，這個時候真的就是靠經驗了。
也有的公司就是，他們也懶得找人，HR給他們面試的第一個人就會錄取，這個完全靠運氣。這件事情真的發生在我第一間公司的另外一個Team，主管非常不喜歡面試人，也覺得我工作都沒時間還要面試。所以就是隨便問問之類的，然後就跟HR說好。
--------------------------------------
以上就是我目前經歷過以及別人分享給我的經驗。我覺得面試的話，運氣真的也是佔滿大的比例，尤其是遇到像第一間公司那種狀況的。
當然年輕的時候可能會比較急躁，也很擔心自己找不到工作，考量到的還有金錢跟公司名聲，所以學不學得到東西也可能是其次。
選offer的時候，也可能就是可以分析一下，自己想要的到底是什麼，是金錢，是做得開心，還是想要可以做的久（這個也要看公司可以活多久），除了看Glassdoor也可以上網看一下公司財報。
最近的疫情衝擊下，有很多新創或中小企業也開始裁員跟減薪，所以公司平常的財務狀況和經營方針也是很重要的。即使公司可能一直都有收入，也可能因為現金管理問題，導致沒有足夠現金需要裁員。
敏捷開發tdd 在 Re: [心得] 敏捷課程觀察心得- 看板Soft_Job - 批踢踢實業坊 的推薦與評價
感覺清明連假挺好的，發文跟看文的人都有比先前多一點。
除了掃掃墓，也要掃掃各種觀念的新仇舊恨 !?
改變一經啟動，最先遇到就是混亂。你一定也經歷過，
就是當你用了新工具、新程序，卻發現比以往還糟的時候，
有人會說：「要是把這些新玩意丟掉，或許能重拾秩序...」
你飽受學習曲線的折磨，並認為問題就出在改變上，這項評斷或許沒有錯，
至少在當時是對的，當時的你真的比以前還糟。
這就是為什麼人對改變的反應是如此情緒化的原因，放棄專精已久的做法，
再次變成初學者，真是令人洩氣與尷尬，沒有人喜歡掙扎的感覺，
更何況你知道用老方法可以做得更好。
很不幸，混亂是改變的必經之路，沒有捷徑。
Peopleware P. 260
※ 引述《YAYA6655 (YAYA)》之銘言：
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
: 就好像1995年，C++鋒頭上的時候，說C++難用的會被一堆腦粉抨擊，不外乎就是說，
: 不是C++難用，是你不會用。
: 這是不是跟太極拳很像？太極拳多強，打輸泰拳，腦粉會跟你說，不是太極沒用阿，
: 是你自己沒有把太極的精髓發揮出來。
: 到最後這根本就是信仰了。但時間會證明一切阿，C++就是產能低落，太極就是打不贏
: 綜合格鬥。
: 回到正題吧，有一段期間我們公司也導入設計模式，搞到每一個簡單的動作都要有
: USECASE，你能想像這是怎麼回事嗎？這就像建構式數學，明明簡單到可以9x5=45的東西，
: 他規定你要9+9+9+9+9。
: 工程師是人，不是白癡。每一個輸出入函示都要UNIT TEST？有些簡單到如同9x5的東西
: 你真的還要替他見一個UNIT TEST？單步追蹤一次就夠了吧，裡面程式碼沒幾行，還是
: 呼叫共用的函示庫，這能出錯叫做共業，根本不需要花時間在這種地方演戲。
: 後來我們導入設計模式大約一兩年後，大家就慢慢不了了之，很多狀況都是慢慢不了了
: 之的，沒有人會願意出來說，我們當初想法天真錯誤啥的，就一切盡在不言中了。
先說說對於整篇文章的看法，
過去我們的學習適教學者為權威，不管他教的好的，或教不好的都太深信不已。
在整個『國立編譯館』的洗腦框架與競試 KPI 下，
我們挺少反思知識的來源是否正確，或對自己是否有價值，該不該追求它。
離那個代年越遠，我們的思考才會越活絡，更加能對知識產生質疑。
由前輩的分享，可以看出在公司導入新觀念、新技術時，
所受到的不平無法抒發之處，這些東西必需有計劃的導入，
本質上得學習組織的活性要足夠，那並不是拿著『權力』大筆一揮，
宣示一下就能成功的事，而是由一連串的小變動，讓組織
(先想個小一點的，例如 3 ~ 5 人的 team) 適應保持變動。
累積足夠的活性與習慣接受新觀念並願意改善行為後，
才能有真正的大幅革新，例如替換工作方法、工作流程。
或是得有回饋機制產生正增強。
先來做點簡單的名詞或概念釋疑
: 以我20年的經驗來說，什麼敏捷，設計模式，很多都是脫褲子放屁。
: 更早期還有什麼OO方法論，部分人神鬼上身，什麼東西都要OO一下，連寫個九九乘法
: 表都要開一個 class ninenine。
就先從敏捷開始吧.
提到『敏捷』就得提與它相對，作為他『假想敵』的 waterfall。
實際上，他們並不是真正的對抗關係，以『定義良好』的系統，
並『完全符合使用者需求的 SD/SA 後』產生的規格書，
並寫了簡易的 reference implemenation (或若干組 POC)，
直接發包、大撤幣是一種相當有效率，而且相當直覺得軟體開發流程。
若上面的『前提』都能滿足，那專案管理與人力調整，
那就單純是程式的『生產線』順不順暢的問題。
是什麼東西，破壞了這些前提呢？軟體開發最終還是在實現需求，
但使用者也許不一定真的理解需求，特別是在若干次使用者訪談之後，
可能發生矛盾的需求，特別是東西做出了一個雛型後，將使用者由
「想像」拉回現實，使用者接著反應「這不是我要的」。
那麼我們還要繼續走完 waterfall 嗎？或是回頭 blame 當初的 SA/SD 嗎？
以商業角度來說，那都不適當，合約在走，違約日一天一天逼進，
不是做完領錢、逾期賠錢或是違約倒閉。
所以，自然地，不太應該在一開始就想著最初的規格是會走完的，
得設定小一點、合理的目標先達成它，
並週期性確認雙方認知是否還在同一個線上，但認知明顯不同
才能以較小的『成本』反應需求變更，以敏捷常用的單位就是 iteration
而後續相依需求的 iteration 也都不用再排入到工作內。
時時確認客戶的需要，適時反應改變，才能符合需求達到降低違約的風險的目標
後來發現，除了對客戶間的互動，開發人員之間也得多多互動。
每個人對於規格或需求的解讀不太一樣，或設想的前提假設也不同，
所以才會有週期性短短的會議，不管是時間預估或是反省會議，
都有機會透過其他人的角度來看事情，知道為什麼不同人估同一個工的時間不同
是他多想了，還是我少想了，或是他知道有哪些既有的 library 或演算能採用
以加快處理的速度。
PS. 由於篇幅有限，其中也很重要的 working software 就省略一下了
大致上，專案在開發初期頭幾個 iteration 就可以有完整的軟體能跑，
好處是客戶能玩到會動的東西，不會過度想像，它就像我們剛進入
新的遊戲，基本功能都能動，但有很多未開發的關卡，等實作到了才開放
再來，談談單元測試 (雖然在你腦中是設計模式)
在聊了敏捷後，看單元測試就特別有意思了。
對比儘可能直衝整個進度的 waterfall，
或幾個 iteration 釋出新版本的敏捷開發，
『單元』是僅測試一部分軟體的功能，而不是整個完整的軟體。
特別是在進入 OOP 的年代，物件與物件之間的界線更好區分了，
而那個界線，自然地可以成為單元測試的切入點，
若是非 OOP 語言也會有其他可以作為界線的部分，
讀者倒是不用太擔心是哪種類型的語言
原 PO 是停留在一組簡單的 unit test 要如何實作的引言部分
但還需要充實一下部分的觀念：
* unit test 測試粒度，至少以 OOP 來說，我們只測 public method
* 不管你喜歡 TDD 或 BDD 都蠻值得看一看的
* 怎麼樣的實作，讓 unit test 難以實現 (ex. singleton pattern)
與適當的工具知識的補充，像是
*. 單元測試常用的 library，怎麼方便建立 test fixture
*. 需要 mock/stub 時，哪些 library 可以輔助
*. mock/stub 成本太高，是否要改用整 e2e 測試
*. 建置持續性整合環境 (並考慮邁向持續性部署)
推薦閱讀：
《Growing Object-Oriented Software, Guided by Tests》
看著原 PO 的年資與對 OO 痛恨的感覺，可以理解並表示同情
因為在早些年代的 OO 概念，確實比較傾向『對應現實世界』的實作方式，
像是弄個 Car 類別，再給他 N 個輪子，給他喇叭之類的東西。
比較現代化的方法，其實很少這麼作，除非學習者只看了入門教材就放棄了
剛入門的人，確實需要較『具體』的解說，但在實際開發的情況，
我們並不會那麼做，千萬不要那麼做 (除非有相當好的理由)
常見的設計方向有 3 種：
1. 標準的 OOAD，就定義好各種 interface 與它們間的互動關係
(語言提供的標準 API 大致走這個路線)
2. 隱喻，採用隱喻或一組故事來設計，比較容易記憶，而且有趣味!?
3. 由 2. 為主，但基底包裝好的 Design Pattern.
簡單來說，我們要過 Design Pattern 學習時，
練習出的眼光試著將程式面對『變更』的節奏做『抽象化』的處理。
Design Pattern 實作可能會讓程式變得比原長，但這代價挺低廉的。
Design Pattern 的精華並不在 Pattern，而是在每章開頭的 Intention
雖然意圖可能不儘相同，但目標如何『動態』地面對改變與擴充。
這裡的『動態』是指 Runtime 為主 (自以為)，
即使在這個 source code 很好取得的年代，
我們並不希望直接修改其他人的程式碼，
或是期望原本的專案，一開始的需求固定處理某些情境就行，
但後來得動態擴充它，都能由 Design Pattern 找到靈感
雖然不求有一模一樣的情境，但我們回頭推敲，
能簡單地設計一下，達到 Open-Closed Principle 的目標
我們該學的除了具體的 "Pattern"，同時是訓練識別 Intention 的眼光
同樣的理由，會出現在 refactoring 的學習上，refactoring 技法固然重要
但培養出快速嗅出 bad smell 的直覺。
====================================================================
回到最開頭講的，脫離了過去教育方式的框架後，
我們有機會『越過』第一次授與知識的源頭，
例如：像是認同原 PO 想法的人且初次知道這些『名詞』
不能只是停留在各自的同溫層取暖，也不能全然相信我單方面的解說。
要略過我們，找找原文書看看那些知識如何使用。
特別在這個資訊多元，價值多元的時代，
更應該鼓勵一些過去受過不好經驗的人，正視一下那些荒謬的經歷
學不學它都沒關係，但至少讓自己由惡夢中醒來。
同時，也該接納不是所有人都能學習的會那些被鼓勵學習的技術，
以我個人來說，對於 agile 沒特別的好惡，並鼓勵『自助餐』
開發者，或同事，只要能做出他能有最大貢獻的『選配』就行了。
我個人『進度至上』主義的，只要求是要有足夠的生產力。
code 寫得好不好看，有沒有 OO 什的，倒不那麼重要，
反正重構技能與砍掉重練技能點滿了，
等那部分要賺錢了、得能 scale out 時，再整理就是。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.231.233.73
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1523003605.A.7EF.html
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:35:21
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:35:51
https://www.books.com.tw/products/0010644283
路過，補個書
※ 編輯: qrtt1 (36.231.233.73), 04/06/2018 16:48:12
... <看更多>