Google on 施星宇

科技巨頭在創新與可靠間的觀察

Sun, 16 Aug 2026 00:40:00 +0800

過去待過 Microsoft 和 Meta 這兩間公司，觀察到這兩間公司有一個有趣的差異，也就是一間公司到底是希望大家覺得它是一間「可靠」、「值得信任」的公司，還是希望大家認為是一間很「有創新能力」、永遠在嘗試新東西的公司

當然，這兩件事情並不是互斥的，一間公司可以同時很可靠，也可以同時很創新，應該幾乎所有科技公司都會希望兩個都有，但我是這樣覺得，當一間公司的規模越來越大之後，這兩件事情其實存在某種程度的 Trade-off，也就是說，當你越想讓整個組織保持快速改變的能力，相對來說就一定會增加一些不確定性，而當你越希望自己的產品、方向和承諾都是穩定而且可以預測的，很多時候就不可能像一間新創公司一樣，想到什麼事情就立刻去做，而我待過的兩間公司，Microsoft 和 Meta 在這件事情上，我覺得剛好是兩個蠻不一樣的例子

當「可靠」本身就是產品的一部分

如果要形容我在 Microsoft 感受到的公司文化，我感覺它是一間相對比較保守的科技公司，我先說我講的保守並不是說 Microsoft 不做新的東西，事實上從 Azure、AI 到各種開發工具，它當然還是持續有很多新的產品和技術，只是相較於很多消費型網路公司，我覺得 Microsoft 做事情的邏輯，會很明顯把安全性、穩定性、相容性，以及長期的可靠度放在比較高的位置，而這其實跟 Microsoft 現在的商業模式有很大的關係，以前很多人對 Microsoft 的印象可能還是 Windows 和 Office，但是今天 Microsoft 很大一部分的業務已經建立在企業客戶上，包括 Azure、Microsoft 365、各種資安方案，許多政府機關和大型企業的基礎設施，本身就建立在 Microsoft 的產品上，而當你的客戶是這些公司的時候，大家對你的期待其實會跟一般消費型產品非常不一樣，舉一個比較簡單的例子，如果今天我做的是一個手機應用程式，我把某個功能拿掉或者重新設計，使用者可能覺得很難用，也可能上網抱怨，但是最多就是換一個應用程式，可是如果今天是一間銀行已經有幾百套內部系統建立在你的平台上，或者一間公司已經把整個基礎設施搬到你的雲端上，那這時候你突然改變一個 API、停止支援一個功能，甚至只是一個原本沒有預期到的破壞性變更，對客戶來說都可能是一件非常大的事情

對這些企業來說，他們買的其實不只是產品本身的功能，而是某種程度上的承諾，也就是我今天選擇你的產品之後，我相信三年後、五年後，甚至十年後，你不會突然告訴我這個東西不能用了，即使技術一直在變，你也會提供足夠的向下相容性、遷移方案，或者長期的支援，讓我不用每隔幾年就重新把整套系統做一次，這也讓我以前在 Microsoft 工作的時候，常常會感受到公司非常在意信任這件事情，有時候從工程師的角度來看，確實會覺得很多事情做得很慢，一個功能可能要經過很多審查，有些東西明明技術上早就可以換掉了，但是因為還有客戶正在使用，所以還是要繼續支援，甚至有些看起來很簡單的改動，最後牽涉到的安全性、法規遵循、相容性問題可能比實際寫程式碼還多

以前我會覺得這是一種大公司的官僚流程，但反過來看，這些官僚流程有一部分其實就是可靠度的成本，因為當很多公司願意把自己的業務建立在你的產品上，他們願意相信的並不是 Microsoft 每一年都一定會做出最酷的新功能，而是它是一間相對不會亂來的公司，對 Microsoft 來說，「可以被信任」本身其實就是產品價值的一部分

相容性的另一面，是不斷累積的複雜度

不過，相容性做得好也不代表產品就一定比較好用，當舊的功能不能隨便拿掉，舊的操作方式需要繼續支援，新的需求又不斷加進來時，產品就很容易變成一層一層往上疊，每一次增加的東西都有它當時合理的背景，但是過了幾年之後，使用者看到的可能就是更多選項、更多入口，以及好幾種看起來很像、實際上又不完全一樣的做法，我自己觀察到 Power BI 對就是個明顯的例子，它的功能很多也需要照顧不同時期、不同使用情境和不同企業客戶的需求，但整個介面和概念也容易變得複雜，有些東西之所以還留在那裡不一定是因為它仍然是今天最好的設計，而可能只是因為已經有人依賴它，不可以直接拿掉

所以 Microsoft 這種做法的代價，很多時候不是功能突然消失，而是歷史包袱會慢慢累積，它讓使用者比較能相信原本的東西明天還會存在，卻也可能讓整個產品變得疊床架屋，需要花更多時間理解

即使已經是一間大公司，還是希望自己可以 Move Fast

相比之下，我到 Meta 之後感受到的是一個蠻不一樣的文化，Meta 今天當然已經不是一間新創公司了，它已經是一間有非常多員工、產品也影響全球數十億使用者的大型公司，但是很有趣的是，它內部到現在還是非常努力想要維持一種新創公司的精神，其中最明顯的當然就是大家都知道的 Move Fast，我以前在外面看到這個口號的時候，會覺得它可能就只是公司文化宣傳的一部分，但真的進到公司之後，會發現它其實會反映在很多做事情的方法上，例如公司如果覺得一個方向很重要，組織和資源可以很快速地往那邊移動，一個專案可以很快開始，方向也可能很快改變，而如果後來發現這件事情不值得繼續做，也可以很快把資源重新移到其他地方，這種文化的好處其實非常明顯，就是一間公司不會因為自己已經變得很大，就完全失去改變方向的能力，因為科技產業本來就是一個變化非常快的產業，如果今天一間公司所有事情都希望等到百分之百確定才去做，那很多時候等你確定的時候，市場可能早就已經往下一個方向走了

