21道題、一小時：字節TikTok直播實習一面，攤開的是直播業務的人力資本支出帳

10月13日晚間，一篇字節跳動後端開發實習生一面面經在牛客網發布，崗位隸屬TikTok國際直播基礎業務，面試時長一個小時。發文者自述流程為自我介紹、項目、八股、算法題加反問，共整理出21道題目。本文以回顧角度，從人力資本支出與招聘漏鬥的視角拆解這份題單。

題單的結構：八股為底、場景題為篩

21道題中，可粗分為三層。第一層是項目追問，共8題，涵蓋微服務拆分思路、OpenFeign與Dubbo並用的理由、秒殺系統設計、Redis扣庫存與訂單失敗的一致性處理、RabbitMQ消息可靠性與積壓方案。第二層是傳統八股，共7題，落在執行緒池參數、volatile與i++、ConcurrentHashMap的JDK版本差異、Redis單線程與IO多路復用、快取穿透擊穿雪崩、MySQL的B+樹與索引結構。第三層是場景與算法，包括線上SQL從20毫秒突增到2秒的排查思路、設計TikTok直播間點讚系統，以及現場手寫LeetCode 152乘積最大子數組與200島嶼數量兩題。

值得注意的比重分配：項目與中間件追問佔了一小時的近四成題量。這與小紅書PE一面以混合檢索、訊息積壓與LRU手撕題為主軸的結構相近，詳見先前整理的小紅書PE一面考題背後的篩選成本分析。差異在於字節這場多了開放式系統設計題，且直接以自家產品場景命題。

點讚系統那道題，考的是業務成本結構

「設計TikTok直播間點讚系統」是整份題單裡資訊量最大的一題。直播點讚的工程特徵是寫入量極大、單次價值極低、容忍秒級延遲，對應的答案是聚合上報、批次寫入、邊緣節點合併計數這類降成本手法。這類題目篩的並非背誦能力，而是候選人能否把高頻低價值寫入的流量特徵轉譯成儲存與網路成本方案。對照發文者自述「八股還不熟練」，這道場景題恰恰是最難靠短期背題覆蓋的一環。

發文者另提到一個招聘漏鬥的細節：第一題算法因剛背過而幾分鐘寫完，面試官隨即追加第二題島嶼數量，最終未寫完即結束。留言區亦有「算法題不能寫太快」的回饋。從企業角度，這是面試官對「解題速度」信號的真偽驗證機制；從候選人角度，這代表算法題的第一輪表現會改變後續題目難度，成本由應試者承擔。

一小時的面試，誰付帳、誰受惠

一小時的面試官時間，對應的是TikTok國際直播這條業務線的人力資本支出前置項。實習生招聘的篩選漏鬥通常包含簡歷篩、一至三輪技術面，每一輪的面試官多為在職工程師，其一小時的機會成本即是該業務線的工程產出。題單刻意壓縮在標準八股與高頻場景題的交集內，本質上是把篩選成本控制在可規模化的評分標準上，這與快手一面連追三輪AI工具使用細節以驗證真實性的做法屬於同一路徑，可參照先前對快手校招篩選成本的拆解。

受惠方是題庫覆蓋率高、短期衝刺能力強的應屆生，因為20道固定模式題中有17道可在公開題庫找到近似版本。承壓方則是項目經驗真實但八股不熟的自學或轉向者，一小時內項目追問與八股各佔一半的結構，對後者的時間分配極不利。發文者自評「想回答全面詳細還是比較難」，正是這種結構下的典型結果。

收束判斷

這份題單可確認的資訊是：TikTok國際直播基礎業務在實習層級的篩選標準，已高度標準化為中間件八股加產品場景設計題，且以直播點讚這類自家業務命題。至於該崗位的招聘量、實習轉正率與薪資水位，來源均未提供數字，本文不予推估。題單本身透露的訊息已足夠明確：直播業務的工程人力需求，正以可複製的評分模板規模化篩選，而模板外的能力，只能在那一道開放式設計題裡自行證明。