2021年1月10日 星期日

美國科技公司面試技巧(初中階)

好久沒有更新文章了,這幾年終於從恐怖環境生還並且跳槽了兩次進入FAANG了!

我也幫忙了朋友準備面試,也成功讓朋友從非Software Engineer成功跳槽進入了FAANG成為軟體工程師,可見我的準備方式和心得還是有些用處的XD

決定在此做個紀錄,等到我下一次跳槽時能複習這些技巧

PS: 標題寫,初中階,意思是這篇心得可以適用於想找初階 + 中階工程師職位的人,資深工程師以上比較強調的System Design等我更有經驗時會再分享!

背景

為了增加可靠度,大家總是會加入背景來佐證。我這兩年跳槽了兩次,從金融科技小公司跳到FAANG,並且也分享了心得並且幫忙朋友準備,也成功讓朋友跳到FAANG了,可見此篇文章還是有點用處的!

網路上大部分分享的面試經驗分享,大多只講到該怎麼準備,或一些High Level Concept,我自己看起來覺得對於了解面試流程是有幫助的,但卻沒有對於真的在面試時的答題技巧有更多的著墨。所以以下心得會比較著重在我覺得有用的面試技巧。

履歷

履歷是很重要的一環,代表你給人的第一印象。履歷上要能適度展現你過去所做過的項目以及經驗,以此來吸引人資或獵頭來給你面試機會。

基本原則就是,關鍵字,履歷上要有各種你想要別人能搜尋到你的關鍵字,例如Java, Python, 或k8s之類技術。

第二就是經歷上的條列式項目,不能單純寫我用了A做出了B,而是要以更高的角度來闡述,這樣才會看起來更厲害更漂亮 (像是我用了A做出了B幫助公司解決了C難題)

第三就是可以適度的誇大一點自己做過的東西,這個比較像是黑暗兵法,使用他的話算是一把雙面刃,正確使用方法是,你必須要完全熟悉你寫在履歷上的東西,而不是隨意誇大,這樣很容易被問倒並且在面試裡給出不佳印象!

刷題

美國科技公司面試有制式的流程,各大公司大同小異,都是遵循以下流程

HR Phone call, OA (Online Assessment), Phone interview, Onsite interview

OA之後的流程一定都會考程式題,所以刷題準備算是最容易的方法了!

網路上流傳的,要刷幾百題才能上FAANG呢?

我個人認為是,重質不重量,每個人情況各不相同 (我自己刷了接近200題就開始面試了XD)

刷題主要是要刷出解題的感覺和提供未知題目的思路!

各種常見類型的題目一定要做過並且了解解法,我推薦的刷題法是:


每一題都要自己想並做過一遍,起碼寫出一個暴力解,實在想不出來可以看解答或討論,了解別人的解法後,一定要自己再做過一遍!


這樣子假如遇到沒見過的題目時也不會慌張,因為再差也在有辦法給出暴力解了!

然後很多文章下面討論過,Hard 題不重要,DP (Dynamic Programming) 遇到就算了。我個人觀點是還是很重要! 很多一線公司多少還是會遇到Hard題的,DP是肯定會出的!

所以高頻Hard還是要刷過,DP也要練習過才是正確準備方式!

面試技巧

電話面試和Onsite面試通常都會考程式題,假如前面刷題部分都準備差不多了,那接下來就是要加強面試的溝通技巧了!

基本原則就是,面試體驗很重要,不管是對面試者或面試官! (這就是為什麼英文好的人比較好拿到Offer)

看人寫Code是一件很痛苦的事情,面試官卻還要看懂你在寫什麼就更痛苦了! 所以如何幫助面試官好好的理解你在幹什麼是一件很重要的事情!

一定要練習邊寫邊講自己在幹嘛! 

這個很重要,可以給面試官良好的面試體驗之外,也是訓練自己Analytic Thinking的重要訓練,可以練習了解自己所打出的每一行Code之外,還可以有邏輯有條理地跟別人解釋自己的Code。

遇到困難時,向面試官尋求幫助!

當你想不出來時,是完全可以尋求提示的! 所以如何清楚的表達自己想要怎麼做,但是遇到了什麼樣困難的能力是很重要的! 可以找朋友模擬面試來訓練這個情況!

無法在短時間內想出最佳解時,先給暴力解!

有答案總比沒答案好,可以跟面試官解釋自己目前只想到這種方法,要我先寫嗎,還是可以給些提示嗎?

最後就是要盡量展現友善的態度 (傻笑) 就可以完美的給面試官一個良好的體驗。最後就算你沒有給出最佳解,面試官也會對你的印象很好,有時可能就放你一馬啦!

系統設計 (System Design)