我覺得 Facebook 後來改名成 Meta 就是一個非常典型的例子，不論現在回頭看元宇宙這個方向是不是完全正確，光是從一間大型企業做決策的角度來看，這其實是一件蠻驚人的事情，Facebook 這個名字已經累積了非常大的品牌價值，但當上面認為下一個運算平台可能會往另一個方向發展時，它真的可以直接把整間公司的名稱改掉，然後投入非常大量的人力和資源去做 VR、AR 和相關技術，這種事情如果放在一間更傳統的大公司，可能光是討論要不要做就要非常久，更不用說真的把整間公司的方向往那邊移動，所以我覺得 Meta 特別之處就是它即使已經是一間非常大的公司，還是很努力不要讓自己變成一間「因為已經成功，所以什麼事情都不敢改」的公司，但這樣的文化其實也一定會有它另外一面的代價

快速改變的另一面，是不斷重新適應

如果說 Microsoft 的難用有一部分來自歷史包袱，那 Meta 則是另一種程度的難用，不是舊的東西留下太多而是東西變得太快，有些今天還能使用、也已經熟悉的功能可能過一陣子就不見了或者被移到另外一個地方，內部的工具、介面和流程也可能持續調整，每一次改變單獨來看都有讓系統變得更好、更一致，或者更符合新方向的理由，但對實際使用的人來說還是需要不斷重新適應，這種做法可以減少長期累積的包袱，讓團隊有機會直接換掉不再適合的設計，可是它同時也降低了可預測性，使用者不一定要理解十年前留下來的所有選項，卻要接受自己今天學會的東西，明天不一定還能照同樣的方法使用

所以從易用性的角度來看，Microsoft 和 Meta 並不是一個好用一個難用，而是兩種不同的成本，一種是為了相容而累積的複雜度，另一種是為了快速迭代而產生的不穩定性

對公司來說是快速改變，對合作的人來說可能是不確定性

同一間公司這特性從內部和外部去看，感受會完全不一樣，例如從 Meta 自己的角度來看，如果一個方向不對可以快速調整方向，這絕對是一個優點，因為代表公司的資源不會一直浪費在一個已經知道沒有機會的專案上，但是如果你今天是間正在跟 Meta 合作的廠商，而且你已經投入了一批人力在共同開發某個東西，那你最在意的事會是：「你們明年還會不會繼續做這件事？」，所以就是對公司本身而言，改變的能力是一種彈性，但是對依賴這間公司的人來說，改變有時候就是一種風險，這點其實不只是在公司合作上，對員工、開發者，甚至投資人來說都是一樣的

今天一間公司很願意嘗試新的東西，對裡面的工程師來說可能代表有很多新技術、新產品可以搞，但也可能代表組織和專案可以很容易改變，甚至哪天突然就被公司砍掉了，而一家公司願意投入大量資源去嘗試一個還不知道會不會成功的市場，從創新的角度來看當然很好，但從投資人的角度來看，問題可能就會是這些資源什麼時候能夠轉換成營收，所以這並不是單純「哪一種公司文化比較好」的問題，而是不同的人在意的東西本來就不一樣，而你到底比較相信哪個

創新和可靠度其實有一點一體兩面

創新和可靠度這兩個看起來都是非常正面的詞，其實在某些情況下有一點一體兩面，創新的本質本來就代表你要去做一些以前沒有做過的事情，而只要是一件以前沒有做過的事情就一定會包含某種程度的不確定性，你不知道市場會不會接受，不知道技術最後能不能成功，也不知道現在投入的資源最後有沒有辦法產生回報，如果一間公司完全不能接受這些不確定性，那它當然很難做出真正很新的東西，因為所有討論最後都會變成：「有沒有過去成功的案例？有沒有資料可以證明一定會成功？」但問題是，如果真的已經有足夠的資料可以證明一件事情一定會成功，那很多時候它可能也已經不算是一件多創新的事情了

反之，可靠度很大一部分的價值，其實就是降低不確定性，一個企業為什麼願意簽長期合約，為什麼願意把基礎設施搬到你的平台上，本質就是因為它相信未來的結果在某種程度上是可以預測的，從這個角度來看 Microsoft 和 Meta 的差異，不是哪間公司比較厲害，而是兩間公司在不同的地方做了不同的取捨，Microsoft 因為有大量企業客戶，所以它需要讓客戶相信：「你今天把重要的東西交給我，未來我不會突然改變規則」，而 Meta 很大一部分的業務還是消費市場，它面對的競爭則是：「下一個平台出現的時候，我是不是還跟得上？」這兩個問題本身就造就出非常不一樣的公司文化

介在兩者中間的公司

如果要再加入另外一家公司，我自己會覺得 Google 是一個蠻有趣的案例，因為它某種程度上好像剛好介在 Microsoft 和 Meta 中間，以前的 Google 給人的印象其實是一間非常創新的公司，而且有很多東西都是先把技術做出來再看看可以拿它來做什麼，它有很強的工程文化，也做過非常多實驗性的產品，這一點我覺得比較接近 Meta，但 Google 這幾年也慢慢開始進入更多企業市場，包括 Google Cloud、Google Workspace，這些東西的客戶跟一般搜尋引擎或 YouTube 的一般使用者是非常不一樣的，如果今天一間公司真的把自己的基礎設施搬到 Google Cloud，它當然也會開始問跟 Azure 客戶一樣的問題，這個服務五年之後還在不在，API 會不會改，你們會不會哪天覺得這個產品不值得繼續做，就把它關掉

