各家公司的行為面試相似遠多於相異，但來自小公司或傳統企業的候選人常卡在「把自身經驗翻譯成大廠面試官期待的樣子」。跳到 FAANG+ 要跨過兩大挑戰：規模移轉與文化移轉（矽谷神話）。技術夠強不代表 story 會引起共鳴。
🧠 Intuition
TIP
你不需要真的擁有大廠規模才能拿 offer——所有員工都曾是新人。你需要的是調整語言與框架：把「被指派、穿越流程、服務數千人」的敘事，重寫成「主動當責、數據驅動、系統性影響」的Builder 語言。神話不是字面為真，而是心理上為真——它決定面試官對你「感覺對不對」的直覺判斷。
大廠規模的差異體現在四處：使用者與系統（數十億 vs 數萬）、組織（一決策擴散到數萬人、一專案橫跨數十團隊）、步調（付得起最好人才，也期待快速交付）、衡量與影響（幾乎衡量一切，成功用指標、決策由數據驅動）。但光靠規模現實無法解釋卡關——真正的斷裂來自文化：大廠優先看重某些行為、態度、語言與工作方式。
🏛️ 六大矽谷神話與 Builder 改寫 (Frameworks)
這些神話的英雄稱為建造者（the Builder）：創造技術解方、驅動影響力、體現神話所頌揚價值的人。理解原型，你就能用自然引起共鳴的方式呈現經驗。
六大神話 × 一般說法 vs Builder 說法
- 從車庫出發（Out of the Garage）：從手上有的資源開始，不等萬事俱備；機智勝過舒適，限制激發創意。是 owner、是創業者。
- 一般：「我向基礎架構團隊提出增加伺服器容量的申請。」
- Builder：「我說服基礎架構團隊，額外投資會透過提升留存率回本。」
- 獨行駭客（The Lone Hacker）：高度看重個人努力與專業，敢冒險、在反對聲中堅持正確；斬斷繁文縟節、清楚直接溝通。
- 一般：「我的主管指派我負責這個功能……」
- Builder：「我主動接下了這個功能……」
- 快速行動、打破成規（Move Fast）：偏好行動勝於分析；在資訊不完整下決策、策略性走捷徑、在正式環境學習。最大風險是打磨時被競爭者搶先。
- 一般：「我們把上線延後兩週打磨 UI。」
- Builder：「我們權衡了延遲 vs 照現況出貨——品牌受損的風險太大了。」
- 快速失敗（Fail Fast）：不帶恐懼地承認什麼行不通、及早浮現問題、迅速轉向；延伸到無咎責事後檢討（blameless postmortem）。
- 一般：「由於市場變化，我們不得不調整交付項目。」
- Builder：「我很早就意識到原方法行不通，砍掉它、把資源重新分配到更有希望的方案。」
- 擁抱衝突（Embrace Conflict）：主動發起關於分歧的困難對話，帶數據與原型化解爭議；相信智識摩擦比虛假和諧產生更好解方。
- 一般：「有分歧時，我們上呈管理層裁決。」
- Builder：「我不認同做法時，安排會議、帶佐證數據提出替代方案。」
- 改變世界（Change the World）：以全公司甚至全球層級的影響力框架工作，把技術定位為人類進步的力量。
- 一般：「新功能提升了客戶滿意度分數。」
- Builder：「我做這功能，是幫小企業主每週省下數小時手動作業，讓他們專注在成長。」
成為 Builder：回答調整清單
- 強調當責（Ownership）：超越被指派的任務、為結果負責，即使得跨出正式職責。
- 數據驅動的語言：不說「我改善了部署流程」，說「把部署從 2 小時縮到 15 分鐘，每月為 20 人團隊省約 40 小時」。
- 拉高影響力層級：資料庫最佳化不只加快查詢，還改善整個客戶群體驗、降低基礎架構成本——用「系統性影響」框架。
- 用大廠術語：不說「試了個新功能」，說「對新使用者體驗做了 A/B 測試」。
- 系統思維：「我考量使用者成長 10 倍後如何擴展，據此設計資料模型。」
- 協作與直接溝通：把「和設計師、PM 對齊」升級為「協調設計、產品、工程三方」；直接提出分歧、用數據化解、視良性衝突為更好結果來源。
- 主動性（Initiative）：把「主管指派我改善結帳」改成「結帳放棄率很高，於是我著手重新設計以減少摩擦」。
- 快速迭代：若前公司釋出慢，就用 side project、黑客松、試行計畫展現你被快節奏激勵、而非壓垮。
🏢 各廠差異 (Company Nuances)
- Amazon：把整個流程建構在 16 條 Leadership Principles 上，投入大量時間評估行為；熟悉並在回答中自然使用其術語很重要。
- Google：相對更側重技術評估。
- Meta：介於兩者之間。所有公司在資深職位上都非常看重行為面試。多數大廠而言，理解核心訊號面向比背誦公司專屬用語更重要。
⚠️ 該避免的模式 (Pitfalls)
- 免責聲明：「我知道這沒你們做的那麼大，但……」
- 防衛性語言：「我們沒有大公司才有的工具。」
- 貶低自身價值：「我們只服務了幾千個使用者……」
- 過度強調流程：只講穿越了多少官僚流程，而非克服了什麼障礙。
- 有限的當責：敘事中透出「那不是我的工作」的態度。
🗣️ Discussion Log
（尚無紀錄。用 /note-enrich big-tech/big-tech-behaviorals 或 note 討論把你的 story 改寫成 Builder 語言。）
🔑 Takeaways
- 大廠面試兩大挑戰：規模移轉（使用者/組織/步調/衡量）與文化移轉（六大矽谷神話）。
- 神話是心理真實而非字面真實；用 Builder 語言（當責、數據、拉高層級、系統思維、直接溝通、主動、快速迭代）重寫既有經驗。
- Amazon 重 LP、Google 重技術、Meta 居中；但核心訊號面向通用性最高。避免免責、防衛、貶低、過度流程、有限當責五種模式。