基本版的 grokking the coding interview 我很推薦,他給了基本Sytem Design面試的思路外也算是考古題,有很多題目都不出課程列出的範例,可以照著同樣思路去做!

一開始看不太懂沒關係,系統設計相關的準備就像是看Paper,一遍一遍的看最後就會有點感覺了!

除了以上課程外,我覺得Amazon System Design Preparation 的youtube影片也很有幫助,算是面試技巧的一部分!

先從High Level 三個方框開始,有淺入深,由自己擅長的領域開始 Dive Deep然後再看面試官想深入問哪個部分。

延伸閱讀的部分就是那些其他經驗分享也有提到的各大公司Tech Talk了,閒暇時間沒事的話可以看一下。


2018年6月27日 星期三

系統的維護與監控

好久沒發文就來分享一下最近在弄得東西覺得比較有趣了

最近在幫公司維護系統時最主要發生的問題就是


  1. 老闆很煩,整天問奇怪的數據分析,例如我們這個月有多少使用者用了這個功能,我們最近有多少人有High Memory, High CPU, 大概是多少,平均是多少
  2. 系統出錯只好拿log看看發生什麼事情
  3. 系統出錯了不知道
對工程師來說,後面兩點可能才是我們在意的

但對上層來說,第一點才是他們最愛問的

假如是平常寫的數據蒐集程式碼很難完美應付老闆整天變來變去的奇怪問題

每多一個新的數據,就必須要改code, compile, deploy 也是蠻麻煩的

再來就是系統也是出錯的時候才可能會送出通知,不清楚是什麼時候出錯的

要知道的話就必須要去拿Log來看看,又花費了寶貴時間在分析訊息

這時候有一個最近比較紅的東西就可以幫助了

所謂的 Time Series Database,專們存取時間性資料的資料庫

有了這個候我們就可以把各種單純的系統資訊都丟進去

例如:
CPU Usage, Memory, User Event, Request Hits
或是其他功能性相關的數據

資料庫就會幫你蒐集然後有提供很好的視覺界面和Query可以做出各種用途的Dashboard











像是上圖那樣,且可以為不同職位的人做出不同的圖出來



這種系統監控的Project可能平常在大公司工作的除非剛好碰到

要不然應該也沒什麼機會需要用到

而系統太小的話可能也還不用特別做一套監控框架出來

算是最近做的比較有趣一點的東西了吧


其他有幫助的還有如何有效率的運用系統Log

原始方法是要叫個Developer來看

好一點的可能有特別的爬檔程式來抓關鍵字

現在流行的是一種Machine Learning + Big Data的 Stack

ElasticSearch

我最近也要開始嘗試用用看,其實還蠻有趣的

他可以直接把原始檔案直接送到他的資料庫裏面

然後就可以用它做快速的搜尋和建立Index

然後也可以基於這些搜尋結果和Index也做出一個好看的Dashboard

算是整天看Log 苦不堪言的工程師小小的福音吧!




2018年4月29日 星期日

開發技術的選擇

由於公司人數少,對於新Project或是怎麼改進系統

我最近也可以參與討論和做決定了

最近我們討論最熱烈的就是

要自幹還是用現有的技術來解決問題?

吵來吵去最後的決定通常還是要回歸現實問題

哪一個決定可以帶來最多的Business Value?



不過撇開商業上的考量 (通常也不是我們工程師該考慮的問題XD)

到底哪一個決定好呢?



自己開發一個系統或是技術

好處就是最能符合自己的需要

使用上也符合公司的開發文化

可能上線的時間會縮短許多 (沒有了研究和整合的時間)

但壞處就是需要自己人去維護他

相當於多了一個需要工程師維護與觀察的系統 (工作量增加...)

還有就是可能開發的不夠彈性,功能只侷限在現有的問題

還有最重要的是,以後跳槽了別的公司沒有這項技術XD

假如其他公司都用某個熱門的開源技術,那就對職業發展有些不良影響


所以我個人覺得假如可以的話,現實情況允許的話

還是盡量選擇現有的開源技術或是熱門技術來解決問題才好

這樣才可以把資源都妥善運用在公司擅長的業務上

而不用花精力去維護多出來的一個系統

(我們有個笑話就是開發了一個Support Tool後我們還要再對這個Support Tool做Support Tool)

但當然假如公司夠大人手充足

願意花長時間好好規畫設計出下一個熱門技術

那當然還是自己幹一個比較好囉!


但假如是小公司或是新創公司

前期假如都是為了趕快趕期限

而使用了一堆自幹出來的技術

那最好要有精美詳細的Wiki或文件

要不然當員工來來去去

要重新訓練一個新人時

就會感到困擾了....


2018年4月11日 星期三

團隊與管理

今年開始工作上的內容也變了