而我覺得這也是為什麼當一間科技公司越來越大、企業業務越來越重要的時候，它很多做事情的方法可能就會慢慢往 Microsoft 那一側移動，這不一定代表公司失去了創新能力，而是當越來越多人開始依賴你的產品之後你能夠隨意改變的空間本來就會變小，這也是一間新創公司變成大型企業之後不太能避免的事情

大公司為什麼最後都會變慢

所以現在回頭看，我覺得所謂的「大公司病」可能也不完全只是因為公司的人變多了，或者管理階層變得比較官僚，而是一間公司成功之後需要負責任的對象也變多了，新創公司最怕的是沒有改變，如果今天產品沒有人用，最合理的做法可能就是明天直接改方向，因為反正原本的東西也沒有什麼人依賴，但是當今天有幾億、幾十億個使用者，有企業客戶、有開發者、有合作夥伴，甚至有政府機關都建立在你的產品上時，一次產品方向的改變影響的就不只是你自己的公司

所以很多大型企業後來會開始出現更多流程、審查、法規遵循、資安要求，我覺得其中當然還是會有一些沒有必要的官僚流程，但是也不能說這些東西全部都沒有意義，有一些其實只是因為你犯錯的成本已經跟以前不一樣了

最困難的可能是，長大之後還能不能同時保留兩件事情

所以不單純是「Microsoft 比較保守，所以 Meta 比較創新」這麼簡單的方式去看這兩間公司，我反而覺得比較有趣的問題是，一間公司在成長的過程中，到底要怎麼同時保留創新和可靠度，如果一家公司太偏向可靠度，所有事情都必須先證明沒有風險，那它很有可能會慢慢變成一間穩定，但是很難再創造新東西的公司，可是如果一家公司所有事情都只追求快速行動，方向一直改，那不論是客戶、合作夥伴還是員工，長期下來也可能不知道自己到底能不能信任今天的方向，所以真正難的但是關鍵的，是要分清楚哪些事情是可以快速試錯的，哪些事情則是一旦承諾之後就不應該隨便改變，一個新的產品方向可以快速實驗，但是已經提供給客戶的 API 可能不能說改就改，內部專案可以快速停止，但如果合作夥伴已經在上面投入很多資源，那對外的承諾就需要另外考慮

如果真的能把這個界線切清楚，那一間大型科技公司或許才有機會在變得越來越可靠的同時，還是保留原本改變自己的能力，而我覺得這可能也是 Microsoft、Meta、Google 這些已經非常成功的大型科技公司，接下來都會一直面對的一個問題：當一間公司已經大到很多人開始依賴它之後，它還能不能在讓別人信任自己的同時，繼續保有冒險和改變的能力？

我覺得這件事情，會比單純比較哪一間公司「比較創新」還要有趣呢

2023 Google Technical Program Manager 面試經驗

Fri, 07 Jul 2023 12:00:18 +0800

Google Technical Program Manager 面試經驗

前言

一直有許多Google SWE的面試經驗分享，然而Technical Program Manager(TPM)的面試經驗則幾乎沒有，其實不光是Dcard國外各大網站TPM的面試經驗分享也很少，因此來分享一下，雖然沒有拿到Offer，但有面到最後，經驗應該可以參考一下。

過去學經歷是112電資相關學碩，今年當完兵之後在比Google略大一點的公司當TPM。以前就有想進去Google，去年也投了Google SWE的面試，面完過HC等Team match時就遇到Hiring Freeze，詳細經歷可以參考：Google SWE 面試心路歷程，直到今年景氣變好才又開始Fit talk，結果連match了三個team都沒中，心灰意冷之際就收到另一個HR寄來TPM的面試邀請，抱著打聽情報的心態就跟HR排了個1:1，其實本來是對Google TPM缺沒什麼興趣，但在會議中被HR一波洗腦後，抱著那就試試的心態就接下面試邀請了。

時間

5/12 - 收到HR的TPM面試邀請
5/23 - 跟HR約1:1了解職缺
6/13 - VO:Technical Judgement*2
6/20 - VO:PgM + GCA
6/30 - 跟HR1:1通知面試結果: not move forward

面試

Google TPM的VO面試總共有五關，每關45分鐘:

兩關的Technical Judgement面試
一關Program Management related(PgM)面試
一關General Cognitive Ability(GCA)面試
一關Googleyness面試

可能因為之前已經面過Googleyness，所以這關就直接跳過了，實際上只面了四關，考慮到我技術能力可能比PM能力好一點，HR先幫我排了兩場Technical Judgement面試，結果不錯的話再排PgM和GCA，後來也證明這是正確的策略。

根據網路上的情報跟HR提供的文件，我認為Technical Judgement面試可能像是技術面試，可能會問Codeing，也可能會問System design，為此還翻出leetcode刷了幾題暖身；PgM可能會問跟經驗相關的問題；GCA則可能問解決問題的邏輯，但這部分當下也想不到有什麼準備方向，所以我只把HR給的參考資料看完，再多回想幾個小故事，由於實在想不到要怎麼準備，我也想辦法跟HR要些Hint，不過HR看起來已經給我全部能給的東西了，那就硬著頭皮上吧，學習嘛…。

順帶一提，TPM的面試是全英文的，四關差不多兩小時都在不停的說英文，這樣的要求也是可以理解，在Google這種公司Cross-function的溝通是極度仰賴英文的，這點也跟SWE面試很不一樣，SWE只有兩關英文，而且不會一直講話。

