1. 為什么工程數(shù)據(jù)崗的筆試要先搞明白考什么、怎么考2024年秋招我投了螞蟻集團(tuán)的工程數(shù)據(jù)崗從簡歷篩選到筆試通知中間隔了大概一周。說實(shí)話收到筆試鏈接那一刻我是有點(diǎn)懵的——因?yàn)楣こ虜?shù)據(jù)崗這個(gè)名字本身就有點(diǎn)模糊它既不像純后端開發(fā)崗那樣大家都能說出個(gè)大概也不像算法崗那樣有明確的刷題路徑。我身邊很多同學(xué)都以為這崗考的是數(shù)據(jù)分析結(jié)果進(jìn)去一看Java并發(fā)、SQL窗口函數(shù)、Flink原理、算法題全都有。所以這篇復(fù)盤我想先聊一個(gè)很多人忽略的問題你到底在考什么。工程數(shù)據(jù)崗在螞蟻內(nèi)部主要做的是數(shù)據(jù)管道、實(shí)時(shí)計(jì)算、數(shù)據(jù)治理、離線數(shù)倉這一類方向也就是把業(yè)務(wù)數(shù)據(jù)從源頭采集、清洗、加工成可用的數(shù)據(jù)資產(chǎn)。這個(gè)崗位的筆試不會(huì)只考數(shù)據(jù)分析它更看重的是你能不能寫對(duì)代碼、能不能處理大數(shù)據(jù)場景下的計(jì)算問題。換句話說它考察的是一個(gè)會(huì)寫代碼的數(shù)據(jù)工程師而不是會(huì)看報(bào)表的數(shù)據(jù)分析師。這一點(diǎn)直接從筆試題目分布就能感受到——算法題占了很大比重SQL也是偏復(fù)雜查詢而不是簡單select。還有一個(gè)很重要的點(diǎn)工程數(shù)據(jù)崗的筆試和純后端崗筆試的重合度大概有六成剩下四成是大數(shù)據(jù)組件和SQL的專屬考點(diǎn)。所以我后來復(fù)盤時(shí)有個(gè)很深的感受如果你只刷LeetCode不練SQL想靠運(yùn)氣過筆試是很懸的反過來如果你只背組件原理不刷算法編程題大概率做不完。筆試的設(shè)計(jì)邏輯其實(shí)非常清晰就是篩掉那些偏科的人。另外要提醒一句螞蟻的筆試是在牛客網(wǎng)這種在線OJ系統(tǒng)上進(jìn)行的全程攝像頭監(jiān)控不能切屏切屏超過一定次數(shù)會(huì)被判作弊。所以考前一定要把網(wǎng)絡(luò)、瀏覽器、攝像頭都調(diào)試好。我筆試那場就有個(gè)同學(xué)因?yàn)殡娔X彈窗導(dǎo)致切屏被警告后面整個(gè)人心態(tài)都受影響了。這些細(xì)節(jié)看起來很碎但實(shí)際影響非常大。2. 考前信息戰(zhàn)從崗位JD倒推考點(diǎn)再定刷題計(jì)劃很多人準(zhǔn)備筆試是看到什么刷什么今天做幾道數(shù)組題明天看兩個(gè)Flink原理視頻結(jié)果到考場上發(fā)現(xiàn)會(huì)的沒考、考的不會(huì)。我的經(jīng)驗(yàn)是準(zhǔn)備筆試一定要從崗位JD倒推考點(diǎn)再倒推刷題計(jì)劃這樣才能把有限的時(shí)間用在刀刃上。2.1 JD里藏著筆試考察方向我當(dāng)時(shí)把螞蟻工程數(shù)據(jù)崗的崗位描述翻來覆去看了好幾遍摘出幾個(gè)關(guān)鍵信息一是要求扎實(shí)的Java或C編程基礎(chǔ)二是熟悉Hadoop、Spark、Flink等大數(shù)據(jù)框架三是熟悉SQL和數(shù)據(jù)倉庫建模四是具備一定的算法與數(shù)據(jù)結(jié)構(gòu)能力。如果你看到這樣的JD基本可以推斷出筆試的兩個(gè)大頭第一是編程題考察數(shù)據(jù)結(jié)構(gòu)和算法第二是專業(yè)題考察Java基礎(chǔ)、SQL和大數(shù)據(jù)組件原理。我把JD里的每個(gè)要求對(duì)應(yīng)到了具體的筆試考點(diǎn)列了一個(gè)表格照著這個(gè)表格復(fù)習(xí)效率和漫無目的刷題完全不一樣JD要求對(duì)應(yīng)筆試考點(diǎn)復(fù)習(xí)優(yōu)先級(jí)扎實(shí)的編程基礎(chǔ)數(shù)組、鏈表、棧、隊(duì)列、哈希、二叉樹、動(dòng)態(tài)規(guī)劃高熟悉大數(shù)據(jù)框架Hadoop HDFS讀寫流程、Spark RDD/Shuffle、Flink 狀態(tài)與Checkpoint高熟悉SQL窗口函數(shù)、多表關(guān)聯(lián)、去重排序、行列轉(zhuǎn)換、連續(xù)問題高具備算法能力TopK、LRU、字符串處理、前綴和、雙指針高Java基礎(chǔ)集合源碼、并發(fā)編程、JVM內(nèi)存模型、類加載中高數(shù)據(jù)倉庫建模星型模型、拉鏈表、緩慢變化維、事實(shí)表與維度表中2.2 題庫選擇和刷題優(yōu)先級(jí)確定考點(diǎn)之后接下來就是選題庫。我個(gè)人的組合方案是LeetCode Hot 100 牛客SQL大廠真題 大數(shù)據(jù)組件原理題。LeetCode不用多說了Hot 100過兩遍基本能覆蓋筆試?yán)锎蟛糠殖Ｒ?guī)算法題。SQL部分?？蜕嫌袑ｉT的大廠真題練習(xí)區(qū)里面有大量真實(shí)面試難度的SQL題比LeetCode的數(shù)據(jù)庫題更貼近國內(nèi)大廠風(fēng)格。大數(shù)據(jù)組件題在?？?、LeetCode上都沒有特別系統(tǒng)的題庫只能靠看面經(jīng)總結(jié)我當(dāng)時(shí)是把牛客上關(guān)于螞蟻工程數(shù)據(jù)崗的筆試面經(jīng)翻了個(gè)遍把能收集到的題目類型都整理出來了。刷題優(yōu)先級(jí)上我建議是SQL和算法題最優(yōu)先JVM和并發(fā)其次大數(shù)據(jù)組件原理可以放在選擇題沖刺階段集中背。因?yàn)镾QL和算法是編程題的主戰(zhàn)場占比高、拉分大值得投入最多時(shí)間。組件原理雖然也重要但更多出現(xiàn)在選擇題里背誦性價(jià)比高但理解深度要求沒那么高。2.3 四周復(fù)習(xí)計(jì)劃參考我實(shí)際用的復(fù)習(xí)計(jì)劃是四周周期比較適合時(shí)間適中、目標(biāo)明確的情況分享出來給大家做參考第一周數(shù)據(jù)結(jié)構(gòu)與算法強(qiáng)化。每天3道LeetCode中等題優(yōu)先數(shù)組、鏈表、二叉樹、動(dòng)態(tài)規(guī)劃周末做一次限時(shí)模擬。第二周SQL專項(xiàng)。每天5道SQL題覆蓋窗口函數(shù)、連續(xù)登錄、行列轉(zhuǎn)換、留存計(jì)算等高頻題型配合?？蚐QL題庫。第三周Java基礎(chǔ)大數(shù)據(jù)組件。白天看Java并發(fā)和JVM晚上看Spark、Flink核心原理周末刷選擇題。第四周真題模擬與查漏補(bǔ)缺。每天按正式筆試的時(shí)間節(jié)點(diǎn)做一套模擬題重點(diǎn)訓(xùn)練時(shí)間分配和抗壓能力。這個(gè)計(jì)劃最大的好處是把輸入和輸出結(jié)合起來了不是只看不練。第四周的限時(shí)模擬非常關(guān)鍵我第一次模擬的時(shí)候編程題根本做不完后來調(diào)整了答題順序才改善這個(gè)后面專門說。3. 筆試題型拆解從選擇題到編程題的實(shí)戰(zhàn)復(fù)盤螞蟻工程數(shù)據(jù)崗的筆試我當(dāng)時(shí)參加的是約120分鐘的線上筆試題量不算小。整體風(fēng)格偏向基礎(chǔ)扎實(shí)思維靈活沒有特別偏門的知識(shí)點(diǎn)但想拿高分也不容易。下面按題型來復(fù)盤。3.1 選擇題覆蓋Java、SQL、大數(shù)據(jù)組件選擇題大概有20到25道左右涵蓋的范圍很廣。Java基礎(chǔ)方面考了ArrayList和LinkedList的區(qū)別、HashMap的底層實(shí)現(xiàn)、并發(fā)編程里synchronized和ReentrantLock的區(qū)別、線程池的核心參數(shù)等。這些都是很典型的八股題難度不高但知識(shí)點(diǎn)細(xì)需要平時(shí)積累。SQL選擇題基本就是給一段SQL問你執(zhí)行結(jié)果或者給個(gè)業(yè)務(wù)場景讓你選正確的SQL寫法。這類題目考察的是對(duì)SQL語義的理解是否準(zhǔn)確尤其是JOIN的細(xì)節(jié)、GROUP BY與HAVING的關(guān)系、窗口函數(shù)的執(zhí)行順序等。我有一個(gè)比較深刻的教訓(xùn)是ON和WHERE的執(zhí)行順序在LEFT JOIN里真的很容易混淆筆試就考了類似的題我當(dāng)時(shí)差點(diǎn)選錯(cuò)。大數(shù)據(jù)組件選擇題是大頭也是工程數(shù)據(jù)崗和其他技術(shù)崗最大的區(qū)別。Hadoop、Spark、Flink都有涉及比如HDFS的副本放置策略、Spark RDD的依賴關(guān)系、Flink的Checkpoint機(jī)制、Watermark和窗口的關(guān)系、數(shù)據(jù)傾斜的處理方式等。這些題目不會(huì)特別深只要你系統(tǒng)看過組件核心原理基本能答對(duì)。但如果只是知道組件名字、沒深入了解原理很容易被選項(xiàng)干擾。我復(fù)習(xí)時(shí)用了對(duì)比法把Hadoop、Spark、Flink的架構(gòu)、計(jì)算模型、存儲(chǔ)方式、容錯(cuò)機(jī)制放在一個(gè)表格里對(duì)比記憶效果很好。3.2 編程題常規(guī)算法題加一道SQL題編程題一般有兩到三道通常包括一道算法題和一道SQL題有時(shí)候會(huì)加一道大數(shù)據(jù)場景題。我這場的結(jié)構(gòu)是兩道算法題加一道SQL題。算法題的方向比較常規(guī)一道是TopK問題的變體一道是字符串處理。難度大概在LeetCode中等不會(huì)到Hard但比Hot 100里的簡單題要難一些。這類題目刷過LeetCode的人應(yīng)該都能下手關(guān)鍵是在有限時(shí)間內(nèi)寫出正確且夠高效的解法。SQL題是典型的大廠業(yè)務(wù)題給了一張用戶登錄表要求計(jì)算每個(gè)用戶連續(xù)登錄的最大天數(shù)。這類問題在SQL面試?yán)锾Ｒ娏撕诵氖怯么翱诤瘮?shù)row_number date_sub來做分組之前如果專門練過連續(xù)登錄類題目基本屬于送分題。但如果沒準(zhǔn)備過考場上現(xiàn)場想可能要花不少時(shí)間。3.3 說說我印象最深的一道編程題有一道編程題我印象特別深題目大意是給一個(gè)很大的日志文件每行是一條用戶訪問記錄包含用戶ID、訪問時(shí)間和訪問頁面要求統(tǒng)計(jì)每個(gè)頁面獨(dú)立訪客數(shù)排名前10的頁面。這道題本質(zhì)上就是經(jīng)典TopK問題但是套了一個(gè)大數(shù)據(jù)場景的外殼。如果用Java寫核心思路就是先用HashMap統(tǒng)計(jì)每個(gè)頁面的獨(dú)立訪客數(shù)然后用小頂堆維護(hù)TopK。我在考場上很快想到了思路但因?yàn)橐幚愍?dú)立訪客這個(gè)條件哈希表存的時(shí)候需要先去重當(dāng)時(shí)在去重的實(shí)現(xiàn)上稍微猶豫了一下最后用了HashSet套在HashMap的value里。這道題給我的啟發(fā)是工程數(shù)據(jù)崗的算法題不會(huì)單純考數(shù)據(jù)結(jié)構(gòu)和算法它會(huì)把實(shí)際業(yè)務(wù)場景包裝進(jìn)去你需要快速把業(yè)務(wù)問題轉(zhuǎn)化成算法問題。4. 最拉開差距的算法題思路、代碼與現(xiàn)場心態(tài)算法題在整場筆試?yán)锏闹匾圆挥枚嗾f它通常分值最高而且直接決定你能不能進(jìn)下一輪。這里我想用一道TopK變體題作為例子完整還原我在考場的思考過程和解法。4.1 一道TopK變體的完整解題過程題目大致是給定一個(gè)字符串?dāng)?shù)組統(tǒng)計(jì)每個(gè)字符串出現(xiàn)的次數(shù)返回出現(xiàn)次數(shù)最多的前K個(gè)字符串如果出現(xiàn)次數(shù)相同則按字典序排序。這題在LeetCode上有原型就是前K個(gè)高頻單詞。我看到這題的時(shí)候心情是比較平靜的因?yàn)樗鼘儆诘湫偷墓＝y(tǒng)計(jì)排序/TopK套路。我的解法思路分兩步第一步用HashMap統(tǒng)計(jì)每個(gè)單詞的出現(xiàn)次數(shù)key是單詞value是次數(shù)第二步構(gòu)建一個(gè)小頂堆堆內(nèi)按出現(xiàn)次數(shù)從小到大排序如果次數(shù)相同則按字典序從大到小排序這樣堆頂是最小的元素遍歷完所有單詞后堆里留下的就是出現(xiàn)次數(shù)最大且字典序靠前的K個(gè)。關(guān)鍵點(diǎn)在于利用優(yōu)先隊(duì)列時(shí)要注意Comparator的寫法。我現(xiàn)場Java實(shí)現(xiàn)的核心代碼如下public ListString topKFrequent(String[] words, int k) { MapString, Integer countMap new HashMap(); for (String word : words) { countMap.put(word, countMap.getOrDefault(word, 0) 1); } PriorityQueueString minHeap new PriorityQueue((a, b) - { if (!countMap.get(a).equals(countMap.get(b))) { return countMap.get(a) - countMap.get(b); } else { return b.compareTo(a); } }); for (String word : countMap.keySet()) { minHeap.offer(word); if (minHeap.size() k) { minHeap.poll(); } } ListString res new ArrayList(minHeap); Collections.sort(res, (a, b) - { if (!countMap.get(a).equals(countMap.get(b))) { return countMap.get(b) - countMap.get(a); } else { return a.compareTo(b); } }); return res; }這里要注意幾個(gè)細(xì)節(jié)一是小頂堆的堆頂是當(dāng)前最小的當(dāng)堆大小超過K時(shí)彈出堆頂最終留下的就是最大的K個(gè)二是當(dāng)次數(shù)相同時(shí)字典序小的應(yīng)該留在堆里所以比較器里字典序那一項(xiàng)要反過來寫也就是b.compareTo(a)三是最后從堆里取出結(jié)果時(shí)順序是亂的需要二次排序恢復(fù)成題目要求的順序。這些細(xì)節(jié)如果平時(shí)沒寫熟考場上很容易翻車。4.2 遇到?jīng)]思路的題怎么辦先暴力再優(yōu)化筆試現(xiàn)場最怕的就是碰到一道題完全沒有思路。我的策略是首先快速判斷這題的考點(diǎn)是什么如果5分鐘內(nèi)想不出最優(yōu)解就直接寫暴力解法。理由很簡單筆試OJ判題是按用例給分的暴力解至少能過一部分用例比交白卷強(qiáng)得多。寫暴力解的時(shí)候一定要把想法和注釋寫清楚方便后面有時(shí)間回來優(yōu)化。很多?？偷墓P試是支持多次提交的你可以先提交一個(gè)暴力解拿保底分然后繼續(xù)想優(yōu)化方案。我筆試時(shí)第二道算法題就差點(diǎn)卡住題目涉及字符串的某種變換我當(dāng)時(shí)第一反應(yīng)是這題跟滑動(dòng)窗口有關(guān)系但是窗口的左右邊界怎么移動(dòng)想了好幾分鐘沒想清楚。后來我果斷放棄了一次寫對(duì)最優(yōu)解的想法先寫了一個(gè)雙層循環(huán)的暴力解提交后大概過了30%的用例。拿到保底分之后我重新理了一下思路發(fā)現(xiàn)可以用前綴和數(shù)組把部分重復(fù)計(jì)算優(yōu)化掉最后優(yōu)化完過了全部用例。這段經(jīng)歷讓我徹底明白筆試不是競賽得分才是硬道理不要在糾結(jié)中浪費(fèi)時(shí)間。4.3 現(xiàn)場心態(tài)管理的幾個(gè)細(xì)節(jié)心態(tài)這件事聽起來虛但真的很影響發(fā)揮。我有幾點(diǎn)實(shí)際感受拿到題先深呼吸快速歸類考點(diǎn)不要一上來就寫代碼。腦子里的錨點(diǎn)很重要看到求前K個(gè)就想到堆看到連續(xù)子數(shù)組就想到前綴和看到字符串匹配就想到雙指針或KMP這些套路能幫你快速進(jìn)入狀態(tài)。遇到卡殼超過10分鐘就跳過做后面會(huì)做的題回過頭來再看卡殼的題往往會(huì)有新的思路。我筆試時(shí)有一道算法題就是這樣先跳過做SQL題回頭再來看反而一下子想到了解法。不要盯著計(jì)時(shí)器看尤其是時(shí)間剩得不多的時(shí)候越看越焦慮?？梢园咽Ｓ鄷r(shí)間拆成幾個(gè)階段比如還剩60分鐘時(shí)應(yīng)該做到哪還剩30分鐘時(shí)應(yīng)該做到哪心里有個(gè)底就行。5. SQL與大數(shù)據(jù)組件題工程數(shù)據(jù)崗的專業(yè)分水嶺算法題大家都會(huì)刷真正把工程數(shù)據(jù)崗和其他崗位拉開差距的其實(shí)是SQL題和大數(shù)據(jù)組件題。這一塊如果你有數(shù)倉實(shí)習(xí)或者平時(shí)工作接觸過大數(shù)據(jù)組件會(huì)覺得很簡單但如果沒有實(shí)際經(jīng)驗(yàn)只能靠臨時(shí)背考場上很容易露餡。5.1 SQL高頻題型連續(xù)登錄、行列轉(zhuǎn)換、留存率SQL題在筆試?yán)锏牡匚环浅８咭驗(yàn)樗苯訉?duì)應(yīng)了未來工作里最核心的能力——寫數(shù)據(jù)查詢和分析SQL。我整理過工程數(shù)據(jù)崗筆試SQL題的高頻題型主要集中在三類一是連續(xù)登錄問題。經(jīng)典場景是給一張用戶登錄表計(jì)算每個(gè)用戶連續(xù)登錄的最大天數(shù)。核心解法是用窗口函數(shù)給每個(gè)用戶的登錄日期編號(hào)然后用登錄日期減去編號(hào)得到一個(gè)新的日期字段如果日期相同說明是同一段連續(xù)登錄。具體SQL如下select user_id, max(continue_days) as max_continue_days from ( select user_id, date_sub(login_date, row_number() over (partition by user_id order by login_date)) as grp_date, count(*) over (partition by user_id, date_sub(login_date, row_number() over (partition by user_id order by login_date))) as continue_days from user_login group by user_id, login_date ) t group by user_id;這個(gè)解法是分組求最大值的思路先給連續(xù)日期打上同一個(gè)標(biāo)記再按標(biāo)記分組統(tǒng)計(jì)數(shù)量最后取最大值。這種題沒有任何捷徑就是多練幾遍把套路刻在腦子里。二是行列轉(zhuǎn)換。比如把一張長表轉(zhuǎn)成寬表或者把寬表轉(zhuǎn)成長表。這類題考察的是CASE WHEN和UNION的靈活運(yùn)用平時(shí)多寫幾遍就熟練了。三是留存率計(jì)算。給用戶活躍表計(jì)算某天新增用戶在之后第N天的留存率。核心是理解新增用戶和活躍用戶的區(qū)別然后通過JOIN和日期差計(jì)算。5.2 大數(shù)據(jù)組件題掌握原理比背八股重要大數(shù)據(jù)組件相關(guān)的選擇題和簡答題是工程數(shù)據(jù)崗筆試的個(gè)性題。我當(dāng)時(shí)復(fù)習(xí)時(shí)重點(diǎn)看了幾個(gè)方向Hadoop的HDFS讀寫流程、MapReduce的Shuffle過程、Spark的RDD依賴和DAG、Spark和Flink的容錯(cuò)機(jī)制區(qū)別、Flink的Watermark和窗口、數(shù)據(jù)傾斜的原因和解決方案。這里最?？嫉囊粋€(gè)點(diǎn)是數(shù)據(jù)傾斜。題目通常會(huì)給你一個(gè)場景比如兩張表JOIN時(shí)某個(gè)key的數(shù)據(jù)量特別大導(dǎo)致reduce端負(fù)載不均問你該怎么解決。我建議至少要掌握以下幾個(gè)方案對(duì)傾斜key加隨機(jī)前綴打散、廣播小表避免Shuffle、調(diào)整并行度、兩階段聚合。這些方案筆試會(huì)考面試還會(huì)追問值得深入理解而不是死記硬背。還有一個(gè)高頻考點(diǎn)是Spark和Flink在容錯(cuò)上的區(qū)別。Spark用Lineage血緣機(jī)制通過RDD的血緣關(guān)系重新計(jì)算恢復(fù)數(shù)據(jù)Flink用Checkpoint分布式快照通過周期性保存狀態(tài)快照實(shí)現(xiàn)精確一次語義。這兩個(gè)都是各自框架的核心機(jī)制一定要能說清楚它們的設(shè)計(jì)思路和適用場景。5.3 一道選擇題啟發(fā)我重新理解SQL執(zhí)行順序筆試?yán)镉幸坏肋x擇題我印象很深問的是SQL語句中WHERE、GROUP BY、HAVING、SELECT、ORDER BY的執(zhí)行順序。看起來很簡單但很多平時(shí)寫SQL的人根本說不清楚。正確答案是FROM是最先執(zhí)行的然后WHERE再GROUP BY再HAVING再SELECT最后才是ORDER BY和LIMIT。這個(gè)執(zhí)行順序決定了你在WHERE里不能使用SELECT里定義的別名但在ORDER BY里可以使用。我后來把這個(gè)知識(shí)點(diǎn)記到了自己的SQL筆記里因?yàn)楹芏鄻I(yè)務(wù)SQL寫錯(cuò)就是因?yàn)闆]搞清楚執(zhí)行順序。比如有人想對(duì)分組聚合后的結(jié)果過濾把條件寫在了WHERE里而不是HAVING里結(jié)果報(bào)錯(cuò)或者結(jié)果不對(duì)。這種題考察的不是你會(huì)不會(huì)寫SQL而是你有沒有真正理解SQL的執(zhí)行邏輯這也是工程數(shù)據(jù)崗需要具備的思維。6. 時(shí)間分配與答題策略別讓會(huì)做的題被時(shí)間拖死筆試時(shí)間有限做題順序和時(shí)間分配在很大程度上決定了你的成績。我第一套模擬題就是吃了順序的虧一上來死磕算法題結(jié)果后面簡單的選擇題都來不及做白白丟了很多分。6.1 我的答題順序先做選擇題再做SQL題最后做算法題我的實(shí)際策略是拿到試卷先快速瀏覽一遍全部題目對(duì)難度有個(gè)大致判斷然后按照選擇題 → SQL題 → 有思路的算法題 → 沒思路的算法題的順序來做。理由是選擇題雖然知識(shí)點(diǎn)碎但單個(gè)題耗時(shí)短、分值固定適合在頭腦最清醒的時(shí)候快速拿下SQL題只要會(huì)寫得分效率很高而且答案相對(duì)確定算法題費(fèi)時(shí)最長不確定性最大放到后面做更合理。很多人的習(xí)慣是先做分值高的算法題我覺得這恰恰是誤區(qū)。大廠筆試的通過標(biāo)準(zhǔn)是總分過線而不是某一道題拿滿分。用更少的時(shí)間拿到更多的基礎(chǔ)分比花30分鐘死磕一道算法題要?jiǎng)澦愕枚唷?.2 每類題目的時(shí)間預(yù)算參考我當(dāng)時(shí)給自己定了一個(gè)時(shí)間預(yù)算大概是這樣題型建議時(shí)間策略說明選擇題25-30分鐘每題控制在1-1.5分鐘不會(huì)的果斷蒙一個(gè)并標(biāo)記SQL題25-30分鐘先寫出正確版本再考慮優(yōu)化不要一上來就寫復(fù)雜解法算法題第一題20-30分鐘這是最容易拿分的算法題全力以赴算法題第二題15-20分鐘10分鐘沒思路就寫暴力解拿保底分檢查和提交10-15分鐘重點(diǎn)檢查編譯錯(cuò)誤、輸入輸出格式、邊界條件這個(gè)預(yù)算不一定適合所有人但有一個(gè)原則是通用的一定要給檢查留時(shí)間。我見過太多人寫完代碼就提交結(jié)果因?yàn)镾canner讀取格式不對(duì)或者沒有處理空輸入被扣分。這些不是不會(huì)做而是太虧了。6.3 編程題提交前的檢查清單說到提交檢查我總結(jié)了一個(gè)簡單的清單每次提交前都按這個(gè)過一遍輸入輸出格式是否正確題目要求多組輸入還是單組輸入用的是Scanner還是BufferedReader。有沒有處理邊界條件比如數(shù)組為空、k為0、字符串長度為1。數(shù)據(jù)類型是否溢出比如用int還是longTopK和累加計(jì)算很容易溢出。題目的方法簽名是否符合要求?？凸P試有時(shí)候要求你實(shí)現(xiàn)某個(gè)類方法類名和方法名都不能改。時(shí)間復(fù)雜度和空間復(fù)雜度是否會(huì)被卡如果題目給的數(shù)據(jù)量很大暴力解可能直接超時(shí)至少要先算一下復(fù)雜度。這些檢查項(xiàng)看起來基礎(chǔ)但每次筆試都有人在上面翻車。我建議平時(shí)刷題的時(shí)候就養(yǎng)成這個(gè)習(xí)慣不要只埋頭寫代碼要站在OJ的角度審題。7. 筆試之后復(fù)盤、面試銜接與抗遺忘安排筆試結(jié)束不代表這件事就完了。我身邊很多同學(xué)考完就徹底放飛自我等收到面試通知才開始慌。實(shí)際上從筆試到面試的間隔期是最重要的準(zhǔn)備窗口能不能利用好這段時(shí)間決定了你在面試時(shí)是講得出深度還是只能聊表面。7.1 考后立刻做一次趁熱復(fù)盤筆試結(jié)束當(dāng)晚趁記憶還新鮮我建議立刻做一次復(fù)盤。我當(dāng)時(shí)是打開備忘錄把能回憶起來的題目類型、考察知識(shí)點(diǎn)、自己做錯(cuò)的點(diǎn)、有疑慮的題全部記下來。不要只記題目要記我為什么做錯(cuò)了和下一次遇到同類題應(yīng)該怎么想。這個(gè)動(dòng)作看起來簡單但非常有價(jià)值因?yàn)楣P試考察的很多知識(shí)點(diǎn)在面試中會(huì)被問到考后復(fù)盤相當(dāng)于提前做了面試梳理。比如我在SQL那道連續(xù)登錄題上雖然做對(duì)了但復(fù)盤時(shí)發(fā)現(xiàn)自己對(duì)date_sub和row_number配合的本質(zhì)原理理解得不深。于是面試前我又專門搜了相關(guān)博客重新理解了一遍用日期減去編號(hào)把連續(xù)區(qū)間變成同一分組這個(gè)思路的數(shù)學(xué)原理結(jié)果面試時(shí)真的被追問了。如果不是考后復(fù)盤把這個(gè)薄弱點(diǎn)標(biāo)記出來我面試很可能答不好。7.2 把筆試知識(shí)點(diǎn)延展成面試口語化表達(dá)筆試是選擇題和編程題面試是口頭交流和手撕代碼這中間有個(gè)轉(zhuǎn)換過程。筆試時(shí)你只要選出正確答案面試時(shí)面試官會(huì)追問為什么選這個(gè)和還有沒有其他方案。我的建議是趁著筆試后對(duì)知識(shí)點(diǎn)的印象還很深挑幾個(gè)核心內(nèi)容做一次口述練習(xí)。比如Flink的Checkpoint機(jī)制你不能只說通過Checkpoint實(shí)現(xiàn)狀態(tài)恢復(fù)要能講清楚檢查點(diǎn)是怎么觸發(fā)的、Barrier對(duì)齊是怎么回事、精確一次和至少一次的區(qū)別、狀態(tài)后端有哪些。再比如數(shù)據(jù)傾斜不能只說加隨機(jī)前綴要能說明加前綴后如何進(jìn)行兩階段聚合、性能代價(jià)有多大、什么場景下適合用廣播變量。這種把知識(shí)點(diǎn)從認(rèn)識(shí)變成會(huì)講的過程是面試準(zhǔn)備中最有價(jià)值的部分。7.3 個(gè)人的一點(diǎn)體會(huì)筆試是短板探測器這次筆試給我最大的收獲不是流程走完了而是讓我看清了自己在哪些方面還有短板。我在復(fù)習(xí)階段自我感覺SQL還不錯(cuò)但實(shí)際筆試時(shí)發(fā)現(xiàn)自己在窗口函數(shù)的某些邊界場景下還是會(huì)猶豫我以為自己對(duì)Spark很熟但選擇題里考到RDD的窄依賴和寬依賴時(shí)有個(gè)選項(xiàng)讓我糾結(jié)了很久。這些自我感覺良好但實(shí)際還不夠扎實(shí)的地方如果不去筆試檢驗(yàn)可能永遠(yuǎn)不會(huì)暴露。所以我也想給正在準(zhǔn)備秋招的人一個(gè)建議不要只盯著筆試通過與否看把它當(dāng)成一次免費(fèi)的壓力測試和短板探測器。每一道做錯(cuò)的題、每一個(gè)卡殼的瞬間都是后續(xù)復(fù)習(xí)最明確的指引。2024年秋招競爭確實(shí)不小但工程數(shù)據(jù)崗的核心考察方向其實(shí)是清晰和穩(wěn)定的把算法、SQL、大數(shù)據(jù)組件、Java基礎(chǔ)這四個(gè)方向扎扎實(shí)實(shí)準(zhǔn)備好筆試這關(guān)沒有想象中那么可怕。