收到騰訊音樂2023春招后臺(tái)業(yè)務(wù)開發(fā)崗的筆試通知是在投遞簡歷后的一個(gè)周三下午。郵件里明確寫著“第一批筆試”我知道準(zhǔn)備時(shí)間已經(jīng)不多了。作為一個(gè)后臺(tái)開發(fā)方向的求職者我當(dāng)時(shí)最關(guān)心的幾個(gè)問題其實(shí)是筆試用什么平臺(tái)、考什么題型、算法題大概什么難度、選擇題覆蓋哪些科目、有沒有場景設(shè)計(jì)題以及最重要的——怎么分配時(shí)間才不至于做不完?，F(xiàn)在回過頭來看這場筆試的考察思路相當(dāng)?shù)湫秃苣艽泶髲S后臺(tái)業(yè)務(wù)崗的選拔邏輯。這篇文章就把整個(gè)筆試復(fù)盤一遍包括題型分布、復(fù)習(xí)重點(diǎn)、解題思路和一些實(shí)用經(jīng)驗(yàn)?zāi)繕?biāo)是讓準(zhǔn)備后續(xù)批次或者其他廠筆試的人心里有底。1. 筆試整體概況平臺(tái)、時(shí)長與題量結(jié)構(gòu)先說最基礎(chǔ)的筆試通過?？途W(wǎng)在線考試系統(tǒng)進(jìn)行全程需要在瀏覽器里完成會(huì)有攝像頭監(jiān)控和切屏記錄。整套題的時(shí)間是120分鐘題量不算夸張但節(jié)奏如果沒控制好很容易出現(xiàn)“選擇題糾結(jié)太久、最后一道算法題只能交白卷”的情況。從題型結(jié)構(gòu)上看大致可以分成三個(gè)板塊計(jì)算機(jī)基礎(chǔ)選擇題單選加不定項(xiàng)選擇、三道編程題、一道或兩道簡答/場景設(shè)計(jì)題。選擇題大概在10道左右覆蓋操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)庫、Java或C語言特性、數(shù)據(jù)結(jié)構(gòu)等編程題按難度遞增排列場景設(shè)計(jì)題則是給出一個(gè)偏業(yè)務(wù)的后臺(tái)問題要求寫出設(shè)計(jì)方案或關(guān)鍵代碼思路。這里有個(gè)容易被忽略的細(xì)節(jié)?？偷墓P試環(huán)境里編程題支持的語言以C、Java、Python為主但如果你用的是比較小眾的語言或者編程環(huán)境依賴特殊庫很可能在編譯環(huán)節(jié)就被卡住。我當(dāng)時(shí)的策略是“Java為主、Python做輔助驗(yàn)證”因?yàn)镴ava在?？偷呐蓄}環(huán)境里生態(tài)最穩(wěn)定而Python適合用來快速驗(yàn)證思路和寫部分分。如果你對(duì)C更熟用C也沒問題但要注意別在筆試時(shí)嘗試一門自己不熟練的語言——網(wǎng)上很多代碼模板看著優(yōu)雅真正手寫的時(shí)候反而容易出低級(jí)語法錯(cuò)誤。筆試的通過線沒有一個(gè)公開標(biāo)準(zhǔn)但從周圍人的反饋來看選擇題的正確率、編程題的通過用例數(shù)、場景設(shè)計(jì)題是否有完整邏輯這三項(xiàng)都會(huì)被綜合評(píng)估。也就是說哪怕有一兩道題沒完全ACAccepted只要整體表現(xiàn)不差還是有進(jìn)入面試的機(jī)會(huì)。但反過來如果三道編程題全掛選擇題正確率再高也很難救回來。2. 三道算法題難度梯度與常見解法拆解后臺(tái)開發(fā)崗的算法題不會(huì)像算法崗那么偏門重點(diǎn)還是那些“工作中真正可能用到”的思維比如模擬、雙指針、二分、動(dòng)態(tài)規(guī)劃、貪心和數(shù)據(jù)結(jié)構(gòu)操作。三道題基本呈梯度分布第一題是入門的模擬或字符串處理第二題是常見套路題第三題則會(huì)綜合兩個(gè)以上知識(shí)點(diǎn)AC起來會(huì)比較費(fèi)勁。2.1 第一題偏模擬與字符串處理送分題不能丟第一題通常是類似“解析一段輸入計(jì)算某種統(tǒng)計(jì)值”的題目核心考察的是編碼基本功和邊界條件處理。這種題沒有高深的算法但如果你平時(shí)習(xí)慣在LeetCode里刷題反而容易在這種題目上吃虧——因?yàn)長eetCode不需要你處理輸入輸出的細(xì)節(jié)而筆試平臺(tái)需要你自己寫完整的main函數(shù)和輸入解析邏輯。舉個(gè)例子有一類典型題是“給定一個(gè)字符串按某種規(guī)則提取數(shù)字并求和”?？雌饋砗芎唵蔚油卦谳斎肜锟赡苡卸嘤嗟目崭?、可能包含負(fù)數(shù)、可能數(shù)字之間沒有明確分隔符。正確做法是先寫一個(gè)穩(wěn)健的解析函數(shù)把字符串拆成token序列再針對(duì)每個(gè)token做判斷。這種題的暴力寫法都能過大部分用例關(guān)鍵是別為了追求一行流而把代碼寫得難以調(diào)試。2.2 第二題滑動(dòng)窗口或二分答案的中等題第二題難度中等常見的考察點(diǎn)包括滑動(dòng)窗口、前綴和、二分查找、拓?fù)渑判虻取．?dāng)時(shí)我印象比較深的一道題思路是典型的滑動(dòng)窗口給一個(gè)整數(shù)數(shù)組和一個(gè)目標(biāo)值求滿足“子數(shù)組和至少為target”的最短子數(shù)組長度。第一次看到這種題很多人會(huì)下意識(shí)用雙重循環(huán)枚舉所有子數(shù)組復(fù)雜度是O(n2)數(shù)據(jù)量一大就直接超時(shí)。而滑動(dòng)窗口可以把時(shí)間復(fù)雜度降到O(n)。滑動(dòng)窗口的核心思路可以這樣理解用兩個(gè)指針left和right表示當(dāng)前窗口的左右邊界右指針不斷向右擴(kuò)展窗口、累加窗口內(nèi)的元素和一旦窗口和滿足條件就嘗試左指針向右收縮在收縮過程中更新最小長度。每個(gè)元素最多被加入窗口一次、移出窗口一次所以整體是線性復(fù)雜度。def min_subarray_len(target, nums): left 0 current_sum 0 ans float(inf) for right in range(len(nums)): current_sum nums[right] while current_sum target: ans min(ans, right - left 1) current_sum - nums[left] left 1 return ans if ans ! float(inf) else 0這類題想拿滿分除了寫出正確代碼還要注意幾件事一是邊界條件比如數(shù)組為空、沒有滿足條件的子數(shù)組時(shí)應(yīng)該返回0二是輸入數(shù)據(jù)規(guī)模如果n可以達(dá)到10^5甚至10^6任何O(n2)的寫法都會(huì)超時(shí)。另一類高頻第二題是二分答案典型特征就是“求最大值的最小值”或“求最小值的最大值”。這類題一旦你意識(shí)到可以用二分去枚舉答案再用貪心或模擬去驗(yàn)證答案是否可行思路就打開了。比如經(jīng)典的“將數(shù)組分成連續(xù)k段使每段和的最大值最小”判斷某個(gè)候選值mid是否可行時(shí)只需要貪心地把元素盡量往當(dāng)前段里塞超過mid就開新段最后看段數(shù)是否不超過k。寫驗(yàn)證函數(shù)的時(shí)候記得用 long 類型避免整型溢出這也是筆試?yán)锏某Ｒ娍鄯贮c(diǎn)。2.3 第三題多個(gè)知識(shí)點(diǎn)的綜合題拿部分分要果斷第三題普遍會(huì)難一個(gè)檔次經(jīng)常需要組合數(shù)據(jù)結(jié)構(gòu)與算法。比如“樹上路徑查詢”可能涉及DFS序加樹狀數(shù)組或線段樹又比如“帶限制的最短路徑”可能涉及Dijkstra變種。面對(duì)這種題我先定的策略是先寫暴力版本確保小規(guī)模數(shù)據(jù)能過再嘗試優(yōu)化到正解。筆試和算法競賽一樣是按通過用例的比例給分的暴力版本通常能拿到30%-60%的部分分直接空著等于放棄這些分非?？上?。以一道常見的綜合題為例給定一棵樹每個(gè)節(jié)點(diǎn)有一個(gè)權(quán)值支持兩種操作——修改某個(gè)節(jié)點(diǎn)的權(quán)值、查詢某個(gè)節(jié)點(diǎn)到根節(jié)點(diǎn)的路徑上的權(quán)值和。如果沒有修改操作直接用DFS預(yù)處理出每個(gè)節(jié)點(diǎn)到根的路徑和一次查詢就是O(1)。但加上修改操作后每次修改都會(huì)影響該節(jié)點(diǎn)整棵子樹到根的路徑和你就要想到用樹狀數(shù)組維護(hù)DFS序把子樹映射成連續(xù)區(qū)間再結(jié)合差分思想做區(qū)間更新、單點(diǎn)查詢。DFS序加樹狀數(shù)組這個(gè)組合幾乎可以說是樹相關(guān)筆試題的標(biāo)配建議復(fù)習(xí)階段就把它練熟。第三題還有一個(gè)明顯的測(cè)試點(diǎn)題目給出的數(shù)據(jù)規(guī)模范圍往往很大比如節(jié)點(diǎn)數(shù)10^5操作數(shù)10^5如果審題時(shí)沒注意到這個(gè)量級(jí)就容易寫出O(n2)復(fù)雜度且自以為正確的解法。拿到題目第一步一定先看數(shù)據(jù)范圍這直接決定了你能接受的上界復(fù)雜度。經(jīng)驗(yàn)上n ≤ 10^5基本要求O(n log n)甚至O(n)n ≤ 5000才允許O(n2)的寫法。3. 計(jì)算機(jī)基礎(chǔ)選擇題高頻考點(diǎn)與易錯(cuò)陷阱編程題決定你能不能過筆試選擇題則決定你能不能高分過筆試。我個(gè)人的感受是選擇題的考點(diǎn)其實(shí)非常固定基本就是操作系統(tǒng)、計(jì)算機(jī)網(wǎng)絡(luò)、數(shù)據(jù)庫、編程語言和數(shù)據(jù)結(jié)構(gòu)這幾大塊。以下表格基本覆蓋了當(dāng)時(shí)的高頻考點(diǎn)科目高頻考點(diǎn)容易踩的坑操作系統(tǒng)進(jìn)程與線程區(qū)別、死鎖條件、虛擬內(nèi)存、頁面置換算法把進(jìn)程狀態(tài)轉(zhuǎn)換的順序記混同步與互斥概念混淆計(jì)算機(jī)網(wǎng)絡(luò)TCP三次握手四次揮手、TIME_WAIT、擁塞控制、HTTP狀態(tài)碼握手過程中各個(gè)狀態(tài)名記錯(cuò)搞混滑動(dòng)窗口與擁塞窗口數(shù)據(jù)庫索引結(jié)構(gòu)、事務(wù)隔離級(jí)別、B樹、SQL執(zhí)行計(jì)劃把隔離級(jí)別對(duì)應(yīng)的問題連錯(cuò)以為索引一定加速所有查詢Java/C內(nèi)存區(qū)域、對(duì)象生命周期、容器類底層結(jié)構(gòu)、并發(fā)機(jī)制基礎(chǔ)類型與引用類型賦值行為的差異HashMap在并發(fā)場景下的行為數(shù)據(jù)結(jié)構(gòu)鏈表操作、棧與隊(duì)列性質(zhì)、二叉樹遍歷、哈希沖突忽略平均與最壞情況復(fù)雜度差異3.1 網(wǎng)絡(luò)題里最喜歡挖的TCP的TIME_WAITTCP題目里出現(xiàn)頻率最高的坑之一是TIME_WAIT。簡單說主動(dòng)關(guān)閉連接的一方在發(fā)送完最后一個(gè)ACK之后會(huì)進(jìn)入TIME_WAIT狀態(tài)并等待2MSL最大報(bào)文段生存時(shí)間后才完全關(guān)閉。為什么要等這么久主要是為了防止最后一個(gè)ACK丟失如果被動(dòng)關(guān)閉方?jīng)]有收到ACK它會(huì)超時(shí)重傳FIN主動(dòng)方必須留有足夠時(shí)間來處理這個(gè)重傳另外也能讓舊連接中遲到的重復(fù)報(bào)文在網(wǎng)絡(luò)中自然消亡避免干擾使用相同四元組的新連接。選擇題里常見的錯(cuò)誤選項(xiàng)是“進(jìn)入TIME_WAIT的是收到FIN的一方”或“TIME_WAIT只持續(xù)1MSL”。如果你不了解主動(dòng)關(guān)閉和被動(dòng)關(guān)閉的角色很容易被繞進(jìn)去。另一個(gè)關(guān)聯(lián)考點(diǎn)是大量短連接同時(shí)關(guān)閉時(shí)服務(wù)端如果作為主動(dòng)關(guān)閉方可能出現(xiàn)大量TIME_WAIT連接導(dǎo)致端口被占滿這也是后臺(tái)開發(fā)實(shí)際工作中會(huì)遇到的性能問題筆試考到也不算超綱。3.2 數(shù)據(jù)庫題里喜歡挖的隔離級(jí)別與幻讀數(shù)據(jù)庫的隔離級(jí)別同樣是必考題。四種隔離級(jí)別——讀未提交、讀已提交、可重復(fù)讀、串行化——分別對(duì)應(yīng)的并發(fā)問題臟讀、不可重復(fù)讀、幻讀需要背得滾瓜爛熟。筆試中一個(gè)高頻陷阱是關(guān)于MySQL的默認(rèn)隔離級(jí)別InnoDB引擎默認(rèn)是可重復(fù)讀很多人默認(rèn)“可重復(fù)讀只能防不可重復(fù)讀不能防幻讀”但實(shí)際上InnoDB通過間隙鎖和next-key lock在可重復(fù)讀隔離級(jí)別下也能阻止幻讀的發(fā)生。這道題如果出成多選題選項(xiàng)里說“MySQL默認(rèn)隔離級(jí)別下不存在幻讀問題”很多人會(huì)因?yàn)楦拍钅：桓疫x。建議在復(fù)習(xí)時(shí)把“臟讀、不可重復(fù)讀、幻讀”三個(gè)詞和對(duì)應(yīng)的解決機(jī)制做成一張對(duì)照表反復(fù)記憶。同時(shí)理解鎖機(jī)制的基本原理記錄鎖鎖住一行間隙鎖鎖住一個(gè)范圍next-key lock是前兩者的結(jié)合鎖住“行加上前面的間隙”。這樣不管題目的措辭怎么變你都能判斷出最終效果。3.3 基礎(chǔ)題里的“選擇題技巧”選擇題并不是只能靠硬知識(shí)還有一些實(shí)戰(zhàn)技巧可循。拿到一道不會(huì)的題先排除明顯錯(cuò)誤的選項(xiàng)再通過“極端情況代入法”驗(yàn)證剩余選項(xiàng)。比如考復(fù)雜度可以把n10^5代入選項(xiàng)看哪個(gè)數(shù)量級(jí)最合理考數(shù)據(jù)結(jié)構(gòu)可以拿一個(gè)最簡單的用例空鏈表、單節(jié)點(diǎn)樹、全相同元素?cái)?shù)組去驗(yàn)證選項(xiàng)描述是否成立。這個(gè)方法尤其適合不定項(xiàng)選擇——寧可少選不要錯(cuò)選因?yàn)槎噙x和錯(cuò)選通常都不得分。還有一點(diǎn)筆試選擇題中偶爾會(huì)出現(xiàn)“每題多選”的情況審題時(shí)必須先看清是單選還是多選別用默認(rèn)的“單選思維”去應(yīng)付多選題。我在模擬練習(xí)中做過不少粗心題幾乎都是在這里丟的分。4. 后臺(tái)場景設(shè)計(jì)題從需求到落地的答題框架場景設(shè)計(jì)題是后臺(tái)業(yè)務(wù)開發(fā)崗筆試?yán)锖苡幸馑嫉囊画h(huán)它不像算法題那樣有固定答案而是在考察你面對(duì)一個(gè)真實(shí)業(yè)務(wù)問題時(shí)的思考方式。騰訊音樂的業(yè)務(wù)屬性很強(qiáng)題目很可能會(huì)從音樂播放、歌單、排行榜、用戶畫像等場景出發(fā)。我整理了一套從需求到落地的答題框架這里詳細(xì)拆一下。4.1 需求邊界分析先把問題定義清楚拿到場景題第一件事不是畫架構(gòu)圖而是把需求邊界問清楚。比如“設(shè)計(jì)一個(gè)播放量排行榜”你需要先明確幾個(gè)問題排行榜是實(shí)時(shí)還是離線榜單范圍是全國還是分地域榜單周期是小時(shí)、天還是周排行的指標(biāo)是播放次數(shù)還是獨(dú)立用戶數(shù)允許的延遲是多少在筆試?yán)锬阋谟邢迺r(shí)間內(nèi)把這些假設(shè)寫在答案最前面這會(huì)向面試官傳遞一個(gè)信號(hào)你具備需求分析能力而不是拿到需求就埋頭寫代碼。我當(dāng)時(shí)給自己定了一個(gè)套路先是用兩三句話描述“這個(gè)系統(tǒng)要解決什么問題、服務(wù)對(duì)象是誰、核心指標(biāo)是什么”再列出“非目標(biāo)”例如暫時(shí)不做的東西最后才進(jìn)入數(shù)據(jù)估算和存儲(chǔ)設(shè)計(jì)。4.2 數(shù)據(jù)估算所有設(shè)計(jì)的起點(diǎn)數(shù)據(jù)估算是場景設(shè)計(jì)題中區(qū)分度很高的一環(huán)。拿“最近7天播放量Top100歌曲榜單”舉例假設(shè)日活躍用戶DAU是1億每個(gè)用戶平均每天聽20首歌那么一天產(chǎn)生的播放記錄就是20億條一周就是140億條。存儲(chǔ)上如果每條播放記錄需要100字節(jié)左右的原始日志那一天的日志量就有接近200GB。這個(gè)估算本身不需要太精確關(guān)鍵是展示你具備從業(yè)務(wù)指標(biāo)推導(dǎo)數(shù)據(jù)規(guī)模的意識(shí)?；谶@個(gè)量級(jí)全量排序顯然不現(xiàn)實(shí)所以核心思路應(yīng)該是“分而治之”每天對(duì)歌曲的播放次數(shù)做聚合統(tǒng)計(jì)生成一個(gè)當(dāng)日統(tǒng)計(jì)結(jié)果查詢7天榜單時(shí)只需要合并這7個(gè)統(tǒng)計(jì)結(jié)果再進(jìn)行排序。這樣需要處理的數(shù)據(jù)量就從百億級(jí)別降到了百萬甚至十萬級(jí)別。我用一個(gè)簡單的計(jì)算舉例如果全站歌曲數(shù)量有5000萬首活躍歌曲每首歌每天用8字節(jié)存儲(chǔ)播放次數(shù)一天的核心統(tǒng)計(jì)結(jié)果才400MB。再進(jìn)一步如果你只需要Top100甚至可以只保留每首歌7天的統(tǒng)計(jì)結(jié)果最終排序時(shí)只需要比較這5000萬首歌的7日播放量如果數(shù)據(jù)再大還可以用“大根堆只保留前100”的方式把內(nèi)存占用控制在極小范圍。這就是典型的時(shí)間換空間、空間換時(shí)間的權(quán)衡。4.3 存儲(chǔ)選型MySQL、Redis還是消息隊(duì)列存儲(chǔ)選型是場景題里必須回答的問題。我的通用做法是核心業(yè)務(wù)數(shù)據(jù)放MySQL熱點(diǎn)數(shù)據(jù)和高并發(fā)讀取用Redis異步解耦用消息隊(duì)列。以排行榜為例播放行為先寫入消息隊(duì)列由消費(fèi)端異步聚合并寫入Redis的有序集合ZSet以歌曲ID為member、播放次數(shù)為score這樣查詢Top100只需要一條ZREVRANGE命令耗時(shí)在毫秒級(jí)。統(tǒng)計(jì)數(shù)據(jù)再定期以異步任務(wù)的方式落庫到MySQL用于歷史查詢和數(shù)倉分析。這里有一個(gè)容易被忽略的點(diǎn)Redis的ZSet在元素?cái)?shù)量特別多時(shí)雖然讀寫仍是O(log n)但內(nèi)存占用會(huì)顯著增加。如果歌曲量極大可以考慮對(duì)歌曲進(jìn)行分桶比如按首字母分桶或按熱度分層熱門歌曲單獨(dú)一個(gè)桶、長尾歌曲進(jìn)另一個(gè)桶查詢時(shí)合并各桶的Top100。這種“分桶合并”思想在后臺(tái)開發(fā)里很常見筆試能寫出來會(huì)是加分項(xiàng)。4.4 緩存與降級(jí)體現(xiàn)你的工程經(jīng)驗(yàn)場景題要拿高分除了結(jié)構(gòu)完整還要有一些工程上的細(xì)節(jié)思考。緩存策略可以說是最加分的一項(xiàng)。排行榜場景里如果每次都實(shí)時(shí)查Redis、再合并排序QPS每秒查詢數(shù)高的時(shí)候仍然會(huì)打滿資源。更穩(wěn)妥的做法是排行榜結(jié)果做成二級(jí)緩存——本地緩存一份例如5秒過期Redis里保存聚合后的全量榜單再從Redis同步一份到本地緩存。讀請(qǐng)求優(yōu)先打本地緩存只有緩存過期了才回源Redis這樣可以大幅降低對(duì)Redis的壓力。降級(jí)策略也需要提一筆。比如下游統(tǒng)計(jì)服務(wù)發(fā)生抖動(dòng)排行榜直接返回舊版本數(shù)據(jù)并打上“更新時(shí)間”標(biāo)記而不是把錯(cuò)誤展示給用戶。這種對(duì)“可用性優(yōu)于一致性”的取舍正是后臺(tái)業(yè)務(wù)開發(fā)區(qū)別于純算法題的重要能力點(diǎn)。5. 做題節(jié)奏與寫給后來者的幾個(gè)提醒整場筆試下來我對(duì)做題節(jié)奏的感悟最深。120分鐘的時(shí)間看似寬裕但如果你選擇題琢磨太久、第一道編程題寫完調(diào)了半天后面的壓力會(huì)滾雪球一樣增大。以下是我復(fù)盤后認(rèn)為最合理的時(shí)間分配方案供參考時(shí)間段任務(wù)策略前10分鐘快速瀏覽全部題目標(biāo)記每道題的難度等級(jí)不在一道題上停留第10-40分鐘完成選擇題不會(huì)的先蒙一個(gè)標(biāo)記下來不戀戰(zhàn)第40-75分鐘編程題第1題和第2題先寫暴力再優(yōu)化保證前兩題盡量接近滿分第75-100分鐘編程題第3題先寫暴力版本拿部分分剩余時(shí)間再想正解最后20分鐘場景設(shè)計(jì)題按“需求→估算→選型→擴(kuò)展”框架寫答案不要求過于精細(xì)剩余時(shí)間檢查所有題目代碼重點(diǎn)檢查輸入輸出格式、邊界用例有幾個(gè)非常細(xì)節(jié)但極其影響結(jié)果的提醒我想單獨(dú)列出來。5.1 輸入輸出處理看起來簡單最容易翻車筆試時(shí)編程題的輸入輸出格式不會(huì)像LeetCode那樣給你封裝好你需要自己寫完整的IO。以Java為例優(yōu)先使用BufferedReader和StringTokenizer處理大量輸入而不是Scanner因?yàn)樵跀?shù)據(jù)量達(dá)到十萬、百萬級(jí)別時(shí)Scanner的性能差距非常明顯。C就記住三行ios::sync_with_stdio(false); cin.tie(nullptr);Python里則用sys.stdin.buffer.readline()而不是input()。這三行代碼幾乎可以當(dāng)成筆試必備模板提前準(zhǔn)備好。另外一個(gè)很容易翻車的點(diǎn)是有些題目要求輸出浮點(diǎn)數(shù)并指定保留幾位小數(shù)或者要求答案對(duì)某個(gè)模數(shù)取余。審題時(shí)如果看到這類描述必須嚴(yán)格按照要求格式輸出否則即使邏輯全對(duì)判題也會(huì)報(bào)錯(cuò)。我在模擬練習(xí)里就遇到過因?yàn)樯倭艘粋€(gè)換行符而全盤判錯(cuò)的情況這種低級(jí)錯(cuò)誤在真正的筆試?yán)锸侵旅摹?.2 離線環(huán)境的適應(yīng)別依賴自動(dòng)補(bǔ)全?？凸P試的在線編輯器功能比較基礎(chǔ)沒有本地IDE那么強(qiáng)大的自動(dòng)補(bǔ)全、多文件組織和重構(gòu)功能。如果你習(xí)慣了在IntelliJ IDEA或VS Code里寫代碼第一次切換到在線編輯器會(huì)有一種“裸寫”的別扭感。我建議在筆試前至少花3-5個(gè)小時(shí)直接在?？突蛘咄惼脚_(tái)做模擬題完全不用本地IDE。這個(gè)過程能幫你熟悉在線編譯器的快捷鍵、錯(cuò)誤提示方式以及最關(guān)鍵的——“在不太舒服的環(huán)境下依然能快速寫出正確代碼”。另外筆試過程中千萬不要頻繁切換瀏覽器窗口。考試系統(tǒng)會(huì)記錄切屏次數(shù)超過閾值可能被判定為作弊。如果實(shí)在需要看在線文檔盡量在筆試開始前就準(zhǔn)備好別在考試中去查基礎(chǔ)API。5.3 筆試只是第一關(guān)精力管理別忽視騰訊音樂春招的流程里筆試之后還有面試整個(gè)招聘流程可能持續(xù)兩周甚至更久。筆試本身雖然重要但你不需要在這120分鐘里把自己所有的精力榨干。我的經(jīng)驗(yàn)是筆試前一天保證睡眠考試過程中保持清醒的頭腦比臨時(shí)抱佛腳多刷幾道題更有價(jià)值。很多人在第三道編程題上死磕半小時(shí)結(jié)果不僅沒想出來還影響到后面場景設(shè)計(jì)題的輸出質(zhì)量這就是典型的精力分配失誤。我個(gè)人的做法是如果一道算法題15分鐘內(nèi)沒有任何思路直接把暴力版本寫好提交然后跳到下一題。暴力分拿到就是賺到死磕失分才是真的虧。等到所有題目都有一版答案之后如果還有剩余時(shí)間再回頭慢慢優(yōu)化難一點(diǎn)的題。5.4 筆試后的復(fù)盤與后續(xù)準(zhǔn)備筆試結(jié)束不代表任務(wù)完成當(dāng)天最該做的是把題目回憶一遍整理出自己哪些地方薄弱。如果選擇題里網(wǎng)絡(luò)相關(guān)的題錯(cuò)得比較多那面試準(zhǔn)備階段就應(yīng)該重點(diǎn)補(bǔ)TCP和HTTP如果編程題第三題卡在樹結(jié)構(gòu)上那后續(xù)就可以專門刷一刷DFS序、樹狀數(shù)組和線段樹的題目。這種“以考促學(xué)”的復(fù)盤方式效果通常比盲目刷題好得多。另外筆試中你寫的代碼如果有自己都覺得笨拙的實(shí)現(xiàn)建議考后重新用更優(yōu)雅的方式實(shí)現(xiàn)一遍。這個(gè)過程不僅提升編碼能力也是為面試中的“手撕代碼”環(huán)節(jié)做積累。很多面試官會(huì)問你項(xiàng)目里用過哪些數(shù)據(jù)結(jié)構(gòu)和算法你說得越熟練越能體現(xiàn)出筆試成績不是靠運(yùn)氣得來的。