很幸運被公司升為了小組長也開始帶人了

這可能就是在小公司工作與大公司工作的差別了

人力不足很容易就有貢獻可以升上去(但薪水沒怎麼變就是了...)



總而言之開始帶人後就發現這真不是一個容易的事情

好像也很少聽到別人分享這方面的經驗

我們工程師,對岸俗稱碼農,唯一會的事情就是寫Code了

叫我們面對2D人物還應對自如

當角色升維變成3D就開始很難溝通了....

尤其用英語更是很難表達出自己的意思啊!



當開始管理一個團隊時候,每一個人的能力各不相同

所以妥善分配事情讓團隊有效率的運作是不容易的事情

(現在真的自己寫Code的時候比以前少了87%了)

會遇到的人大概分成幾種


  1. 會思考的人 (Thinker)

    這種人就是會好好的想自己的工作該怎麼樣達成

    且會考慮效能以及未來擴充性

    假如團隊裡都是這種人應該非常強大

    可以迅速完成複雜的工作

    但通常這種人就是會比較不喜歡做重複的事情

    可惜一個Project 可能複雜的事情或是架構方面只占少數

    多的是實作以及無聊的工作

    所以要給這種人多一點能發揮強大實力的事情
  2. 一個指令一個動作的人 (Doer)

    這種人就是你叫他做什麼,他就做什麼

    你沒叫他做什麼,他就什麼都沒做

    所以假如你都把事情規劃好讓這位仁兄去做

    你就可以妥善的使用他了

    但期待你跟他解釋一個虛擬概念讓他找出解決方法就太為難人家了
  3. 不知道在想什麼的人 (Mediocre)

    這種人就很神秘了,你會不知道他到底來公司是幹什麼

    今天你跟他交代請完成A,過一陣子他會做一個B給你

    你覺得是基本的事情他拼命卡關問你

    你覺得是要詢問的事情他自己靈機一動然後做一個垃圾給你

    或是可能這個人常常不在狀況內到處打混摸魚

    且可能還會自我感覺良好

理論上大家的目標應該都是要成為第一類人

第一種人很聰明可以完成複雜的事情

這種工程師在有正常升遷管道的公司應該可以爬得很快

但事實上大部分的人應該都是會屬於第二類或第三類的人

(就算在大公司強者如雲的地方應該也是這樣
或是他們的第二類人在其他地方就已經是強者了)



這裡就要提到本篇主題,我老闆跟我分享的管理哲學

他覺得你的團隊不可避免的一定會是混雜的狀況

該如何好好運用所有人才是決定你的管理能力好壞的點

並且一個團隊的好壞

並不是取決於最強的那個人有多強

而是最弱的那個人有多弱




我覺得還蠻有啟發性的

畢竟一個Project 複雜的事情其實只要少部分的人去完成就好了

例如設計程式架構,可擴充性

或是說正夯的AI 所用的 Algorithm, Model

也是少部分的 PHD 去搞就好了

剩下的人就是要完成實作或是

Monitoring Tool, Clean Data,Saving or Parsing Data 之類的事情

所以假如團隊裡一直有一個人狂拖後腿

無法好好完成真正實作以及維護系統的工具

那整體效率可定是大幅降低了

2018年3月8日 星期四

工作之餘還能做什麼

很羨慕那些興趣就是寫程式的人

閒暇時間寫個程式做個side project當作休閒的人

我覺得才有可能成為所謂的技術大神


我反而下班回家就懶了

不如打打魔物獵人或玩LOL

想了一些點子想要作但又覺得有點複雜麻煩

或是進度非常緩慢


最近回台跟朋友聊天

他建議我沒事幹也是可以經營部落格之類的

他起碼會友情幫我按讚

聽到這句話感覺就熱血沸騰了....大概一天


不過想想也是繼續這樣魯下去好像也無法改變什麼

之後希望能真的稍為打起精神做自己的神祕project

順便記錄下來

雖然沒什麼人看

但可以自嗨也是好的

學校申請與準備

關於學校申請與準備,我以前太懶了所以準備得有點遭

幸好最後還能申請到學校....

最近剛好有參與一些分享活動發現了一些有趣得現象


老學長姊的建議通常都是:


  1. 在校成績一點都不重要
  2. 要看你興趣在哪直接去連絡教授,表達你的熱情
這些建議老實說是對的,但假如你不是想申請PHD

這些建議能起的作用非常小

所以參考了我上次與我朋友的討論,我們覺得應該要往這方面考量

(一) 假如你還是大一大二生

恭喜你,你還有很多時間可以好好地衝高GPA

在校成績真的非常重要,很多學校門檻都是要有個基本GPA

就算是PHD,很多教授還設標準要3.8以上

衝高GPA同時,也有很多時間可以好好的準備英文

