Published on

轉職前端工程師的海外求職 (德荷英日新) 心得 II — 找工作與面試篇

目錄

嗨,相信你會點入這篇文章,可能是因為你看到 coding bootcamp 的標題,也可能是有海外求職的打算。在往下讀之前請先讓我介紹自己,以及說說這系列心得會談先什麼。假如你有覺得符合你的需求再往下讀,可能比較不會浪費時間 (因為文章會有點長 XD)。

先說說我的背景,我是個平凡的台灣人,人生前 24 年沒碰過程式,兩年前開始透過線上課程 (YouTube & Udemy) 自學程式。去年報名了線上 Alpha Camp 的實戰課程 (Alpha Camp 是一個線上 coding bootcamp,詳見此),後來轉職軟體業,目前是有約一年多開發經驗的前端工程師。

前陣子因為家庭規劃要搬去歐洲,所以我也順著找了在歐洲的軟體工程師工作,最後有順利拿到一些工作機會。由於過去在網路社群中 (Medium 與 PTT 等地方),獲得很多前人分享的寶貴經驗,因此希望透過接下來兩篇文章回饋社群。

第一篇心得《轉職前端工程師的海外求職 (德荷英日新) 心得 I — coding bootcamp 之後的能力養成篇》會是談 coding bootcamp 後的能力養成。主要是網路上比較多分享從非本科轉成工程師,但比較少分享轉職成功後的持續養成 (我的經驗來說,轉職後反而才是挑戰的開始)。

而這一篇我會分享我獲得各國面試機會的過程,以及線上面試各國前端軟體工程師的實際經驗 (包含被問到的問題)。雖然我面試的公司基本上沒有簽面試的 NDA,但為了必免麻煩,我不會直接寫公司名稱,但會有足夠的資訊讓大家推敲 XD 另外就是我會分區域寫,所以假如你只對某個區域的工作機會感興趣,可以直接跳去那個段落。

先在最前面聲明,我是轉職且開發年資不深,所以這篇文可能適合的,會是前端工作經驗 0–2 年這個區間的資淺工程師。因為資深工程師面試會被問到的問題跟資淺工程師應該不太一樣,所以假如是資深工程師,這篇可能對你會沒太大幫助 (除非你想從面試官的角度,參考國外面試官會問哪些問題)。

另外,因為我面試的公司數量也沒有真的很多,所以可以看成僅是一個資料點能參照。畢竟海外求職方式百百種,我雖然順利拿到機會,但也僅是其中一種。推薦大家多看幾篇不同經驗,然後也可以上 Glassdoor 多爬爬別人的評論、面試經驗文,會對全貌有更多了解。

最後,雖然這篇心得是用中文寫,但我各國加起來總共面了快十間公司,不論德國、荷蘭、日本、新加坡,以及一間在台美商,全都是用英文進行。

如何獲得歐洲區的機會

地緣與簽證的原因,台灣人要拿到新加坡與日本的機會相對容易,網路上也有比較多的經驗分享,大家爬個文就容易找到 (我下面分享該兩國的面試經驗時也會簡易提到我如何獲得面試機會),這邊主要聚焦在歐洲區的西歐。假如不排斥西歐以外的地方,網路上的資訊看起來,東歐與北歐也是很缺人;但我因為個人偏好所以主要聚焦在西歐。

如這篇的前輩提到的,歐洲區現在鬧軟體人才荒;這個現象可以看到包含荷蘭有祭出 30% ruling (外國人前五年的減稅方案),以及德國在 IT 產業拿到藍卡的門檻比較低等政策,可以看到各國都透過國家策略來吸引國際軟體人才。

因為我自己會的外文只有英文,所以鎖定只會英文也能工作與生存的歐洲地區,加上一些個人偏好的考量下,將範圍限縮到愛爾蘭的都柏林、英國的倫敦、荷蘭的阿姆斯特丹,以及德國的柏林。在鎖定完這些國家後,我基本上按照這篇前輩分享的方式 (這篇是我爬完超多文章後,覺得幫助最多的一篇,感謝原作者大大!),改了自己的 LinkedIn 有興趣的工作地點,以及開始加一些歐洲的獵人頭與人資,同時開始投履歷。

必須說,假如你已經在軟體業有 3 年以上經驗,只要英文履歷寫得不差,基本上要獲得面試機會不是難題。但假如是跟我一樣,是透過 bootcamp 轉職,且只有一年開發經驗,可能就要做好多數會收到罐頭訊息的狀況。很多罐頭信都回說他們想找更資深的人,但礙於我開發年資不足,就只能認命,並專注在願意給我機會的公司。

