正式開始前，說明一下我的背景。我是轉碼選手，21 年從台灣私立大學商科學士畢業。大四交換學生回來才認知到我對發展企管相關的職涯沒有興趣，畢業前決定朝著前端（Frontend）軟體工程師前進。上了一系列前端的 Udemy 課程，拿著課程的 toy project，面試台北內科的本土軟體公司，幸運的拿到 Offer（那時 covid 疫情，軟體工程師需求大爆發），就這樣有了一年的軟體工作經驗，後來就來美國 Seattle 讀 master program 了。
Chapter 0
經過去年 24 年秋季如火如荼，為期三個月的 recruiting process，包含 two round virtual onsites (coding interviews), team match calls 等等，終於在今年初拿到灣區科技大廠 Offer，這個撒花的小 mile stone，一掃去年苦命刷題、瘋狂 mock interview 的烏雲，像是西雅圖久違的陽光，照耀我焦慮已久的心情。
開心了一會兒之後，還是回頭照樣上課（話說實習前的那個學期，我修了 Program 數一數二艱辛的 Cloud Computing），就這樣時間快轉到實習開始日 5/5 ⏩
Week 1 - All About Onboarding
其實我來灣區實習之前，有傳一封郵件問 Host 可以在實習前準備什麼，還有了解實習會如何參與開發流程。得到的回覆是前端的 tech stack 暫定會是 Angular Dart，開發過程會是 Design -> Implementation -> Test，最後在 team 來個關於 intern project 的presentation。當時我有上網找了一些關於 Angular Dart 的教材，但學的很零散。總之我個人感想是，在實習前要做到完整的準備，這件事實際來看是頗困難的，後面會再具體說明原因。以 Google 來說，第一週就是設定員工 credential，以及一系列 onboarding tasks，目的是將員工資料，loading 到公司內部系統；其他還有 orienation，與 host, co-host 首次見面，認認真真討論、go through project doc，了解 intern project timeline、考核的 mile stone 事項。第一週完全可以當薪水小偷（😊 笑），就是個探索，建立對於實習會發生什麼事、要做什麼事的預期。
Week 2.1 - GTI Courses
GTI 課程（Google Technical Immersion Program）提供新進軟體工程師員工（包含實習生）一系列關於如何使用 Google 內部代碼提交的系統的線上課程，可以想像你做完小部分的開發，需要將這部分的改動，融合到 project 的 code base。Google code base 與一般可以創建不同 branch 的 Github 的架構設計不一樣，我也是實習到 mid term 的時候才完全掌握 workflow 的操作以及背後知識。
另外一個知識點是如何跑代碼，看測試代碼跑起來有沒有報錯。實習生需要了解要 import 什麼正確的 package 到 build file，以及每個 file 需要什麼依賴（dependency），和 import dependency path 的指令。
Week 2.2 - Access Request
這一週還有一項重要的事：開始申請各種權限！這件事越早進行越好，如果 host 願意第一週開始幫實習生設置權限會更好，像是 run 代碼，註冊 virtual machine 及 ssh 登入虛擬機（還有很多 blablabla 各式權限）。可以說沒有這些權限，實習生根本無法開發，沒有辦法進入 project code base 讀代碼。我覺得這個時候，實習生可以與 host, co-host 詢問，或是請他們條列開發專案時，需要使用到什麼工具，再使用 Google 內部搜索引擎，查詢 intern 使用這項工具需要什麼權限，而不是碰到 access deny 再找 host，如此一來比較有效率。
Week 3&4 - Understanding ur scope & knowing its relation within the team
第一次在大廠工作的震撼教育就是一個系統的 code base 非常大，每一頁幾乎是接近 1000 行代碼，然後有數千個資料夾（directory）。我第一個 intern project 負責的功能是在一個頁面創建一個簡單評估廣告（campaign）的跳窗，算是前端活。我的 host 有指引一個 directory，並跟我說在這邊建立一個跳窗的 component，然後我就開始反覆閱讀我的 project doc，但對於下一步沒有任何想法，這也是我實習撞牆期的開始 🥲😂
遇到的挑戰
1. 花太多時間研究、理解其他 contributors 的 code，卻不知如何應用到自己開發的功能
在我實習的時候，Google 內部的 IDE 已經整合了 Code AI agent，能夠直接讀取選取的 code file。開發過程中，我可以請 AI 解釋某段程式碼、確認自己理解是否正確，或是協助分析 build result error。除了編輯器中的 AI，還能透過 Gemini corp 模式（類似日常使用 Gemini 的方式）或 Duckie（基於 Google 內部搜尋引擎）來取得更多輔助。
一開始，host 提供了一些可能相關的 code pointer。我花了不少時間去理解這些範例，並透過 AI 詢問某個 method 的用途，以及為什麼要這樣設計。然而，AI 的回答往往只針對局部實作，而不是從整體架構的角度去解析脈絡，因此給出的建議有時並不符合我的實際需求或 requirement。即使換個方式提問，得到的 solution 也常常無法真正解決問題。
跟 host sync 幾次後，我逐漸意識到更有效率的方法是：先用 AI 釐清範例程式碼的設計原因和運作邏輯，再把這些理解延伸到自己要開發的功能上。接著再帶著具體的思路或初步 code solution，去和 host 或 co-host 討論，確認方向是否正確。例如，我曾經需要研究如何透過 listener 訂閱 event change。我會先請 AI 說明 listener 的使用方式、為何範例是這樣寫、最後能達成什麼效果；接著再問 AI 該如何將這種設計應用到我自己的功能，並帶著明確的目標與程式碼草稿，和 host 討論可能的問題或限制。
我也學到，獨立研究解決問題的時間不宜拉得太長。通常我會給自己一個 1 小時的上限，超過就直接去問 host 或其他同事，像是請他們給我更精準的 code pointer，或指引我能找哪位 engineer 了解這塊功能。畢竟在快速迭代的環境中，與其花大把時間自己摸索，不如學習如何精準提問，這樣能大幅提升開發效率。
2. 沒有明確的設計文檔
一般來說，專案開始前會有 PRD（Project Requirement Document），讓工程團隊清楚知道需求和設計方向。但在我的實習專案裡，我沒有拿到 PRD，只有 UXDR（UI 設計簡報），所以很多工程面細節只能靠自己推敲。
這就造成一個挑戰：我要接到其他 engineer 的 data model，但沒有設計文檔指引我怎麼串接。於是我必須自己先看懂他們的程式碼，再和對方溝通，討論到底要用哪個 data model、資料要透過 parent component 傳，還是直接注入到我負責的 component。這些 code 又來自不同工程師，所以需要更多來回確認。
後來我意識到，沒有文檔並不代表沒辦法做事，而是要更主動去讀 code、問問題、確認彼此理解。這讓我在過程中提升了表達與溝通的能力，也體會到這正是 collaboration 中非常重要的一環。
Pause a little bit...
這篇文章先記錄了我在實習前 4 週的經歷：初期遇到的挑戰，以及在過程中所做出的調整與改變。下一篇，我會分享更多關於跨組合作的經歷，以及這些開發過程中所體會到的 Google 文化。
實際上，在實習期間我才寫到 week 2，就已經能強烈感受到開發的快步調：快速獲得 feedback、即時調整並進步，幾乎沒有太多時間停下來紀錄或喘息。到了 week 4 時我真的很崩潰。在一群優秀的 SDE 們中工作，我曾害怕如果太常提問，會顯得自己能力不足，甚至擔心評估會被寫成「學習不夠快」。
但隨著心態的調整，我開始理解到：學會如何帶著初步思路去積極尋求討論，本身就是 problem solving 的基礎能力。真正的價值不是獨自解決，而是懂得何時該開口，如何把問題清楚表達出來，並和同事一起推進解法。
很感謝能在一個鼓勵發問、允許學習的環境裡實習。這讓我不只在技術上持續進步，也在職場心態和合作方式上有了新的成長。