Technical Judgement 老實說聽到第一個問題時就開始懷疑人生了，我原本已經擺好寫Code的姿勢了，結果第一個問題是：「你最成功的專案什麼？」(詳細題目記不得了，反正是類似這的問題)，是那種我以為應該在PgM或GCA面試會問的問題，還好之前已經準備了不少小故事，姿勢一換搬出從大學、研究所到工作時做的還算有技術深度的案子，講解要解決的問題、我在團隊扮演的腳色、技術的選擇、克服的問題等，過程有來有回，面試官聽也還算滿意，不過一連的幾個問題也都是差不多這種類型，讓我有種我是不是走錯棚的錯覺，結束時還問了一下：「請問這個是Technical Judgement Interview嘛？」面試官愣了一下回：「是阿」，「Ok…」瞬間好像懂了甚麼又覺得甚麼都不懂，第二場Technical Judgement也是差不多的情況，總之自認表現還行，後來HR的feedback也是說Positive。
Program Management Related Knowledge(PgM) 有鑒於Technical Judgement面試問題實在出乎意料，因此再次問HR有關PgM面試的細節，HR還是回說他給的文件已經有資訊了，那就只能自行腦補了，既然名字叫Program Management那應該就是問PM相關能力吧，那應該多往PM的腳色去回答就行，果然不其然，面試的題目跟Technical Judgement幾乎一樣，而我就搬出之前做專案時怎麼定Scope、怎麼寫Spec、怎麼drive project、怎麼溝通協調，面試官看起來還算滿意我的回答，結束面試前小聊了一下這個position的情報，面試官覺得跟我目前的經驗差距頗大，不過還是祝我Good luck。
General Cognitive Ability(GCA) 到了GCA，我是真的想不到要怎麼準備了，如果是問解決問題的邏輯好像也很難準備。果然這關又問了跟前三關差不多的問題，然後我先從執行面去回答，但感覺面試官不太滿意，因此我又換一條路從技術面切入回答，面試官還是不太滿意，並建議我應該先從更High level的架構回答，因此我再給出了一個這方向的答案，不過沒有想得很透徹，應該是Bug滿滿，自己覺得答的超級爛，有感自己答的很爛，結束前後臉皮的跟面試官請教了一回，他也人很好跟我解釋了每一個問題的回答重點，大方向的概念是要先想出一個解決問題的框架，再將這個框架套入回答問題的框架去依序回答才有辦法打到得分點。

結果

後來再跟HR約了一次1:1，結果跟想像的差不多，前面表現都還不錯，主要掛在GCA，沒辦法再move forward，只能回去等還有沒有team match的機會了。

後來想了一下這次的面試確實有很多可以改進的點，除了現在真的菜，能講的經驗還太少外，就是對TPM面試回答的框架還不夠熟，這邊指的框架像是: 面對PgM的問題可以依序從以下幾點下手:

專案範疇與組織
專案執行
溝通與影響力
釐清模糊不清的情況

面對GCA的問題可以依序從以下幾點下手:

理解問題
蒐集資訊
找出解決方案
支持解決方案的證據
良好的溝通

下次要再嘗試Google TPM的面試時，應該要多花點時間打磨手上的案例，想辦法塞進這些框架組織，然後熟練使用這些框架回答問題，某種程度上也算是刷題吧。

結語

個人覺得TPM的面試比SWE面試還要難而且複雜，即便如此Google似乎很想找有EECS背景且有PM能力的人進去當TPM，只是這類人不多又或者沒興趣所以一直找不到人，如果有相關背景的人有興趣可以去嘗試看看。

如果有看完這篇對你有幫助，就順便祝福我早日拿到Google Offer啦。

附一張今年去101蹭飯的照片，好想進Google呀。

Google Taiwan Hiring Event Recording

Wed, 26 Apr 2023 09:00:18 +0800

Google Taiwan Campus Talk, 2023 線上直播校園徵才說明會

Date: 2022/11/11
Title: Google Taiwan Campus Talk, 2023 校園徵才說明會
Agenda:

主題	講者
Welcome & Google Culture
Hear more from the Googlers
Fireside Chat with all the

Recording:

Made by Google: Behind the Scenes Livestream

Date: 2022/11/5
Title: Taiwan Made by Google: Behind the Scenes 2022
Agenda:

主題	講者
Next-gen Google Tensor processor
Fireside Chat : Pixel Camera
Live Q&A and Latest Opportunities @Google Taiwan

Recording:

Google 台灣 Platforms 團隊介紹＆徵才說明會

Date: 2022/07/08
Title: 2022 Google Taiwan Platforms Team Face to Face
Agenda:

主題	講者
Google Taiwan Platforms Team at a glance	Director Platforms HW Test/Quality & Eng Labs
Software & Hardware Engineers in Google Taiwan Platforms Team	Hardware & Software Managers
Google Hiring Process & Tips	Recruiter
All You Want to Know - Q&A & See You at Google!	All Speakers

Recording:

Google 台灣軟體開發及測試團隊分享＆招募說明會

Date: 2022/05/18
Title: Google 台灣軟體開發及測試團隊分享＆招募說明會
Agenda:

主題	講者
解密Google 台灣軟體開發團隊
Googler 分享 - Engineering Manager\Test Engineer\Tech Lead 及 Software Engineer
Google 招募流程
Q&A 時間

Google 台灣 Silicon & CPU 團隊面對面

Date: 2022/04/29
Title: 2022 Google Taiwan Silicon & CPU Face to Face
Recording:

Campus Talk 校園徵才線上說明會

Date: 2021/11/18
Title: 2022 Google Taiwan Tech Campus Talk YouTube Livestream
Recording:

Life@Google台灣硬體工程師篇

Date: 2019/07/19
Title: Life@Google台灣硬體工程師篇
Recording:

2022 Google Taiwan SWE 面試心路歷程

Mon, 05 Dec 2022 09:00:18 +0800

一個普通人的Google面試經驗

前言

大學時期正處AI技術火熱發展的幾年，也因此經常有媒體報導AI技術領頭的Google的工作環境，像遊樂場一般的辦公室、吃不完的零食和飲料、五星級的免費三餐、領著百萬年薪上班還可以想睡覺就睡覺，其內部夢幻的刷新我對一份工作的三觀，從那時起對這間公司逐漸產生好奇，儘管好奇，我卻一直抱持著觀望的心態，如此夢幻的企業收人的標準想當然也是異常的高，傳言中只收台大電資的書卷大神或是競賽選手，望向我那慘慘的在校成績，完全不敢想像要如何才能拿到進入Google的門票。

大四那年系上開了企業參訪，地點就是朝思暮想的Google，當下毫不猶豫就報名了，就此開啟了與Google的第一次相遇的緣分，那時候板橋的總部還沒有成立，我們參觀的是位於101的總部，隨著前往76樓的電梯快速上升，興奮的心情難以壓抑，電梯們打開的剎那，迎接我的是我朝思暮想的夢幻國度，原來新聞裡講的都是真的，免費的冰、免費的飲料、免費的五星級三餐，搭配著76樓的高空美景，真有種去度假的感覺，遊樂器材、打盹房也是真的，完全體現了Google對員工的信任，在與帶領我們的員工交流後了解到Google對員工管理的自由，不僅僅是工時上的自由，工作項目上員工也有相當大的主導權，員工甚至可以自行組建小組發起專案，就這樣在震撼中結束了與Google的第一次邂逅，從那之後進入Google成了我的夢想，我深知自己的不足，只能一步步的朝那裡邁進。

大四的暑假有了一次前往美國舊金山的機會，趁著這個機會再次造訪心中的夢想之地，位在山景城的Google總部，不過這次比較可惜沒有人脈可以帶我進去參觀參觀，只能當個觀光客在園區閒晃，雖然說只能從外部看，也能感受到整間公司以Have Fun為中心思想的氛圍，隨處可見的腳踏車、沙灘排球場、還有各式各樣的野餐區域簡直就是個大型的度假中心，後來也去了園區附近的紀念品中心買了不少伴手禮回來，朝聖之旅讓我感受的這間公司迷人的活力與矽谷這個科技業的傳奇之地的魅力，這裡的創造力與帶給世界的改變，我心想未來的某一天，我也希望能來到這裡工作。

回台灣之後進入了研究所就讀，原本就對自己的技術能力不太抱有信心，進入研究所後被各路大神強者環繞，更是讓我深切的感受到想要進入Google還有很長的路要走，在技術能力與研究能力上必須要有更上一層的累積，抱持著這個心態，在被研究進度追趕之餘也儘可能的參與各式各樣的side project、hackathon，也參與了幾個新創專案累積了一些參與新創的經驗，在跌跌撞撞之中夾雜著過人的運氣，在研究所的最後一年極度幸運的拿到了微軟的實習機會，開啟了一年的實習與研究所兩邊跑的生活，儘管這個老牌的軟體公司在Google、Facebook這些當紅的網路公司略顯遜色，但作為老牌卻長青的科技巨頭，仍提供了我不少的成長養分，開發技術能力的提升、專案管理能力的培養，也讓我得以窺見在科技公司中的生活模式。

2021年板橋的Google成立，將會是亞洲最大的硬體研發中心，能預期的是Google在台灣將會有大規模的人才招募活動，進入Google的難度也會較以往稍微容易，我深知想要進入Google這是個非常好的機會，在2021年底我在Linkedin上第一次收到來自Google HR的面試邀約，在與HR面談後了解到這是屬於Google Silicon的Hardware Engineer職缺，招募台灣電機背景或是有硬體開發經驗的工程師，只可惜我完全沒有學過硬體設計，對於verilog是一竅不通，面談後就完全沒有後續消息了…

2022年初聽聞有個學弟進入Google，我厚著臉皮請他幫忙推薦並投了2022年度的Software Engineer校園招募，這一次我總算沒有被拒於門外，順利的拿到了第一次面試的機會，就這樣開始了魔王級的面試挑戰之旅。

背景

112資管系雙主修森林系學士+112電信所碩士，沒有參加過程式競賽，也沒有貢獻過開源專案，只有和幾個朋友做過Side Project和Hackathon，大二修程式設計時因為花太多時間在社團而被當掉，大三重修A+過，資結演算法只能說是普通水準。

準備

差不多從2021年12月左右開始刷題，中間有一段時間在趕研究進度跟過年荒廢了一段時間，過完年後為了要強迫自己刷題買了一年份的Leetcode Premium，現在看起來是很不錯的投資，另外我也有買很多人推薦的Cracking the coding interview不過只有看一兩個不太熟的章節而已，刷題的策略前期我自己是從動態規劃開始練習，那時候是看花花醬的動態規劃終極學習方案系列影片累積思考動態規劃問題的技巧，差不多二月開始開始以寫完Leetcode前100題為目標，首先從Easy開始，然後是Medium，三月時開始以寫完Blind 75為目標，刷完一遍Blind 75後在去看前100題中的Hard題，最後在Onsite前一週努力刷Google面試的高頻率題，不得不說Leetcode Premium都將高頻題整理好了真的蠻方便的(而且真的蠻有用的XD)，這段期間每天會固定上去寫Daily，算是強迫自己每天維持解題手感，刷的題目數量，在Phone Interview前差不多150題左右，在Onsite之前差不多230題左右，相對於各路大神來說應該不算多，不過對我自己而言還算夠，各方面的題型都算是有顧到，自己的感覺是都能夠穩定的解出Medium，Hard則是可以想出可行解。比較可惜的是這段時間沒有找朋友幫忙Mock interview，面試經驗的累積是靠實戰累積，在這之前還面了Amazon、Nvidia。因為Google的Technical Interview至少會有兩關以上的全英文面試，英文也是很重要的一部分，雖然不用到Native specker那樣流利，但至少邏輯要能正確傳達，我英文的部分主要就仰賴實習的時候累積下來的，抱括日常聊天用語與解釋技術的能力，很感謝在這段時間願意跟我交流和我練習英文的人。這一段時間的刷題紀錄