至於怎麼寫好一個軟體工程師的履歷呢? 在眾多資源中,我個人最推薦 Rahul Pandey 的 YouTube 頻道。他是 Facebook 的 Staff Engineer,同時兼任史丹佛大學的 CS 課程講師,負責教 Android 開發。雖然頻道多數內容是 Android 開發,但同時也有從如何求職、如何刷題,到如何寫履歷 (例如這個影片實際比較了普通的履歷與好的履歷,很有幫助),以及實際成為工程師後如何精進的各類分享。只能說是個非常佛心的人呀,大推!

我基本就照著上面那位台灣前輩、Rahul Pandey 的方法,讓我在一個月內陸續拿到柏林與阿姆斯特丹的面試機會。同時因為我 LinkedIn 求職地點也設定了新加坡與日本,可能因為這兩地也很缺軟體人才,所以即使我沒主動求職,也陸續不少獵頭與人資找上來。因為想說不浪費練習面試的機會,因此雖然沒有真的想去新加坡與日本,但還是面了幾間公司。

薪資與福利

在往下看實際面試經驗前,可能有人會好奇在歐洲的公司待遇如何。比較大的公司,基本上都可以上 levels.fyi 或是 Glassdoor 看。身為僅有一年左右全職開發經驗的轉職平凡人,我自然沒有面試像 FAANG 這類大廠。不過即使是一般的公司,我最後有拿到 offer 的荷蘭與德國的公司,薪水部分是每年六萬歐元上下 (約臺幣兩百萬上下),給薪假則是每年 26–28 天不等。然後荷蘭公司有提供高技術移民簽證,德國公司則是協助歐盟藍卡的申請。

這樣的薪資與福利在歐洲能過什麼樣的生活,對比起臺灣又如何,在網路上有蠻多文章討論,這邊就不多談,純粹提供一個資料點給大家參考~

歐洲區面試談

先說其實我沒有真的面試英國的公司。最主要是我已經談妥也簽約新的工作後,才拿到英國的面試機會,所以後來沒有真的面試。有趣的是,上面說我沒面試 FAANG 這類大廠,但我有拿到的兩個英國面試機會,其中一個是 FAANG 當中的亞麻 XDD

不過因為已經簽完新工作的約,加上我先前有在新加坡跟日本的非 FAANG 大廠分別在資料結構演算法,以及系統設計被電的經驗。評估下來我覺得自己可能要再蹲個一年多準備,以及我相信我目前人在亞洲都拿得到面試機會,未來人直接搬去歐洲,應該不擔心沒機會。因此這邊的面試談主要只有荷蘭與德國的。不過上面提到的獲得面試的方法,看來也同樣適用於英國。

我這次經驗下來,覺得要申請歐洲公司可能需要多一點耐心 (特別是我是八月開始申請,夏季特別多人去放假)。因為歐洲的勞動法規執行嚴格,員工在放假時就真的在放假,換句話說面試流程被拉很長,可能是因為員工在休假。舉例來說,荷蘭的 P 公司,我一面完後,人資來信說要幫我安排下個階段,同時 cc 了一位該人資的同事,說因為她接下來要休兩週的假,所以會轉給該同事接手。第二階段是一個回家作業,我寫完之後寄給接手的人資,她說會幫我轉給工程團隊作審核;然後我一等過了兩週,想說怎麼都沒收到回覆,於是寄信去問接手的人資,結果收到自動回覆信件,原來該接手的人資也去放假了。然後在她休假完後,才進一步收到回覆,這樣輾轉就過了快三週才進到下一輪 orz…。

另一間荷蘭 G 新創 (LinkedIn 上寫 20–50 人規模的),在我二面結束後,寄信來說想邀我進到三面,但因為現在我申請的那個團隊的工程師都放假去了,所以現在很難安排到面試,請我再耐心等候……。是直到兩週後才又被聯繫安排面試。我當時心裡想說新創不是通常會步調比較快、比較拼嗎? 沒想到荷蘭連新創都很讓員工生活與工作很平衡,覺得這挺好的。

歐洲這樣的慢步調,對申請者來說可能煎熬,但換個角度想,歐洲工作真的是讓人更有生活,員工也是休假排好排滿。從這觀點來看,歐洲真是頗吸引人的。總之,假如在申請時,等一段時間都沒收到回覆,不要放棄希望,因為很可能是人資或工程團隊在休假 XD

在實際面試上,歐洲公司跟我在台灣的經驗沒有差很多,主要分成出作業 (take-home assignment) 跟直接考資料結構演算法類的公司。可能因為我不是面試大廠,所以僅有一間是考線上直接白板題,其他都是出作業類。所以假如你跟我一樣會是以中小型公司或新創為主,可能多加強前端實作能力,會比較有幫助;但假如是要衝大廠的人,專注在刷題會比較有效益。

