Google 台灣面試分享(無藏私)

TechwithLC
16 min readAug 11, 2024

--

在這注意力只有三秒的時代,感謝各位讀者停下來閱讀此文章,希望能給予你/妳在求職的過程中一些啟發。

未經同意不得轉載感謝!

我會盡可能的用簡單明瞭的語言並且深挖所有面試的細節,在開始分享前,我會以四大標題的主軸架構往下發展,讀者們可以在各大標題快速找到自己要的資訊。

背景 → 動機 → 過程 → 展望

我很推薦看他的影片,Jeff H Sipe 之前在 Google 當了四年的 recruiter

個人覺得要去面試該公司的動機最為重要,千萬不要只為了薪水而做你不快樂的事情(上方影片有解釋到為何選擇 Goolge 任職的原因)

背景

我本身大學是在台灣中部私立大學畢業,並沒有唸碩士(因為我真的很討厭被強迫唸書的感覺),然而我完全不知道我大學畢業要幹嘛,所以在大學畢業前選修了當時 AWS (Amazon Web Services) 與我們學校雲創學院共同協辦的雲計算學程,進而了解到雲計算的強大之處以及應用。

會想講這段的原因是因為,你在很多面試過程中,很多 interviewer 會想了解你的 background,這時候說故事的能力就來了,你總不能說你喜歡打籃球,你家庭成員有誰等等,沒人想聽。

大學畢業當完兵後,面試申請上亞洲最大的 AWS 雲端代理商 — 伊雲谷,在裡面深耕了許多雲端的知識以及前後做了兩個職位 — AWS 講師以及 Microsoft Azure 的雲端架構師,公司其實在當時就往多雲的策略發展,目前也有蠻多間公司走混合雲的策略進行 fail over。

某天心血來潮想說挑戰原廠(AWS) 看看,沒想到自己準備了快兩個月,最後很幸運的拿到了 Offer (我記得是 2022 12/08 拿到 offer),有關於這部分的細節,我之後也會寫有關於如何準備 AWS 的面試。不過,我挑戰的職位是在愛爾蘭 AWS ,所以有關於海外的生活以及整個 relocate 的流程也會之後在準備 AWS 面試中細說,由於內容較多,我大概會分為上下集,畢竟也來兩年半。

歡迎與我在 Linkedin 相遇~~~

原先在愛爾蘭 AWS 擔任 Cloud Support Engineer 一職,但由於發現自己不太適合等其他因素,毅然決然在離開之前,到 Linkedin 逛逛看有沒有適合自己的職位以及工作的性質比較著重在 customer facing 的部分,而非太看重 Engineer 性質上。隨後,在 Linkedin 看到 AWS 前同事轉發現在 Google (GCP) 有在招募 Technical Account Manager (TAM) 技術經理一職,因此,我透過 Linkedin 的私訊功能,簡單自我介紹並且告訴前同事(雖然我們沒有共事過) 我目前的狀況以及想了解一下細節,並安排了簡單的會議和幫忙內推的流程。

在擔任 Support 時,我們最常對接的角色除了顧客以外,還有 TAM (技術經理),因為很多買 Enterprise Support Plan 的顧客組織相當龐大,甚至有時候一間公司每年支付的 Support Plan 費用,就足以支撐 AWS Dublin 工程團隊每年 90% 的薪水。所以,如此大規模的公司想當然就會安排幾位 TAM,除了時刻照顧顧客使用 AWS 遇到問題外,偶爾還需要安撫顧客失控的情緒。

我跟不少 TAM 對接過,且時常分享自己知道的技術細節以及如何更好的解決顧客問題等軟硬實力結合,我發現擔任 TAM 這一角色能看到更多顧客面向以及 Business 層面上的 impact,相對於 Support 較於制式化且時常被高 severity 的案例打斷注意力與種種不合理的 KPI 制度,我認為我更適合 TAM 這一職位的角色,也不少 Support 的職涯發展會往 TAM 前進。