刷題的三圍

時辰

2022/01/20 -> 收到朋友的內推通知信，官網投遞履歷，投的是Software Engineer, University Graduate, 2022 2022/03/07 -> 收到HR來信通知安排面試 2022/03/28 -> Phone Interview 2022/04/07 -> 通知通過Phone Interview，準備安排Virtual Onsite Interview 2022/04/25 -> 第一天Virtual Onsite Interview，兩關Technical Interview + 一關Behavior Interview 2022/04/26 -> 第二天Virtual Onsite Interview，兩關Technical Interview 2022/05/07 -> 通知面試結果most on positive 2022/05/26 -> 得知Hiring政策可能會異動

過程

要說面試有什麼最需要注意的，我會覺得是要保持平常心，這也是我認爲面試最困難的部分，畢竟在跟自己的夢想公司面試，興奮、期待、緊張等情緒交雜，很難保持平常心，在第一次Phone Interview時我甚至前兩天晚上都緊張到睡不著，能做的就是去Youtube上找各種國外講軟體工程師面試的影片來看，提醒自己面試該注意的點，英文類的也順便可以練習英文聽力，以下推薦幾個不錯的影片：

面試流程大解析，用SOP的方式講解軟體工程師面試，淺顯易懂
Google谷歌技术面试经验分享，這個講解面試的過程與注意事項講的很仔細，很有參考價值
How to tech interview Like a Pro，這個用搞笑的方式呈現程式面試的過程，蠻有趣的

Phone Interview

我差不多在預定時間的前十分鐘就坐在電腦前等，不過在預定時間點進去時面試官還沒上來，讓我緊張了一下以爲是不是記錯時間，等了差不多十分鐘後面試官終於來了，很抱歉的表示因為前面有一個會有一點耽擱到。面試官其實是一個親切的中國的小姊姊，一開始問了一個類似字串比對的問題，差不多是Easy等級，基本上一看到題目想到解法了，陳述了解法後面試官也同意這個解法，就花了10分鐘左右完成這題的coding，接著他表示有Follow up，比較像是會重複使用到第一題的概念屬於Medium等級，在思考這題的時候我原本以為只需要重複使用第一題的解法就行，結果發現我第一題使用的解法並非最佳解，到這邊其實有一點慌了，還好小姊姊人很好，不斷引導我去思考更好的解法，最終想出一個更佳的解法並花了幾分鐘實現，面試結束前小姊姊表示其實還有更好的解法，因此又花了幾分鐘請教一下，不過他表示這個解法他自己也沒有想到。個人評價，整體來說面試表現還行，解題並不是很流暢，中間卡了一下，但算是有解出來，所以也不到差。後來是通過了這一輪面試。

Onsite Interview

Technical Interview #1

這一關是一個人很不錯的中國的大叔，也沒有遲到，問了一題排序的變化題，一開始以為是Easy，但實際解下去後發現有Medium難度，完全錯估了這題的深奧程度，最一開始提了一個可行解，但面試官希望我提出最佳解，就這樣在這討論解法的30min中我至少提出了五六種解法，並分析在輸入範圍不同的情況下複雜度的差異，但我都沒有提出最佳解，後來在面試官的提示下想出了最佳解，但時間基本上已經用完了，我只能快速的將想法實作出來，後來想想自己實作的演算法是有Bug的，還好面試官人很好，並沒有很急著要結束面試，反而盡可能多留一些時間讓我完成面試，最後面試官回應我認為這是個很有趣的討論，認爲我提出了許多有趣的想法。有了Phone Interview的經驗後，並沒有讓我比較不緊張，反而一直很擔心面試官一上來就會來一題Hard，就面試情形而言自己覺得表現是比較糟糕的。

Technical Interview #2

這一關是一個懶得說話的小哥，問了一個類似尋找子字串的問題，他先請我思考一個brute force solution我基本上看完題目就有想法直接給出了解法，他聽完後也覺得可以因此就請我實作，我差不多花十分鐘實作完成並解釋了一下時間複雜度，接著希望我提出最佳解，對於最佳解自己其實沒什麼把握，只感覺字串應該可以用prefix tree來處理，因此提出了自己想法，沒想到他回應這是正確的思路，因此接續的想就給出了最佳解，還算順利的完成這一關，難度大概是Medium。在第一關爆掉之後這關心情反而輕鬆許多，有一點隨他去的感覺，大概是因為心情放鬆不少，反而思緒比較清楚，果然緊張才是大魔王。

Behavior Interview

這一關是一個中國的姊姊面試，首先問了一些蠻常見的Behavior question像是團隊的合作以及如何溝通，詳細題目網路上有蠻詳細的資訊，比較特別的是面試官問了一題有點類似產品設計的題目，因為事前完全沒有預料到，只能憑想像回答，但感覺面試官似乎沒有很滿意，面試最後有給個feedback認為我回答的沒有很深入，但他覺得我可能缺少工作經驗，因此回答的不深入也算預料之內。整體來說回答的算尚可，至少都有給出個穩健中庸的答案。