出作業類的公司

我的第一個作業類別的面試,是荷蘭的 P 公司。該公司是在做生鮮電商的,因為強調永續,在我申請的期間,正好獲得蓋茲基金會 6 億歐元的 D 輪領投。可能因為拿到新一輪募資,所以大舉招人,成為我最早獲得面試機會的公司 (雖說後來荷蘭 P 公司的員工休假都休好休滿,讓流程拉得很長…)。

前面第一輪是先跟人資聊聊,問的問題不出為什麼想換工作、為什麼想來荷蘭 (歐洲),此外也問了一些過去工作經驗的問題,都是網路上常見的那種。人資聊完後,就被邀請進到技術審核關卡,第一關是先有一個簡單的 take-home assignment,寫完後會跟工程團隊討論我寫的程式碼;說有過的話才會有 virtual onsite。

先說結論,我在技術審核後沒有通過,所以沒有進到他們的 virtual onsite。但我必須說,申請荷蘭 P 公司的經驗讓我大徹大悟,也讓我後續在寫各類 take-home assignment 時特別認真,在思考架構、選擇的工具等等,都會準備深入的理由。甚至之後的 take-home assignment 我還都把測試補上,因為被 P 公司說假如有寫測試會更好;在那之前我本來想說不過是個作業,沒特別想要寫測試,但殊不知這點也被拿出來點評。

幾個在這關卡被挑戰的問題

  • 某個東西為何用這技術? 為何寫法是這樣? 為什麼不選其它方式等等?
  • 為什麼這個元件這樣設計? 為什麼這元件做這麼多事? 這樣不會很難重複利用、測試嗎?
  • 為什麼這個元件這樣命名? 為什麼這個函式這樣命名?
  • 為何 data model 這樣設計? 這樣不會有多餘的東西嗎?

總之本來只想說快速寫完這個作業,寫出來功能都能動就快速交出去,但現實是,他們不只想要能寫出功能的人,而是要能寫出無暇程式碼、能夠運用設計模式到程式中的人。後來想想也很合理,假如作業 + 針對作業的技術討論,是主要篩選方式,那當然要把畢生所熟知的軟體設計原則都用上,才能更有助於通過這項考核。

我很感謝荷蘭 P 公司是我作業類別的第一間,雖然流程拖很久,被狠狠地挑戰一番後最後也沒錄取,但正是因為這個經驗,讓我後來大徹大悟。一般來說 3–5 小時就能寫完的小作業,我會搞十多小時才弄完,並且把荷蘭 P 公司挑戰我的所有問題,都拿來問自己一遍,然後有覺得不夠好的地方就重構。也因為這樣,後來的作業考核都有通過,甚至被後來有拿到 offer 的德國 S 公司說作業寫得很不錯 (殊不知這是前面先被洗過臉後發憤圖強的結果 XDD)。

考演算法類的公司

上面有提到,我只有一間歐洲的公司有考白板題,是荷蘭 G 新創。面試總共有四輪,第一輪是跟一般人資關類似,就是問出國動機、過去的工作經驗這類的。第二輪則是兩個工程師加上一個產品經理,線上三對一,大約一個半小時。

這一關前面前面由產品經理主導,問以下類別的問題:

  • 過去跑敏捷的經驗、團隊協作經驗 (例如跟產品經理、設計師的協作)
  • 過去開發經驗中,有遇到什麼特別的難題? 如何應對?
  • 如果遇到共事的人對你的表現不滿意,並直接來跟你說時,你會怎麼應對?
  • 假如在開發時仰賴第三方供應商,但他們的更新還沒推出,這時導致你準備要開發的項目被卡住,你會怎麼做?

後面換到工程師提問時,才有比較技術面的問題

React 相關的問題,印象深刻的問題包含:

  • 為什麼要用 React? 比起 Vanilla JavaScript,React 有哪些特點?
  • 解釋 React 中的 higher-order component,過去實際有用過哪些 HOC?
  • React 有哪些常見會造成效能的問題? 要怎麼解決?
  • 有用個 React profiler 嗎? 可以分享一下使用的經驗? 如何靠 profiler 找問題?

Redux 相關的問題,印象深刻的問題包含:

  • 解釋 Redux 用途
  • 解釋 pure function,以及 reducer 為什麼要是 pure function?
  • Redux Thunk vs. Redux Saga 的差別、分析兩者分別適合什麼情境?

另外還有問了 Git 的問題,但就比較是快問快答

  • 問了 git cherry-pick 要怎麼用?
  • 還有 rebase 與 merge 的差別與分別適用情境為何?

