牛客網近日流傳一篇標題為「秋招-字節跳動-抖音電商-Agent開發一/二/三面」的面經貼文。發帖人自述於9月2日完成一面、9月8日完成二面、9月15日完成三面，最終在第三輪遭到「橫向掛」，即被判定不匹配原崗位而未獲錄用。貼文寫道「累了，毀滅吧」，並交代三面之後的後續發展。
三面時間軸與後續拒面
依貼文自述，發帖人的面試時間軸為：9月2日一面、通過；9月8日二面、通過；9月15日三面，結果為橫向淘汰。9月剩餘兩週內，字節跳動另有兩個部門來電約面。其一為雲服務部門，發帖人表示因無對口實習經驗而直接婉拒；另一個是Data部門的Agent開發崗，發帖人稱自己對Agent開發興趣有限，認為該方向「實際上缺乏穩定性」，個人更傾向傳統業務後端，因此同樣拒絕面試。發帖人最後表示，希望國慶假期之後字節能釋出「正常的崗位」撈面。
一面考題：MySQL索引深挖與Redis並發控制
從貼文整理的題目看，一面分為數個板塊。開場環節包含自我介紹、實習經歷、在字節實習未轉正的原因與得知缺少轉正名額（HC）的時間點、求職方向，以及平時使用AI工具或學習大模型與Agent基礎知識的情況。
技術部分以MySQL與B+樹佔最大篇幅，涵蓋InnoDB索引設計、B+樹相較二叉搜尋樹與紅黑樹的優勢、最左前綴原則、覆蓋索引與索引體積的權衡、ORDER BY情境下的聯合索引設計、兩個獨立索引在底層是幾棵B+樹、LIMIT深分頁的效能問題與遊標分頁優化，以及一億條子訂單逐批呼叫RPC並更新狀態的離線任務設計。這類索引追問鏈與本站先前整理的字節跳動Agent開發一面涼經中MySQL深挖的路數相近，顯示同崗位序列的考點存在延續性。
Redis與並發控制板塊則包括MVCC的作用、Redis與MySQL事務的差異、Redis命令串行執行下業務仍出現並發問題的原因、SET NX與分散式鎖、釋放鎖需用Lua而不能直接DEL的理由、鎖過期的處理，以及Pipeline與Lua各自解決的問題。最後另有緩存淘汰策略與LRU演算法，要求以熟悉的語言實作支援建構、get與put的LRU Cache。
二面：AI Coding實作與技術方案審查
二面在自我介紹與風控實習專案追問後，重心轉向面試前發放的AI Coding題。發帖人被要求展示合同審核題的完成過程，說明如何使用AI開發，以及對AI產出的技術方案提出哪些具體修改。面試官進一步追問：AI給出的方案篇幅很長時，人應如何審查、抓重點與取捨；不接入模型的baseline能做到什麼；當前實作處於哪個階段。
貼文亦記錄了輸入歧義與不確定性的追問，包括報告提示的歧義問題如何看待、輸入有歧義時輸出關係如何得出、原始資訊不完整時「預設結果」應如何處理等。來源正文在此處截斷，三面完整題目未見收錄，相關細節無法核實。以AI Coding與方案審查為核心的考法，與本站整理過的字節跳動AI算力基礎設施方向27秋招面經屬同屆秋招中字節各部門引入AI環節的又一案例。
可核實資訊的邊界
上述內容均出自單一發帖人在牛客網的自述，三輪面試的題目為其個人記錄，面試結果與「橫向掛」的判定無法從官方管道核實。發帖人未說明雲服務與Data部門約面的具體日期，三面考題內容亦未在貼文中完整呈現。本屆秋招期間，牛客網上字節跳動各部門的面經數量持續增加，本臺僅就該篇貼文輪廓做事實整理，不對招聘形勢與崗位優劣做出判斷。