下方大概解釋一下 Enterprise 顧客與 Support 的關係(請注意只有 Enterprise 顧客才會配 TAM,詳情可參考 AWS Support Plan)

Enterprise Customer → 有 Business Development(BD),Solutions Architect (SA),TAM → TAM 最常與 Support 對接了解顧客痛點 → AWS Support → 若有解不了的案例 → 開 Ticket → Support Ops 或是 Service Team 來看哪邊有問題 (曾經最複雜上升到 VP level)。

Technical Account Manager (技術經理)

在面試任何職位的時候,千萬不要亂槍打鳥或是海投,根據經驗海投上千封最後可能只有拿到個位數的面試邀約,不如鎖定 5 -10 家並好好把 Job Description 看懂並注意該公司的要求,並依照每間公司的要求客製化自己的履歷,拿到面試的機會才會提高。

而官方 po 出來的要求和標準以及日常責任如下(但由於我對 TAM 的工作內容已經相對熟悉,所以我大概再強化一下 TAM 這個角色的工作內容即可)

一定要熟讀 JD

熟悉這些工作內容以及查找別人面試的經驗,都會對你後面在面對 interviewer 時,能夠更對談如流且不會太緊張,不然一問知道你是亂投,很快就沒有後續了。

過程

整個過程大致簡化如下(接下來要講的細節是整個文章最重要的部分):

Internal Referral → Recruiter Phone Screen → Interview → Result

Google Technical Account Manager Interview Process:

  1. Role Related Knowledge(RRK) 1: 45min
  2. RRK 2 — Case Study: 1hr
  3. General Cognitive Ability(GCA): 45min
  4. Googleyness and Leadership(G&L): 45min

很多人問說面試是用中文還是英文,大部分還是用英文比較多,很多 interviewer 基本上是不會中文的,even 你 based 在台灣,所以還是建議大家口說部分可以多練習。

時間序

  1. 2024 06/03 找前同事內推
  2. 2024 06/05 收到 Recruiter 的 phone screen 邀約,大概了解一下你的背景以及對這個職位的了解是否正確。