第三關則是考白板題,也是一個半小時,先請我自我介紹,然後問了我過去專案經驗相關的問題,接著就是三題白板題。前面兩題就是比較簡單的,第一題是給一個字串,然後寫一個函式,回傳該字串當中有幾個母音;這題只要有注意一下大小寫的處理,基本上是 LeetCode Easy 的題目。第二題則是常見的 LeetCode 412 Fizz Buzz 的變形,只要能善用 modulo operator 基本就能解出來,也是 LeetCode Easy。而第三題則是比較難一點,是需要用我上一篇有提到的 Floyd’s cycle detection algorithm 來解的題目,算是 LeetCode Medium,不過假如熟悉該演算法的邏輯,基本上這題也不太是問題。

最後一輪則是再跟 CTO 面,但這邊反而沒有技術相關,問得更多是了解我這個人,了解我對生涯發展的規劃與想像;同時讓我問問題。基本上有點像是聊天一般地結束這個關卡。

歐洲區小結

如上面提到,我前面太小看作業關卡,假如遇到這類型的關卡,絕對不能只是寫出來能動就好;盡可能把畢生學到的軟體設計原則都用上,把程式碼寫得夠乾淨,會是能否進到下一階段的關鍵。而白板題、React、JavaScript 的問題則跟其他地方一樣,就是多練習題目準沒錯。至於人資類的問題,就是練習好英語自我介紹、海外求職動機、專案經驗介紹、團隊協作經驗介紹;然後多準備一些問題,因為幾乎每一關最後都有一個環節是讓申請者提問。

這邊特別推薦 Tech Interview Handbook (是由一位 Facebook Staff Engineer 彙整出來的寶典,他也是著名的 LeetCode Blind 75 的作者),裡面的 Behavioral Round 的問題,以及 Questions to ask 的問題,對我在準備時幫助很多!

新加坡面試談

最開始我其實沒考慮新加坡,最主要是因為我是很怕熱的人,住台灣時覺得夏天最難受,因此不敢想像搬去新加坡。不過可能因為我把 LinkedIn 求職地點之一設定成新加坡,也陸續收到一些面試邀約,其中包含新加坡最大的電商 S 購物等公司。

S 購物對我來說是很有啟發性的一次面試,跟前面提到的荷蘭 P 新創一樣有啟發性,但方向不太一樣。若說荷蘭 P 新創讓我知道作業要好好寫,那麼 S 購物就是讓我知道我對 JavaScript 這門語言、對 React 的底層運作有多不熟、多需要加強。在被 S 購物電翻後,我就瘋狂加強自己的 JavaScript 與 React 相關的深度知識。

假如你要面試 S 購物的前端工程職缺,除了確保自己 JavaScript 跟使用的框架夠熟外,我會推薦你務必要把 Glassdoor 上面的 Software Engineer 以及 Frontend 相關的面試經驗分享全部看過,以及把 LeetCode 中該公司高頻題都刷過一輪;以下我會由我的慘痛經驗分享,為什麼這麼做有幫助。

S 購物的第一輪會是人資面,就是被人資在 LinkedIn 上聯繫,然後約了一個 30 分鐘的視訊電話,主要就是問人資類的問題,例如為什麼想換工作、為什麼對 S 購物有興趣,能 relocate 到新加坡嗎? 家人支持自己出國工作嗎? 等等這類問題 (跟 Glassdoor 上分享的基本都差不多)。

接著會用一個在 Glassdoor 被罵翻的 Glider.ai 來做 OA。題目分成選擇題,考對網頁開發的熟悉程度。舉例來說,假如關掉瀏覽器的分頁後,以下哪些的資料會被清掉 (cookie, session, indexedDB, localStorage)。或是 JavaScript 的熟悉程度,例如非同步 (asynchronous) 與 event loop 的運作機制細節,實際問題類似這一題,以下程式碼印出的結果為何 (不知道的話可參考這篇)。

Promise.resolve().then(() => {
  console.log('Promise1');
  setTimeout(() => {
    console.log('setTimeout2');
  }, 0);
});
setTimeout(() => {
  console.log('setTimeout1');
  Promise.resolve().then(() => {
    console.log('Promise2');
  });
}, 0);

另外也有考兩題演算法題,但都是 LeetCode Easy 的問題,其中一題是字串的處理,另一題則是網路上找得到的 Maximum sum of non-leaf nodes among all levels of the given binary tree。過了 OA 之後就會進到第一輪技術面試。

雖然人資的信上寫第一輪技術面試會是問前端相關的知識,但實際上完全不是這麼一回事……。我在這一輪只有三題白板題……。第一題是簡單的字串處理,大概是 LeetCode Easy;第二題則是實作函式快取。

第三題則是要把字串轉換成 2D 陣列,但有幾個 edge cases 需要處理。我把題目中的城市改為台灣的城市,但問題基本不變。這題只要能處理掉空白、以及後面的那個雙引號問題,基本上不會太困難。

