跳至主要內容
SUE NEWS
科技 產業分析

三道演算法題交了兩張白卷:BIGO前端筆試,攤開的是題庫標準化那本篩選帳

BIGO前端秋招筆試以KMP、旋轉列印等經典演算法題為主軸,候選人自述多題白卷,本文從篩選成本與題庫標準化角度拆解這場筆試背後的招聘帳。

刊登 閱讀約 7 分鐘

9月19日下午3點,BIGO前端開發(語音項目)秋招筆試準時開考。一位候選人事後在牛客網發帖記錄:單選題難度一般,多選題有幾個選項不確定,WebGL 相關題目完全沒接觸過;三道編程題裡,「求至少重複一次的重複子串」知道該用 KMP,但記不住模板,放棄;「能被 3 或 5 整除的前序和」用暴力解通過;「旋轉列印數字」交了白卷。發帖者自己下的結論是「演算法還是太菜,只會刷力扣」。

這則面經本身資訊量有限,但對照同帖下方其他 BIGO 筆試記錄,它透露的訊號值得攤開來算:一家中等規模的出海直播公司,用什麼樣的題庫結構、以什麼成本,在秋招第一關完成大規模初篩。

題庫結構:同一套題,發給所有方向的候選人

帖內另一位參加 BIGO 安卓崗筆試的用戶留下記錄:10 道單選、5 道多選、3 道編程題,ACM 模式(自行處理輸入輸出),編程題分別是合併區間、滑動窗口最大值,以及統計 SUCCESS、FAIL、PEND 字串出現次數。前兩題均為力扣原題。

前端與安卓是兩個技術棧差異不小的崗位,但選擇題與編程題的框架高度一致:力扣中等難度左右的經典模板題,加上少量覆蓋面廣、深度不均的選擇題。有上海考生在評論區疑惑「這題庫竟然是互通的嗎,我還以為是題庫裡隨機抽幾道」。

這個細節指向一個明確的成本選擇:BIGO 沒有為每個技術崗位維護獨立題庫。統一題庫意味著出題成本、判題成本、防作弊成本都能攤薄到所有崗位上,代價是題目與崗位技能的相關性下降。前端崗出現 WebGL 選擇題、但核心計分仍落在通用演算法題上,正是這種折衷的產物。

從篩選效率看,這套設計的邏輯成立。演算法題的判分是全自動的,ACM 模式下以測資通過率計分,不需要人工閱卷。發帖者提到「暴力解擔心超時,沒想到用例全過」,北京評論區用戶也證實「其實都可以暴力解」。測資強度放寬,讓暴力解也能拿分,這在無形中把筆試的區分度往「有沒有基本程式能力」這一層壓,而不是「演算法功底多深」。

篩選漏鬥:筆試不選人,只做粗篩

發帖者判斷「最近 BIGO 好像挺多人面的,估計這個筆試成績很難過篩」。這句話背後是秋招筆試在招聘漏鬥中的實際功能定位。

以網路公司校招的慣常流程估算,一家 BIGO 規模的公司,單一崗位收到數千到上萬份履歷並不罕見。筆試環節的成本結構極度偏向固定成本:接入第三方判題平臺或自建系統後,每多一個考生,邊際成本接近於零。相比之下,一面需要一位工程師投入 45 分鐘到 1 小時,以工程師的機會成本換算,人工篩選上萬份履歷在經濟上不可行。

因此筆試的設計目標是高吞吐、低邊際成本的粗篩工具。三道題裡允許一題白卷仍可能有面試機會,但兩題白卷基本出局。這解釋了為什麼題目停留在力扣原題與模板題難度:門檻設得太高,會把漏鬥末端的面試官時間浪費在演算法競賽選手身上,而這類候選人未必匹配前端業務需求;設得太低,粗篩失效。

同帖相關討論裡另一則前端求職帖提供了需求端的對照:一名雙非背景、有一段大廠實習的前端候選人,面了四次大廠,兩次一面掛、兩次二面掛,自述「答得都不錯,估計是招的人少但候選人太多」。供給過剩時,筆試分數作為排序依據的權重自然上升,這與 BIGO 考生的焦慮互為印證。這個現象與先前分析的秋招面試怪題背後的篩選成本帳是同一條傳導鏈的兩端:候選人過載,篩選手段就會往低成本、高吞吐的方向傾斜。

崗位結構的信號:語音項目單列,前端需求仍在但分層

值得注意的第二個細節是崗位命名。發帖者投遞的是「BIGO 前端開發,語音項目」。將前端職缺細分到具體項目線,通常意味著該項目有獨立編制與獨立 headcount,而非打包進通用前端池。

BIGO 的主營業務是海外直播與短影音,語音相關功能(語音房、連麥、即時通訊)是其核心場景之一。語音項目單列招聘,反映的是需求端的結構性傾斜:通用前端擴編趨緩,但直接服務營收場景的項目線仍在補人。這與前述前端求職者的體感一致:大廠前端「招的人少但候選人太多」,機會集中在特定業務線,而非全端開花。

從薪資與成本角度,這種分層對公司有利。項目線單列可以精準控制 headcount 總量,筆試統一題庫可以壓低初篩成本,兩者疊加,把招聘預算的確定性拉高。代價則轉嫁給候選人:面對標準化考題,準備方式被壓縮成刷題,而刷題投入在落選後幾乎完全沉沒。

對照組:隔壁的二面在考什麼

同帖收錄的另一則記錄提供了筆試之後的樣貌。一位參加 BIGO 後端開發二面的候選人列出的追問清單包括:Redis 與資料庫一致性、B+ 樹範圍查詢、MySQL 慢查詢處理、TCP 四次揮手、TIME_WAIT 堆積、Java 線程池參數設定與死鎖排查、Linux netstat 與 Send-Q 佇列滿的排查思路,最後手撕重排鏈表。

對照之下,筆試與面試的分工非常清楚。筆試考可自動判分的通用能力,面試考需要人際互動才能評估的工程判斷、排查思路與技術深度。這也回過頭解釋了筆試題目為何必須簡單到允許暴力解:它的職能是擋掉明顯不合格者,真正的選拔發生在後面的環節。這個分層邏輯,與先前拆解過的字節 Agent 面試背後的工程師技能定價觀察一致:自動化工具承擔粗篩,人的時間被保留給高價值判斷。

收束:白卷背後的帳,記在誰頭上

回到那位交了兩張白卷的前端候選人。KMP 模板記不住、旋轉列印不會做,直接暴露的是準備策略與考題結構的錯配:力扣刷題覆蓋了暴力解能過的那一題,但沒有覆蓋模板題的默寫要求。ACM 模式(自行處理輸入輸出)對只習慣力扣核心代碼模式的考生也構成額外摩擦,安卓崗那位考生就自述「忘了字串怎麼處理沒寫出來」。

BIGO 這場筆試本身沒有意外,它就是一套運轉中的標準化初篩機器:統一題庫壓低出題成本,ACM 自動判題壓低評分成本,暴力解可過的測資強度控制區分度,項目線單列控制 headcount。機器的每一端都在省成本,省下來的成本與風險,最終沉澱在候選人側的刷題時間與落選沉沒成本裡。秋招進行中,這臺機器還會對每一批考生重複運轉,而題庫互通與否,對考生來說早已不是重點,重點是在供給過剩的市場裡,粗篩分數線只會被同儕推著往上走。