2023年春招騰訊音樂的數(shù)據(jù)工程崗筆試放在第一批說實(shí)話這個(gè)時(shí)間點(diǎn)挺考驗(yàn)人的。大部分人的春招節(jié)奏還停留在“過完年再說”的狀態(tài)結(jié)果招聘流程說開就開不少人是在完全沒準(zhǔn)備的情況下被拉進(jìn)考場(chǎng)的。我身邊就有朋友考完出來直搖頭說題目看著不難但時(shí)間根本不夠用SQL剛寫完一大半編程題還沒碰就交卷了。這篇文章我就結(jié)合那批筆試的實(shí)際考察邏輯聊聊數(shù)據(jù)工程崗的筆試到底在篩什么人、題目背后考的是什么能力、以及怎么在有限時(shí)間內(nèi)把分拿滿。如果你現(xiàn)在正在準(zhǔn)備大廠數(shù)據(jù)工程崗的校招筆試或者之后打算投騰訊音樂相關(guān)的數(shù)據(jù)崗位這篇文章會(huì)把整個(gè)筆試的考察框架、實(shí)戰(zhàn)策略和容易忽略的細(xì)節(jié)拆開講清楚幫你少走彎路。1. 數(shù)據(jù)工程筆試和普通后端/算法筆試篩選邏輯完全不一樣很多人在準(zhǔn)備數(shù)據(jù)工程崗筆試的時(shí)候容易犯一個(gè)方向性的錯(cuò)誤照著后端開發(fā)崗或算法崗的題庫刷。結(jié)果就是選擇題里的JVM調(diào)優(yōu)、紅黑樹旋轉(zhuǎn)看得一頭霧水編程題死磕動(dòng)態(tài)規(guī)劃最后真正該拿分的SQL反而沒有時(shí)間練。1.1 數(shù)據(jù)工程崗考核的三個(gè)層次數(shù)據(jù)工程崗日常做什么本質(zhì)上就三件事把數(shù)據(jù)從A點(diǎn)搬到B點(diǎn)過程中保證數(shù)據(jù)不丟不重不錯(cuò)把雜亂的數(shù)據(jù)加工成可分析的形態(tài)讓整個(gè)數(shù)據(jù)鏈路跑得穩(wěn)、跑得快。因此筆試考的不是某個(gè)單一技能而是圍繞這三件事分層次考察。第一層是數(shù)據(jù)基礎(chǔ)能力。SQL是絕對(duì)的核心這幾乎是所有數(shù)據(jù)工程崗筆試的共識(shí)騰訊音樂也不例外。它考的不只是會(huì)不會(huì)寫select、join而是能不能處理真實(shí)業(yè)務(wù)里常見的復(fù)雜查詢場(chǎng)景比如連續(xù)登錄、留存計(jì)算、同環(huán)比、窗口函數(shù)排序。第二層是大數(shù)據(jù)生態(tài)的知識(shí)廣度。數(shù)據(jù)工程離不開分布式計(jì)算框架所以Hadoop、Spark、Flink、Kafka這些組件會(huì)被反復(fù)提及。這個(gè)層次的考察方式通常是選擇題或簡(jiǎn)答題重點(diǎn)看你是否理解這些組件的基本原理、適用場(chǎng)景和常見問題的排查思路。第三層是編程與工程能力。畢竟數(shù)據(jù)工程師也寫代碼尤其是寫數(shù)據(jù)處理邏輯。筆試?yán)锏木幊填}一般不會(huì)出特別偏難怪的算法更多是考察你用代碼解決實(shí)際數(shù)據(jù)問題的能力比如解析日志、實(shí)現(xiàn)一個(gè)簡(jiǎn)單的聚合邏輯。1.2 騰訊音樂筆試的風(fēng)格特點(diǎn)騰訊音樂的筆試整體風(fēng)格偏向務(wù)實(shí)或者說“業(yè)務(wù)導(dǎo)向”。同一套題里可能會(huì)出現(xiàn)某個(gè)音樂App的真實(shí)業(yè)務(wù)場(chǎng)景比如統(tǒng)計(jì)某首熱門歌曲的播放量、分析用戶聽歌時(shí)長(zhǎng)分布讓你在熟悉的業(yè)務(wù)背景里完成數(shù)據(jù)處理任務(wù)。這種出題方式的好處是它不是死板地考語法而是考你面對(duì)真實(shí)業(yè)務(wù)需求時(shí)能不能快速轉(zhuǎn)化成可執(zhí)行的查詢邏輯。另一個(gè)特點(diǎn)是時(shí)間緊湊。整個(gè)筆試時(shí)間一般控制在90到120分鐘但題量并不算少要涵蓋選擇題、SQL題、編程題有時(shí)還會(huì)有簡(jiǎn)答題。如果你在某道SQL題上糾結(jié)太久后面的編程題很可能來不及寫。1.3 崗位JD與筆試內(nèi)容的對(duì)應(yīng)關(guān)系投遞崗位的時(shí)候可以留意一下JD里的關(guān)鍵字。騰訊音樂數(shù)據(jù)工程崗的JD里往往會(huì)出現(xiàn)“數(shù)據(jù)倉庫”“ETL”“數(shù)據(jù)質(zhì)量”“Spark”“Flink”這些詞這些關(guān)鍵字基本預(yù)告了筆試的重點(diǎn)。如果JD重點(diǎn)提了數(shù)據(jù)倉庫那SQL題大概率考數(shù)倉建模相關(guān)的內(nèi)容比如維度建模、拉鏈表設(shè)計(jì)如果重點(diǎn)提了實(shí)時(shí)計(jì)算那Flink相關(guān)的知識(shí)點(diǎn)肯定會(huì)出現(xiàn)在選擇題里。拿著JD去反推筆試范圍比漫無目的地刷題高效得多。2. 題型盤點(diǎn)選擇題、SQL題、編程題和場(chǎng)景題各自的考察重點(diǎn)根據(jù)那批筆試的反饋來看題型基本固定但每個(gè)題型的側(cè)重點(diǎn)和平時(shí)刷題的感覺不太一樣。我先逐類拆一遍。2.1 選擇題大數(shù)據(jù)組件原理和基礎(chǔ)知識(shí)覆蓋面廣選擇題大概占30%左右的分值覆蓋面非常廣。我印象比較深的幾個(gè)方向是這樣Hadoop相關(guān)問得最多的就是HDFS讀寫流程、NameNode和DataNode的角色分工、MapReduce的Shuffle過程。比如“HDFS默認(rèn)副本數(shù)是多少”這種基礎(chǔ)題基本屬于送分題但“MapReduce中Shuffle階段的作用是什么”這種題就需要你真正理解整個(gè)計(jì)算流程。Spark是選擇題里的重頭戲。RDD、DataFrame、Dataset三者的區(qū)別寬依賴和窄依賴的判斷Stages劃分機(jī)制Spark作業(yè)提交流程Client模式與Cluster模式的區(qū)別這些問題反復(fù)出現(xiàn)。建議準(zhǔn)備的時(shí)候重點(diǎn)搞懂“寬依賴和窄依賴如何影響Stage劃分”這個(gè)點(diǎn)因?yàn)樗呛芏郤park相關(guān)題目的底層邏輯。Flink在騰訊音樂的筆試?yán)锍霈F(xiàn)頻率也不低畢竟音樂平臺(tái)的實(shí)時(shí)推薦、實(shí)時(shí)榜單都離不開Flink。狀態(tài)管理、Checkpoint機(jī)制、事件時(shí)間與處理時(shí)間的區(qū)別、Watermark的作用這幾個(gè)知識(shí)點(diǎn)要熟練。有一個(gè)很容易考的點(diǎn)是“Flink如何保證精確一次語義”要能說清楚Checkpoint和兩階段提交配合的原理。消息隊(duì)列Kafka同樣繞不開。分區(qū)與副本的概念、消費(fèi)者組如何管理位移、消息會(huì)不會(huì)丟失生產(chǎn)者、Broker、消費(fèi)者三個(gè)層面分別怎么保證這些需要理解到位。還有一個(gè)容易被忽視的點(diǎn)是基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)和計(jì)算機(jī)網(wǎng)絡(luò)。我見過有選擇題考到TCP三次握手、HTTP狀態(tài)碼的含義如果你大學(xué)學(xué)的東西忘得差不多了建議考前快速過一遍不用太深但基本概念得撿起來。2.2 SQL題筆試題的拉分項(xiàng)也是刷人最狠的部分SQL題往往是整張卷子里分值占比最高的單項(xiàng)而且一旦寫錯(cuò)幾乎沒有蒙對(duì)的概率。那批筆試的SQL題大概有3到4道難度從入門到進(jìn)階遞進(jìn)。入門題一般是單表查詢或簡(jiǎn)單的兩表連接考最基本的語法比如按某個(gè)字段分組統(tǒng)計(jì)、過濾條件組合。這類題是送分題但要注意別在細(xì)節(jié)上丟分比如COUNT和COUNT(DISTINCT)的區(qū)別、NULL值的處理方式。進(jìn)階題就開始上難度了。窗口函數(shù)是必考的ROW_NUMBER()、RANK()、DENSE_RANK()三兄弟的區(qū)別、SUM() OVER()跑批計(jì)算、LAG()和LEAD()取前后行數(shù)據(jù)這些是最基礎(chǔ)的窗口函數(shù)操作?？挤ㄍǔＪ沁@樣的給你一張用戶聽歌記錄表讓你統(tǒng)計(jì)每個(gè)用戶聽歌時(shí)長(zhǎng)的累計(jì)值或者找出每個(gè)用戶聽得最多的前三首歌。還有一個(gè)常考的題型是連續(xù)問題比如統(tǒng)計(jì)連續(xù)登錄N天的用戶。這種題用窗口函數(shù)做非常方便核心思路是用日期減去ROW_NUMBER()的序號(hào)得到一個(gè)分組標(biāo)識(shí)然后按這個(gè)標(biāo)識(shí)分組統(tǒng)計(jì)。我第一次見到這個(gè)思路的時(shí)候覺得非常巧妙理解了之后SQL能力會(huì)有一個(gè)明顯提升。那批筆試?yán)镞€出現(xiàn)了一道被很多人討論的題統(tǒng)計(jì)每分鐘在線聽歌人數(shù)的峰值。這類問題本質(zhì)上是個(gè)時(shí)間區(qū)間重疊問題思路是把每條記錄拆成開始事件和結(jié)束事件然后用SUM() OVER()做事件流累加峰值就是累加過程中的最大值。這類題在LeetCode上叫“會(huì)議室II”或者“卡車占用車位”但套上聽歌場(chǎng)景之后對(duì)數(shù)據(jù)工程崗來說更貼切。2.3 編程題難度適中重在實(shí)際問題的解決編程題一般有兩道左右可以用Python或Java寫。和算法崗動(dòng)輒困難難度的動(dòng)態(tài)規(guī)劃題不同數(shù)據(jù)工程崗的編程題更偏向“用代碼處理實(shí)際數(shù)據(jù)”考法通常是給定某種格式的日志文件或數(shù)據(jù)流讓你寫代碼完成某個(gè)統(tǒng)計(jì)任務(wù)。比如給定一個(gè)包含用戶ID、歌曲ID、播放時(shí)間戳的日志列表統(tǒng)計(jì)每首歌的獨(dú)立播放用戶數(shù)或者給定一批包含開始時(shí)間和結(jié)束時(shí)間的記錄找出所有存在沖突的時(shí)間段。這種題要求你熟悉Python里字典、集合、列表的基本操作能快速把思路轉(zhuǎn)化成代碼。還有一類題是自選實(shí)現(xiàn)某種數(shù)據(jù)結(jié)構(gòu)比如手寫一個(gè)帶過期時(shí)間的緩存、實(shí)現(xiàn)一個(gè)簡(jiǎn)單的LFU緩存這其實(shí)是在考察你對(duì)生產(chǎn)環(huán)境中常見問題的理解比如需要緩存熱點(diǎn)歌單數(shù)據(jù)時(shí)怎么處理過期和淘汰。需要注意編程題的判題環(huán)境一般比較嚴(yán)格你要自己處理輸入輸出格式。很多人不是思路不對(duì)而是卡在了輸入輸出的解析上這在平時(shí)用LeetCode刷題時(shí)不太容易暴露因?yàn)長(zhǎng)eetCode已經(jīng)把輸入輸出處理好了。2.4 場(chǎng)景題/設(shè)計(jì)題隱藏在簡(jiǎn)答里的加分項(xiàng)有些場(chǎng)次會(huì)包含一兩道簡(jiǎn)答或場(chǎng)景設(shè)計(jì)題比如讓你設(shè)計(jì)一個(gè)音樂播放量實(shí)時(shí)統(tǒng)計(jì)方案或者問你“如果數(shù)據(jù)倉庫里某張表的任務(wù)失敗了你如何排查”。這類題看起來開放但其實(shí)考察的是你對(duì)完整數(shù)據(jù)鏈路的理解。設(shè)計(jì)實(shí)時(shí)統(tǒng)計(jì)方案時(shí)可以從數(shù)據(jù)接入Kafka、實(shí)時(shí)計(jì)算Flink、結(jié)果存儲(chǔ)Redis或ClickHouse三個(gè)層面回答每一步說清楚用的組件和原因。任務(wù)失敗排查則可以從調(diào)度日志、上游依賴、數(shù)據(jù)傾斜、資源不足幾個(gè)方向展開。開放題沒有標(biāo)準(zhǔn)答案但一定要展示出結(jié)構(gòu)化的思維——分步驟、分模塊地組織你的回答讓面試官能通過筆試看到你解決問題的思路這本身就是一種能力證明。3. 做題順序和時(shí)間分配決定你能否把會(huì)做的題都做完那批筆試最大的坑不是題目難而是時(shí)間不夠用。很多人栽在“先做選擇題再做SQL最后做編程題”這個(gè)順序上結(jié)果選擇題消耗了太多精力SQL沒寫透編程題直接空白。這里我分享一套經(jīng)過驗(yàn)證的時(shí)間分配策略。3.1 拿到試卷先花3分鐘看全貌不要上來就埋頭做題。先花兩三分鐘把整張?jiān)嚲韽念^到尾翻一遍搞清楚每類題有多少道、每道題大概多少分、難度感覺如何。這能幫你在心理上建立一個(gè)全局觀知道哪些題是穩(wěn)拿分的、哪些題需要沖刺。一套比較合理的分配方案參考下面這個(gè)表格題型建議用時(shí)做題策略選擇題20-25分鐘會(huì)做的直接選不會(huì)的先跳過每道題不超過1分鐘SQL題35-45分鐘先寫有把握的題難題留到最后編程題25-35分鐘至少保證一題完整提交另一題寫出核心思路檢查5-10分鐘重點(diǎn)檢查SQL字段名、表名、邊界條件3.2 做題順序先做最優(yōu)性價(jià)比的題我的建議是如果試卷整體題量較大先用幾分鐘快速掃一遍所有SQL題和編程題判斷哪些是自己有把握的優(yōu)先做這些。原因是SQL題和編程題分值高、區(qū)分度強(qiáng)是決定你能否進(jìn)入面試環(huán)節(jié)的關(guān)鍵。選擇題就算全對(duì)如果SQL和編程拉胯總分也不會(huì)好看。反過來如果SQL和編程答得不錯(cuò)選擇題錯(cuò)幾道影響不大。具體操作可以這樣優(yōu)先做所有你一看就有思路的SQL題再回頭做選擇題中會(huì)做的題接著做編程題里最有把握的那道最后利用剩余時(shí)間去磕難題。這個(gè)順序看起來跳來跳去但確實(shí)能在有限時(shí)間里拿到最多分?jǐn)?shù)。3.3 編程題的保底策略不追求滿分追求有提交編程題如果完全沒寫基本等于直接放棄一整塊的分。哪怕時(shí)間再緊也要保證至少一道題有一個(gè)能跑通的版本。一個(gè)很實(shí)用的保底策略是先把暴力解法寫出來并確保它能正確計(jì)算小規(guī)模輸入。很多時(shí)候暴力解法能幫你拿到一部分測(cè)試用例的分?jǐn)?shù)而且能在寫的過程中慢慢優(yōu)化思路。另一個(gè)策略是如果某道編程題完全沒思路就把你能夠想到的步驟用偽代碼或者注釋寫出來同時(shí)給出你的基本思路。這在人工閱卷的情況下有一定概率拿到過程分。我這么說吧筆試不是競(jìng)賽不是為了拿滿分而是為了在有限時(shí)間內(nèi)證明你具備基本的數(shù)據(jù)處理能力。一道能跑通的簡(jiǎn)單題遠(yuǎn)比一道寫了一半的難題有價(jià)值。4. 幾類高頻SQL題的破題思路從聽懂到能寫對(duì)SQL題考來考去翻來覆去就是那幾類經(jīng)典題型。這里我挑了幾個(gè)高頻方向把核心思路完整拆解一遍你如果能把這些題型的代碼熟練掌握筆試的SQL部分基本穩(wěn)了。4.1 窗口函數(shù)不只是會(huì)寫要理解它的執(zhí)行邏輯窗口函數(shù)是數(shù)據(jù)工程崗SQL題的核心工具。很多看起來復(fù)雜的SQL問題一旦想到用窗口函數(shù)解法就變得非常簡(jiǎn)潔。窗口函數(shù)的執(zhí)行順序要牢記先WHERE過濾再GROUP BY分組然后窗口函數(shù)計(jì)算最后ORDER BY排序。注意WHERE在窗口函數(shù)之前執(zhí)行所以你不能在WHERE里直接使用窗口函數(shù)的別名。以“統(tǒng)計(jì)每個(gè)用戶聽歌時(shí)長(zhǎng)的累計(jì)值”為例SELECT user_id, song_id, play_ts, SUM(play_duration) OVER (PARTITION BY user_id ORDER BY play_ts ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS cum_duration FROM play_log;這里面有幾個(gè)關(guān)鍵點(diǎn)PARTITION BY表示按用戶分組ORDER BY表示組內(nèi)排序ROWS BETWEEN...AND...定義了窗口的范圍。理解這三者的組合關(guān)系你就能寫出從累計(jì)求和到移動(dòng)平均的各種查詢。4.2 連續(xù)問題日期減去序號(hào)這一步是關(guān)鍵“統(tǒng)計(jì)連續(xù)登錄N天的用戶”是SQL題里的常青樹它表面上考的是連續(xù)判斷實(shí)際考的是你能否用一個(gè)巧妙的轉(zhuǎn)換把連續(xù)問題變成分組問題。核心思路(1) 先用窗口函數(shù)ROW_NUMBER()按用戶分組、按日期排序得到每個(gè)用戶每個(gè)登錄日期的序號(hào)(2) 用登錄日期減去序號(hào)得到一個(gè)日期值(3) 如果日期是連續(xù)的日期減序號(hào)的差值會(huì)保持不變所以這個(gè)差值就可以作為分組標(biāo)識(shí)。WITH t AS ( SELECT user_id, login_date, DATE_SUB(login_date, INTERVAL ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) DAY) AS grp FROM login_log ) SELECT user_id, MIN(login_date) AS start_date, MAX(login_date) AS end_date, COUNT(*) AS consecutive_days FROM t GROUP BY user_id, grp HAVING COUNT(*) 3;這個(gè)技巧看著簡(jiǎn)單但是假如你之前沒接觸過考場(chǎng)上臨時(shí)想是很費(fèi)時(shí)間的。建議把它當(dāng)成一個(gè)固定套路來記。4.3 每日活躍/留存率把握住“去重”和“時(shí)間偏移”兩個(gè)核心統(tǒng)計(jì)DAU日活躍用戶的題目在筆試?yán)锓浅３Ｒ娨驗(yàn)樗苯訉?duì)應(yīng)業(yè)務(wù)里的核心指標(biāo)。做題的時(shí)候要注意兩點(diǎn)一是去重邏輯同一用戶同一天產(chǎn)生多條記錄應(yīng)該只算一次二是時(shí)間維度的處理按天統(tǒng)計(jì)需要注意日期格式的轉(zhuǎn)換。留存率的計(jì)算是另一個(gè)高頻題型。以“次日留存率”為例核心方法是把同一用戶的登錄記錄按日期錯(cuò)位連接找到第T天登錄且第T1天也登錄的用戶數(shù)。SELECT a.login_date, COUNT(DISTINCT b.user_id) / COUNT(DISTINCT a.user_id) AS retention_rate FROM login_log a LEFT JOIN login_log b ON a.user_id b.user_id AND b.login_date DATE_ADD(a.login_date, INTERVAL 1 DAY) GROUP BY a.login_date;如果把DATE_ADD(a.login_date, INTERVAL 1 DAY)改成INTERVAL 7 DAY或INTERVAL 30 DAY就能分別得到7日留存和30日留存。這類題目不復(fù)雜但細(xì)節(jié)很關(guān)鍵比如JOIN條件里必須限定日期偏移否則會(huì)出現(xiàn)數(shù)據(jù)膨脹的問題。4.4 時(shí)間區(qū)間重疊峰值在線人數(shù)的經(jīng)典解法統(tǒng)計(jì)“在線用戶峰值”或“會(huì)議室最大使用數(shù)量”這類問題在數(shù)據(jù)工程筆試?yán)锉桓木幊伞懊糠昼娫诰€聽歌人數(shù)峰值”出現(xiàn)的概率很高。這類題的核心解法非常巧妙把每一條記錄拆成兩個(gè)事件一個(gè)開始事件1一個(gè)結(jié)束事件-1然后按時(shí)間順序做累計(jì)求和。WITH events AS ( SELECT user_id, start_time AS ts, 1 AS delta FROM play_log UNION ALL SELECT user_id, end_time AS ts, -1 AS delta FROM play_log ) SELECT ts, SUM(delta) OVER (ORDER BY ts) AS concurrent_cnt FROM events ORDER BY ts;然后再取出concurrent_cnt的最大值就是峰值。這個(gè)思路在很多真實(shí)場(chǎng)景里都能用到比如并發(fā)任務(wù)數(shù)統(tǒng)計(jì)、直播間同時(shí)在線人數(shù)等。理解了事件流累加這個(gè)底層邏輯這類題就都通了。5. 踩坑記錄和復(fù)盤方法細(xì)節(jié)決定最終成績(jī)最后這部分我想聊聊那些容易被忽略、但實(shí)際考試中非常致命的細(xì)節(jié)。這些內(nèi)容沒有多少技術(shù)含量可一旦踩中很可能讓你前功盡棄。5.1 環(huán)境準(zhǔn)備筆試平臺(tái)的隱藏坑筆試用的在線OJ平臺(tái)和本地IDE差別很大。第一個(gè)坑是代碼自動(dòng)補(bǔ)全的缺失。在本地IDE里寫SQL習(xí)慣了自動(dòng)提示表名和字段名到了在線平臺(tái)手寫SQL經(jīng)常會(huì)因?yàn)槠村e(cuò)字段名而報(bào)錯(cuò)。第二個(gè)坑是本地驗(yàn)證和在線評(píng)判的差異。平臺(tái)一般提供本地自測(cè)用例但通過自測(cè)不代表最終能拿滿分因?yàn)闇y(cè)試數(shù)據(jù)里會(huì)有一些你沒考慮到的邊界情況。一個(gè)值得養(yǎng)成的習(xí)慣是在正式筆試前用牛客網(wǎng)或賽碼網(wǎng)刷幾套在線編程題提前適應(yīng)這些平臺(tái)的輸入輸出格式和評(píng)判規(guī)則。尤其是輸入輸出解析不同平臺(tái)之間的規(guī)范可能不太一樣但一旦適應(yīng)了就不至于在考場(chǎng)上糾結(jié)“這行字符串到底要不要去掉末尾的回車”。5.2 做題過程中的低級(jí)錯(cuò)誤SQL題最容易犯的低級(jí)錯(cuò)誤包括JOIN條件漏寫、GROUP BY字段不完整、COUNT和SUM的語義混淆、NULL值處理不當(dāng)。這些錯(cuò)誤在本地試數(shù)據(jù)量小的時(shí)候不容易暴露一旦跑到全量數(shù)據(jù)上就會(huì)出現(xiàn)結(jié)果偏差。編程題更容易栽在邊界條件上比如空列表輸入、單元素列表、數(shù)字溢出等。寫代碼的時(shí)候可以給自己一分鐘的時(shí)間專門想想“如果輸入是空的我這代碼跑不跑得通”這個(gè)習(xí)慣能幫你避免很多無謂的失分。另外讀題一定要讀完整特別是題目最后幾行對(duì)輸出格式的要求。每年都有人因?yàn)檩敵龈袷讲环弦蠖鴣G掉一整道題的分?jǐn)?shù)格式問題最可惜。5.3 考后一定要復(fù)盤筆試結(jié)束不等于學(xué)習(xí)結(jié)束。無論這次筆試的結(jié)果如何考后復(fù)盤都是提升能力最有效的方式。建議趁熱打鐵把考場(chǎng)上沒能做出來的題重新做一遍對(duì)照題目回憶自己的思路卡在哪里是知識(shí)點(diǎn)沒掌握還是時(shí)間分配出了問題。復(fù)盤時(shí)可以把所有錯(cuò)題按題型歸檔比如“SQL-連續(xù)問題”“SQL-留存率”“編程-區(qū)間重疊”“選擇題-Flink”。春招期間要投的公司往往不止一家騰訊音樂的筆試真題就是最好的練兵場(chǎng)把每場(chǎng)筆試?yán)锏腻e(cuò)題都變成自己的彈藥庫下一場(chǎng)筆試的勝算才會(huì)明顯提升。根據(jù)我自己的經(jīng)驗(yàn)數(shù)據(jù)工程崗的筆試到最后拼的其實(shí)不是智商而是你是否對(duì)常見題型足夠熟悉。熟練度這東西只能在反復(fù)練習(xí)中積累。把高頻題型的套路吃透再養(yǎng)成規(guī)范的做題習(xí)慣拿到面試機(jī)會(huì)并沒有想象中那么難。