第一輪三題算是有解出來後,有幸在隔天收到第二輪技術面試邀請。雖然人資的信上寫第二輪技術面試會是問電腦科學相關的問題,搭配白板題,但實際上再次完全不是這麼一回事……。我在這一輪有三分之二的題目是被問跟前端有關,只能說人資跟面試官之間的認知有很大落差呀 XD

進到第二輪時,前面第一題先是要手寫 debounce 函式,因為這題是蠻常見的題目,先前有寫過,所以算順利完成。但是第二題就直接被電慘,要實作一個 LRU cache,這題雖然我先前看過題目的標題,但因為它在 AlgoExpert 中被歸類在 Very Hard 的題目 (不過 LeetCode 把它歸類 Medium),我先前就想說我才一年半經驗,還是面試前端,應該不會被問到這題吧,於是就沒有練習過。透過這個慘痛的教訓,想跟同為資淺前端的人說,想要面大廠,平常練一下難度高的題目還是有必要的。

因為題目要求 O(1) 時間複雜度來處理 get 與 put,我當下有想到用 hash table 搭配 linked list 來解這一題。我當時說出這個思路時,面試官就說,不然你先建一個 doubly linked list 吧。但這時就顯露出我對 JavaScript 不熟之處,我在面試當下建不出來一個 doubly linked list ,然後就掛在那邊。後來面試官看我實在寫不出來,就叫我講完我的思路,然後就往下問前端的問題。

這邊先稍微插播一下,上面有提到 LeetCode 高頻題要多做,原因是我在面試後上網查,發現 LRU cache 就是 S 購物在 LeetCode 上被回報最高頻的題目之一。假如我是在面試前知道這資訊,肯定會多練習幾次,只可惜我是面試完後才知道。所以看到這邊的你,千萬不要鐵齒,高頻題優先刷可能讓你少走我走過的冤枉路……。

接著進到前端類的問題,又是另一番轟炸。基本上就是問了 React 與 Redux 底層類的問題。以 React 來說,一路被問到 React 的 reconciliation 機制是怎麼運作? 因為先前我讀過 React 官方 Advanced Guides 每一篇且有做筆記,所以到這邊都還算頂得住,不過後面就開始慢慢沒辦法招架。

後面問了 Redux 的問題,然後每當我講了一個點,就會被往下開始追問,到後面追問 Redux 效能問題,問說 Redux 會問每個 connected component 要不要 re-rendering,這要怎麼實作? 以及這麼做導致 O(n) 效能不好該怎麼解決?

這邊就是我掛機的時刻,當下我真的回答不出來,因為我在那之前只用過 Redux,沒去研究過它是怎麼實作。我也從來沒想過假如我要寫一個類似 Redux 的套件,我會怎麼做到把效能從 O(n) 變成 O(1)? 雖然面試當下答不出來,但事後去查,發現這些問題在前端社群還真是被探討過,甚至 Facebook 內部就有一個實驗性的專案 Recoil,就是做到 Redux 在做的事,然後用 O(1) 的方式實踐。

這個經驗引發我一個思考,在面試時我答不出來,當然只能怪自己過去了解不夠深入。不過我一直以來都有追蹤的 Dan Abramov (React 團隊核心成員,同時也是 Redux 共同發明者),他在他的部落格文章中,談到 React 底層的技術時,都有特別講 you don’t need to know this to be productive in React。所以有些東西我讀過去就想說,不深知也還好,畢竟不影響工作上使用 React 與 Redux。

但在 S 購物這輪高強度的面試下,我在想的確不用知道這些底層也可以把 React 或 Redux 寫得很好,但可能會過不了這類面試 XDD 所以到底要不要把這些深入搞懂呢? 我想端看你是不是發自內心好奇,或者你是不很想去會問這種深度技術問題的公司。假如想去的話,那建議還是好好搞懂吧!

總之很合理地,因為我沒順利寫出 LRU cache,被追問 Redux 實作問題又答不出來,這關自然就掛彩了。不過必須說這真的是個很棒的學習經驗,讓我清楚知道我自己的不足。好在我歐洲區的一些技術面試其實是在這場面試之後,在這場被電完我開始瘋狂加強這些。上面提到的荷蘭 G 新創問的那些 React 與 Redux 問題,每問一題我就在被追問前,自己主動講個三四層,他們工程師有說很 impressed 我能講到那些,殊不知是因為我先前被慘電後發憤圖強 XDD

新加坡雖然後續還有其他機會,但因為後來拿到歐洲的 offer,就沒繼續面下去。不過 S 購物的經驗真的是讓我開了眼界,也希望這個被慘電的經驗,對想去挑戰新加坡大廠的前端工程師們有幫助。