Technical Interview #3

第三關開始就變成了用英文面試，面試官還是中國小哥，不得不說跟同樣母語是中文的人用英文溝通難度真的低很多，可能是因為背後的思考還卡在中文的框架下。面試官問了一個tree traverse然後output路徑的題目，高度相似於leetcode上某題Google高頻題，剛好前幾天刷題有寫到，幾乎是秒想出最佳解，當然看到原題還是很興奮的，大概花了15分鐘講解完以及寫完code之後面試官給了我一個follow up，表面上是上面這題的延伸，但實際上已經轉換成BFS尋找兩點最短路徑的題目，還算是有趣的Follow up，這個變化在leetcode上就找不到了，這題同樣也是medium難度。

Technical Interview #4

第四關是一個沒有什麼表情的中國小哥，問了一個類似blind 75 pacific atlantic water flow的題目，看完題目後第一反應就連想到blind 75這題，事後也證明用同一題的方法可以解決這題，大概花了20分鐘講解跟寫完code後面試官同樣也給了follow-up，不過這個follow-up就沒有前一關有趣，只是單純數量上的增加，用同一題的方法改一下code就解決了，這題難度大概Medium。結果後來反而是這關的面試官認為我寫的code有些微的瑕疵，果然看到熟悉的題目還是不能太大意啊。

後續

我面試的時間已經算是Google 2022Campus Hire的末端了，大部分的缺都已經招完了，所以後來就變成直接沒有Headcount可以進行Team match，因此那時就有心理準備可能會需要等到下一年度的campus hire在繼續。

後來就如同大家所見的，在美國升息的壓力下各大公司開始被迫精簡人力，台灣這邊的campus hire也延到11月才開始，而headcount也必須要等到明年初人力政策確定後才會比較確定，好在面試結果可以保留一年，就祈禱明年還有機會可以繼續進行面試流程。

雖然尚未成功的進入我的Dream company，但這一路上還是很感謝許多人提供的機會以及幫助，此外也感謝協助我的Google HR不厭其煩的提供招聘流程的各種資訊。

機械相機系列 - 哈蘇A12片盒上片方法

Mon, 11 Jul 2022 17:10:00 +0800

機械相機系列 - 哈蘇A12片盒上片方法

前言

前陣子被朋友推坑敗了一台哈蘇500cm + CB 60mm 3.5f，作為中片幅底片單眼相機，其機械結構的精妙不言而諭，即便不帶出去拿在手上把玩依舊很過癮，從觀景窗看出去，蔡司的光學之美展露無遺，唯一的缺點就是碩大的機身跟重量實在不太方便帶出門，買了好一陣子卻一直被我冰在防潮箱，最近終於下定決心要用它好好來拍照，心血來潮就記錄一下如何使用哈蘇A12片盒更換底片，對於初次使用哈蘇攝影的小白才驚覺還有許多細節需要注意，完全不如135底片相機來的無腦，一不小心就可能毀掉一捲底片跟辛苦累積的12張攝影作品。

從一位老師傅那裡收過來的黑色塗裝Hasselblad 500cm，一般人印象中的哈蘇有著銀色不銹鋼的外邊，有種古典工藝品之美，全黑的哈蘇則有種現代感也更為低調，CB 60mm 3.5f則是從品光攝影購入的原本是想搭個中規中矩的80mm，可惜當時市面上的80mm價格太過嚇人，CB 60mm算是CP質很高的選擇，銳度畸變都很完美，視角也接近135片幅的35mm鏡頭，不過實際拍攝給人的透視感就完全不同。

開始裝底片

拆片盒

首先要做的是將片盒從機身上拆下來，將片盒上的圓鈕往圖片左邊的方向撥就可以解開卡楯將片盒拆下，要注意如果豆腐刀沒有插回片盒上時卡楯是撥不動的，硬撥的話可能會造成機械損壞喔，片盒拆下來後要小心不要碰到機身後的兩片長得像門一樣的遮光板，否則弄壞造成漏光就不好玩了。

抽出上片機構

接下來要將裡面的上片機構取出來，但在取出來之前務必先確定一下裡面是不是還有底片，如果有的話確認一下是不是已經完成回片，如果貿然取出上片機構的話會造成裡面底片漏光就慘了，再來只要將片盒一側的旋鈕從左邊的樣子轉成右邊的樣子在向外拉就可以將上片機構拉出來了，有時候可能會拉不出來，大多都是因為插刀叉反了卡住上片機構，所以記得插刀也是有方向性的。

交換片軸

拆出來的上片機構長這樣，原來在左側的是舊的片軸，需要將他換到右邊去，所以舊的片軸不要弄丟，如果弄丟也只能去~~找底片沖洗店家要了~~，哈蘇的片盒在拍完後會將底片回卷到舊的片軸上，所有每次都回留下上一次拍的底片的片軸。

底片

今天要裝的是Kodak的Portra 400底片，這捲應該是在底片種類越來越少的年代少數能讓人滿意的底片，色彩的寬容度與細緻度都比新的Gold 200還要好上許多，而且還有400度的ISO能提供比較高的快門速度，除了價格偏高外應該算是120彩色的首選了。

拆開120底片包裝後，需要撕開底片外部的紙封條，拉出來的這一段其實不是底片而是背紙，是120底片和135底片最大的差別，120底片因為沒有片殼，要防止底片意外曝光就需要靠背紙遮光，真正的底片是夾在背紙中間，拉到某一個位置會將真正的底片一起拉出來，真正的底片跟背紙是用一段紙膠帶黏起來的，詳細的結構可以參考這篇：120底片結構。

安裝底片

