2023年這一輪秋招大環(huán)境有多卷不用我多說了。大數(shù)據(jù)崗位更是重災(zāi)區(qū)投出去的簡歷不少真正能走到筆試環(huán)節(jié)的其實(shí)沒幾個(gè)。58集團(tuán)的筆試是我秋招過程中印象比較深的一場不是因?yàn)轭}特別難而是它的考察面非常典型幾乎把大數(shù)據(jù)崗位筆試應(yīng)該有的模塊全涵蓋了Java基礎(chǔ)、大數(shù)據(jù)組件原理、SQL實(shí)戰(zhàn)、算法、架構(gòu)設(shè)計(jì)一個(gè)都沒落下。這篇文章我就把整個(gè)備考和實(shí)戰(zhàn)過程完整復(fù)盤一遍從題型分布到具體題目思路再到我踩過的坑全部分享出來給后面準(zhǔn)備大數(shù)據(jù)秋招的同學(xué)一個(gè)參考。先說清楚這篇內(nèi)容適合誰準(zhǔn)備投遞58集團(tuán)或其他互聯(lián)網(wǎng)公司大數(shù)據(jù)開發(fā)/數(shù)據(jù)倉庫崗位的同學(xué)正在刷筆試真題、想了解大廠筆試套路的人以及那些剛接觸大數(shù)據(jù)方向、對筆試考察重點(diǎn)還很模糊的在校生。如果你已經(jīng)工作了一段時(shí)間這篇文章也能幫你回顧一下大數(shù)據(jù)崗位筆試的核心考點(diǎn)長什么樣。1. 秋招大數(shù)據(jù)崗筆試的整體認(rèn)知與準(zhǔn)備思路1.1 別急著刷題先搞懂公司想要什么樣的人我在投58集團(tuán)之前先花了幾天時(shí)間研究它的大數(shù)據(jù)業(yè)務(wù)形態(tài)。58同城的核心業(yè)務(wù)是分類信息覆蓋招聘、房產(chǎn)、二手車、本地生活服務(wù)等板塊。這些業(yè)務(wù)有一個(gè)共同特點(diǎn)用戶行為數(shù)據(jù)量級巨大但數(shù)據(jù)價(jià)值密度相對較低需要從海量日志里挖掘出有價(jià)值的用戶意圖再反哺到推薦、搜索、風(fēng)控等場景。這個(gè)業(yè)務(wù)特點(diǎn)直接決定了58大數(shù)據(jù)崗筆試的考察方向。它不是那種純理論考核而是很務(wù)實(shí)地圍繞“海量數(shù)據(jù)處理”這個(gè)核心命題展開。我在刷題群里也見識過不少同學(xué)的失利原因有的人Java基礎(chǔ)很強(qiáng)但對Hive調(diào)優(yōu)完全沒概念有的人SQL寫得很溜遇到Flink的狀態(tài)管理就懵了。這些問題本質(zhì)上都是沒有理解大數(shù)據(jù)崗位對人才的真實(shí)要求——你要能打通從數(shù)據(jù)采集到數(shù)據(jù)應(yīng)用的全鏈路而不是只擅長某一段。所以我的建議是在動(dòng)手刷題之前先花一兩天時(shí)間做兩件事第一把目標(biāo)公司的業(yè)務(wù)模式和核心數(shù)據(jù)場景梳理清楚第二對照大數(shù)據(jù)崗位的通用能力模型Java基礎(chǔ)、離線計(jì)算、實(shí)時(shí)計(jì)算、數(shù)據(jù)倉庫、調(diào)度與治理做一個(gè)自我評估找出自己最薄弱的兩個(gè)模塊重點(diǎn)突擊。這個(gè)投入產(chǎn)出比遠(yuǎn)高于盲目刷題。1.2 我的備考時(shí)間線與資料清單我是從9月初開始集中準(zhǔn)備的到58集團(tuán)筆試大概是9月中旬前后大概兩周多。時(shí)間不算充裕所以我的策略是抓大放小。具體安排大概是這樣的第一周主攻大數(shù)據(jù)組件原理Hadoop生態(tài)系的HDFS和MapReduce我不再細(xì)究集中精力過Hive和Spark尤其是Hive的調(diào)優(yōu)參數(shù)和Spark的作業(yè)執(zhí)行流程這兩塊是筆試高頻考點(diǎn)。第二周前半段刷SQL題重點(diǎn)練窗口函數(shù)、留存分析、漏斗轉(zhuǎn)化這類互聯(lián)網(wǎng)經(jīng)典場景題。第二周后半段突擊Java并發(fā)和JVM基礎(chǔ)同時(shí)刷了大概20道LeetCode中等難度的算法題以數(shù)組、鏈表、哈希表為主。資料方面我用的不是某一本固定的書而是組合拳Hive調(diào)優(yōu)部分參考了官方Wiki和幾篇深度技術(shù)博客Spark部分以《Spark快速大數(shù)據(jù)分析》為主SQL刷題用的是LeetCode數(shù)據(jù)庫題庫和牛客網(wǎng)的SQL實(shí)戰(zhàn)模塊算法部分則直接用LeetCode Hot 100。Java部分我沒花太多時(shí)間啃書主要靠?？途W(wǎng)的大數(shù)據(jù)崗位真題里的Java題來查漏補(bǔ)缺。另外有一點(diǎn)我想單獨(dú)提醒很多同學(xué)喜歡收集資料網(wǎng)盤里存了幾十個(gè)G的面試題但真正打開看的沒幾個(gè)。我當(dāng)時(shí)就一個(gè)習(xí)慣凡是收集到的面經(jīng)和真題必須當(dāng)天消化完并整理成自己的筆記。因?yàn)榫W(wǎng)上流傳的真題答案很多是有問題的如果自己不驗(yàn)證、不思考背下來的答案反而是隱患稍一追問就露餡。2. 58集團(tuán)筆試題型全拆解從選擇題到編程題2.1 筆試整體結(jié)構(gòu)與時(shí)間分配策略58集團(tuán)的筆試是在?？途W(wǎng)平臺上進(jìn)行的我記得整體時(shí)長是90分鐘題量不算小大概有40道左右的題目。整張?jiān)嚲淼慕Y(jié)構(gòu)大致可以分為四個(gè)部分選擇題單選多選、簡答題/填空題、SQL編程題、算法編程題。它沒有單獨(dú)的主觀架構(gòu)設(shè)計(jì)題但在SQL題和簡答題里會滲透一些設(shè)計(jì)思維的考察。時(shí)間分配上我吃了個(gè)小虧這個(gè)后面會在避坑章節(jié)詳細(xì)說。這里先給一個(gè)合理的參考方案選擇題控制在25分鐘以內(nèi)因?yàn)榇蟛糠质歉拍铑}會就是會不會的糾結(jié)也沒有意義簡答題和填空題控制在15分鐘左右這類題通?？疾斓氖菍δ硞€(gè)具體知識點(diǎn)的理解深度不需要長篇大論SQL題和編程題是拿分大頭至少留出40分鐘尤其是編程題寧可前面的選擇題蒙一個(gè)也要保證編程題有充足的時(shí)間調(diào)試。我還記得當(dāng)時(shí)有個(gè)同學(xué)跟我吐槽說他選擇題做得太細(xì)每題都想得很透徹結(jié)果最后編程題只剩10分鐘三道題全都沒來得及提交這基本等于直接宣告筆試失敗。所以時(shí)間策略不是技巧問題是生死問題。2.2 選擇題板塊集中考察的幾類知識點(diǎn)Java基礎(chǔ)類是選擇題的重頭戲大概占了三分之一左右的比例?？疾斓闹攸c(diǎn)集中在集合框架的底層實(shí)現(xiàn)HashMap的put流程、ConcurrentHashMap的鎖粒度、ArrayList和LinkedList的適用場景、JVM內(nèi)存區(qū)域劃分、垃圾收集算法、線程池的核心參數(shù)和執(zhí)行流程。這些題目不算偏但出題人喜歡在細(xì)節(jié)上做文章比如問你“HashMap在JDK1.8中鏈表轉(zhuǎn)紅黑樹的閾值為什么是8”這種題如果只看過面經(jīng)而沒有真正理解泊松分布的含義很容易翻車。大數(shù)據(jù)組件的選擇題也很密集。HDFS的讀寫流程、MapReduce的Shuffle機(jī)制尤其是環(huán)形緩沖區(qū)的默認(rèn)大小和溢寫比例、Hive的架構(gòu)組成、Spark的寬窄依賴判斷、Kafka的ISR機(jī)制和消息投遞語義、Flink的Checkpoint機(jī)制這些都是高頻考點(diǎn)。說實(shí)話這部分題目只要能系統(tǒng)過一遍組件原理拿分并不難難點(diǎn)在于范圍廣容易遺漏。另外還有幾道計(jì)算機(jī)網(wǎng)絡(luò)和操作系統(tǒng)的題比如TCP三次握手的狀態(tài)變化、進(jìn)程和線程的區(qū)別、死鎖產(chǎn)生的必要條件?？吹竭@些題的時(shí)候我確實(shí)愣了一下因?yàn)榇蟛糠謺r(shí)間都在準(zhǔn)備大數(shù)據(jù)組件差點(diǎn)忽略了這些基礎(chǔ)科目。我當(dāng)時(shí)是靠著平時(shí)的積累硬答的所以建議時(shí)間充裕的同學(xué)還是要把計(jì)網(wǎng)和OS的?？歼x擇題過一遍不要有僥幸心理。2.3 主觀題與SQL實(shí)戰(zhàn)題拉開差距的關(guān)鍵填空題和簡答題量不大我記得有兩三道考的是非常具體的知識點(diǎn)。比如有一道填空題考查的是Hive中sort by和order by的區(qū)別還有一道簡答題問的是Spark寬依賴和窄依賴的區(qū)別以及各自對容錯(cuò)的影響。這類題目其實(shí)比選擇題更考驗(yàn)理解深度因?yàn)樘羁疹}不能蒙簡答題需要你用專業(yè)術(shù)語把原理說清楚。SQL題一共三道幾乎都是業(yè)務(wù)場景題難度是梯度上升的。第一道是基礎(chǔ)聚合類似“統(tǒng)計(jì)每個(gè)類目下的商品數(shù)量”主要考察GROUP BY的基本使用第二道是窗口函數(shù)應(yīng)用我記得是“計(jì)算每個(gè)用戶最近三筆訂單的平均金額”用到的是ROW_NUMBER或者AVG配合窗口排序第三道就是拉開差距的題了考的是留存分析這個(gè)我下一章詳細(xì)展開。說實(shí)話第三道題如果沒有提前練過留存分析的套路在筆試那種緊張的環(huán)境下很容易卡殼。3. 真題回憶與解題思路復(fù)盤3.1 留存分析SQL題從暴力解法到標(biāo)準(zhǔn)寫法這是一道典型的互聯(lián)網(wǎng)公司數(shù)據(jù)分析場景題題目的具體描述是有一張用戶登錄日志表login_log包含字段user_id用戶ID、login_date登錄日期需要計(jì)算2023年1月1日當(dāng)天新增用戶的次日留存率、7日留存率和30日留存率。這個(gè)題的難點(diǎn)在于“新增用戶”的定義。我后來復(fù)盤時(shí)發(fā)現(xiàn)很多人第一反應(yīng)是直接找login_date等于2023-01-01的用戶但這其實(shí)是有問題的——一個(gè)新用戶在1月1日之前可能已經(jīng)注冊但從未登錄也可能在1月1日當(dāng)天注冊當(dāng)天登錄這兩種情況需要區(qū)分。題目里如果只給了登錄日志表那我們就約定固定一個(gè)口徑以用戶在1月1日第一次出現(xiàn)在登錄日志中視為該日新增用戶。我當(dāng)時(shí)在筆試中寫的解法是這樣的用多表關(guān)聯(lián)的方式實(shí)現(xiàn)-- 先找出2023-01-01的新增用戶 -- 定義該用戶的首次登錄日期就是2023-01-01 WITH new_users AS ( SELECT user_id, MIN(login_date) AS first_login_date FROM login_log GROUP BY user_id HAVING MIN(login_date) 2023-01-01 ) SELECT COUNT(DISTINCT nu.user_id) AS new_user_cnt, ROUND( COUNT(DISTINCT CASE WHEN ll.login_date DATE_ADD(2023-01-01, 1) THEN ll.user_id END) / COUNT(DISTINCT nu.user_id), 4 ) AS day1_retention_rate, ROUND( COUNT(DISTINCT CASE WHEN ll.login_date DATE_ADD(2023-01-01, 6) THEN ll.user_id END) / COUNT(DISTINCT nu.user_id), 4 ) AS day7_retention_rate, ROUND( COUNT(DISTINCT CASE WHEN ll.login_date DATE_ADD(2023-01-01, 29) THEN ll.user_id END) / COUNT(DISTINCT nu.user_id), 4 ) AS day30_retention_rate FROM new_users nu LEFT JOIN login_log ll ON nu.user_id ll.user_id AND ll.login_date IN ( DATE_ADD(2023-01-01, 1), DATE_ADD(2023-01-01, 6), DATE_ADD(2023-01-01, 29) );這里有幾個(gè)關(guān)鍵點(diǎn)需要說明。第一WITH子句的寫法是為了讓邏輯更清晰在Hive、Spark SQL中都是支持的但如果你不確定筆試用的SQL引擎是否支持CTE穩(wěn)妥的辦法是寫成子查詢嵌套的形式。第二留存率的計(jì)算一定要用活躍用戶數(shù)除以新增用戶數(shù)我當(dāng)時(shí)算的是7日留存判斷條件用的是DATE_ADD(2023-01-01, 6)因?yàn)榈?天是1月7日差值是6天。第三COUNT(DISTINCT)去重是必須的同一個(gè)用戶在同一天可能多次登錄不去重會導(dǎo)致分母或分子虛高。這里多提一句筆試中遇到留存題除了這種基礎(chǔ)口徑現(xiàn)在大廠更愛考多日留存矩陣就是一次SQL同時(shí)算出多個(gè)自然日新增用戶的次日、3日、7日留存率做成一個(gè)透視表。這個(gè)結(jié)構(gòu)其實(shí)是一個(gè)經(jīng)典的“行轉(zhuǎn)列”問題主要靠CASE WHEN配合DATEDIFF來實(shí)現(xiàn)。建議大家在準(zhǔn)備階段就把這兩種寫法都練熟。3.2 Hive/Spark調(diào)優(yōu)題數(shù)據(jù)傾斜的經(jīng)典解法筆試中有一道簡答題考察的是數(shù)據(jù)傾斜的處理方案具體問法是在使用Hive或Spark進(jìn)行Join操作時(shí)某些Key的數(shù)據(jù)量遠(yuǎn)大于其他Key導(dǎo)致任務(wù)長時(shí)間運(yùn)行在某個(gè)Stage請列舉至少三種解決方案。這道題其實(shí)不算難考察的是考生有沒有真正處理過數(shù)據(jù)傾斜的經(jīng)驗(yàn)而不是只會背參數(shù)。我當(dāng)時(shí)是按這個(gè)思路作答的。第一大小表Join使用MapJoin。如果一個(gè)大表和一個(gè)小表做Join可以通過set hive.auto.convert.jointrue開啟自動(dòng)MapJoin把小表加載到內(nèi)存中在Map端完成Join避免Shuffle階段的數(shù)據(jù)傾斜。我在實(shí)際項(xiàng)目中也遇到過這種情況把參數(shù)調(diào)上之后原本跑40分鐘的任務(wù)縮短到8分鐘。第二針對空值Key進(jìn)行過濾或加隨機(jī)前綴。在實(shí)踐中數(shù)據(jù)傾斜最常見的原因就是Key值為空比如用戶日志里沒有匹配上的user_id是空字符串導(dǎo)致所有空值都分發(fā)到同一個(gè)Reduce。解決思路是如果空值本身無意義直接過濾掉如果空值有意義可以給空值加上隨機(jī)前綴讓它分散到不同的Reduce中去。第三對傾斜Key加隨機(jī)前綴再進(jìn)行二次聚合。這個(gè)方案適合聚合場景比如WordCount中某個(gè)單詞出現(xiàn)頻率特別高。第一次聚合時(shí)給Key加一個(gè)隨機(jī)數(shù)前綴將一個(gè)大Key拆成多個(gè)小Key并行聚合第二次聚合再把隨機(jī)數(shù)去掉做最終聚合。這樣能顯著緩解單點(diǎn)壓力。除此之外我還提到了使用Salting技術(shù)做兩階段Join以及調(diào)整Spark中的spark.sql.shuffle.partitions參數(shù)來增加Reduce數(shù)量讓數(shù)據(jù)打得更散。這道題我答得比較完整后面對答案時(shí)確認(rèn)了幾個(gè)關(guān)鍵點(diǎn)都踩中了。數(shù)據(jù)傾斜是面試中的高頻話題筆試中雖然只考察了簡答形式但面試環(huán)節(jié)大概率也會追問建議一定要理解原理而不是背答案。3.3 Java與算法題TopK問題與字符串處理58的算法題不算難但很能考察基本功。我記得有一道題是給定一個(gè)整數(shù)數(shù)組找出出現(xiàn)頻率最高的K個(gè)元素也就是經(jīng)典的TopK問題。這道題有幾種解法最直接的是用哈希表統(tǒng)計(jì)頻率再根據(jù)頻率排序。如果限定時(shí)間復(fù)雜度為O(nlog k)就要用最小堆來維護(hù)當(dāng)前頻率最高的K個(gè)元素。我當(dāng)時(shí)用的是PriorityQueue實(shí)現(xiàn)最小堆的寫法順手還能在IDE里跑通測試用例。這道題的關(guān)鍵點(diǎn)在于堆的大小一定要設(shè)為K堆頂是當(dāng)前頻率最小的元素每來一個(gè)新元素如果它比堆頂大就彈出堆頂并插入新元素。這樣遍歷完整個(gè)數(shù)組后堆里剩下的就是頻率最高的K個(gè)元素。Java題我記得考了一道字符串相關(guān)的大概意思是給定一個(gè)字符串找出其中最長的無重復(fù)字符子串的長度。這個(gè)題用滑動(dòng)窗口可以做到O(n)的時(shí)間復(fù)雜度核心是維護(hù)一個(gè)哈希表記錄每個(gè)字符最近一次出現(xiàn)的位置再維護(hù)一個(gè)左指針。如果發(fā)現(xiàn)某個(gè)字符已經(jīng)在窗口中出現(xiàn)過就把左指針移到它上一次出現(xiàn)位置的下一個(gè)位置。說句題外話我在筆試前大概兩周做了20多道這種中低難度的算法題這幫我建立了足夠的解題手感。筆試中的算法題其實(shí)比LeetCode Hot 100里的同類型題要簡單一點(diǎn)所以不用太擔(dān)心難度但也不能完全不準(zhǔn)備。比較搞笑的是我后來在面試中被追問了HashMap在多線程下為什么會死循環(huán)的問題這反而是筆試選擇題里考察過的知識點(diǎn)所以知識積累這個(gè)東西真的會在你不經(jīng)意的時(shí)候給你獎(jiǎng)勵(lì)。3.4 大數(shù)據(jù)架構(gòu)設(shè)計(jì)題雖然沒有單獨(dú)出但處處是埋伏這里我想多說一句。拋開58集團(tuán)這場筆試不談2023年的大數(shù)據(jù)崗筆試整體趨勢是純架構(gòu)設(shè)計(jì)型主觀題越來越少但很多細(xì)節(jié)題會以架構(gòu)設(shè)計(jì)的底層邏輯作為背景。比如第2章提到的那道用窗口函數(shù)計(jì)算“每個(gè)用戶最近三筆訂單的平均金額”表面上是一道SQL題但出題人真正想考察的是你能不能理解如何在實(shí)時(shí)數(shù)倉中做會話級別的數(shù)據(jù)處理。所以我的建議是準(zhǔn)備筆試的時(shí)候不能只停留在寫SQL、背原理的層面要把組件原理串聯(lián)成一條完整的數(shù)據(jù)鏈路數(shù)據(jù)從業(yè)務(wù)方的日志產(chǎn)生通過Flume采集到Kafka由Flink或Spark Streaming消費(fèi)做實(shí)時(shí)計(jì)算同時(shí)通過Sqoop或DataX同步到HDFS做離線計(jì)算離線任務(wù)跑完落庫到Hive數(shù)倉再由調(diào)度工具比如DolphinScheduler或Airflow統(tǒng)一管理最后通過BI工具或接口服務(wù)對外提供數(shù)據(jù)支持。你不需要寫出一份完美的架構(gòu)文檔但必須清楚每一層是做什么的、組件之間怎么銜接、數(shù)據(jù)一致性怎么保證。我在筆試中就遇到了一道選擇題問的是Kafka Producer端如何保證消息不丟失。光是這個(gè)知識點(diǎn)如果你沒有把Kafka放在整條數(shù)據(jù)鏈路里理解很容易只記住幾個(gè)參數(shù)acksall、retries、enable.idempotencetrue而不知道這些參數(shù)在真實(shí)場景中的意義。實(shí)際上這三個(gè)參數(shù)分別解決的是Broker確認(rèn)、網(wǎng)絡(luò)重試、冪等寫入三個(gè)不同層面的問題缺一個(gè)都不能算完備。所以組件原理不是孤立的考點(diǎn)它在任何一個(gè)大廠筆試?yán)锒贾档帽划?dāng)成一門系統(tǒng)工程來復(fù)習(xí)。4. 常見問題與避坑指南4.1 我在真實(shí)筆試中踩過的坑第一個(gè)坑是時(shí)間分配失衡。我前面提到過我在選擇題上花的時(shí)間有點(diǎn)多尤其是幾道多選讓我猶豫了很久結(jié)果到了SQL題和編程題階段時(shí)間只剩下不到35分鐘。雖然最后憑借手速勉強(qiáng)提交了但有幾道SQL題我明顯可以做得更從容、考慮得更周全。這給所有準(zhǔn)備筆試的同學(xué)一個(gè)教訓(xùn)選擇題的優(yōu)先級永遠(yuǎn)是低于編程題的一道選擇題可能就兩分而一道SQL題動(dòng)輒十幾二十分。遇到猶豫的選擇題憑第一感覺快速選完立刻進(jìn)入下一題。第二個(gè)坑是平臺環(huán)境的適配問題。58集團(tuán)的筆試是在?？途W(wǎng)上進(jìn)行的它的代碼編輯器和本地IDE差別很大沒有自動(dòng)補(bǔ)全、沒有代碼提示、甚至切換語言時(shí)一些快捷鍵也不一樣。我平時(shí)刷題習(xí)慣用IntelliJ IDEA筆試時(shí)在牛客網(wǎng)的編輯器里手寫代碼一開始特別不適應(yīng)各種小語法錯(cuò)誤反復(fù)出現(xiàn)。所以建議大家在筆試前至少去牛客網(wǎng)在線編程平臺練習(xí)兩三次熟悉那個(gè)編輯器的交互方式包括怎么切換輸入輸出、怎么查看報(bào)錯(cuò)信息、怎么調(diào)試代碼。第三個(gè)坑是SQL題的函數(shù)兼容性。筆試平臺提供的SQL引擎通常是MySQL或PostgreSQL而不是Hive或Spark SQL。我當(dāng)時(shí)有一道SQL題用了Hive特有的LATERAL VIEW配合EXPLODE來炸裂數(shù)組結(jié)果平臺報(bào)語法錯(cuò)誤我不得不改寫成標(biāo)準(zhǔn)的SQL寫法白白浪費(fèi)了幾分鐘。這提醒大家筆試中寫SQL優(yōu)先用標(biāo)準(zhǔn)的SQL語法不要使用具體框架特有的函數(shù)除非題目明確說明了是在Hive環(huán)境下進(jìn)行。第四個(gè)坑是沒有提前檢查網(wǎng)絡(luò)和硬件。聽起來很基礎(chǔ)但我真的有同學(xué)在筆試當(dāng)天因?yàn)樾@網(wǎng)不穩(wěn)定編程題提交到一半斷線了最后系統(tǒng)自動(dòng)交卷直接白給。我自己在寫SQL題時(shí)也遇到了編輯器卡頓的問題還好網(wǎng)絡(luò)恢復(fù)后內(nèi)容還在。建議至少在筆試前半小時(shí)檢查一下網(wǎng)絡(luò)環(huán)境如果可以使用有線網(wǎng)絡(luò)連接并把其他占用帶寬的程序全部關(guān)掉。4.2 常見問題速查表這里整理一個(gè)筆試過程中最容易出問題的點(diǎn)按“考前要確認(rèn)”和“考中要警惕”兩個(gè)維度來梳理維度問題點(diǎn)建議處理方式考前確認(rèn)筆試平臺是哪家?？?賽碼/智鼎提前去平臺官網(wǎng)完成一次模擬測試熟悉界面和交卷邏輯考前確認(rèn)題目是否支持多種語言提前確認(rèn)編程題支持的編譯語言列表別只準(zhǔn)備Java考前確認(rèn)SQL運(yùn)行環(huán)境是什么引擎優(yōu)先使用標(biāo)準(zhǔn)SQL遇到窗口函數(shù)等復(fù)雜操作做好語法兼容的準(zhǔn)備考中警惕選擇題在多選題上卡殼不確定的多選先憑第一感選完標(biāo)記后繼續(xù)推進(jìn)別戀戰(zhàn)考中警惕編程題編譯報(bào)錯(cuò)卻找不到原因先看是不是輸入輸出格式寫錯(cuò)了再檢查類名和Main方法簽名不要反復(fù)整體重寫考中警惕本地有相對路徑依賴的代碼筆試平臺不讀本地文件所有輸入都必須通過Scanner或System.in獲取考后復(fù)盤忘記截圖或記錄題目答題時(shí)盡量給自己的答案和思路做筆記方便筆試后復(fù)盤4.3 獨(dú)家避坑技巧如何利用好歷年真題和面經(jīng)網(wǎng)上關(guān)于大廠筆試的真題很多但質(zhì)量參差不齊。我的習(xí)慣是每道真題不要只看答案而是自己先做一遍然后對照多個(gè)版本的答案來驗(yàn)證。比如我復(fù)習(xí)Hiveorder by和sort by的區(qū)別時(shí)網(wǎng)上有三種說法有的說order by是全局排序sort by是分區(qū)內(nèi)排序有的說order by會啟用單個(gè)Reducer有的說sort by在設(shè)置了set hive.mapred.modestrict時(shí)不能用來做全局排序。這三種說法其實(shí)互相補(bǔ)充并不矛盾但如果你只背了第一個(gè)遇到變形題就很容易判斷失誤。所以同一道題多看兩套解釋是完全值得的這個(gè)過程本身就是在加深理解。另外我也建議大家加一兩個(gè)秋招交流群但不是用來閑聊的而是用來交換筆試題信息的。我是在群里看到有人分享了58集團(tuán)前幾年的筆試題目回憶雖然不保證完全一致但確實(shí)讓我的準(zhǔn)備方向更清晰了。筆試結(jié)束后盡量趁記憶還熱的時(shí)候把題目和你的答案記錄到一個(gè)文檔里這個(gè)文檔不僅對復(fù)盤有用面試前拿來過一遍面試官問“你筆試中有印象深刻的題嗎”時(shí)你能直接回答上來顯得很真誠。5. 筆試之后的銜接準(zhǔn)備面試的前置鋪墊筆試只是第一道門檻如果你順利通過了接下來大概率會進(jìn)入面試環(huán)節(jié)。從我的經(jīng)驗(yàn)來看58集團(tuán)的筆試和面試之間的間隔不會太長所以筆試結(jié)束后我一般不會像其他人那樣徹底放松而是立刻趁著對考題的印象還在做兩件事。第一件事是復(fù)盤筆試中不確定的題目。比如我在筆試中對一道關(guān)于ConcurrentHashMap在JDK1.8中的鎖粒度變化的判斷題沒有十足把握筆試結(jié)束后就去查了源碼注釋和相關(guān)博客把這個(gè)知識點(diǎn)徹底弄懂。這類“當(dāng)時(shí)不確定”的問題往往是面試官最喜歡拿來深入追問的點(diǎn)。因?yàn)槊嬖嚬倌芸吹侥愕墓P試答卷如果他在筆試中發(fā)現(xiàn)某個(gè)基礎(chǔ)概念你掌握得不夠扎實(shí)極大概率會在面試中專門問一次。第二件事是結(jié)合簡歷做一個(gè)項(xiàng)目亮點(diǎn)的梳理。58的大數(shù)據(jù)崗面試基本會圍繞兩個(gè)方向展開一是基礎(chǔ)原理二是真實(shí)項(xiàng)目經(jīng)歷。如果你簡歷上寫了自己做過數(shù)據(jù)倉庫項(xiàng)目面試官一定會問你數(shù)倉分層的思路、維度建模的方法、數(shù)據(jù)質(zhì)量怎么保證。我在準(zhǔn)備面試時(shí)把自己做過的一個(gè)基于Hive的用戶行為數(shù)倉項(xiàng)目整體復(fù)盤了一遍從數(shù)據(jù)接入、ETL過程、指標(biāo)定義到調(diào)度運(yùn)維每一個(gè)環(huán)節(jié)都能講清楚選型和背后的原因。這種前置準(zhǔn)備遠(yuǎn)比臨時(shí)背答案管用。第三件事比較實(shí)用就是準(zhǔn)備一段30秒的自我介紹。不要小看這個(gè)面試官每天面很多人一個(gè)能快速體現(xiàn)你技術(shù)棧和優(yōu)勢的自我介紹會直接影響面試官對你的初始印象。我的介紹邏輯很簡單先說我在大數(shù)據(jù)方向的定位離線數(shù)倉還是實(shí)時(shí)計(jì)算再提我做過的最有代表性的項(xiàng)目最后說一下我當(dāng)前在深入學(xué)習(xí)的領(lǐng)域比如Flink或數(shù)據(jù)治理。這樣既清楚又坦誠面試官也有抓手來展開提問。我還想特別提一點(diǎn)筆試中如果有某道題確實(shí)不會面試中萬一被問到不要裝作自己當(dāng)時(shí)就會了。誠實(shí)地回答“這道題我當(dāng)時(shí)沒有完全想清楚但筆試結(jié)束后我查閱了相關(guān)資料現(xiàn)在的理解是……”這種回答反而會給面試官留下比較好的印象因?yàn)槟阏宫F(xiàn)了主動(dòng)學(xué)習(xí)和解決問題的態(tài)度。面試官其實(shí)不怕你不會怕的是不會卻硬編。寫在最后的一點(diǎn)心得回看58集團(tuán)這場筆試我認(rèn)為它最大的價(jià)值在于幫我把整個(gè)大數(shù)據(jù)知識體系做了一次全面檢閱讓我清楚認(rèn)識到哪些地方是真正的強(qiáng)項(xiàng)哪些地方只是“看著會了”。備考期間我每天刷題到晚上十一點(diǎn)說實(shí)話挺累的但那種對一個(gè)知識點(diǎn)從模糊到通透的過程確實(shí)很讓人上癮。最后再分享一個(gè)小技巧筆試時(shí)如果時(shí)間特別緊張編程題就算不能AC全部用例也一定要把思路和部分實(shí)現(xiàn)寫上去平臺通常會對通過部分用例的代碼給部分分?jǐn)?shù)這個(gè)分?jǐn)?shù)有時(shí)候就能讓你壓線晉級。我當(dāng)時(shí)有一道算法題只過了60%的用例最后依然收到了面試通知很大概率就是部分得分救了我。所以無論遇到什么情況都不要空著提交把能寫的代碼都寫上去。大數(shù)據(jù)這條路筆試、面試、入職后的挑戰(zhàn)一個(gè)接一個(gè)但只要每一步都認(rèn)真走結(jié)果不會太差。希望這份復(fù)盤能幫到正在準(zhǔn)備秋招的你也祝你在筆試環(huán)節(jié)穩(wěn)穩(wěn)發(fā)力順利晉級。