同時這個經驗讓我體認到,把自己的非第一志願地區,做為前導的面試練習是很不錯的方式。目標為歐洲的我,在面歐洲之前,透過新加坡的面試,累積了高強度的英文技術面試經驗。雖然被慘電,但被電當充電,而且充得很飽很滿 XDD

日本面試談

因為在疫情前我每年至少去日本玩兩次,所以雖然目標在歐洲,但我仍把 LinkedIn 的求職地點之一設定成為東京,但沒抱特別多期待。不過陸續也有幾位獵頭私訊提供面試機會,然後我就想說不試白不試,當練習的機會,所以就把履歷給了獵頭。接觸幾個下來,我個人感覺最專業的是一間叫 Wahl+Case 的公司,該獵頭很詳盡地跟我介紹日本現在的資訊/軟體產業現狀,然後也幫我投了幾間公司。以下跟大家分享獵頭跟我說的一些資訊:

現在日本資訊的工作市場很缺工程師,該獵頭說基本上日本國內已經找不太到人了,所以日本的公司才開始往海外找人,甚至不少公司的軟體工程師,外國人的人數比日本人還多。然後說因為這樣,所以其實不太有日文的要求,溝通的語言都是英文。

日本很多職缺雖然會寫要求 3 年以上經驗,但是即使經驗不到也可以申請 (我就只有一年多一點)。獵頭說之所以會設定 3 年以上,是因為日本公司覺得通常要至少 3 年經驗才能通過他們的技術面試。但事實上過去也很多不到 3 年經驗的人通過,所以不用因為自己年資不夠深就不申請。

日本我有遇到的也是分成作業與考演算法的兩種類別。因為分別被拒跟因為拿到歐洲 offer 後主動婉拒後續,以下與大家分享比較特別的經驗的:

出作業類的公司

日本我只有遇到一個是作業類別的公司,是 N 新創。他們出了一個 code refactoring 作業,我覺得是很不錯的作業。比起從零寫一個小專案,這個 refactoring 作業花的時間就稍微少一點,然後又能測出懂不懂軟體設計原則、懂不懂如何寫乾淨的程式碼。

考演算法類的公司

演算法類的公司則是跟其他國家都差不多。舉例來說一家算大公司的 W 公司,前面先給了一個 HackerRank 的 OA。HackerRank 著名的就是題目都寫很長 (幾乎是在考英文閱讀能力呀 XD),假如對這種長敘述不熟的人,推薦多上 HackerRank 做題目練習。

比較特別的地方是,該公司的 HackerRank 除了算法的題目外,還有申論題。事後查了一下,題目是比較類似 System Design 一點,就是需要了解整個系統的運作,了解前後端如何協作來做到題目中的要求。因為我的算法題目跑測試時都有過,但最後 HackerRank 關卡沒通過,我猜這邊的申論題是我掛掉沒通過的原因。

反思了一下,如上面提到日本獵頭說日本公司會希望找 3 年以上,是因為覺得 3 年以上經驗的人才能過得了他們的面試。我在想這背後的原因之一,可能也是因為這種類似 System Design 的問題。我自己先前在網路上看到,多半是比較資深的工程師面試才會問 System Design,所以我就沒特別準被。不過對於跟我一樣不到兩年開發經驗,又想越級打掛的前端大大們,推薦還是準備一下 System Design,才不會像我一樣掛掉。

在台外商

上面有提到,我把我的 LinkedIn 求職地點設定為歐洲各國與日本新加坡,但可能因為我所在的工作地點仍是台北,所以還是有不少在台灣的人資與獵頭來找。因為我很確定要到海外生活、做全球化的產品,所以一開始會問能不能有國外辦公室,或是有沒有外派、全遠端的機會,假如都沒有的話就就先婉拒邀約。因此最後僅有跟兩間總部在海外、且有其他海外辦公室的在台外商面試。 我有面的這兩間可能因為都有募資順利,所以都在大舉擴招;我猜可能蠻多在台的前端大大們會接觸到,所以這邊我盡可能寫得詳細一點。

港商 O 新創

港商 O 新創是做純網路保險的,我在先前就已經耳聞該公司,主要因為台灣前端有好幾個社群活躍的人在該公司,算是因此建立了對該公司的人都很熱愛技術的第一印象。該公司目前主要只找 mid-senior level 的,所以我蠻訝異僅一年左右開發經驗的我也能獲得面試機會 XD

該公司的流程是分成三關,技術關卡前是先跟人資聊,主要是了解個人職涯發展、為什麼會開始想找工作;同時也聽人資介紹該公司以及開發團隊。聊完後的技術關卡第一關是 90 分鐘的線上技術測驗,是用 coderbyte 這個平台進行,主要分成簡單的演算法題目、JavaScript 與 TypeScript 題目,以及 React 的題目。