首先我們將底片安裝到右側原來放片軸的位置，請注意背紙拉出的方向，是從下方拉出的，不要將底片的方向裝反，接著將背紙拉到上片機構的背面。

將背紙繞到背面後，請注意在上片機構上有一個用來夾住背紙的結構，這個結構在拉出上片機構的時候是卡緊的，我們需要先將上片機構的旋鈕轉回原位這樣這個夾背紙的結構就會鬆開，才方便讓背紙從下面通過。

背紙通過之後在將上片結構的旋鈕轉回開啟的狀態，這個結構就會再夾緊背紙。

將背紙的末端穿過舊的片軸中心的孔洞。

最後我們旋轉另一側片軸下方的旋鈕收緊背紙，持續旋轉直到新底片側出現START箭頭(不一定有START)，這個箭頭會對齊片盒上的紅色箭頭，這樣就完成底片的安裝了。

裝回上片機構

裝回的時候請注意上片機構旋鈕的位置，需要將夾背紙的機構收緊上片機構才裝的進片盒中，裝進去後再將旋鈕轉回原位完成上片機構的安裝。

哈蘇的片盒需要將底片預先捲至最後一張，可以理解為哈蘇片盒是從最後一張開始拍的，因此需要選轉片盒另一側的旋轉把手直到片盒左下角的小窗出現數字1。

最後將片盒裝回機身就可以開始拍攝了，記得在裝回機身時確定機身已經是過片狀態了，否則裝上片盒再上片會讓底片少拍一張。

拍攝的時候要記得拔出片盒插刀，不然快門是按不下去的。

從觀景窗看出去的畫面，蔡司光學的成像真美呀。

實拍

附上一些Portra 400實拍的畫面給大家參考，紫羅蘭沖掃

遠東軟體園區正在蓋的Google新大樓

Google板橋辦公室門口的Logo

Google板橋大樓

Google辦公室樓下的貳樓餐廳

內湖往野柳的小路

風櫃嘴的展望

A12片盒的一些奇淫巧技

Google Interview Leetcode Question Challenge

Mon, 30 May 2022 11:41:18 +0800

Google Interview Challenge

https://www.1111.com.tw/1000w/fanshome/discussTopic.asp?cat=FANS&id=301667

https://www.gushiciku.cn/pl/gyQP/zh-tw

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

https://docs.google.com/spreadsheets/d/1yRCOJ8KysRVkq0O9IlDriT01tC6lzPapmFO4PCmDJQA/edit#gid=126913158 Google面試準備刷題類型

Arrays
Binary Search Tree
Binary Tree
Dynamic Programming
Greedy
Graph – BFS、DFS
Heap
LinkedList
Recursion
Searching – Binary Search、Quick Select
Stack
String
Sorting
Topological sorting
Trie

Google面試經典題目

coin change
coin change 2
Unique path
Unique path 2
Permutation
Permutation 2
subset
subset 2
search in rotated sorted array
search in rotated sorted array 2
word break
word break 2
jump game
jump game 2
word search
word search 2
combination
combination 2
meeting room
meeting room 2
number of islands
number of islands 2
number of distinct island
number of distinct island 2

BQ準備 Imagine you worked in a project or a team that had a problematic culture Tell about the leading experience of a group project Thinking about a time you were given a large amount of work to complete under the tight deadline Tell about a time you face a problem without having clear solution How do you solve the conflict that happen in the team

Array

Binary

Dynamic Programming

Graph

Clone Graph
Course Schedule
Pacific Atlantic Water Flow (M)
Number of Islands
Longest Consecutive Sequence (M)
Alien Dictionary (Leetcode Premium) (H) Key: directed graph + DFS or BFS
Graph Valid Tree (Leetcode Premium) (M) Key: Check edges number first and then check unconnected component (Graph theory), Union Find!
Number of Connected Components in an Undirected Graph (Leetcode Premium) (M)

Interval

Insert Interval
Merge Intervals
Non-overlapping Intervals (M) Key: greedy
Meeting Rooms (Leetcode Premium)
Meeting Rooms II (Leetcode Premium)

Linked List

Matrix

String

Longest Substring Without Repeating Characters
Longest Repeating Character Replacement
Minimum Window Substring (H) Key: Optimized Sliding Windows!
Valid Anagram
Group Anagrams
Valid Parentheses
Valid Palindrome
Longest Palindromic Substring Key: Manacher’s Algorithm
Palindromic Substrings (M) Key: Manacher’s Algorithm
Encode and Decode Strings (Leetcode Premium) (M)

Tree

Heap

Tips

https://hackernoon.com/14-patterns-to-ace-any-coding-interview-question-c5bb3357f6ed

Funny One

Count Unique Characters of All Substrings of a Given String Key: really special solution
Find the Duplicate Number
Find Leaves of Binary Tree
Split Array Largest Sum Key: Binary Search!!!
Trapping Rain Water
The Skyline Problem Key: Select the building with heapqueue
Largest Rectangle in Histogram Key: tricky Apply with stack!!!
Subtree of Another Tree Key: Markle Hash
Substring with Concatenation of All Words Key: Sliding Window
Longest Valid Parentheses key: Two pointer or DP or Stack
Best Time to Buy and Sell Stock IV Key: Tricky One pass solution (DP or O(k) space)
Design HashSet Key: Multiplicative hashing
Unique Binary Search Trees Key: Catalan number!
Shortest Path in a Grid with Obstacles Elimination Key: BFS + A*
Student Attendance Record II Key: hardhard DP
Guess the Word Key: Game theroy, compare with previous
Min Cost to Connect All Points Key: minmun spanning tree!! (Prim’s or )
Path With Minimum Effort Key: Binary search space
132 Pattern Key: stack+min array