大型科技公司的行為面試#
雖然各家公司的行為面試相似多於相異，但來自小公司或傳統企業的候選人，常在「把自身經驗翻譯成 Big Tech 面試官期待的樣子」這件事上卡關。他們技術往往夠強，但跳到 FAANG+ 會遇到兩大挑戰：規模（scale）與文化（culture）。
如果你已在 FAANG+ 或矽谷新創歷練過，可能早已有調整 story 的直覺；但若你來自不同產業、地區或公司文化，本章會幫你解讀這些「不成文的期待」，並重新編碼你的回答。
規模的移轉（The Shift in Scale）#
「因為規模。」這是我問候選人為何想加入 FAANG+ 時最常聽到的理由，也很合理：那裡的影響力、技能成長與職涯成長都最大。Big Tech 的規模差異體現在方方面面：
- 使用者與系統：數十億使用者跟數萬使用者是兩回事。程式碼庫的複雜度、彼此交錯的系統數量都極端龐大。
- 組織：服務數百萬到數十億人需要大量員工。一個決策的影響會擴散到數萬甚至數十萬名員工；一個專案需要橫跨數十個團隊、多種職能協調。
- 步調（Pace）：Big Tech 付得起最好的人才，也期待他們快速交付。個人常被期待同時處理多個專案，且時程積極。
- 衡量與影響（Measurement and impact）：因為做得到，Big Tech 幾乎衡量一切。成功以指標表達、決策要求嚴謹地由數據驅動。這也延伸到職涯規劃與績效管理，每個人的貢獻都被量化與比較。
文化的移轉：矽谷神話（Silicon Valley Mythos）#
但光靠規模的現實，並不能解釋候選人為何卡關。即使技術與組織經驗都對，他們的 story 往往「無法引起共鳴」。這種斷裂源自 FAANG+ 文化如何優先看重某些行為、態度、語言與工作方式——這是在結構化的訊號面向之外，另一層評估：那些決定你「感覺對不對」的直覺文化模式。
對某些帶偏見或訓練不足的面試官而言，「culture fit」可能只是你念的學校、外貌、能不能一起喝杯啤酒。這些對建立成功的招募實務毫無幫助。但在這之下，還有更深的東西：關於「科技界的成功長什麼樣」的不成文期待。
這些移轉細微又相互交織，是「感受到的」而非「條列出來的」。與其給你一串零散建議，作者選擇揭示形塑 Big Tech 文化的底層神話（mythology）。理解這些原型故事，能讓你用自然引起共鳴的方式呈現經驗。
這些故事之所以稱為「神話（myth）」，是因為它們並非字面為真，而是心理上為真。它們根深柢固，卻不會寫進員工手冊；它們比公司價值觀宣言更有力量——因為那些價值觀正是從這些神話中提煉出來的。
作者也坦承這些故事可能強化有害的刻板印象，且聚焦於矽谷的形成期，其他科技樞紐另有自己的故事。理解它，是為了先看清我們想改變的世界。
這些神話的英雄，作者稱之為建造者（the Builder）：創造技術解方、驅動影響力、體現這些神話所頌揚價值的人。以下逐一檢視定義科技文化的核心神話，以及 Builder 如何框架自身經驗，讓它在 Big Tech 行為面試中引起共鳴。
從車庫出發（Out of the Garage）#
Builder 從手上擁有的資源開始，而不是等到萬事俱備。刻苦的機智勝過資源充裕的舒適；限制激發創意。你從小處起步，先證明概念可行，再從那裡擴展。Builder 是個 owner、是創業者；即使在較傳統的由上而下的組織裡，也能想辦法快速推進。
神話原型與 Builder 語言範例
1938 年，兩位史丹佛畢業生 Bill Hewlett 與 Dave Packard 在加州 Palo Alto 一間小車庫裡，湊了 538 美元與一個夢想，做出第一件技術產品——不只創立了自己的公司，也開啟了矽谷本身。六十年後，Larry Page 與 Sergey Brin 租下 Susan Wojcicki 位於 Menlo Park 的車庫作為 Google 第一個辦公室；Jeff Bezos 甚至特地在西雅圖找有車庫的房子，好讓自己能說 Amazon 是「從車庫起家」。這個傳統延續到今天的「war room」——狹小的會議室裡，小團隊靠決心而非預算，埋頭交付關鍵功能。
改寫對照：
一般說法：「我們依採購流程評估了各家廠商方案，因 SOC2 需求選了推薦的企業平台。」
Builder 說法：「我判斷採用廠商方案能讓我們更快上市，代價是使用者體驗上的一些限制；它還有個好處，是讓我們在 SOC2 合規上搶得先機。」
一般說法：「我向基礎架構團隊提出增加伺服器容量的申請以因應負載。」
Builder 說法：「我說服基礎架構團隊，額外的伺服器投資會透過提升客戶留存率回本。」
獨行駭客（The Lone Hacker）#
Builder 高度看重個人努力與專業，即使身處團隊環境。他們敢冒險、在反對聲中堅持正確、追尋別人斥為不可能的想法。他們斬斷繁文縟節、不講「商業套話」，而是清楚直接地溝通。
神話原型與 Builder 語言範例
Linus Torvalds 在赫爾辛基大學就讀時創造了 Linux；Susan Kare 在方格紙上畫出第一代 Mac 的像素圖；John Carmack 在 id Software 以整週的程式閉關革新 3D 圖學；Mark Zuckerberg 在哈佛宿舍打造 Facebook。這個「獨行駭客」原型延續為「10 倍工程師（10× engineer）」的迷思，也延續為離開傳統人生路、成為傳奇科技 CEO 的輟學生。
改寫對照：
一般說法：「我的主管指派我負責這個功能……」
Builder 說法：「我主動接下了這個功能……」
一般說法：「團隊在每週檢視中發現效能問題。」
Builder 說法：「我在監控數據中注意到異常模式，團隊後來確認那是效能瓶頸。」
一般說法：「我們發揮跨職能綜效來發想擴展性挑戰的解方。」
Builder 說法：「我與平台團隊合作，修復了我們的效能瓶頸。」
快速行動、打破成規（Move Fast and Break Things）#
Builder 偏好行動勝於分析。市場變動太快，等不及完美方案。主動意味著在資訊不完整下做決策、策略性地走捷徑、在正式環境（而非規劃會議）中從失敗學習。在矽谷，最大的風險不是交付了不完美的東西，而是你還在打磨時競爭者先出手了。Builder 擁抱快速變化，隨時準備依市場調整策略、充滿活力地學習新技能。
神話原型與 Builder 語言範例
「真正的藝術家會出貨（Real artists ship）」——Steve Jobs 在 1980 年代初對 Mac 團隊如此宣示，推著他們帶著不完整、勉強能跑的功能上線。把產品送到使用者手上，比追求完美更重要。Mark Zuckerberg 把這哲學做成了半官方口號「Move Fast and Break Things」，貼滿 Facebook 的牆；Google 則以「永久 beta」呼應——Gmail 掛著 beta 標籤五年，持續出貨改進，把數百萬使用者當成願意共同開發的夥伴。
改寫對照：
一般說法：「我們遵循標準安全審查流程，確保符合公司政策。」
Builder 說法：「我提早處理安全需求，以避免任何可能延誤上線的意外。」
一般說法：「我們把上線延後兩週，處理所有剩餘邊角案例並打磨 UI。」
Builder 說法：「我們權衡了延遲 vs 照現況出貨的影響——但品牌受損的風險太大了。」
快速失敗（Fail Fast）#
Builder 不帶恐懼地承認什麼行不通、及早浮現問題、迅速轉向可行的方案。這套哲學也延伸到團隊如何處理錯誤與故障。
神話原型與 Builder 語言範例
YouTube 起初是使用者上傳自拍影片的交友網站；Pinterest 前身是沒人要的購物 app「Tote」；Slack 從失敗的遊戲公司 Tiny Speck 廢墟中誕生；Instagram 原本是雜亂的打卡 app「Burbn」，直到創辦人砍掉一切、只留下照片分享。這些創辦人沒花數年硬撐第一個點子，而是觀察使用者行為、快速承認失敗、轉向真正有起色的方向。
這套哲學也延伸到事故處理：John Allspaw 把航空業的「無咎責事後檢討（blameless postmortem）」帶進科技界（先在 Flickr、後在 Etsy）。怪罪飛行員會讓飛行更不安全，因為這會讓人不敢通報近失事件；同理，若你為了故障責怪工程師，他們只會藏起問題而非攤開它。
改寫對照：
- 一般說法：「由於市場變化，我們不得不調整時程與交付項目。」
- Builder 說法：「我很早就意識到原本的方法行不通，於是砍掉這個專案，把資源重新分配到更有希望的方案上。」
擁抱衝突（Embrace Conflict）#
Builder 主動發起關於分歧的困難對話。他們帶著數據、原型、概念驗證來化解爭議；相信好點子能來自組織的任何角落、無關階層，也相信智識上的摩擦比虛假的和諧產生更好的解方。
神話原型與 Builder 語言範例
矽谷的形成期正逢 1960 年代西岸的反文化運動，挑戰傳統權力結構、反階層的管理方式成了競爭優勢。避免衝突的代價，在矽谷最早的警世故事中顯露無遺：William Shockley 發明了電晶體，但他多疑的管理風格逼走了八位最有才華的員工。這「八叛徒（Traitorous Eight）」出走成立 Fairchild Semiconductor，打造出商業上最成功的電晶體公司，並催生了現代半導體產業。後來，八人之一、Intel 創辦人 Andy Grove 把這套哲學制度化為「建設性對抗（constructive confrontation）」，鼓勵工程師積極挑戰彼此的想法。創投也放大了這種「良性衝突」文化，把嚴厲質問創辦人假設的「tough love」變成常態——在那裡，犯錯不如「未受挑戰」危險。
改寫對照：
一般說法：「有分歧時，我們上呈管理層裁決。」
Builder 說法：「當我不認同提議的做法時，我安排了一場會議，帶著佐證數據提出我的替代方案。」
一般說法：「工程資源有競爭，我們透過正規管道爭取專案被排優先。」
Builder 說法：「拿不到需要的工程資源時，我帶著客戶影響的數據，直接向領導層陳述商業理由。」
改變世界（Change the World）#
Builder 著手處理人類面臨的根本挑戰。他們至少以「全公司層級」、甚至「全球層級」的影響力與社會轉型來框架自己的工作，把技術定位為人類進步的力量。他們是樂觀主義者。
神話原型與 Builder 語言範例
Steve Jobs 想「在宇宙留下凹痕」，把個人電腦定位為讓人類擺脫從眾的解放工具；Bill Gates 在多數人沒見過電腦時就宣示「讓每張桌子、每個家庭都有一台電腦」；Google 從「組織全世界的資訊」出發；OpenAI 以「確保 AGI 造福全人類」為使命；Elon Musk 更要讓人類成為跨行星物種。
改寫對照：
一般說法：「新功能提升了客戶滿意度分數，達成了業務需求。」
Builder 說法：「我做這個功能，是要幫小企業主每週省下數小時的手動作業，讓他們能專注在成長上。」
一般說法：「自動化專案消除了手動任務、提升了團隊效率。」
Builder 說法：「我把這些流程自動化，消除那些讓工程師心力交瘁的重複工作，好讓他們專注在直接影響使用者的功能上。」
成為 Builder：把回答調整成 Big Tech 的樣子#
你不需要真的擁有這一切規模或文化的經驗才能成功——所有員工都曾是 Big Tech 的新人。但你確實需要調整行為面試中使用的語言與框架：
- 強調當責（Ownership）：談你如何超越被指派的任務、在乎並為結果負責，即使得跨出正式職責。
- 使用數據驅動的語言：別說「我改善了部署流程」，改說「我把部署時間從 2 小時縮到 15 分鐘，這能為我們 20 人的工程團隊每月省下約 40 小時」。
- 拉高影響力的層級：你的決策影響力常比你以為的更廣。那個資料庫最佳化不只加快查詢，還改善了整個客戶群的體驗、降低了基礎架構成本。用「系統性影響」來框架決策。
- 使用能顯示你熟悉 Big Tech 實務的術語：別說「我們試了個新功能」，改說「我對新的使用者體驗做了 A/B 測試」。
- 展現對現代模式的熟悉：即使前公司做法不同，你仍能展現前瞻性。「雖然我們用單體架構，但我在設計功能時劃清了服務邊界，未來要拆成微服務會很直接。」
- 表達系統思維：「實作這個功能時，我考量了使用者成長 10 倍後如何擴展，並據此設計了資料模型。」
- 強調與他人協作：突顯任何跨組織邊界的經驗，即使那些「團隊」只是小公司裡的不同角色。把「我和設計師、PM 對齊需求」升級為「我協調了設計、產品、工程三方，確保在使用者體驗與技術可行性上對齊」。
- 描述直接溝通：科技界期待你直接提出分歧、用數據化解爭議、把良性衝突視為更好結果的來源。迴避困難對話或一味順從階層，會被視為軟弱。
- 強調主動性（Initiative）：把「主管指派我改善結帳流程」改成「結帳放棄率很高，於是我著手重新設計以減少摩擦」。
- 展現對快速迭代的自在：若前公司釋出週期較慢，就強調你在 side project、黑客松或試行計畫中的快速迭代經驗，展現你是被快節奏環境激勵、而非壓垮。
結語與陷阱#
如果你已花了幾年打造使用者真正在用的技術，你的 story 對 Big Tech 大概就夠了：面試官想理解你如何跨越整個軟體開發生命週期運作，而這你都做過，所以就好好告訴他們每個環節。
務必避免這些模式：
- 免責聲明：「我知道這沒你們做的那麼大，但……」
- 防衛性語言：「我們沒有大公司才有的工具。」
- 貶低自身價值：「我們只服務了幾千個使用者……」
- 過度強調流程：story 只講你穿越了多少官僚流程，而非你克服了什麼障礙。
- 有限的當責：敘事中透出「那不是我的工作」的態度。