演算法題目第一題是很常見的 LeetCode 15. 3Sum 的變形 (output 要求不太一樣,但概念一樣) ,屬於 LeetCode Medium 的題目,這題幾乎是必刷的題目,所以我先前其實在 AlgoExpert 與 LeetCode 上都寫過,在線上測驗時我是用常見的 two pointers 來解這題。另外一題是做字串轉換,就是給一個字串,要把裡面的英文字轉換成後一個字,然後遇到母音的話要大寫 (例如 'abcd' 要變成 'bcdE' ),這題我是透過 charCodeAt() 以及 fromCharCode() 這兩個 JavaScript 內建方法,搭配一個母音的 hash Map 來完成,難度算是 LeetCode Easy。順道一提,coderbyte 這平台有鑲嵌 Google 搜尋,所以假如有不熟的語法,可以直接在上面搜尋。

React 的部分有一題手寫題,是給一個 array of objects,然後要建一個表單出來。我是中規中矩地用 map() 方法,搭配上 <ul> 以及 <li> 來完成。這個對於有在用 React 做日常開發的人來說應該都不會太難。除了手寫題之外,也有問一些概念題,例如 React PureComponent 的用途? 以及在 function component 可以如何做到相同效果? 算是面試常見題目,不過特別注意,這邊是簡答題,不是選擇題,且需要用英文作答。

JavaScript 是問了我在美商 H 公司被問過的 Scope 題目,再次附上這篇文章,能懂的話基本上這題不會太難。然後還問了一題 IIFE 的題目,跟實作一個簡單的 Curry 函式,基本上能手寫出這篇裡面 Curry 實作的部分,那題就不會是問題。而 TypeScript 的話是問了 Generics 用途為何? 並要求手寫一個範例。我剛好之前看過這篇用 React 的 useState 來講解 Generics 的文章,所以就寫了一個簡易版 useState,然後透過該範例來說明。

線上測試後的隔週一收到港商 O 新創的第二場面試邀請,有趣的是,這是我面快十間公司、超過三十場面試中,唯一用中文進行的,反而覺得不太習慣 XDD 這關總共兩小時,前面 1.5 小時是技術面試,由三位工程師進行,其中一位是 hiring manager (也是團隊中的 Tech Lead);後面 0.5 小時則是由 HR 進行。技術面試前面會有 hiring manager 介紹公司、產品、團隊,以及讓申請者有機會提問任何問題。

在介紹完也讓我提問後,就進入到我被問問題的階段。這階段沒有直接手寫的白板題,主要都是問概念與思路。 我還記得的 JavaScript 題目包含以下

  • script tag 當中的 async 與 defer 有什麼功用? 兩者的區別? 這邊還出了一個情境題問我,在該情境下該用哪一個? 結果我當下沒有完全理解題目,說了一個不是正確的回答,感謝面試官協助導正我的觀念。
  • JavaScript 的 shallow copy 與 deep copy 有什麼區別? 哪個是傳一個 reference? 如果要實作 deep copy 該怎麼做? 這種 lodash 手寫類的題目真的很常出現,大家務必要熟。我當下回答的版本是透過 recursive 的方式來實踐的,思路如下:

React 相關的問題則是有

  • useMemouseCallback 的區別為何? 什麼情境該用什麼? 這裡我有順利回答後,被追問了「可以用 useMemo 來處理函式嗎?」這邊我沒回答的很好,面試官補充其實 useCallback 背後也是透過 useMemo 的概念來做到。
  • 為何要用 Redux Toolkit? 說明 Redux Toolkit 的優點 (會問這題,是因為我履歷有寫到我有用 Redux Toolkit 的經驗。自己履歷上的寫的每個東西真的都要熟呀~)
  • Redux Thunk 如何使用? 運作機制為何? (因為我在的公司都是用 createAsyncThunk 所以我就回答了它的用法,以及它搭配 extraReducerbuilder pattern 做操作)

另外也有 Web 相關的問題

  • 問了效能優化的經驗 (因為我履歷中有寫到,所以我當下就分享一下我們當時的做法)
  • 說明 localStorage 跟 sessionStorage 差別? 分別適用時機? (可參考這篇 MDN )
  • 說明 cookie 機制 (可參考這篇 MDN)
  • 說明 http caching (剛好我先前讀過這篇 MDN 的文章,還有這篇 web.dev 的文章,就講了 Cache-Control, ETag, 以及 Last-Modified 三種機制)
  • 問了瀏覽器中提供的 preloadprefetchpreconnect 等功能 (這篇寫得很清楚)