把托福考高分也是很重要的

假如還有空的話看看能不能死纏爛打進入某個教授的實驗室

最好有辦法掛名一個論文成功發表出去

那申請學校的資料就很強大了

(二) 假如你已經快畢業了

GPA對你來說已經是定數了,人生不像遊戲無法重來

這時還是好好準備英文吧,考個托福破百接近滿分是非常有用的

英文這種東西還是要常講常看才能進步的

為了衝高托福成績,還是去補個習吧

(三) 準備好申請資料

基本上申請資料應該要相輔相成

推薦信的重點和讀書計畫的重點要能一致比較好

最近幫人看了申請學校的準備資料

有一點關於英文寫作的點可以講一下

在推銷自己時不要過於沒自信,讀書計畫裡面最好描寫得有自信一點

不要單純地用台灣人自謙的語氣直翻成英文

看起來非常的奇怪

(四) 聯絡教授

基本上我覺得你假如不是要寫論文或是要申請PHD

這個步驟應該根本沒用,但是人生會發生什麼很難說

多試一招也不會影響什麼

說不定剛好給你寄到評審委員之一他很欣賞你的積極也說不定呢


2017年4月21日 星期五

美國軟體工程師的日常

今天看到有科技報導介紹台灣Fintech的新聞

講到台新銀行的新App Richart

App好不好用我是不太清楚

畢竟網路銀行轉帳在美國已經很成熟了

中國也是網路轉帳算是日常生活了

台灣因為某些原因,現在才開始發展

希望網路銀行相關技術也能在台灣成熟普及

不過主要這篇報導讓我驚訝的是

裡面特別強調了他們是如何成功轉型並且開發出這個App

他們引入了軟體開發流程Agile (敏捷開發流程)

我本來以為這已經是很常見的開發模式了



1. Agile

以我公司來說也算是Fintech (但不是網路銀行這種)

我們也是引用了Agile開發

但以我們人少小公司來說

其實並不是完全遵循所有精神

以我們來說並沒有開一些公司常做的會議

像是什麼Backlog 清理,Sprint 的增減會議



平常流程大概是這樣

每周一早上,組長會跟他所有組員follow up他們進度以及這周需要完成事項

組長會把這些事項根據是新功能或是Bug修正做成Task 和 Issue分配給你

接下來就只要把事情做完了,沒有問題就沒事了

而我們公司策略的關係,公司每個禮拜都會推出一個Release

每天變動得很大,所以我們主要是以一個Release作單位

每個禮拜一組長們都會去開Release會議

而到周五會有Group sign off的會議

所有對這次Release有貢獻的人都會參與



至於當初這些Sprint跟Spec是怎麼來的

我們公司跟客戶有很密切的聯繫

公司主力產品每天都會有客戶來跟我們說希望改進什麼會新增什麼

組長們評估後覺得可行好用就會看難度加入這周或下周Release裡


2. 工作時數

不得不說美國科技公司大多工時大勝台灣

我上班都是朝8晚5,但通常5點半之後才會離開

但我們公司不像其他公司,可以隨意幾點到都好

畢竟跟行業有關,客戶大多是華爾街人士

他們一大早就上班了,假如我們還姍姍來遲9點10點才進公司

在那之前系統出問題就沒人幫忙了


3. 文化

平常與主管相處我覺得見仁見智,很多時候真的看你組長人好不好

幸運的是我的組長人很好

平常沒事時都會跟組員講垃圾話 (當然你要回話他才要跟你講)

有聽說朋友的主管很喜歡在家工作

我朋友每個禮拜都有一兩天在家工作也是很爽

但不得不說溝通對於一個軟體工程師來說真的很重要

開發大型系統來說已經非常難以單打獨鬥了

要大家一起合作溝通真的是很重要的一環

平常工作遇到問題,我都會馬上提出跟主管同事討論

他們通常都比較有經驗可以馬上提出良好建議給你

要是因為卡關而自己摸索許久反而會拖類工作效率

是不太建議的


4. 表現

美國科技公司大多你勇於表現發表看法大家不會因為你資淺而不聽你的

在適當時候表現自己的能力有助於主管與你討論規畫你的發展

當交給你的任務做得好又快

自然會被主管發現也會反映在你未來薪水上了XD

以我來說我會在自己能力所及(deadline之前)

盡量思考如何把我程式碼寫得更好懂

邏輯更清晰,更好維護,方便擴充

一方面當練功,也會因為程式穩定而被重視

因為我們小公司來說,我的工作自由度很高

交給我做的都是一個大元件

一個新功能服務來說牽扯到Backend Frontend

我通常都是負責整個Backend的開法

整體設計流程架構都可以自由發揮

算是小公司的福利吧XD