拼多多服務端一面題目流出：電商後端的面試，考的全是帳本能不能對上

2026 年 10 月 11 日上午十一點，一位求職者在牛客網記下了自己第二次挑戰拼多多的經歷，時長一個小時，結果是「再次含恨」。貼文於次日發出後，吸引了不少同屆秋招的人留言詢問結果與細節。這份題目清單本身，比「過沒過」更值得看：整場面試幾乎沒有脫離 MySQL、Redis、訊息佇列與 Spring 事務這幾個主題，最後搭配兩道手寫演算法題。

這與我們先前分析的TikTok 後端一面題目流出方向不同：TikTok 那份考卷有超過半數圍繞 AI Agent 工程設計，而拼多多這一份，仍以交易系統的資料一致性為絕對核心。

考題結構：一條慢 SQL 貫穿全場

從題目安排看，面試官的提問路徑相當有秩序。先從求職者履歷上的 MySQL 查詢優化經驗切入，追問聚合查詢統計的是哪些業務指標、指標是每天計算還是只算一次、有沒有用視窗函數。這一連串追問的用意很明確：驗證履歷上的專案是親手做的，還是照著文件複述的。

接著進入通用題組。慢 SQL 怎麼排查、EXPLAIN 要看哪些欄位、面對 user_id 與 state 兩個等值條件加 create_time 範圍查詢與排序時索引怎麼設計、哪些情況會讓索引失效。資料庫設計題也沒有停留在標準答案層面：什麼時候該加冗餘欄位、用戶表能不能直接冗餘存地址、冗餘與資料庫範式衝突時怎麼權衡。這類題目沒有唯一正解，考的是求職者能不能講出取捨的理由。

Redis 段落同樣沿著一條主線走：快取與資料庫的一致性。先更新資料庫再刪快取還會不會不一致、延遲雙刪之外還有什麼方案、透過監聽 MySQL Binlog 經訊息佇列更新快取有什麼好處。訊息佇列段落接著問訊息不丟失、消費者處理到一半宕機怎麼辦、冪等性怎麼實現。最後是 Spring 的 @Transactional 在哪些情況下失效。

把這些題目放在一起，會發現它們其實在問同一個問題：當訂單、庫存、付款分散在多個系統裡，任何一環斷掉，帳還能不能對上。

為什麼電商後端特別怕「對不上帳」

用日常情境打個比方。一家超商的收銀機、倉庫帳本和會計系統如果各自記各自的，某臺收銀機當機重開後補記了交易，倉庫那邊卻沒同步，月底盤點就會出現對不上的差額。電商後端工程師的日常，就是設計規則讓這三本帳在任何當機、重試、網路延遲的組合下仍趨於一致。

這也解釋了為什麼拼多多這場面試不考新名詞。快取一致性、訊息冪等、事務失效，這些都是交易系統裡最老也最貴的問題：一旦出錯，直接反應在訂單金額與庫存數字上，使用者看得到，財務也看得到。延遲雙刪、Binlog 監聽這些方案沒有時髦之處，但它們是在高併發場景裡被反覆驗證過的工具。

相比之下，Bigo 後端一面題目流出那份考卷反映的是直播與串流平臺的焦慮，重點放在串流穩定性與高併發架構；拼多多的考題則更貼近交易的每一分錢。

手寫演算法：二分插入排序與會議室問題

最後兩道手撕題，第一題是二分插入排序，第二題是 LeetCode 253 原型：給定一組任務各自的起訖時間，計算至少需要多少執行緒，且同一執行緒不能同時執行兩個時間重疊的任務。這題在臺灣的工程圈常被稱為「會議室最少需要幾間」，考的是區間排程與貪婪或掃描線的判斷。

演算法題只佔一小時的尾段，這個比重本身就是訊號。對這類崗位，演算法是門檻，資料庫與中介軟體的深度才是分水嶺。

求職者能讀出什麼

對正在準備服務端崗位的求職者，這份題單提供了一份務實的複習地圖。與其追逐框架新版本的功能列表，不如把幾個經典問題的完整推理走一遍：一條慢 SQL 從發現到修復的全流程、快取不一致的每種情境與對應方案、訊息佇列從生產到消費端的不丟失與不重複機制、Spring 事務傳播與失效條件。面試官追問的方式顯示，能講出「為什麼選這個方案、放棄了什麼」的人，比背出方案名稱的人走得更遠。

發文的求職者寫下「再次含恨」，但題單留在版上，對下一批投遞的人來說，這一個小時的題目比結果更有參考價值。