另外也有 CSS 類的問題

一連串的問題後,最後也留給我一些時間問問題。結束之後換 HR 進行提問,這部分的問題就比較是了解個人發展偏好、了解過去一些團隊協作經驗;另外也讓我有機會提問。我自己在跟工程師們,以及跟 HR 的提問都問了不少團隊協作、文化、以及問了一些個人經驗的問題

這次的面試經驗算是讓我意識到,我過去點的技能點比較多在 JavaScript、React 的知識點,以及 LeetCode 的刷題;但是 Web 相關的 (瀏覽器相關的),以及 CSS 的我就相對薄弱了一些,這兩部份答得不是太深入詳盡。我覺得與港商 O 新創的面試是很不錯的經驗,讓我在後續的準備上,知道自己還有更廣的面向應該加強。

美商 H 公司

美商 H 公司 是做室內設計與居家裝修的電商公司,因為已經募資到 E 輪,估值 40 億美元,所以基本上不太能說是新創了。當時的流程是獵頭接觸後,有一次初步的電話談話,主要是了解我接下來的職涯發展、為何想換工作等等。聊完沒太大問題後,就幫我送履歷給該公司,然後就約了第一次面試。因為他們正在大舉徵才,如果對這間公司有興趣的前端大大們,可以在 LinkedIn 上找獵才公司 MVP Fastlane,在接觸的過程中,感受得到他們很尊重應徵者,很推薦 (這邊特別感謝當初接洽我的 James,幫我與該公司做了許多的協調。有興趣這間的人,James 有說可以找他)。

因為是跟美國總部面試,所以當時被開的時段是台灣晚上 12 點,或是早上 7 點或 8 點。如果對這間公司有興趣,可能要特別注意這點,面試的時間是比較罕見的 (但好處是不用請假面試 XDD)。因為是直接面美國總部,所以 我當時特別上了一畝三分地、Glassdoor 看了一下過來人的面試經驗,蠻推薦大家這樣做的,因為我就剛好有一題被問到一樣的。另外就是台灣也有過去的申請者曾分享面試經驗,可以看到這篇-2020 年底碩士新鮮人軟體找工作紀錄跟心得分享(前端為主)、這篇-面試心得 - Houzz,還有這篇-2020 Software Engineer / Backend Engineer 面試心得

我的第一面是對到一個 Staff Engineer。一開始對方先請我自我介紹,然後請我聊聊我過去的開發經驗,在分享的過程被追問了很多問題。比較特別的地方是,追問的問題很多是產品面的。我先前就聽說美國軟體公司很重視產品思維,在該次面試中很直接應證了這點。所以推薦假如要準備這間的前端,可能要練習一下用英文介紹自己做過的專案、用的技術,甚至回答一些從技術角度看 UIUX 的問題 (例如要實作某 UI,或是要能提供某 UX,可以用什麼技術之類的)。

前面被追問了十五分鐘左右,才真的進到技術問題。技術總共被問到三題,第一題是很經典的 JavaScript scope 問題,以及相關的追問問題。具體來說,假如你能解釋這篇文章在講的東西,這題應該會沒問題。

第二題則是 Glassdoor 上有看到的類似問題。簡單來說就是給一串網址 (字串),然後要能夠去 parse 該網址的 query params。具體來說會是例如下面這樣 (題目沒完全一樣,但概念是這樣)。這題有幾個要注意的,一個是如果某個 key 重複出現,要讓 value 是一個陣列;以及要能把那些看似亂碼的東西作轉換 (JavaScript 有個內建的 decodeURI() 方法在做這件事)。因為題目不難,我蠻順利地解出來。

第三題則是手寫 debounce 函式。假如你有看上面的話,這題其實我在新加坡 S 購物的技術二面也被問過。只能說這種手寫出 lodash 裡面常見的函式,幾乎是前端面試必備的題目 (我一路被問到好多次,包含上面分享的港商 O 新創就有問 cloneDeep XDD)。所以假如對 debouncethrottleflattencloneDeep 等等手寫不熟的人,這些務必事先練習,確保面試時被問到,會寫得出來。假如你沒頭緒怎麼實作的話,其實網路上有很多人有寫文章教學,例如這篇就講得很淺顯易懂,推薦讀讀~

三題技術題之後,面試官也讓我有一些時間發問。在我問完一些我對該公司好奇的點後,結束了第一面。過了第一輪後,接下來被連續約了兩輪面試,因為也都是對在美國的工程師,所以兩個也都安排在早上七點面。不過因為我在第一面與後續兩輪面試之間,回應接受了歐洲的 offer,所以就主動取消了後續的兩輪面試;這邊就沒辦法有後續的實際經驗分享了。