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