一份被排好順序的題目清單：BIGO 後端二面，先是一張可閱讀的介面

9 月初，牛客網上出現一篇標題樸素到近乎制式的貼文：「BIGO後端二面」。沒有修辭，沒有情緒詞，正文就是一份題目清單，按「RAG 項目」「點評項目」「八股」「手撕」四個區塊依序列出，共二十幾個問題。發文者只留了一句「主要問的項目，項目問完了問的八股」，像是在替這份清單寫下最簡短的圖說。

這類面經在求職社羣裡每天都在產出，但把它當成一份被設計出來的文件來讀，會發現一場技術面試的結構、優先順序與價值判斷，其實全都排在題目的順序與措辭裡。

先從第一個區塊的措辭看起

清單的第一段是 RAG 項目，十二個問題。開頭三題問的全是邊界條件：「如果是有單號這種關鍵信息怎麼辦」「多個單號怎麼對應上」「段落語義是怎麼劃分？是固定 1000 字符，然後有 200 重疊的嗎」。

第三題尤其值得停下來看。面試者自己把技術細節寫得非常精確：固定一千字符、兩百重疊，這是做文件切分的標準參數。問題把它原樣複述一遍，再補上「你覺得有什麼缺點」，等於是在說：我知道你做過，現在我想看你能不能站在外面看自己做的東西。這種「複述加反問」的句式，在這份清單裡反覆出現，構成了整場面試的語法。

第五到第七題則換了一種問法。「系統會能保證到用戶不會檢索到其他用戶的物流資料信息嗎」，這一題表面上問的是 RAG 的檢索隔離，實際上是在問一個更商業的問題：一套對話系統在物流場景裡，資料邊界畫在哪裡。清單裡完全沒有「請介紹一下 RAG 原理」這類教科書句式，所有題目都從具體情境倒推回系統設計，這是這份面經最明顯的篩選傾向。

中段的節奏：從開放式收攏到封閉式

第二個區塊「點評項目」的題目密度更高，句式也更短。「點贊有持久化嗎」「MySQL 計數失敗怎麼辦」「怎麼保證消息不丟失」。與第一區塊相比，這裡的問題幾乎都是封閉式的，答案指向明確：要嘛有，要嘛沒有；要嘛能保證，要嘛不能。

這種由寬收窄的排列，本身就是一種節奏設計。前半場讓面試者說，後半場讓面試者答。到 Redis ZSet 那一題，「爲什麼用跳表這種結構而不是樹」，問的已經是資料結構的取捨理由，等於把整場對話壓縮回最古典的電腦科學語彙。一份面經讀到這裡，能看出面試官的注意力是怎麼移動的：先跟著你的專案走，再把話題一層層剝回地基。

八股與手撕：清單的收尾版面

第三區塊的「八股」只有七題，全部繞著 Spring 事務與 ThreadLocal 打轉。開頭三題連成一條線：普通方法呼叫事務為何失效、多執行緒呼叫能否生效、異步呼叫加了註解的方法如何生效。三題共用同一個場景，只改動一個變數，像一組控制變數的對照實驗。這種連環追問的排列方式，比任何單一題目都更能說明面試官想測什麼：不是背誦，是同一個機制在不同呼叫路徑下的行為推演。

最後一行是「手撕字典序，恰好比當前排列大的下一個排列」。經典的 LeetCode 第 31 題。它出現在清單的最末端，篇幅只佔一行，卻是整份文件的定錨點：前面二十幾個問題都在對話裡發生，只有這一題要在白板或編輯器裡留下可檢驗的產物。這與我們先前在少數派七月購物清單的設計觀察裡看到的現象類似：一份清單的說服力，往往取決於它最末端那個最具體的物件。

求職社羣怎麼閱讀這份清單

貼文底下的留言也很誠實。「這家問的東西可真不少啊」「蹲後續」「後續還有幾面啊」。沒有人討論題目本身的難度，大家的問題都指向流程：還有幾面、什麼方向、多久有結果。對正在秋招的人來說，這份清單的價值不在於題目可以被準備，而在於它透露了一家公司二面的題目配比：專案追問佔了將近八成，純八股只佔一小段，手撕收尾。

同一時期，牛客上還能看到「BIGO 一面」的音演算法面經、以及「3 段大廠實習仍然一面掛」的焦慮貼文。對照之下，這份二面清單反而顯得節制：題目多，但每一題都有明確的檢驗目標，沒有刁難式的腦筋急轉彎。它的排版也呼應了這一點，四個區塊、編號清楚、沒有多餘的形容詞，是一份寫給同溫層看、以可複製為前提的文件。這種質樸的清單排版，跟社羣裡大量情緒先行的求職貼文形成了明顯的版面差異。

收在順序裡的觀點

一份面經能做到的，從來只有一件事：把一場發生在視訊或會議室裡、一小時左右的對話，壓縮成可以被陌生人快速掃讀的清單。這篇「BIGO後端二面」做得特別乾淨，題目的順序就是面試的順序，措辭的鬆緊就是追問的力道，最後一行的那道排列題，則替整場對話留下一個可以驗證的句點。

對求職者而言，讀這份清單的正確方式不是逐題背答案，而是讀出題目背後的排列邏輯：專案先於八股、情境先於定義、取捨理由先於標準答案。一家公司怎麼面試，就跟一個品牌怎麼排版一樣，順序本身就是表態。這份清單表態得很清楚：BIGO 想找的是能站在系統外面看系統的人，而它連這一點，都被寫進了題目的先後裡。