這次 Snowflake Backend SDE 的電面整體體驗非常“工程向”。題目本身不追求花哨演算法，但每一輪都在追問：如果這是你日常在寫的後端系統，你會怎麼設計？
下面是我當時在輔面階段大概記錄下來的內容，整理成一次完整覆盤，供準備 Snowflake / 偏後端系統方向的同學參考。
Coding Round 1：支援事務的 Key-Value Store（常數複雜度）
題目本體：
實現一個簡單的 key-value store，支援：
get(key)set(key, value)remove(key)
這一部分很基礎，用 HashMap 就能快速完成。
Follow-up（真正的考點）：
在上述基礎上，支援以下事務操作：
begin()commit()rollback()
並且要求操作的時間複雜度是 O(1)（至少是均攤意義）。
面試官真正關心什麼？
這道題不是在考 API，而是在考：
- 你對 事務 / 回滾 / 狀態隔離 有沒有工程直覺
- 能不能想到 log / stack / shadow copy / 多版本 這些設計手段
- rollback 的成本你有沒有提前考慮，而不是寫完才發現很難退回
整個過程中，面試官會不斷追問：
- 如果巢狀 begin 怎麼辦？
- commit 的語義是合併還是覆蓋？
- rollback 時如何保證不掃描全量資料？
如果你只是寫了一個“能跑”的實現，很容易被追問到卡住。
Coding Round 2：樹的高度 + 結構修改下的最優解
基礎題：
給定一棵樹，計算樹的高度。
這是一個非常標準的 DFS / BFS 題，幾乎沒有難度。
Follow-up（難度明顯上升）：
給定一個目標 height，問最少需要刪除多少個 node，才能讓樹的高度 ≤ height。
刪除某個 node 後，它的所有子節點會直接變成該 node 父節點的子節點。
這題在考什麼？
這道題非常 Snowflake 風格：
- 表面是樹
- 實際是在考 結構變化後的全域性最優策略
關鍵難點在於：
- 刪除節點並不是“整棵子樹沒了”
- 而是子節點會上移，重新參與高度計算
所以這題不是簡單的“砍最深的節點”，而是要你思考：
- 哪些節點的刪除，對整體高度影響最大
- 如何自底向上做決策，而不是暴力模擬
面試官會重點看你的：
- 思路拆解能力
- 是否能清楚解釋為什麼這樣刪是最優
- 而不是程式碼有多漂亮
System Design：Quota Management Service（非常貼近真實後端）
題目：
设计一个 quota management 服务，支持：
- 申请 quota
- 归还 quota
- 每個使用者有 quota 上限
- 需要考慮「申請了 quota 但沒有使用」的情況
面試官的風格
這一輪面試官非常嚴謹，全程在抓你做 back-of-the-envelope：
- 併發使用者有多少？
- quota 的粒度多細？
- 超時未使用的 quota 怎麼回收？
- 是 push 回收，還是 lazy 回收？
明顯不是要你畫一個很“漂亮”的架構圖，而是看：
- 你會不會從 真實業務約束 出發
- 有沒有意識到資源浪費、鎖競爭、延遲一致性這些問題
如果你只停留在“用 Redis + DB + API”這種層面，會被追問得很深。
Behavioral：不走套路，但本質仍是 STAR
這一輪幾乎沒有傳統的行為面模板題（比如“和同事有分歧怎麼辦”那種）。
而是：
- 全程圍繞你做過的專案
- 細摳設計決策、權衡、失敗經驗
印象最深的一道題
如果老闆給你一個 business metric，讓你負責提升公司在這個 metric 上的表現，你會怎麼做？
如果目標是提升 20%，你怎麼拆解？
這道題非常典型 Snowflake：
- 不考情緒管理
- 考的是 工程師如何對 business 負責
面試官關注點包括：
- 你會不會先定義 metric 的組成
- 能不能拆成可行動的子指標
- 如何評估哪些改動是“高 ROI”的
即使不是標準 STAR，但用 STAR 的結構去組織答案依然非常有用。
總結：Snowflake Backend SDE 在找什麼樣的人？
整體面下來，我最大的感受是：
- 不太吃“刷題型選手”
- 非常看重 工程思維 + 業務理解 + 設計拆解能力
如果你準備 Snowflake 或類似偏後端 / 資料系統的公司，建議重點準備：
- 帶狀態的系統設計（transaction、quota、resource management）
- 能被追問很深的資料結構題（不是一行寫完那種）
- 如何把技術決策和 business metric 聯絡起來
寫得出程式碼只是起點，解釋得清楚“為什麼這樣設計”才是關鍵。
為什麼工程型面試更需要實時面試輔助
如果你在準備 Snowflake 這類強工程、強追問的後端面試，其實很多人卡的並不是“不會寫”，而是當場思路發散、被連續 follow-up 拉崩。我們做的 面試輔助服務 ，能幫你把工程思維穩住：在 Coding 輪協助你快速釐清資料結構與複雜度取捨，在 System Design 時實時提醒關鍵邊界條件（併發、回收、超額、異常路徑），在 Behavioral / Business Question 中幫你把零散經歷迅速組織成有邏輯、有指標、有決策依據的表達。尤其像 Snowflake 這種愛深挖設計合理性的面試，有一個“站在你背後的工程視角校準器”，往往能決定你是被追問壓垮，還是把面試節奏牢牢掌控在自己手裡。
