
秋招季最磨人的其實不是簡歷被刷而是好不容易過了篩選收到筆試通知后發(fā)現(xiàn)——題量和難度完全超出預期。騰訊音樂2024年秋招技術崗第二批筆試我是在一個周六下午參加的整套做完最大的感受是這批題比第一批更看重工程實現(xiàn)能力算法題占大頭但選擇題里摻了不少業(yè)務場景題稍不留神就容易在“你覺得你會”的題目上翻車。這篇文章不搞虛的直接把第二批筆試的題型分布、考點側重、編程題的常見套路、以及我踩過的坑全部拆開講。不管你是正在備戰(zhàn)后續(xù)批次還是明年才上戰(zhàn)場參考價值都很直接。1. 騰訊音樂筆試到底在考什么第二批和第一批的差異先說結論騰訊音樂的筆試風格和騰訊集團其他事業(yè)群一脈相承但又有自己的小脾氣——音樂業(yè)務場景的題目占比不低而且越往后批次越喜歡在選擇題里塞“閱讀理解”式的情境題。1.1 整體題型結構與時間壓力第二批筆試時長我記得是120分鐘題量在20道選擇題加3道編程題左右。聽起來好像不算多但實際做起來時間非常緊。選擇題里有一部分是“多選”少選得部分分、錯選零分這個規(guī)則本身就很考驗對知識點的把握精度——模棱兩可的選項到底選不選直接決定你這一題是拿分還是白給。時間分配上我的建議是選擇題控制在40分鐘以內(nèi)剩下的時間全部留給編程題。很多人容易犯的錯誤是在選擇題上死磕遇到不會的題反復權衡結果編程題只剩二十分鐘最后一道往往只能寫個半成品。騰訊音樂的編程題不是那種“暴力解就能拿滿”的題至少有一道需要優(yōu)化到O(n log n)甚至O(n)才能過全部數(shù)據(jù)。1.2 第二批相對第一批的變化從身邊同學和牛客、知乎上的反饋來看第二批在題型上有幾個明顯變化第一純記憶型題目變少了。像“TCP三次握手四次揮手的狀態(tài)變遷”“HashMap的負載因子是多少”這種送分題第二批里幾乎絕跡取而代之的是給一段代碼讓你判斷輸出、給一個場景讓你選設計方案。第二算法題難度梯度拉得更開。第一批普遍反映第一題是簽到題但第二批的第一題也帶了一點思維量不再是無腦模擬。第三題則偏向中等偏上難度涉及數(shù)據(jù)結構的組合運用。第三業(yè)務場景題的比例提高。騰訊音樂畢竟是做音樂流媒體的直播、歌單推薦、評論系統(tǒng)、會員購買這些業(yè)務場景都可能成為選擇題或編程題的背景。第二批里我印象很深的一道題就是圍繞“歌曲熱度排行”設計的。1.3 這套題出給誰能力模型的側重點綜合來看騰訊音樂筆試想篩選的不是“背題機器”而是具備三種能力的人基礎功扎實計算機網(wǎng)絡、操作系統(tǒng)、數(shù)據(jù)庫這些核心課程不能只停留在概念層面要能分析實際問題。代碼實現(xiàn)速度快編程題要做完且保證正確性平時刷題量不夠的話考場上一緊張很容易崩。具備一定的業(yè)務理解力讀題時能快速把業(yè)務場景抽象成數(shù)據(jù)結構或算法模型而不是被花里胡哨的背景描述繞暈。提醒這里說的“業(yè)務理解力”不是讓你去研究產(chǎn)品經(jīng)理那套東西而是能從工程角度把一個業(yè)務問題翻譯成代碼問題。這個能力在選擇題和編程題里都能派上用場。2. 選擇題考點全景拆解從計算機網(wǎng)絡到業(yè)務場景選擇題一共20道覆蓋的范圍很廣但并非毫無規(guī)律可循。結合我這批的做題記錄和考后復盤把比較有代表性的考點按模塊拆開供大家參考。2.1 計算機網(wǎng)絡從背概念到看現(xiàn)象網(wǎng)絡題大概是4到5道難度不高但很靈活。比如有一道題給了個場景用戶在手機上聽歌時頻繁切換Wi-Fi和4GApp出現(xiàn)卡頓問最可能的原因和優(yōu)化方案。這種題本身就是在考TCP連接遷移、斷線重連、緩沖區(qū)管理等知識點光背“TCP是面向連接的”根本答不上來。還有一道題我印象很深給了四個關于HTTP/2和HTTP/3的說法讓選出正確的。其中涉及多路復用、隊頭阻塞、基于UDP的QUIC協(xié)議等。這里要注意的是題目不會直接問“HTTP/3基于什么協(xié)議”而是會包裝成“以下哪個說法最能解釋HTTP/3在弱網(wǎng)環(huán)境下的優(yōu)勢”。備考建議不要只背協(xié)議層的知識點多看“XX場景下為什么選擇這個方案”之類的分析文章尤其是移動端網(wǎng)絡優(yōu)化、弱網(wǎng)適配這類和App體驗強相關的話題。2.2 操作系統(tǒng)與Linux進程、內(nèi)存、IO三座大山操作系統(tǒng)大概有3到4道題集中在進程間通信、內(nèi)存管理、文件系統(tǒng)。有一道多選是問“哪些進程間通信方式適合大量數(shù)據(jù)傳輸”共享內(nèi)存和消息隊列都對管道在某些條件下也能用這就比較糾結——但題目會限定“高效”和“跨主機”這就需要你自己判斷每個選項的適用邊界。Linux命令行相關的知識點也出現(xiàn)了一道給了一個日志文件要求統(tǒng)計出現(xiàn)次數(shù)最多的前五個IP。本質(zhì)就是在考awk、sort、uniq這些命令的組合使用。這道題如果你平時沒怎么碰過Linux運維很容易被選項里的“sort -u”和“uniq -c”搞混。2.3 數(shù)據(jù)庫索引和事務是絕對高頻數(shù)據(jù)庫相關題目幾乎是每批必考的內(nèi)容第二批也不例外。考點高度集中在索引底層結構、最左前綴原則、事務隔離級別、MVCC機制這幾個方向。有一道題給了個SQL查詢場景表里有a、b、c三個字段建了聯(lián)合索引(a, b, c)問WHERE條件里用b和c查詢時索引是否生效。這題就是典型的最左前綴原則考察只要清楚聯(lián)合索引的匹配順序基本不會錯。事務隔離級別那道題比較有意思給了四個并發(fā)場景問你分別需要什么隔離級別才能避免問題比如臟讀需要READ COMMITTED不可重復讀需要REPEATABLE READ等。這個知識點光背四種隔離級別的名字沒用得理解每種級別解決了什么問題、沒解決什么問題。2.4 編程語言與數(shù)據(jù)結構基礎語言相關的題主要圍繞Java和C比如Java的HashMap在JDK不同版本下的區(qū)別、ConcurrentHashMap的鎖粒度變化、C的虛函數(shù)表機制等。這些題不算難但覆蓋面廣平時只刷算法題不注重語言底層原理的話容易丟分。數(shù)據(jù)結構部分有一道平衡二叉樹調(diào)整的題給了一個插入序列問經(jīng)過什么旋轉后樹保持平衡。這種題就比較看基本功了AVL和紅黑樹的旋轉邏輯得爛熟于心不然現(xiàn)場推演非常浪費時間。2.5 業(yè)務場景題這批題的最大變數(shù)我之所以把業(yè)務場景題單獨拿出來說是因為它在第二批中的占比明顯提升而且最沒有參考資料可以背。比如有一道題是“用戶在評論區(qū)發(fā)了一條帶有敏感詞的評論要求系統(tǒng)能在秒級內(nèi)完成審核并決定是否展示”本質(zhì)上考的是字符串匹配算法和分布式系統(tǒng)的實時性設計。這種題怎么準備說實話短期突擊很難有質(zhì)的提升。但有一個思路可以借鑒把Redis、Kafka、消息隊列、緩存淘汰策略這些知識點和音樂App的前后臺交互天然語言聯(lián)系起來。比如“熱門歌曲排行”這個業(yè)務背后的技術點就是“有限容量內(nèi)的排序”“熱點數(shù)據(jù)的緩存更新”——這么一想很多題目其實是把經(jīng)典的數(shù)據(jù)結構題換了一層業(yè)務皮。建議做選擇題時讀題先抓“技術關鍵詞”別被業(yè)務背景描述帶偏。比如看到“秒級”“大規(guī)模”“高并發(fā)”這些詞馬上對標分布式緩存、異步隊列、分庫分表等知識點。3. 編程題全拆解三道題分別考什么、怎么答第二批的3道編程題總體難度可以用“中等偏上”來形容。第一道約等于LeetCode的Easy到Medium之間第二道是標準的Medium第三道則接近Hard的思維量。3.1 第一題字符串處理與哈希表的組合應用這類題通常是給定一個字符串或單詞列表通過哈希表進行計數(shù)或分組。第二批第一題我記得是處理歌曲評論中的關鍵詞頻次本質(zhì)就是個“統(tǒng)計詞頻并排序”的問題。解法上直接用哈希表統(tǒng)計頻率再按頻率和字典序排序即可。代碼思路大致如下MapString, Integer freq new HashMap(); for (String word : words) { freq.put(word, freq.getOrDefault(word, 0) 1); } ListMap.EntryString, Integer list new ArrayList(freq.entrySet()); list.sort((a, b) - { if (!a.getValue().equals(b.getValue())) return b.getValue() - a.getValue(); return a.getKey().compareTo(b.getKey()); });這道題真正的坑在“字典序排序”上很多人會用HashMap然后只按頻率排序忽略了字典序要求導致部分測試用例過不了。還有就是要留意題意說的是“按出現(xiàn)次數(shù)從高到低次數(shù)相同按字母順序”這種邊界條件在考場上一緊張容易看漏。3.2 第二題動態(tài)規(guī)劃與狀態(tài)設計第二題一般是動態(tài)規(guī)劃題型可能是背包、子序列或者路徑規(guī)劃。第二批考的是一道“在給定操作序列下求最大收益”的題目本質(zhì)上是個二維DP需要設計好狀態(tài)含義才能正確轉移。這類題的核心是先明確DP數(shù)組某個位置代表的含義再思考當前狀態(tài)的轉移來源有哪些。比如“到第i天為止手里是否持有歌曲版權”這種設計狀態(tài)轉移無非就是“持有-繼續(xù)持有”“持有-賣出”“未持有-繼續(xù)觀望”“未持有-買入”幾種。我第一次做的時候把狀態(tài)設計成了一維結果轉移的時候發(fā)現(xiàn)信息不夠只記錄了第i天能得到的最大收益卻沒法區(qū)分當前是否持有版權。后來改成二維DP就順暢了。這道題想提醒大家看到題目里有“選擇一個操作并產(chǎn)生收益”這樣的描述先考慮是否需要用二維狀態(tài)不要盲目套一維模板。3.3 第三題數(shù)據(jù)結構組合與二分查找第三題往往需要綜合運用多種數(shù)據(jù)結構比如“維護一個動態(tài)數(shù)據(jù)集支持插入和查詢第k大”或“對每個元素求左邊第一個比它小的元素的位置”等。這批的第三題背景是“歌曲熱度實時刷新并支持多次查詢指定名次的熱度值”本質(zhì)上就是動態(tài)維護有序集合。解法上平衡樹是理論最優(yōu)但面試筆試環(huán)境往往不允許你手寫平衡樹。那就需要用別的思路比如離線處理加樹狀數(shù)組或者用單調(diào)棧、優(yōu)先隊列進行轉化。這道題我當時的解法是這樣因為查詢是離線的先把所有可能的歌曲加入一個坐標壓縮數(shù)組然后用樹狀數(shù)組維護每個熱度值出現(xiàn)的次數(shù)查詢時通過二分求前綴和定位名次。#include bits/stdc.h using namespace std; const int MAXN 200005; int bit[MAXN], n; void add(int i, int x) { for (; i n; i i -i) bit[i] x; } int sum(int i) { int s 0; for (; i 0; i - i -i) s bit[i]; return s; } // 查詢第k大時對樹狀數(shù)組做二分定位這種離線加樹狀數(shù)組的做法時間復雜度是O((NQ)logN)在現(xiàn)場環(huán)境下已經(jīng)足夠穩(wěn)定。如果你能想到這層第三題的分數(shù)基本就穩(wěn)了如果只能寫暴力可能只能過部分小數(shù)據(jù)測試點。3.4 編程題的作答策略從讀題到拿滿分的節(jié)奏編程題的作答節(jié)奏很關鍵。我個人的習慣是先花3到5分鐘通讀全部題目判斷題目的難度和是否熟悉類型。先做最有把握的那道確保把保底分拿到手。再做第二有把握的盡量追求全部測試點通過。最后啃最難的那道就算不能AC也要把暴力解寫上至少拿部分分數(shù)。提醒筆試系統(tǒng)通常按測試點給分不是只分“通過/不通過”。所以哪怕只能寫出樸素解法也一定寫上去別留著空白。我見過太多人第三題直接放棄結果最后差一兩分進面試非常可惜。4. 編譯環(huán)境與輸入輸出的暗坑這部分很容易被忽視但實際上是筆試翻車的重災區(qū)。騰訊音樂的筆試系統(tǒng)用的是牛客網(wǎng)或賽碼網(wǎng)不同平臺的輸入輸出要求和本地IDE有差異如果不提前適應寫對了代碼也可能掛在運行錯誤上。4.1 ACM模式還是核心代碼模式我記得騰訊這次秋招筆試是ACM模式也就是需要自己處理輸入輸出。這個和LeetCode默認的核心代碼模式完全不同。LeetCode是給你一個函數(shù)讓你實現(xiàn)測試用例已經(jīng)幫你解析好了ACM模式需要你自己讀入數(shù)據(jù)、然后按格式輸出結果。這個差異聽起來不大實操起來很多同學就慌了。比如第一題統(tǒng)計詞頻在LeetCode里你只需要寫一個接受String數(shù)組、返回List的方法但在ACM模式下import java.util.*; public class Main { public static void main(String[] args) { Scanner in new Scanner(System.in); int n in.nextInt(); in.nextLine(); for (int i 0; i n; i) { String line in.nextLine(); // 處理邏輯 } } } }很多人在練習時只刷LeetCode完全沒碰過牛客的模擬題結果考試時連Scanner類的常用方法都要想半天時間就這么白白浪費掉。一定要提前去牛客或賽碼上熟悉幾個ACM模式的例題。4.2 常見輸入輸出的坑點拿幾種典型輸入來說行首是否有多余空格有些題會在第一行先給一個整數(shù)N表示后面有N行數(shù)據(jù)但還有的題不給N而是讀到文件末尾為止。這兩種場景的讀取方式完全不同。整行讀取如果一行數(shù)據(jù)中包含多個用空格分隔的數(shù)字可以用nextInt()連續(xù)讀但如果一行內(nèi)包含字符串和數(shù)字混合建議用nextLine()讀取整行再split。輸出的格式比如“每兩個結果之間用空格隔開最后一個結果后無空格”這種要求很多題都在最后檢查這種細節(jié)。在考場上的判斷標準是如果本地樣例能過但提交后報了越界或格式錯誤第一時間檢查輸入輸出部分而不是算法邏輯。5. 筆試復盤從錯題到面試的知識遷移筆試結束不代表事情就完了。真正拉開差距的是筆試后有沒有做系統(tǒng)性復盤。騰訊音樂的面試中有些問題會直接引用筆試題目作為切入點尤其是你寫出來的解法面試官會追問“為什么這樣設計”“有沒有更優(yōu)方案”。5.1 我復盤時用的三個維度我復盤時會把每道錯題拿下來看三個維度知識點歸屬這道題考的是數(shù)據(jù)結構、算法、網(wǎng)絡、數(shù)據(jù)庫中的哪一塊如果這個知識點我不熟那就是一個明確的待補短板。錯誤原因是概念不清、代碼細節(jié)寫錯、還是題意理解偏差如果是題意理解偏差要重點提醒自己以后讀題時先劃關鍵信息。最優(yōu)解能否獨立寫出來看了題解之后合上答案自己重新寫一遍確保真會了而不是“看懂了”。5.2 筆試題目在面試中的“變體”面試環(huán)節(jié)經(jīng)常出現(xiàn)筆試原題的延伸。比如果筆試考了“統(tǒng)計詞頻并排序”面試官可能會接著問“如果數(shù)據(jù)量大到單機內(nèi)存放不下怎么辦”“怎么設計一個在線的實時統(tǒng)計系統(tǒng)”這些問題其實就是從哈希表延伸到了MapReduce、流式計算、滑動窗口等更復雜的場景。所以筆試復盤時不要只停留在把題AC了而要多想一步如果把數(shù)據(jù)規(guī)模擴大、加上實時性要求、引入分布式環(huán)境這個題還能怎么做提前準備這些延伸思路面試時被追問就不會卡殼。5.3 建立自己的錯題與考點清單我準備秋招時給自己的要求是每場筆試結束后24小時內(nèi)整理一份考點清單按出現(xiàn)頻率排序。等到騰訊音樂筆試的時候我已經(jīng)能大致判斷哪些點是這家公司的“必考點”了——比如數(shù)據(jù)庫索引和動態(tài)規(guī)劃基本上是標配。這種判斷能力比盲目刷題高效得多。6. 這批筆試暴露出的共性問題你的競爭對手都在哪里失分最后聊聊我在考后交流中觀察到的共性問題。同一批筆試的同學水平參差不齊但失分點高度集中總結出來也就這么幾類。6.1 讀題速度與準確性不足很多人不是不會做而是題目背景描述太長讀著讀著就忘了核心要求。比如編程題讀題花了五分鐘結果漏掉了“結果需要對1000000007取模”這個關鍵條件最后導致大規(guī)模用例全錯。我的應對方法是讀題時先用筆在草稿紙上寫下幾個核心信息比如輸入規(guī)模、數(shù)據(jù)類型、輸出要求、特殊限制條件。這比在腦子里過一遍可靠得多。筆試現(xiàn)場雖然緊張但條件反射式地記錄題目要點是可以通過平時刷題訓練出來的習慣。6.2 邊界條件與極端數(shù)據(jù)考慮不周考試時大多數(shù)人會關注常規(guī)情況忽略了空輸入、單元素輸入、數(shù)組越界等邊界條件。有一道編程題我寫的代碼在本地測試了三個用例都通過但提交后只過了一半測試點問題就在于沒有考慮輸入為空的情況。解決這個問題的辦法不是記住每道題的邊界條件而是在平時刷題時養(yǎng)成一個固定流程寫完代碼后依次檢查這幾個Case——空輸入、只有一個元素、元素全部相同、數(shù)據(jù)量最大的極端情況。在筆試題里邊界Case通常能占到20%到30%的分數(shù)。6.3 不重視調(diào)試與本地驗證還有一部分人代碼寫完后不調(diào)試就直接提交。在ACM模式下樣例輸出和實際輸出經(jīng)常因為格式問題對不上。我的建議是寫完代碼后先用自己的腦補數(shù)據(jù)驗證再用題目給的樣例驗證最后再構造幾個極端數(shù)據(jù)驗證。三步驗證法雖然多花幾分鐘但能避免大量提交錯誤。6.4 心態(tài)管理不要被一道題拖垮整場第二道編程題如果半小時還沒思路果斷先跳過把第三題的暴力解寫上去保住部分分再回頭想第二題。筆試比的不是單題滿分而是總分的排名。保證自己會的題都拿滿不會的題盡量拿部分分結果一般不會差。7. 針對后續(xù)批次和明年秋招的準備建議如果你是在看這篇內(nèi)容準備下一批筆試那我給你幾條實操性強的建議都是我從自己和其他上岸同學的經(jīng)驗里總結出來的。7.1 刷題策略按公司風格做針對性訓練騰訊系算法的風格傾向于“在業(yè)務包裝下的經(jīng)典問題”所以準備時不要只刷LeetCode Hot 100那種純算法題最好每周做兩到三套互聯(lián)網(wǎng)公司筆試真題鍛煉從業(yè)務描述中提取算法模型的能力。推薦的練習順序是先保證LeetCode上的數(shù)組、鏈表、二叉樹、哈希表、動態(tài)規(guī)劃這五大類題目熟練再去做筆試真題。如果時間有限動態(tài)規(guī)劃務必重點突破它是中高難度編程題的高頻考點。7.2 基礎知識要形成體系而不是散點選擇題覆蓋范圍廣但并不是無規(guī)律可循。按我上面分析的模塊去復習每個模塊各準備一個“知識樹”——計算機網(wǎng)絡圍繞TCP/IP、HTTP、WebSocket、網(wǎng)絡安全展開操作系統(tǒng)圍繞進程線程、內(nèi)存管理、文件系統(tǒng)、IO模型展開數(shù)據(jù)庫圍繞索引、事務、鎖、優(yōu)化展開。建議用思維導圖來整理這樣即使遇到?jīng)]見過的題也能從相近的知識點推理出答案。知識點之間建立聯(lián)系遠比孤立記憶更可靠。7.3 模擬筆試環(huán)境訓練時間感考前一周至少要做三次完整的模擬筆試按時長控制甚至找一個相對嘈雜并且沒有外部幫助的環(huán)境逼自己進入考試狀態(tài)。模擬時要用ACM模式別用LeetCode。每次模擬完認真核對所有錯題找到速度的短板。特別注意模擬筆試一定要留出一定的、專門的時間進行復盤復盤的收獲經(jīng)常比做題本身還要多。我前期刷題進步慢就是因為做完對個答案就扔了后來改了復盤流程才明顯感覺到正確率和速度同步提升。7.4 簡歷之外讓筆試成為你面試的“敲門磚”筆試成績不僅決定你是否能進面試寫代碼時的思路和習慣也會被記錄下來。有些面試官在面試前會調(diào)閱你的筆試代碼然后在面試中追問你的設計思路。所以筆試時即使時間緊張也盡量保持代碼風格清晰變量命名規(guī)范、函數(shù)邏輯分塊、有一定的注釋。這不只是為了給面試官留好印象更重要的是在考場上讓自己思路更清晰。總的來說騰訊音樂第二批筆試的難度在互聯(lián)網(wǎng)大廠中屬于中上水平每年題型也會隨著業(yè)務方向有所調(diào)整但核心考察的能力框架不會變——扎實的基礎知識、快速的代碼實現(xiàn)能力以及從業(yè)務場景中抽象出技術問題的思維習慣。把這三件事準備好不管是第幾批筆試你都不會是被刷掉的那一個。