每年這個時候都是秋招筆試最密集的階段。作為一個連續(xù)參加過兩屆大廠數(shù)據(jù)科學(xué)崗筆試、也陪身邊不少學(xué)弟學(xué)妹復(fù)盤過題目的老數(shù)據(jù)人我對這套騰訊音樂秋招數(shù)據(jù)科學(xué)崗第二批筆試題印象挺深。它的風(fēng)格很有代表性不搞偏題怪題但非?？简?zāi)惆呀y(tǒng)計、機器學(xué)習(xí)、SQL、業(yè)務(wù)分析串起來的能力尤其是最后幾道業(yè)務(wù)場景題直接對標(biāo)真實工作中“從數(shù)據(jù)到?jīng)Q策”的鏈路。這篇文章我會完整復(fù)盤這套筆試題的核心內(nèi)容包括我自己的解題思路、踩過的坑以及從面試官角度反推回來的評分點。無論你是正在準(zhǔn)備數(shù)據(jù)科學(xué)崗秋招還是想系統(tǒng)補一下數(shù)據(jù)科學(xué)職業(yè)核心能力這篇都能給你一個比較落地的參考框架。文章比較長建議先收藏再慢慢看尤其是準(zhǔn)備投騰訊、騰訊音樂的這套題的思路復(fù)用價值很高。1. 筆試整體復(fù)盤與題型分布1.1 這次筆試考了什么四類題型背后的真實篩選邏輯第二批筆試整體分為四個部分統(tǒng)計概率與機器學(xué)習(xí)基礎(chǔ)、SQL與數(shù)據(jù)處理、業(yè)務(wù)場景案例分析、編程題。分值占比大概是統(tǒng)計概率和SQL各占30%業(yè)務(wù)場景占25%編程題占15%左右。整體時間很緊張滿分100分的話我體感能穩(wěn)定做完并檢查一遍的人不多多數(shù)人會在業(yè)務(wù)場景題上耗費大量時間。先說題型分布背后的篩選邏輯。四分法看起來常規(guī)其實是在測三個維度基礎(chǔ)理論的扎實程度、工程落地的熟練度、業(yè)務(wù)思維的敏感度。統(tǒng)計概率和機器學(xué)習(xí)基礎(chǔ)考的是你有沒有建立完整的知識框架——這決定了入職后能不能接住分析類需求SQL和編程題考的是你有沒有動手能力——數(shù)據(jù)科學(xué)不是純算法崗天天要跟數(shù)倉打交道業(yè)務(wù)場景題則是區(qū)分度最大的部分它決定了你是“會做分析的人”還是“能解決問題的人”。一個值得注意的細(xì)節(jié)是這套題的統(tǒng)計題幾乎全部帶業(yè)務(wù)背景不是干巴巴地讓算概率而是把概率放進用戶行為場景里比如“用戶連續(xù)打開App天數(shù)”“推薦流點擊概率異常波動”。這一點比較像騰訊系筆試的風(fēng)格題目本身不難但審題不仔細(xì)容易把簡單問題復(fù)雜化。1.2 時間分配策略先保大分再啃硬骨頭75分鐘做大概12道題不完全統(tǒng)計可能有微調(diào)其中選擇題8道左右問答題和編程題4道左右。我身邊做完的同學(xué)反饋高度一致選擇題看似簡單但坑很多單題耗時遠(yuǎn)超預(yù)期編程題反而還好因為思路相對固定。我的建議是先快速掃一遍所有題目在卷面上標(biāo)記出“確定能做對”和“需要思考”兩類題。統(tǒng)計概率類選擇題如果30秒內(nèi)沒有明確思路先跳不要戀戰(zhàn)。業(yè)務(wù)場景題先讀最后一問因為騰訊系的場景題往往最后一問才是核心訴求前面都是鋪墊信息帶著最終問題回頭看材料效率高很多。編程題建議放在業(yè)務(wù)題前面做因為編程題答案是非對即錯的做出來就是滿分而業(yè)務(wù)題寫得再好也可能因為踩不到得分點給個中等分。兩權(quán)相害取其輕先把確定性分?jǐn)?shù)拿到手。2. 統(tǒng)計概率與機器學(xué)習(xí)基礎(chǔ)題詳解2.1 經(jīng)典概率題為什么“貝葉斯更新”在業(yè)務(wù)里無處不在我印象最深的概率題是這樣的某推薦策略迭代后點擊率預(yù)估從2%提升到3%。假設(shè)單次曝光點擊與否服從伯努利分布現(xiàn)在要給這個策略算一個“95%置信水平下是否存在顯著提升”的結(jié)論。選項里給了幾個不同的檢驗方法描述讓你選錯誤的那個。這道題表面是假設(shè)檢驗但選項里埋了貝葉斯方法的干擾項。很多人在這里會猶豫到底該用頻率學(xué)派還是貝葉斯學(xué)派。我的建議是遇到這種描述性選擇題優(yōu)先把每個選項里的“術(shù)語定義”和“適用條件”拆開看。比如選項中說“貝葉斯方法不需要先驗”這明顯是錯的然后選項中說“兩組樣本量不同會影響t檢驗結(jié)果”這就是對的再比如“置信區(qū)間包含0代表無顯著差異”這對頻率學(xué)派來說是對的。用排除法選出“錯誤的描述”比直接判斷“哪個正確”容易得多。這題背后其實在考察你對“比率類指標(biāo)顯著性檢驗”的掌握程度。業(yè)務(wù)里最常見的就是對比實驗——新版策略和舊版策略相比點擊率、轉(zhuǎn)化率有沒有顯著提升。你可能手里只有點擊率和樣本量兩組數(shù)這時候兩個比例的z檢驗是標(biāo)配。如果你了解貝葉斯更新還能用Beta-Binomial共軛結(jié)構(gòu)去做序貫決策這在騰訊系的業(yè)務(wù)題里很吃香因為音樂推薦場景中用戶行為是流式產(chǎn)生的實時更新后驗分布是個加分項。實操中可以用一個簡單公式快速估算某個策略提升是否顯著當(dāng)兩個樣本量都在幾千以上時如果 |p1 - p2| 1.96 * sqrt(p(1-p) * (1/n1 1/n2))其中p為合并后整體轉(zhuǎn)化率則可以說在95%置信水平下有顯著差異。這道題我當(dāng)時直接用這個邏輯套心里踏實很多。如果實在記不住公式也可以用Python快速跑一下以下為答題時的速算腳本import numpy as np from statsmodels.stats.proportion import proportions_ztest # 對照組10000次曝光200次點擊實驗組10000次曝光300次點擊 n1, x1 10000, 200 n2, x2 10000, 300 p1, p2 x1 / n1, x2 / n2 # 合并比例 p (x1 x2) / (n1 n2) se np.sqrt(p * (1 - p) * (1 / n1 1 / n2)) z (p2 - p1) / se print(fz值約等于{z:.2f}) # 輸出大于1.96說明有顯著差異這道題給我的啟發(fā)是筆試不是考你會不會推公式而是考你知不知道“什么場景用什么方法”。數(shù)據(jù)科學(xué)職業(yè)核心能力里最重要的一條就是方法工具箱的匹配速度。你不能看到“置信區(qū)間”就只想到t分布看到“點擊率”就只想到漏斗分析得快速在業(yè)務(wù)描述里捕捉到“兩個比例對比”這個本質(zhì)。2.2 機器學(xué)習(xí)基礎(chǔ)題從“調(diào)包”到“知道為什么調(diào)包”機器學(xué)習(xí)部分的題目比較常規(guī)但有一道題很能說明問題——它給了一個用戶流失預(yù)測的二分類場景正負(fù)樣本比例大概是1:99問以下哪個方案不能有效緩解類別不平衡問題。選項有對多數(shù)類做下采樣、對少數(shù)類做SMOTE過采樣、使用F1作為評估指標(biāo)、直接使用準(zhǔn)確率評估模型。如果用“死記硬背”的思路很多人會選“降低分類閾值”但這個選項根本沒出現(xiàn)。實際上這道題最迷惑的地方在于“使用F1作為評估指標(biāo)”這個選項從模型訓(xùn)練角度F1作為評估指標(biāo)確實能幫助你選擇更好的模型但它本身不會改變正負(fù)樣本的分布也不能“緩解”類別不平衡本身它只是讓評估更合理。而“直接使用準(zhǔn)確率”在正負(fù)樣本1:99的背景下會讓模型傾向于把所有樣本都預(yù)測為負(fù)類準(zhǔn)確率高達(dá)99%卻沒實際意義這顯然是“不能緩解”的反例。所以如果題目問的是“哪個不能”反而要選那個看起來“很合理”的F1選項——這類題的陷阱往往藏在選項的措辭里。這道題我見過太多次了幾乎是各家大廠數(shù)據(jù)崗的標(biāo)配考法。它實際上在考察你對“類別不平衡處理手段”的完整理解數(shù)據(jù)層面采樣、增廣、算法層面代價敏感學(xué)習(xí)、集成學(xué)習(xí)、評價層面PR曲線、F1。在騰訊音樂的場景里你可能會做付費預(yù)測、流失預(yù)警、歌曲熱度預(yù)測都會遇到正負(fù)樣本極度不均衡的問題。比如平臺里付費用戶占比可能不到10%你想用模型找“高潛付費用戶”如果直接用準(zhǔn)確率評估模型就會偷懶地把所有人判為非付費這是實戰(zhàn)中一定會踩的坑。還有一道關(guān)于XGBoost和邏輯回歸對比的題問的是在特征相關(guān)性較高的情況下哪個更穩(wěn)定。正確答案是邏輯回歸更穩(wěn)定因為樹模型在做特征分裂時如果兩個特征高度相關(guān)會出現(xiàn)“選擇哪個特征分裂都能得到相似增益”的情況導(dǎo)致單棵樹的特征重要性被隨機地分到兩個特征上。雖然沒有破壞整體預(yù)測能力但如果你是通過樹模型做特征篩選可能誤以為某幾個特征沒用這會影響后續(xù)的特征工程。這道題考察的是模型的機制理解不是簡單背結(jié)論。真正的數(shù)據(jù)科學(xué)工作流應(yīng)該包含“模型選型→特征篩選→業(yè)務(wù)解釋”的閉環(huán)而這對騰訊音樂這種看重推薦和增長的業(yè)務(wù)來說尤其重要。我當(dāng)時在答這道題時還引申了一個點邏輯回歸雖然穩(wěn)定但在特征非線性關(guān)系復(fù)雜時表達(dá)能力有限XGBoost雖然對特征相關(guān)性敏感但配合SHAP值能挖掘很多交互效應(yīng)。筆試答題如果只寫“XX更穩(wěn)定”不會得高分一定要寫清楚“在什么條件下更穩(wěn)定、為什么、對業(yè)務(wù)有什么影響”這才是數(shù)據(jù)科學(xué)崗和算法工程師崗的區(qū)別。2.3 關(guān)于AUC、召回率和置信區(qū)間的關(guān)系題AUC相關(guān)題目也出現(xiàn)了而且結(jié)合了一個很具體的場景在版權(quán)音樂推薦中模型A的AUC略高于模型B但A在頭部歌曲的召回率遠(yuǎn)低于B。題目問你該怎么選。這里考察的核心其實是你是否理解“單點指標(biāo)不能代表全部”——AUC是全局排序質(zhì)量的度量它對中間閾值區(qū)域的區(qū)分能力比較敏感并不會直接告訴你“頭部用戶最關(guān)心的那幾十首歌推得準(zhǔn)不準(zhǔn)”。如果你只盯AUC可能模型全局效果好但核心用戶刷了兩屏都沒聽到喜歡的新歌很快就會流失。這類題沒有絕對標(biāo)準(zhǔn)的答案但一般會被認(rèn)可的思路是把“AUC”和“頭部召回率”分開看AUC用來衡量整體排序能力頭部召回率衡量在高價值內(nèi)容上的定向能力二者并不沖突。如果你要選的模型是為了提升整體時長選A如果是為了優(yōu)化核心付費用戶的新歌發(fā)現(xiàn)體驗選B。更聰明的答法是先分析業(yè)務(wù)指標(biāo)落在哪個漏斗層級再決定模型選型。比如頭部歌曲召回低就要看是不是數(shù)據(jù)不平衡導(dǎo)致頭部歌曲曝光太少或者訓(xùn)練樣本中頭尾權(quán)重沒調(diào)好甚至可以考慮在損失函數(shù)里加上頭部樣本的權(quán)重。能寫出這個層面的思考基本就能在這道題上拿高分。3. SQL與數(shù)據(jù)處理題筆試?yán)锏摹皵?shù)據(jù)工程底子”3.1 連續(xù)登錄天數(shù)與留存率窗口函數(shù)的三種寫法對比SQL題里有一道經(jīng)典的連續(xù)登錄天數(shù)計算。表結(jié)構(gòu)是user_id, login_date要求算出每個用戶2023年以來的最大連續(xù)登錄天數(shù)并按連續(xù)天數(shù)降序輸出前10個用戶。這道題不算難考的是窗口函數(shù)ROW_NUMBER()和“日期減去行號”的技巧。我當(dāng)時用的解法是WITH t1 AS ( SELECT user_id, login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date) AS rn FROM user_login WHERE login_date BETWEEN 2023-01-01 AND 2023-12-31 ), t2 AS ( SELECT user_id, DATE_SUB(login_date, INTERVAL rn DAY) AS group_date FROM t1 ) SELECT user_id, MAX(continuous_days) AS max_continuous_days FROM ( SELECT user_id, COUNT(*) AS continuous_days, group_date FROM t2 GROUP BY user_id, group_date ) t3 GROUP BY user_id ORDER BY max_continuous_days DESC LIMIT 10;這個解法的核心邏輯是登錄日期和行號同時減去某個基準(zhǔn)如果用戶是連續(xù)登錄的減出來的“組標(biāo)識”相同連續(xù)斷了組標(biāo)識就變了。第一次接觸這個思路可能覺得繞但多寫幾次會形成肌肉記憶幾乎90%的“連續(xù)”類問題都能用這個思路解。做題時要注意一個問題login_date里有沒有重復(fù)記錄如果同一天有多次登錄需要先去重。我那次答題時忽略了這一點導(dǎo)致抽樣自測時連續(xù)天數(shù)比預(yù)期多了一天。題目雖然沒說有重復(fù)但明細(xì)表通常會有重復(fù)訪問穩(wěn)妥起見應(yīng)該在t1里先SELECT DISTINCT user_id, login_date。這個細(xì)節(jié)不扣分則已一扣就是整題0分因為后續(xù)所有分組都會被帶偏。還有一種更進階的解法用LAG()判斷前后日期差值是否為1然后打標(biāo)記計算連續(xù)組。這個思路更適合處理“間隔小于等于N天也算連續(xù)”的擴展需求。筆試時我建議用第一種解法因為它邏輯最直觀、不容易寫錯面試被追問擴展需求時再把第二種拋出來會顯得你有縱深。3.2 留存率計算日期表關(guān)聯(lián)的九九歸一法另一道SQL題是算7日留存和30日留存。給定user_id, register_date, login_date要求輸出每日新增用戶的次日留存率、7日留存率、30日留存率。這題常見做法是把注冊表作為主表左關(guān)聯(lián)登錄表再按注冊日期聚合。我當(dāng)時寫的是SELECT r.register_date, COUNT(DISTINCT r.user_id) AS new_users, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 1 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d1_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 7 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d7_retention, COUNT(DISTINCT IF(l.login_date DATE_ADD(r.register_date, INTERVAL 30 DAY), l.user_id, NULL)) / COUNT(DISTINCT r.user_id) AS d30_retention FROM new_user_registration r LEFT JOIN user_login l ON r.user_id l.user_id AND l.login_date IN ( DATE_ADD(r.register_date, INTERVAL 1 DAY), DATE_ADD(r.register_date, INTERVAL 7 DAY), DATE_ADD(r.register_date, INTERVAL 30 DAY) ) GROUP BY r.register_date;這里有個很重要的點LEFT JOIN的關(guān)聯(lián)條件里同時放“時間窗口”和“用戶ID”能極大減少中間結(jié)果的數(shù)據(jù)量。很多人習(xí)慣先全部join再where篩選這在數(shù)據(jù)量大的時候容易把中間表撐爆筆試雖不考性能但面試官看到你的join條件寫得干凈會加分不少。另一個容易被忽略的點留存率的分子和分母都要加DISTINCT防止用戶在同一天有多條訪問記錄導(dǎo)致重復(fù)計數(shù)。盡管很多公司數(shù)倉里的登錄表做了去重但從嚴(yán)謹(jǐn)角度講DISTINCT是數(shù)據(jù)科學(xué)崗的職業(yè)習(xí)慣。3.3 會話切分用戶行為序列處理的前置技能SQL第三題是算會話數(shù)。給定user_id, event_time, event_name定義同一個用戶相鄰兩條行為事件時間差超過30分鐘則標(biāo)記為一次新會話計算每個用戶一天內(nèi)的會話數(shù)。這個問題的標(biāo)準(zhǔn)解法是用LAG()取上一個事件時間然后比較差值WITH t1 AS ( SELECT user_id, event_time, LAG(event_time) OVER(PARTITION BY user_id ORDER BY event_time) AS prev_time FROM user_events WHERE DATE(event_time) 2023-09-01 ) SELECT user_id, COUNT(*) AS session_count FROM ( SELECT user_id, event_time, SUM( CASE WHEN prev_time IS NULL OR TIMESTAMPDIFF(MINUTE, prev_time, event_time) 30 THEN 1 ELSE 0 END ) OVER(PARTITION BY user_id ORDER BY event_time) AS session_id FROM t1 ) t2 GROUP BY user_id;這道題看似是寫SQL其實在考察你處理“行為序列數(shù)據(jù)”的基本功。真實業(yè)務(wù)中你在做用戶路徑分析、異常行為識別、推薦效果評估時第一步功夫就是把原始埋點切成有意義的會話。還以騰訊音樂為例一個用戶可能早中晚各打開一次App每次包含十幾條操作日志只有正確切分會話才能算出“人均session數(shù)”“單session點贊率”“session內(nèi)跳轉(zhuǎn)路徑”這些高級指標(biāo)。如果這一步就有bug后面所有分析都是謬之千里。我見過很多候選人簡歷上寫著“精通SQL熟悉Hive”但真正寫到這種稍微需要一點的邏輯題就卡殼。本質(zhì)問題是平時只做簡單的SELECT, WHERE, GROUP BY很少接觸窗口函數(shù)。這批筆試題里SQL部分整體難度中等但它會暴露你平時在數(shù)倉里到底干的是“取數(shù)”還是“做分析”。4. 業(yè)務(wù)場景案例分析數(shù)據(jù)科學(xué)工作流的完整閉環(huán)4.1 從點擊歸因到預(yù)算優(yōu)化的閉環(huán)實踐一道完整的SEM場景題這次筆試的業(yè)務(wù)場景題出了一道和廣告相關(guān)的綜合大題背景相當(dāng)貼近真實業(yè)務(wù)某音樂平臺在外部渠道投放廣告包含社交媒體、短視頻、搜索等渠道用戶點擊廣告后可能當(dāng)天就下載App也可能隔幾天才下載?，F(xiàn)在需要做兩件事第一設(shè)計一個歸因模型決定每個渠道應(yīng)該獲得多少下載轉(zhuǎn)化功勞第二基于歸因結(jié)果優(yōu)化各渠道預(yù)算分配使整體獲客成本最低。這就是熱詞里說的“SEM數(shù)據(jù)科學(xué)工作流從點擊歸因到預(yù)算優(yōu)化的閉環(huán)實踐”。一開始看到這道題我愣了一下因為市面上大多數(shù)分析課程只講“歸因”或只講“預(yù)算分配”很少把兩者串起來。但實際業(yè)務(wù)里這確實是一個閉環(huán)歸因看清楚每個渠道貢獻了多少轉(zhuǎn)化是預(yù)算分配把錢花到最有效的渠道的輸入而預(yù)算調(diào)整后反饋回來的新數(shù)據(jù)又會重新影響歸因結(jié)果。如果你只是在筆試?yán)飳憽坝肧hapley值做歸因”或者“用線性規(guī)劃做預(yù)算分配”而不提閉環(huán)帶來的數(shù)據(jù)反饋問題說明你還停留在方法論層面。我當(dāng)時的答題思路是這樣的首先明確歸因目標(biāo)不是“看個熱鬧”而是為了指導(dǎo)預(yù)算調(diào)整所以歸因模型的選擇要考慮可解釋性和穩(wěn)定性。第一梯隊推薦用基于Shapley值的多觸點歸因——在渠道數(shù)少于10個時這個方法很實用它能把“每個渠道在不同組合下的邊際貢獻”平均化得到穩(wěn)定且公平的貢獻度。第二梯隊是可解釋的機器學(xué)習(xí)模型比如帶線性項的LightGBM或邏輯回歸直接把渠道曝光量或點擊量作為特征預(yù)測最終轉(zhuǎn)化概率然后用特征重要性近似歸因。但缺點是樹模型的特征重要性只代表“預(yù)測貢獻”不代表“因果貢獻”容易受到渠道曝光量本身大小的影響。預(yù)算分配部分普通答法是“把錢投給ROI最高的渠道”這個答案只能拿基礎(chǔ)分。更好的答法是引入預(yù)算彈性約束假設(shè)渠道曝光量翻倍時轉(zhuǎn)化率不一定翻倍而是服從一個遞減的邊際曲線然后在這個約束下求最優(yōu)分配。筆試時間有限不需要真正解出數(shù)值重點是寫出約束條件和目標(biāo)函數(shù)。我當(dāng)時給的是類似這樣的思路假設(shè)第i個渠道的獲客量 f_i(x_i)其中x_i為該渠道預(yù)算f_i為單調(diào)遞增且邊際遞減的函數(shù)。我們的目標(biāo)是minimize 總獲客成本 Σ x_i / Σ f_i(x_i) subject to Σ x_i B總預(yù)算固定 x_i ≥ 0同時考慮頻次控制和跨渠道協(xié)同同一用戶可能既看了信息流廣告又點了搜索廣告如果直接按各個渠道獨立優(yōu)化會造成預(yù)算浪費和歸因過度重疊。更扎實的做法是引入“轉(zhuǎn)化路徑”級別的建模把用戶看到廣告的序列當(dāng)成一個整體用馬爾可夫鏈三明治法求每個渠道在整條路徑中的平均移除貢獻。馬爾可夫鏈的想法很直接把用戶轉(zhuǎn)化路徑看成狀態(tài)轉(zhuǎn)移移除某個渠道后如果整體轉(zhuǎn)化率明顯下降說明該渠道很重要把所有渠道的“影響值”歸一化就是每個渠道的貢獻權(quán)重。這道題寫的篇幅最長也是我認(rèn)為整套卷子最有區(qū)分度的地方。能獨立寫出“歸因-預(yù)算-反饋”鏈條的人哪怕細(xì)節(jié)不完美面試官也大概率愿意給高分因為這說明你做過真實的增長分析而不是只會套模板。4.2 指標(biāo)異動排查DAU下降了你第一步做什么業(yè)務(wù)場景題還有一道很經(jīng)典的某音樂App的日活用戶數(shù)連續(xù)三天下降2%但同期新用戶數(shù)穩(wěn)定問你怎么排查原因。這道題沒有代碼要求純粹考察分析框架也是我見過最多次的面試題變種。答這種題一定要有結(jié)構(gòu)和優(yōu)先級不能胡子眉毛一把抓。我當(dāng)時按“拆分母→拆維度→驗因果”三步走寫的。第一步確認(rèn)DAU的定義有沒有變化是不是修正了渠道歸因?qū)е履承┰O(shè)備不再計數(shù)是不是改版后埋點上報策略變了導(dǎo)致部分老版本客戶端數(shù)據(jù)缺失這聽起來很基礎(chǔ)但真實情況下很多指標(biāo)異動到最后查出來都是口徑變化而不是業(yè)務(wù)惡化。第二步DAU 新增用戶 老用戶回流 存量用戶活躍。新增用戶穩(wěn)定那重點看老用戶回流和存量活躍。需要按平臺、版本、地區(qū)、渠道拆解定位下降集中在前端還是后端。比如是否只有iOS端下降是否只有某個老版本下降是否只在某幾個省份下降這里建議再拆一層“活躍質(zhì)量”比如人均使用時長有沒有同步下降如果時長沒降只是人數(shù)降可能是部分低活躍用戶被淘汰會影響不太大如果時長和人數(shù)一起降那就是核心用戶體驗出了問題。第三步因果驗證。羅列可能的假設(shè)比如七夕等活動結(jié)束導(dǎo)致回落、熱門歌曲獨家版權(quán)到期、競品大促分流、推送策略限制等一個個用數(shù)據(jù)驗證。比如若懷疑某頭部歌曲版權(quán)到期就查這首歌的播放量趨勢和貢獻DAU若懷疑推送策略調(diào)整就查推送到達(dá)率和點擊率變化。最后給出結(jié)論和監(jiān)控建議建立核心指標(biāo)的異常預(yù)警規(guī)則類似“DAU連續(xù)N天下降超過X%且偏離歷史波動范圍”自動觸發(fā)日報。這道題其實在考察數(shù)據(jù)科學(xué)職業(yè)核心能力里的“業(yè)務(wù)定義能力”和“假設(shè)驅(qū)動思維”。很多新手容易犯的錯誤是一上來就做復(fù)雜的用戶分層、機器學(xué)習(xí)預(yù)測忘了先看分母和口徑。真正的數(shù)據(jù)科學(xué)工作流應(yīng)該永遠(yuǎn)從業(yè)務(wù)問題出發(fā)而不是從模型出發(fā)。4.3 推薦系統(tǒng)面試題離線評估和線上指標(biāo)不一致怎么辦還有一個問答題稍微偏推薦方向離線AUC漲了線上點擊率卻跌了可能是什么原因這題也不屬于純筆試中的“客觀題”范疇但基本每年都會出現(xiàn)。我歸納了四個最可能的方向筆試時可以從這四個角度展開每個方向補充一個例子基本就能拿滿。第一離線在線特征不一致。模型上線后如果特征拼接鏈路出錯比如離線用了某個昨日特征線上卻用了實時默認(rèn)值模型效果一定崩。這類問題在推薦、廣告系統(tǒng)里最隱蔽排查也需要核對特征日志和上線配置。第二樣本選擇偏差。離線訓(xùn)練時用的是“有曝光才有反饋”的樣本但線上模型會給新內(nèi)容打分會帶來“新的曝光機會”這些新曝光的行為分布和訓(xùn)練分布不一樣自然會導(dǎo)致離線/在線差異。第三評估指標(biāo)本身的問題。離線AUC衡量的是排序正確率線上點擊率是偏絕對值的指標(biāo)兩者并不線性等價。一個模型可能把排序整體做得更好了但因為推薦列表頭部的舊爆款被換掉導(dǎo)致用戶第一屏的點開意愿反而下降這在短時數(shù)據(jù)上可能表現(xiàn)為點擊率下跌。第四時間窗口的不一致。離線評估如果用的是和線上不一致的樣本時間窗口比如離線用了過去30天訓(xùn)練并驗證模型線上策略只上線了3天新模型還沒來得及適配近期熱度和用戶興趣的短期變化效果容易出現(xiàn)波動。這題的答題思路能直接反映你有沒有真正做過推薦相關(guān)項目。如果你只在Kaggle上跑過模型而沒有接觸過線上系統(tǒng)大概率只答得出“數(shù)據(jù)泄露”“過擬合”這類常規(guī)答案很難答到“特征鏈路一致性和評估指標(biāo)錯位”這種層面。5. 編程題思路與筆試準(zhǔn)備建議5.1 編程題考察點不是算法競賽是工程思維編程題一共兩題第一題是動態(tài)規(guī)劃給定一個數(shù)組求連續(xù)子數(shù)組最大和。經(jīng)典到不能再經(jīng)典但限制條件不能使用額外數(shù)組只允許O(1)空間。這道題應(yīng)該所有人都會做核心就是Kadane算法def max_subarray_sum(arr): if not arr: return 0 current_max global_max arr[0] for num in arr[1:]: current_max max(num, current_max num) global_max max(global_max, current_max) return global_max這題考察的不是算法技巧而是你在緊張狀態(tài)下還能不能寫出無bug的邊界條件。比如空數(shù)組、全負(fù)數(shù)數(shù)組這些邊界值很多人一緊張就忽略。遞推公式是dp[i] max(dp[i-1] arr[i], arr[i])但更關(guān)鍵的是理解為什么空間可以壓縮到O(1)——因為當(dāng)前狀態(tài)只依賴前一個狀態(tài)不需要記錄整個dp數(shù)組。第二題是基于“好友關(guān)注關(guān)系”的推薦題給一組關(guān)注關(guān)系[follower_id, followee_id]找出“可能認(rèn)識的人”——即你和某個人有兩個以上共同關(guān)注的人但你們尚未互相關(guān)注按共同關(guān)注人數(shù)降序輸出。這個題我在筆試時用的解法是構(gòu)造“用戶→關(guān)注列表”映射然后暴力兩兩比較因為筆試數(shù)據(jù)量不會太大。更高效的方法是用倒排索引先建“被關(guān)注者→關(guān)注者列表”的倒排表然后遍歷每個用戶的關(guān)注列表兩兩組合計數(shù)。這個思路和計算共同好友、商品協(xié)同過濾、歌曲協(xié)同過濾是同一個套路。def recommend_friends(follow_relations): follow_map {} for follower, followee in follow_relations: follow_map.setdefault(follower, set()).add(followee) follow_map.setdefault(followee, set()) suggestions {} for user in follow_map: followed follow_map[user] for followee in followed: for candidate in follow_map.get(followee, set()): if candidate ! user and candidate not in followed: common len(followed follow_map[candidate]) if common 2: key (user, candidate) suggestions[key] common result sorted(suggestions.items(), keylambda x: x[1], reverseTrue) return [(a, b, cnt) for (a, b), cnt in result]這道題的本質(zhì)和音樂平臺的“相似用戶推薦”“歌單協(xié)同過濾”非常接近。如果你在簡歷里寫過推薦相關(guān)的項目面試官看向你的眼神都會不一樣因為這表明你具備把推薦算法落到工程代碼里的能力而不只是會用現(xiàn)成的庫。5.2 備考建議圍繞數(shù)據(jù)科學(xué)職業(yè)核心能力做刻意練習(xí)我整理了大概三周的備考計劃基于騰訊音樂這批真題做專項訓(xùn)練。第一周主攻統(tǒng)計概率和機器學(xué)習(xí)基礎(chǔ)重點是二項分布、正態(tài)分布、假設(shè)檢驗、貝葉斯公式、常見模型對比LR、樹模型、KNN、樸素貝葉斯。資料上推薦《統(tǒng)計學(xué)習(xí)方法》前幾章加StatQuest的視頻兩者配合效率高。第二周集中刷SQL窗口函數(shù)題每天至少5道覆蓋連續(xù)性問題、TopN問題、留存率、會話切分、行列互轉(zhuǎn)直接在LeetCode數(shù)據(jù)庫題庫里找中等難度的題。第三周做業(yè)務(wù)場景模擬從“某個指標(biāo)下降”開始練習(xí)排查框架再自己找?guī)讉€公開數(shù)據(jù)集做簡單的歸因分析或預(yù)算分配建模。對于“數(shù)據(jù)科學(xué)與大數(shù)據(jù)技術(shù)就業(yè)方向”這個熱詞我也多說一句這個方向的畢業(yè)生如果目標(biāo)是大廠數(shù)據(jù)科學(xué)崗最需要補的不是建模能力而是SQL和業(yè)務(wù)思維的銜接。算法崗位門檻高、需求量少、競爭激烈數(shù)據(jù)科學(xué)崗位更看重你是否有能力把業(yè)務(wù)問題轉(zhuǎn)化成數(shù)據(jù)問題再把數(shù)據(jù)結(jié)論翻譯回業(yè)務(wù)語言。騰訊音樂這套筆試的題型分布其實已經(jīng)暗示了它們更看重的還是“扎實基本功清晰業(yè)務(wù)邏輯”。一個比較實用的備考技巧是每次做完一套真題都把錯題按“知識盲區(qū)”“審題失誤”“速度不夠”三類歸類而不是籠統(tǒng)改成“學(xué)習(xí)不夠”。知識盲區(qū)需要系統(tǒng)補課審題失誤需要平時練題時強迫自己圈出關(guān)鍵詞速度不夠則需要專項限時刷題。這套方法堅持兩周提分效果明顯。筆試前也可以多去了解目標(biāo)公司的業(yè)務(wù)形態(tài)。比如投騰訊音樂就應(yīng)該提前了解它的產(chǎn)品矩陣、核心指標(biāo)月活、日活、付費率、播放時長等、主要推薦場景每日推薦、歌單推薦、搜索、直播以及會員轉(zhuǎn)化路徑。業(yè)務(wù)場景題給你的材料可能沒有具體數(shù)字但如果你對業(yè)務(wù)足夠熟就能答出更有針對性的建議而不是泛泛而談“提高用戶粘性”。6. 這批筆試題的隱藏考點從做題到做事的思維升級6.1 為什么說“歸因-預(yù)算-反饋”是整場筆試的分水嶺前面說了很多具體題目現(xiàn)在想脫離題目本身聊聊這套筆試隱含的“職級思維”。騰訊音樂這套題里SQL題和概率題解決的是“能不能干活”的問題而場景題中的歸因預(yù)算題解決的是“能不能扛事”的問題。一個只會寫SQL、調(diào)參、跑模型的人和一個能獨立負(fù)責(zé)業(yè)務(wù)指標(biāo)、給出決策建議的人在職級上可能就是P5和P7的差別。歸因預(yù)算這道題之所以是分水嶺是因為它同時考察了你三種能力歸因模型選型與計算的落地能力、預(yù)算優(yōu)化問題中約束條件的拆解能力、以及“數(shù)據(jù)-決策-數(shù)據(jù)”閉環(huán)的復(fù)盤意識。如果你能在這個題里主動提到“歸因結(jié)果影響預(yù)算分配預(yù)算調(diào)整后各渠道的用戶質(zhì)量發(fā)生變化需要重新校準(zhǔn)歸因模型”哪怕算法細(xì)節(jié)寫得不夠完美面試官也會覺得你具備較強的業(yè)務(wù)閉環(huán)意識。反過來如果你只把歸因和預(yù)算當(dāng)成兩個獨立模塊去寫就說明你還沒有真正在業(yè)務(wù)中做過“數(shù)據(jù)驅(qū)動增長”的完整項目。6.2 一個可能被忽略的細(xì)節(jié)渠道曝光量與歸因的因果偏差最后再補充一個容易被絕大多數(shù)候選人忽略的點在歸因預(yù)算這類題目里如果你推薦用機器學(xué)習(xí)模型做歸因一定要提“曝光量對模型歸因的干擾”。舉個具體例子短視頻渠道的曝光量可能遠(yuǎn)大于搜索渠道樹模型在訓(xùn)練時會把“曝光量”當(dāng)成一個強特征于是誤以為短視頻渠道貢獻最大。但實際情況可能是搜索渠道來的用戶搜索意圖更強、付費意愿更高只是因為搜索曝光量基數(shù)小總貢獻看起來不如短視頻。這就是典型的“popularity bias”。怎么緩解可以從樣本權(quán)重或特征構(gòu)造角度回答在歸因模型訓(xùn)練時對渠道曝光做某種降權(quán)處理或者構(gòu)造“點擊率/曝光量”這樣的比值特征而不是把曝光量的絕對值直接放進模型。這個層次的答案能立刻拉開你和普通候選人的差距因為它說明你不是只會拿現(xiàn)成模型跑數(shù)據(jù)而是能理解數(shù)據(jù)背后的業(yè)務(wù)邏輯和潛在偏差。這種“偏差意識”在數(shù)據(jù)科學(xué)職業(yè)核心能力里被反復(fù)強調(diào)但在實際工作中很多人一遇到業(yè)務(wù)指標(biāo)波動就開始盲目建模忽略了數(shù)據(jù)本身的生成機制。一個合格的數(shù)據(jù)科學(xué)從業(yè)者應(yīng)該像偵探一樣首先懷疑數(shù)據(jù)的生成過程而不是直接跳進模型調(diào)參。6.3 關(guān)于時間分配和答題策略的再思考整套題做下來我最大的遺憾是在概率選擇題上花的時間略多導(dǎo)致編程題寫得比較趕。如果能重來一次我會嚴(yán)格遵循“每個選擇題最多3分鐘超過就標(biāo)記跳過”的策略。數(shù)據(jù)科學(xué)崗筆試不是要把每道題都做對而是要在有限時間拿到最多加權(quán)分。題目的分值分布通常不會明確標(biāo)出但可以根據(jù)題型推斷一個大致權(quán)重選擇題數(shù)量多、主觀題數(shù)量少。如果你時間緊張優(yōu)先保證主觀題有完整思路和清晰表達(dá)比死磕一道選擇題值錢得多。因為單選、多選是零分或滿分而主觀題只要你踩中得分點哪怕沒有最終數(shù)值也能拿到不少過程分。另外給一個小技巧如果筆試平臺允許返回修改一般在交卷前都可以第一遍把所有題快速過一遍把自己確定能拿分的題先答完第二遍再回頭啃沒做出來的。很多平臺會顯示“未答題數(shù)”看著那個紅色數(shù)字壓力會很大但越到這時候越要先保分再攻堅。寫在最后一次筆試暴露的數(shù)據(jù)科學(xué)能力全景我個人復(fù)盤完這套題的最大感受是騰訊音樂這批秋招筆試題難得不在具體某個知識點而在它把所有知識點都放到了真實業(yè)務(wù)場景里。這不是一套刷題刷出來的題而是一套“做事做出來的題”。如果你平時只是刷Kaggle、背面試題、看機器學(xué)習(xí)課程你會發(fā)現(xiàn)每一道題都眼熟但就是答不透。反過來如果你做過真實的用戶分析、廣告歸因、推薦評估項目這套題答起來會順很多。騰訊音樂的數(shù)據(jù)科學(xué)崗業(yè)務(wù)側(cè)重很明顯內(nèi)容推薦、用戶增長、商業(yè)化變現(xiàn)三大方向。所以準(zhǔn)備筆試時別只盯著機器學(xué)習(xí)算法推導(dǎo)多花時間想想“指標(biāo)為什么漲跌”“模型評估和線上效果為什么不一致”“預(yù)算怎么花才能帶來更多確定性增長”。數(shù)據(jù)科學(xué)崗真正值錢的地方從來不是算法本身而是用數(shù)據(jù)幫業(yè)務(wù)做決策的能力。這套筆試就是一面照妖鏡把你的真實水平照得明明白白。