3. 2024 06/13 與 Recruiter 進行會議,大致上了解一下背景以及工作經驗是否了解 TAM 的職務內容(由於這部分經常接觸,很快隔日就收到 Recruiter 的面試安排邀約

4. 2024 06/14 Recruiter 發信過來簡述接下來面試流程大致上為何,並且附上不少有用的學習資源以供面試準備

這邊推薦幾個很有用的學習資源,在面試的時候必考必問!

5. 2024 06/25 安排第一場面試 RRK 1 Interview

面試關於 Google Cloud 相關的技術以及各種假設性場景問題,我當下面試完就感覺自己表現的不錯,大概只有一題不太會。很快當天下午,我就收到 Recruiter 反饋可以給時間進行下一關。

我是有把所有被問的問題記錄下來,但基於隱私原因,我這邊很抱歉無法分享具體問題,但我能在後面給各位讀者一些回答的技巧。

6. 2024 07/02 General Cognitive Ability(GCA) + 2024 07/03 Case Study (RRK2) Interview

正常以這個職位來說,您可能在第一階段或是第二階段,會有一個階段是接連面試的情況,也就是說一週可能會面兩次來加快整個進程,而我原本是要先面試 RRK1 + RRK2,但我只先面試了 RRK1 ,而第二階段是面試 GCA + RRK2 連續兩天的面試。

GCA 準備

我這邊會多說一點篇幅,我認為這兩關相當關鍵,其中 GCA 的部分是最難準備的,依照人資給的文件說明這關想判定 candidate 的能力如下:

This interview is designed to understand how you solve problems. The interviewer is interested in observing the data-driven approach you take to identify a logical recommendation to a problem with an ability to support your solution. For the GCA questions, interviewers will be evaluating your problem-solving and critical-thinking skills. In these scenarios, there may not be any right answer; they are mostly curious about how you think, approach challenges and come up with solutions.

簡單來說,這關所詢問的問題都沒有正確答案,這關通常是由 Hiring Manager 也就是 TAM 的主管來評斷你在遇到問題時的整個思考邏輯以及思考方式和得出的解決方法,是不是 Google 想要的人才。其實我認為這關相當重要,原因是其實在你回答的過程中,有經驗的 interviewer 就大概可以根據你的回答,知道你的做事方式,以及性格和面對未知問題時如何處理。

這邊有幾點建議可供大家參考在回答 hypothetical questions 的時候,用什麼框架來回答問題會比較好。

  1. Understanding of the question.
  2. Preparation Strategy.
  3. Ability to identify solutions.
  4. Justification for a specific solution.
  5. Communication.

如何組織出比較完整的回答框架?(請練習到你的回答都已經依照這框架去進行,若你的回答是有框架的,會比較有邏輯性)

  1. Take a moment before responding (記得遇到問題先理解問題,不要急著回答,想個一到兩分鐘,interviewer 都會理解的)
  2. Asking clarifying questions (有些問題 interviewer 問的很模糊,你是有權利可以提出你的問題以及多問一些細節的,記得要多與 interviewer 互動)
  3. Share logical assumption (有些問題沒有很明確的方向,你可以自己假設大概的數據和場景).
  4. Show your work .
  5. Consider pros and cons.
  6. Think about how you measure success.
  7. Tie it back to the role (呼應我前面說的,了解 JD 很重要)
這影片一定要細看!!!

Case Study — RRK2

這關主要就是場景題,面試官會給你一個公司的背景,以及預計要上線的業務和預期的規模使用量,然後根據提供的資源以及使用到 GCP 的服務,問你 follow-up 的問題。這關很不好準備,因為你不太知道會問什麼問題,以及面試官提供給你的素材公司是什麼產業,你熟不熟悉等。面試時,主要會衡量以下三個面向:

  1. Technical aptitude.
  2. Customer advocacy.
  3. Crisis management.

舉個比較簡單的場景大致如下:

某遊戲公司採取多雲的策略,預計在三個月後需要上線服務到 GCP,而其中需要上線 8 款遊戲,其中 2 款只支援手機端應用,而每年產生的營業額大致為 10 億美元,且年活躍用戶數在 5 千萬左右。

但該公司基於一下資料法規和資訊安全問題,某部分的運算資源希望自己來掌握而非是使用 managed service 的產品…… .

面試官會給你 10–15 分鐘 (準備好隨時跟面試官說,他就會開始詢問相關問題),消化吸收該公司的背景以及該公司開出來希望達到的條件,要比較好準備這關的話,需要熟讀一下 Migrate to Google Cloud — Best Practice 的部分,因為其中有不少問題會問到如果顧客在搬遷或是使用 GCP 服務時,要怎樣降低搬遷時間,以及若是在 bandwidth 有限情況下,搬遷大量數據時,需要考慮的點有哪些 (坦白說這關是我覺得我表現最差的一關,因為前一天緊張到半夜四點都睡不著

7. 2024 07/08 收到 Recruiter 確認可以到最後一關了,由於我不想拖太久,於是我給 Recruiter 這週就可以面試的時間,隨後在三天後確認了最後一關面試的時間為 2024 07/11。

更新!!

8. 2024 08/19 我收到 recruiter 說 hiring team 決定不會 process 我的 application 到下一階段,不過未來有任何相關職位他會與我同步(雖然沒拿到 offer 但還是很感激能面試到最後一關了!)

Googleyness & Leadership

如果你面過科技業大廠的話,例如 FAANG 或是現在說的 Magnificent 7,基本上考 behaviour questions 不會差太多,但每間公司的文化不太相同,建議可以先上網查找一下該公司的文化以及最重視員工的特質為何,並且將自己過去做過專案的經驗用 STAR 的方式包裝起來。

有關於 STAR (Situation, Task, Action, Result) 的部分,大家可以參考相關的文章,這邊就不多贅述。

這邊給大家提供根據 Recruiter 給的 document 來細說一下 Googleyness 的文化

I like to share the denition of Googleyness so you can beer understand the type of people we strive to hire:

  • Googley people bring creativity, sincerity and passion to their work. They communicate openly and act ethically; can thrive in Google’s fast-paced, rapidly changing environment; and are willing to “roll up their sleeves” and get things done. They can be serious without wearing a suit and tie.
  • Googley people can be world renowned experts while still remaining approachable and open to new ideas and experiences. Staying humble and having passion to learn is great!
  • Being Googley is more about being active and collaborative rather than competitive, about being curious and embracing diversity rather than just being “smart”.

總整一下比較會注重的特點:

  1. 適應不確定性:員工應能夠處理不確定的情況和複雜的問題,即使沒有明確的答案(這點是我工作到目前為止覺得最重要的特質,科技業變化真的太快)。
  2. 合作精神:團隊合作非常重要,能夠與他人良好合作至關重要。(跟 Amazon 不太一樣,Amazon 比較 competitive)。
  3. 開放態度:對新想法和多元觀點保持接納,並願意教導他人和向他人學習。
  4. 智識謙遜:認識到自己的不足,並且願意學習。
  5. 敢於冒險:鼓勵創新,即使有時可能會失敗。

大概會遇到的問題如下:

請舉例在你的職業生涯中的成就範例:

  1. 你解決過的困難問題或面臨的挑戰,以及你如何克服這些困難/努力變得更好
  2. 你在團隊合作和獨立工作中學到新知識的範例
  3. 你挑戰一個想法並為團隊帶來更好變化的時刻

面試官可能不按牌理出牌,但隨時把自己做過比較有印象或是困難的專案記錄下來,對在後面回答這些問題會比較游刃有餘。

展望

後續我等待面試結果還算蠻久的,由於我可能算是第一批面試的人(加上我其實闖這四關的過程不到一個月),所以我這個組大概還陸續面試其他 candidate,以至於我等了一個月還沒有後續進展,甚至不知道自己是否錄取等(目前可看更新部分,等了一個月又八天才有結果,實在折磨!

不過這中間你是可以傳一個有禮貌的 follow-up email 給你的 recruiter 詢問一下目前的情況,大概是否會有結果等,我自己則是被告知目前還在 debriefing 階段,也就是說人資會把所有 interviewer 的評分搜集起來,並且覺得合適的話會跟 senior 的 manager 討論人選是否合宜,若是符合要求就會送到 Hiring Committee(HC 簡稱),HC 若覺得你不錯才會到 negotiate 薪水 Package 等階段。

我自己問過其他神人朋友,大概都是一週後會收到結果,不過這個很看組別,若是等了兩週後還是沒收到回覆,可以傳個簡單 email follw-up 問一下沒問題的,但最後你還是會收到結果。

我還記得當時考到 AWS 第一張證照的時候是在 2019 11/30 ,當時覺得雲計算有好多有趣的東西可以學習,甚至有一個念頭閃過把全部證照都考完。

但隨著時間推移以及被工作荼毒後,我發現若是要持續在一個領域精進,一定要找到該領域令你感興趣的地方,坦白說在經過講師 → 架構師 → 雲端支援工程師這些職涯發展後,我發現我目前最感興趣的專業領域是底層網路以及人工智慧相關技術,並且透過自己對知識的吸收傳遞給客戶或是想要了解這個領域知識的人,因為我很喜歡跟人互動,我很喜歡一群有相同喜好的人們聚集在一起討論和動手把東西做出來的感覺。不管你是學生,中途轉換跑道還在摸索職涯的人,抑或是真的不知道自己要幹嘛的人,我相信若是你有機會接觸到雲端計算的技術,你一定會很對科技的發展感到興奮以及能夠將其所學應用在未來的職業發展中。

祝福所有求職者都能順利上岸 ,Peace Out ~~

--

--

TechwithLC

Ex-Amazonian in Dublin's silicon docks. Demystifying interviews and AI networking one post at a time.