神策數(shù)據(jù)這兩年在數(shù)據(jù)圈子里熱度一直不低做用戶行為分析出身產(chǎn)品線覆蓋采集、ETL、查詢分析、智能運(yùn)營一整條鏈路。2023年秋招技術(shù)崗?fù)读怂业娜瞬簧俚谝慌P試刷人也很狠。我把當(dāng)時(shí)參加第一批筆試的記錄翻了出來結(jié)合周圍一起筆試的同學(xué)反饋把考察方向、題型分布、踩坑點(diǎn)整理成這篇東西給后面準(zhǔn)備數(shù)據(jù)類公司校招的朋友做個(gè)參考。這篇東西不摻水分主要講清楚三件事筆試到底考什么、怎么備考才高效、有哪些非技術(shù)因素會(huì)莫名其妙讓你丟分。先交代一下背景。神策技術(shù)崗筆試是典型的在線筆試時(shí)長大概120分鐘題型分三塊編程題、選擇題和簡答題。編程題一般2到3道選擇題大概15到20道簡答題1到2道。整體難度在互聯(lián)網(wǎng)公司校招里屬于中游偏上但跟大廠純算法題海戰(zhàn)術(shù)不同它更看重你對(duì)大數(shù)據(jù)業(yè)務(wù)場(chǎng)景的理解很多題都是圍繞自家埋點(diǎn)采集和用戶行為分析業(yè)務(wù)展開的。1. 筆試前的信息收集與整體定位1.1 神策的技術(shù)棧決定了筆試方向在打開筆試鏈接之前我建議你先花一個(gè)晚上搞清楚神策到底是做什么的技術(shù)上又偏重哪些東西。這不是套話因?yàn)樗墓P試題是真的會(huì)貼著業(yè)務(wù)走。神策的核心產(chǎn)品是神策分析主打用戶行為數(shù)據(jù)采集、建模、查詢分析。底層技術(shù)棧主力是Java后端服務(wù)大量基于Spring生態(tài)。數(shù)據(jù)這塊采集端有各種埋點(diǎn)SDK數(shù)據(jù)傳輸會(huì)用到Kafka這樣的消息隊(duì)列實(shí)時(shí)計(jì)算部分Flink用得不少存儲(chǔ)和查詢側(cè)主要是ClickHouse。你要是對(duì)這套鏈路沒概念筆試?yán)锬切╊}幾乎無從下手。我當(dāng)時(shí)把它的官網(wǎng)文檔翻了一遍重點(diǎn)是數(shù)據(jù)接入SDK設(shè)計(jì)和全端采集方案又看了幾篇技術(shù)博客基本摸清了它的技術(shù)偏好。這套準(zhǔn)備給我最大的幫助不是記住某個(gè)API而是建立了一個(gè)判斷標(biāo)準(zhǔn)凡是跟用戶行為、事件上報(bào)、漏斗分析、留存查詢相關(guān)的題它想考察的一定不只是算法而是你對(duì)整套數(shù)據(jù)鏈路的理解。1.2 筆試形式與考查模塊總體概覽神策的筆試系統(tǒng)用的是第三方在線評(píng)測(cè)平臺(tái)會(huì)開啟攝像頭監(jiān)控和切屏檢測(cè)。這里提醒一點(diǎn)筆試前務(wù)必找一個(gè)網(wǎng)絡(luò)穩(wěn)定、沒人打擾的環(huán)境瀏覽器建議用Chrome或Edge關(guān)掉所有無關(guān)插件。從第一批筆試的反饋來看整體模塊大致如下模塊題型題量建議用時(shí)考察重點(diǎn)編程算法在線編碼2~3道50~60分鐘數(shù)組、字符串、二叉樹、動(dòng)態(tài)規(guī)劃、模擬技術(shù)基礎(chǔ)不定項(xiàng)選擇15~20道30~40分鐘Java、SQL、操作系統(tǒng)、網(wǎng)絡(luò)、大數(shù)據(jù)組件業(yè)務(wù)場(chǎng)景簡答/設(shè)計(jì)1~2道20~30分鐘埋點(diǎn)鏈路、OLAP查詢、系統(tǒng)設(shè)計(jì)思維選擇題是倒扣分還是不得分當(dāng)時(shí)頁面上有說明不同批次規(guī)則不一定一樣進(jìn)去先仔細(xì)讀規(guī)則再動(dòng)手。編程題支持的語言以Java、C、Python為主但不建議用Python參加這場(chǎng)筆試原因后面說。2. 編程題與算法真正的分水嶺2.1 常見題型與難度區(qū)間編程題在整個(gè)筆試?yán)锸亲钅芾_差距的部分。不是說它難到天花板而是很多人前面選擇、簡答寫得太慢輪到編程題時(shí)時(shí)間已經(jīng)不夠了。神策這批筆試的編程題從題面風(fēng)格來看明顯不是力扣Hard堆出來的而是更接近Medium偏下的工程模擬題。我遇到的幾類是字符串處理類比如解析一段日志文本提取指定字段并做統(tǒng)計(jì)聚合。這類題考的是你用代碼處理半結(jié)構(gòu)化數(shù)據(jù)的能力跟數(shù)據(jù)采集鏈路的關(guān)系非常密切。數(shù)組與狀態(tài)模擬類類似于實(shí)現(xiàn)一個(gè)簡單的滑動(dòng)窗口同環(huán)比計(jì)算或者模擬一個(gè)事件隊(duì)列的處理過程。二叉樹或者鏈表基礎(chǔ)考得比較常規(guī)但只要出就藏在第二、第三題的位置。第一道題通常是送分題只涉及基礎(chǔ)語法和簡單邏輯一定不要慌快速寫完。第二、第三道是區(qū)分度所在考的是你能否把業(yè)務(wù)描述轉(zhuǎn)化成數(shù)據(jù)結(jié)構(gòu)和算法。比如有一道題題面?zhèn)窝b成統(tǒng)計(jì)用戶在指定時(shí)間段內(nèi)的事件序列實(shí)際解法就是排序加雙指針。如果你平時(shí)刷題只刷純算法題這類包裝過的題很容易看走眼。注意神策的編程題看重代碼的完整性和健壯性。光寫出核心思路但沒處理輸入邊界或者沒有考慮空數(shù)組、越界訪問都會(huì)扣分。在線評(píng)測(cè)用例覆蓋很全裸寫不測(cè)邊界基本過不了。2.2 我的做題策略和時(shí)間管理我的策略很簡單拿到題先全部掃一遍根據(jù)題面長度和數(shù)據(jù)范圍判斷難度不是按順序做而是按性價(jià)比做。第一道簡單題5到8分鐘內(nèi)必須寫完并自測(cè)通過第二、第三道每道給自己15分鐘思考加實(shí)現(xiàn)超時(shí)先跳過把能拿的分保住。時(shí)間上我會(huì)預(yù)留最后10分鐘做兩件事第一逐題檢查輸入輸出格式有沒有和題目要求對(duì)齊第二重新確認(rèn)有沒有漏掉的邊界條件。說實(shí)話很多校招生不是不會(huì)做是倒在了這個(gè)環(huán)節(jié)——樣例能過但一提交就是0分因?yàn)樽x的是System.in但題目要求從參數(shù)傳入或者輸出格式化少了個(gè)空格。編程語言這里多說一句。能用Java就優(yōu)先Java原因是神策整個(gè)技術(shù)棧是Java系的面試官看你的代碼時(shí)會(huì)更加認(rèn)同而且你回答問題也能結(jié)合JVM、并發(fā)這些Java生態(tài)的東西給后續(xù)面試埋伏筆。用Python雖然寫起來快但在線評(píng)測(cè)對(duì)Python的輸入輸出要求更嚴(yán)格反而容易出錯(cuò)。2.3 經(jīng)典題目思路復(fù)盤事件時(shí)間區(qū)間合并這里挑一道我當(dāng)時(shí)印象比較深的題題面大致是給定N個(gè)用戶的訪問事件每個(gè)事件包含用戶ID、開始時(shí)間、結(jié)束時(shí)間要求合并每個(gè)用戶的重疊時(shí)間區(qū)間輸出合并后的區(qū)間數(shù)量。做法就是經(jīng)典的排序加貪心。先按用戶ID分組組內(nèi)按開始時(shí)間排序然后遍歷區(qū)間維護(hù)當(dāng)前合并區(qū)間的右端點(diǎn)。如果下一個(gè)區(qū)間的開始時(shí)間小于等于當(dāng)前右端點(diǎn)就合并更新右端點(diǎn)為較大的結(jié)束時(shí)間否則開啟新區(qū)間。復(fù)雜度O(n log n)主要花在排序上。這道題本身不難真正坑人的是數(shù)據(jù)范圍很大如果用兩層循環(huán)暴力合并用例直接超時(shí)。另外它還隱含了一個(gè)陷阱開始時(shí)間和結(jié)束時(shí)間是用long類型給的用int接會(huì)溢出。你要是沒注意類型提交后可能有一半用例掛在溢出上。3. 后端基礎(chǔ)與大數(shù)據(jù)組件考察重點(diǎn)3.1 Java基礎(chǔ)、并發(fā)與JVM選擇題的重頭戲神策技術(shù)崗的選擇題里Java占比非常高這是由它的后端技術(shù)棧決定的。我當(dāng)時(shí)統(tǒng)計(jì)了一下Java相關(guān)的題大概能占到選擇題的三分之一到一半?？疾禳c(diǎn)集中在三個(gè)方向集合源碼、并發(fā)工具、JVM。集合這塊HashMap的底層結(jié)構(gòu)、擴(kuò)容機(jī)制、紅黑樹化條件是高頻考點(diǎn)。別只看八股文要真正理解為什么鏈表長度到8才轉(zhuǎn)紅黑樹為什么默認(rèn)負(fù)載因子是0.75這些數(shù)字背后都有工程考量面試延伸問起來也能接得住。并發(fā)部分ConcurrentHashMap在JDK 1.8前后的實(shí)現(xiàn)差異、synchronized和ReentrantLock的區(qū)別、線程池的核心參數(shù)和拒絕策略都是選擇題和后續(xù)面試的高頻問題。建議把線程池的工作流程畫一遍核心線程數(shù)、任務(wù)隊(duì)列、最大線程數(shù)、拒絕策略這條鏈路閉著眼睛都要能說出來。JVM考點(diǎn)主要是內(nèi)存區(qū)域劃分、對(duì)象創(chuàng)建過程、GC算法和常見垃圾回收器。神策這種做數(shù)據(jù)服務(wù)的公司對(duì)JVM調(diào)優(yōu)是有真實(shí)需求的所以筆試會(huì)考你Full GC問題排查的思路比如怎么通過jstat、jmap定位內(nèi)存泄漏。我做選擇題時(shí)有一個(gè)體會(huì)不定項(xiàng)選擇的坑在于少選扣分、錯(cuò)選不得分所以拿不準(zhǔn)的選項(xiàng)寧可不選也別多選。你以為是多選題實(shí)際上選錯(cuò)比不選更虧。3.2 消息隊(duì)列與實(shí)時(shí)計(jì)算結(jié)合業(yè)務(wù)場(chǎng)景來理解神策的數(shù)據(jù)鏈路里客戶端SDK產(chǎn)生的埋點(diǎn)事件會(huì)先進(jìn)入Kafka這類消息隊(duì)列再被Flink等實(shí)時(shí)計(jì)算引擎消費(fèi)處理。所以消息隊(duì)列和實(shí)時(shí)計(jì)算的題目是它筆試的一個(gè)特色。Kafka的考察重點(diǎn)無非是分區(qū)機(jī)制、副本機(jī)制、消費(fèi)組和偏移量管理。光背概念不夠它會(huì)換一層皮來問你比如某個(gè)Topic的分區(qū)數(shù)從3調(diào)整到6之后舊數(shù)據(jù)怎么分布或者消費(fèi)者組發(fā)生Rebalance時(shí)可能導(dǎo)致哪些問題。這就要你真正理解分區(qū)與消費(fèi)者之間的映射關(guān)系。Flink的題通常不深主要考思想層面事件時(shí)間和處理時(shí)間的區(qū)別、Watermark機(jī)制的作用、Exactly-Once語義怎么保證。我當(dāng)時(shí)復(fù)習(xí)的時(shí)候把Flink的容錯(cuò)機(jī)制和Checkpoint流程用一張流程圖梳理了一遍雖然筆試考不到這么細(xì)但這套體系本身就是面試加分項(xiàng)。實(shí)際工作里Kafka和Flink是很多數(shù)據(jù)系統(tǒng)的地基。就算筆試不考也建議花時(shí)間搞透。神策的崗位描述里經(jīng)常能看到熟悉Flink、Kafka優(yōu)先先儲(chǔ)備起來沒壞處。3.3 數(shù)據(jù)庫、ClickHouse與OLAP數(shù)據(jù)公司的必考項(xiàng)數(shù)據(jù)庫在神策筆試中一定是重頭戲因?yàn)樗漠a(chǎn)品核心就是讓用戶能對(duì)海量行為數(shù)據(jù)做即席查詢。SQL題大概率會(huì)有一道考多表關(guān)聯(lián)、Group By聚合、窗口函數(shù)。窗口函數(shù)是必須熟練掌握的特別是Row_Number、Rank、Sum Over這種寫法。神策的SQL題經(jīng)常是這種風(fēng)格有一張用戶事件表記錄每個(gè)用戶每天的事件數(shù)請(qǐng)用SQL算出每個(gè)用戶連續(xù)活躍的天數(shù)或者求每個(gè)用戶第N次事件的路徑。這些直接對(duì)應(yīng)產(chǎn)品的活躍分析、漏斗分析功能。ClickHouse是神策分析引擎的一個(gè)重要組成部分筆試會(huì)考它的特點(diǎn)列式存儲(chǔ)、向量化執(zhí)行、稀疏索引、MergeTree表引擎。它會(huì)換個(gè)方式問你對(duì)OLAP和OLTP區(qū)別的理解只要你能答出ClickHouse為什么適合海量數(shù)據(jù)聚合查詢、不適合高頻行級(jí)更新基本就能過關(guān)。我當(dāng)時(shí)在復(fù)習(xí)ClickHouse時(shí)做了個(gè)總結(jié)表把MySQL和ClickHouse的適用場(chǎng)景對(duì)比著看維度MySQLClickHouse存儲(chǔ)結(jié)構(gòu)行式存儲(chǔ)列式存儲(chǔ)適合場(chǎng)景事務(wù)處理OLTP數(shù)據(jù)分析OLAP寫入方式隨機(jī)更新批量追加查詢特點(diǎn)點(diǎn)查頻繁寬表聚合掃描索引方式B Tree稀疏主鍵索引把這張表理解透相關(guān)選擇題基本十拿九穩(wěn)。4. 場(chǎng)景設(shè)計(jì)題神策風(fēng)格的必考題4.1 埋點(diǎn)數(shù)據(jù)采集鏈路設(shè)計(jì)簡答題里出現(xiàn)描述一條完整的埋點(diǎn)數(shù)據(jù)采集鏈路并說明各環(huán)節(jié)需要注意的問題的概率非常高因?yàn)檫@是神策的看家本事。我當(dāng)時(shí)看到這題的時(shí)候心里大概就清楚了這不是考我背文檔而是想看我有沒有全局視野。一條完整鏈路長這樣客戶端SDK采集用戶行為事件先做本地緩存再批量上報(bào)到服務(wù)端網(wǎng)關(guān)服務(wù)端做參數(shù)校驗(yàn)、清洗和格式統(tǒng)一把事件數(shù)據(jù)寫入Kafka下游Flink消費(fèi)Kafka做實(shí)時(shí)維表關(guān)聯(lián)、Session識(shí)別、異常數(shù)據(jù)過濾最后寫入ClickHouse供神策分析做實(shí)時(shí)查詢。答這題的關(guān)鍵不是列步驟而是體現(xiàn)你對(duì)每個(gè)環(huán)節(jié)隱患的思考。比如客戶端數(shù)據(jù)上報(bào)失敗要怎么重試、服務(wù)端如何防止SDK偽造數(shù)據(jù)、Kafka消息重復(fù)消費(fèi)怎么保證最終一致性、Flink作業(yè)反壓怎么處理、ClickHouse寫入抖動(dòng)會(huì)對(duì)查詢?cè)斐墒裁从绊?。你每多一個(gè)這樣的視角分?jǐn)?shù)就上一個(gè)臺(tái)階。我當(dāng)時(shí)還主動(dòng)提了冪等性問題事件數(shù)據(jù)是append-only的天然適合用事件ID用戶ID時(shí)間戳做去重鍵下游即使重復(fù)消費(fèi)也不會(huì)產(chǎn)生臟數(shù)據(jù)。這種細(xì)節(jié)是面試官想看到的。4.2 事件分析場(chǎng)景的存儲(chǔ)與查詢?cè)O(shè)計(jì)另一類簡答題方向是給一個(gè)分析場(chǎng)景讓你設(shè)計(jì)存儲(chǔ)方案和查詢方案。比如找出近30天內(nèi)完成過注冊(cè)且之后7天內(nèi)下過單的用戶人數(shù)你會(huì)怎么設(shè)計(jì)存儲(chǔ)和查詢。這類題最重要的不是一上來就寫方案而是先拆解需求用戶屬性是維度數(shù)據(jù)用戶行為是事實(shí)數(shù)據(jù)注冊(cè)和下單是兩個(gè)事件類型。早期我容易犯的錯(cuò)是直接用一張大寬表接所有需求結(jié)果查詢性能一塌糊涂擴(kuò)展性也差。合理的思路是用戶維度表存注冊(cè)時(shí)間等靜態(tài)屬性事件表存行為流水兩張表通過用戶ID關(guān)聯(lián)。實(shí)時(shí)查詢用ClickHouse的AggregatingMergeTree做預(yù)聚合或者用物化視圖維護(hù)每日活躍指標(biāo)。離線分析則走Hive或Spark。如果你還知道用位圖Bitmap去做留存和漏斗計(jì)算那就屬于加分項(xiàng)了?；卮疬@類題時(shí)一定要把為什么講清楚。別只說我用Kafka做緩沖要說因?yàn)槁顸c(diǎn)上報(bào)存在峰值流量用Kafka削峰填谷防止ClickHouse寫入過載這種思路會(huì)在閱卷時(shí)拉開差距。5. 容易丟分的細(xì)節(jié)與備考避坑5.1 筆試現(xiàn)場(chǎng)環(huán)境與在線IDE的坑第二次提醒一下環(huán)境問題因?yàn)樗娴氖菬o差別丟分點(diǎn)。在線筆試不是本地IDE系統(tǒng)可能不支持某些快捷操作代碼自動(dòng)補(bǔ)全也弱很多。我第一場(chǎng)筆試時(shí)用本地IDE寫完后把代碼從聊天窗口粘過去結(jié)果縮進(jìn)變成了全角空格編譯直接報(bào)錯(cuò)浪費(fèi)了5分鐘。建議考前就去在線評(píng)測(cè)平臺(tái)熟悉一下界面至少練習(xí)一次完整流程讀題、寫代碼、提交、看運(yùn)行結(jié)果。考試時(shí)如果發(fā)現(xiàn)代碼跑不通先看是不是編碼格式或類名public class Main的問題在線筆試通常要求主類名固定為Main這個(gè)細(xì)節(jié)每年能卡掉不少人。攝像頭和切屏檢測(cè)這塊老實(shí)說不要有僥幸心理。筆試期間后臺(tái)會(huì)監(jiān)測(cè)切屏次數(shù)切屏超過一定次數(shù)可能直接判作弊。我建議把手機(jī)放遠(yuǎn)點(diǎn)電腦上只留一個(gè)瀏覽器窗口加一個(gè)本地編輯器其他全部退出登錄。5.2 選擇題里的概念陷阱神策選擇題很愛考看似對(duì)了但表述差一點(diǎn)的概念。舉幾個(gè)我印象深刻的例子Kafka的消費(fèi)者組可以同時(shí)訂閱多個(gè)Topic這個(gè)選項(xiàng)是對(duì)的但一個(gè)分區(qū)可以被同一消費(fèi)組內(nèi)的多個(gè)消費(fèi)者同時(shí)消費(fèi)就是錯(cuò)的。Spring AOP是基于動(dòng)態(tài)代理實(shí)現(xiàn)的是對(duì)的但Spring Bean的默認(rèn)作用域是Prototype是錯(cuò)的默認(rèn)是Singleton。ClickHouse適合高并發(fā)點(diǎn)查這個(gè)表述是錯(cuò)誤的它更適合批量聚合分析。做這類題的感覺就像在打假每個(gè)選項(xiàng)都似曾相識(shí)但只有完全精確的那個(gè)才是答案。備考時(shí)不要只看面經(jīng)結(jié)論而是要把每個(gè)結(jié)論背后的因果鏈理清楚才能在干擾項(xiàng)里活下來。5.3 準(zhǔn)備筆試的同時(shí)別忽略簡歷和后續(xù)面試筆試只是秋招的第一道關(guān)神策的流程一般是筆試通過之后會(huì)經(jīng)歷一輪技術(shù)初試、一輪技術(shù)復(fù)試、一輪HR面部分崗位可能還有一輪組長面。筆試答得好只是給你拿到面試入場(chǎng)券。筆試結(jié)束后建議趁熱打鐵把簡答題里沒答好的內(nèi)容整理成筆記因?yàn)槊嬖嚬俸芟矚g拿筆試題延伸追問。我當(dāng)時(shí)筆試?yán)镉幸坏繤link Watermark相關(guān)的題答得一般面經(jīng)復(fù)盤后自己啃了一遍源碼機(jī)制結(jié)果技術(shù)面里真被問到因?yàn)闇?zhǔn)備過所以回答得比較順。簡歷上建議突出和神策業(yè)務(wù)相關(guān)的項(xiàng)目經(jīng)驗(yàn)尤其是埋點(diǎn)采集、數(shù)據(jù)管道、OLAP查詢優(yōu)化這類。沒有直接項(xiàng)目經(jīng)驗(yàn)的就把課程設(shè)計(jì)或者實(shí)習(xí)項(xiàng)目往這個(gè)方向包裝并準(zhǔn)備好為什么用這個(gè)方案數(shù)據(jù)量多大性能瓶頸在哪這些細(xì)節(jié)。神策的面試官普遍比較務(wù)實(shí)問到項(xiàng)目細(xì)節(jié)時(shí)會(huì)一直追問到你說這里當(dāng)時(shí)沒考慮那么深為止準(zhǔn)備得越細(xì)越有優(yōu)勢(shì)。6. 一些建議校招筆試備考的整體節(jié)奏最后聊一下我個(gè)人的備考節(jié)奏不一定適合所有人但幾個(gè)朋友照著調(diào)整后反饋都不錯(cuò)。筆試前兩周是黃金沖刺期。第一周用來掃盲把Java集合、并發(fā)、JVM、MySQL、Kafka、Flink這些主線知識(shí)點(diǎn)過一遍重點(diǎn)看自己最薄弱的兩塊。第二周進(jìn)入刷題狀態(tài)每天保持2到3道力扣中等題的手感再做一套模擬筆試題練節(jié)奏。選擇題部分不用專門刷很多面經(jīng)和?？蜕系恼骖}整理已經(jīng)夠用關(guān)鍵是確保每個(gè)選項(xiàng)的對(duì)錯(cuò)都能說出理由。沖刺期還有一個(gè)容易被忽略的點(diǎn)練輸出。簡答題不是你心里明白就能拿分的要能在一個(gè)小時(shí)內(nèi)寫清楚方案結(jié)構(gòu)。我當(dāng)時(shí)的習(xí)慣是拿到一個(gè)場(chǎng)景題先寫一句話需求定義再畫系統(tǒng)鏈路最后分模塊寫設(shè)計(jì)要點(diǎn)。這種總—分—分的結(jié)構(gòu)閱卷人看起來不累你也不容易漏點(diǎn)。筆試當(dāng)天建議提前20分鐘進(jìn)入房間準(zhǔn)備好身份證、空白草稿紙、筆調(diào)試好攝像頭和麥克風(fēng)。答題順序上我是選擇題—簡答題—編程題但也有人習(xí)慣先做編程題保底。我個(gè)人不推薦把編程題放最后因?yàn)榇竽X在最疲勞的時(shí)候?qū)懘a是最容易出低級(jí)錯(cuò)誤的時(shí)候。2023年這批筆試過去之后我和幾個(gè)上岸的同學(xué)復(fù)盤過大家的共識(shí)是神策的筆試不是靠臨時(shí)抱佛腳能過的它考察的是你對(duì)數(shù)據(jù)類系統(tǒng)知識(shí)體系的完整度。你可以不精通每一項(xiàng)但不能有明顯的知識(shí)死角。把上文里的三個(gè)板塊——算法手感、技術(shù)基礎(chǔ)、場(chǎng)景設(shè)計(jì)思路——按部就班準(zhǔn)備好筆試這一關(guān)是完全可以穩(wěn)穩(wěn)拿下的。