這些年秋招季我經(jīng)常會翻到一些舊筆記恰好整理到了當(dāng)時參加唯品會2019秋招數(shù)據(jù)開發(fā)崗的完整復(fù)盤。那會兒數(shù)據(jù)開發(fā)這個崗位還沒有現(xiàn)在這么“卷”但考察的深度和方向已經(jīng)非常明確SQL是基本功離線數(shù)倉是主線實時計算是加分項。如果你正準(zhǔn)備投遞數(shù)據(jù)開發(fā)崗或者正在糾結(jié)怎么準(zhǔn)備大廠數(shù)據(jù)崗面試這篇文章基本能幫你把考察重點、面試套路和實戰(zhàn)避坑一次性理清。我先把結(jié)論放在前面唯品會數(shù)據(jù)開發(fā)崗的考察風(fēng)格屬于典型的“電商大廠通用型”——不考偏題怪題但特別重視你對數(shù)據(jù)倉庫建模的理解、對Hive/Spark等離線計算引擎的掌握深度以及能不能把業(yè)務(wù)問題翻譯成技術(shù)方案。筆試會卡一輪SQL和算法技術(shù)面會深挖項目里的數(shù)倉分層、數(shù)據(jù)傾斜、指標(biāo)一致性這些細(xì)節(jié)。下面我按時間線把整個流程拆開講。1. 崗位畫像與考察節(jié)奏先搞清楚他們要什么樣的人1.1 數(shù)據(jù)開發(fā)崗在電商大廠到底做什么投簡歷之前我建議你先想明白一件事數(shù)據(jù)開發(fā)崗和數(shù)據(jù)分析崗、大數(shù)據(jù)平臺開發(fā)崗是有本質(zhì)區(qū)別的。很多同學(xué)投遞時容易混淆結(jié)果面試時答非所問。從唯品會這類電商公司的組織架構(gòu)來看數(shù)據(jù)開發(fā)崗的核心職責(zé)可以概括為三塊離線數(shù)倉建設(shè)負(fù)責(zé)從業(yè)務(wù)庫、日志、第三方渠道把數(shù)據(jù)同步到數(shù)倉然后完成ODS、DWD、DWS、ADS各層級的建模、清洗、加工最終產(chǎn)出供BI報表、數(shù)據(jù)分析師、算法團(tuán)隊使用的數(shù)據(jù)表。數(shù)據(jù)服務(wù)與保障保證數(shù)據(jù)任務(wù)按時產(chǎn)出、數(shù)據(jù)質(zhì)量可靠包括調(diào)度系統(tǒng)的維護(hù)、任務(wù)血緣管理、數(shù)據(jù)對賬、異常監(jiān)控告警。實時計算開發(fā)隨著業(yè)務(wù)對時效性的要求提高數(shù)據(jù)開發(fā)崗需要承擔(dān)一部分實時鏈路建設(shè)比如Flink/Spark Streaming消費(fèi)Kafka做實時大屏、實時特征、實時報表。也就是說你不僅要會寫SQL還要懂調(diào)度、懂存儲、懂引擎原理甚至要懂一點業(yè)務(wù)指標(biāo)口徑。面試官考察的就是你“能不能獨立把一個數(shù)據(jù)需求從取數(shù)到建模再到上線跑通”。1.2 2019秋招的考察節(jié)奏與環(huán)節(jié)分布我當(dāng)年的整個流程是這樣的網(wǎng)申投遞、在線筆試、技術(shù)一面、技術(shù)二面、HR面Offer審批。不同批次可能略有差異但整體結(jié)構(gòu)差異不大。這里說一下筆試環(huán)節(jié)的通過率感受。數(shù)據(jù)開發(fā)崗的筆試會同時考到四類內(nèi)容計算機(jī)基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)、Java/Python基礎(chǔ)、操作系統(tǒng)、網(wǎng)絡(luò)、SQL編程題、大數(shù)據(jù)組件原理、少量數(shù)倉建模設(shè)計題。其中SQL題占比最高大概能到40%左右其次是大數(shù)據(jù)組件Hadoop/Hive/Spark原理約30%剩下的是算法編程和計算機(jī)基礎(chǔ)。所以如果你準(zhǔn)備時間有限優(yōu)先攻克SQL和Hive/Spark原理這兩塊決定了你筆試能不能過線。2. 筆試真題復(fù)盤SQL和數(shù)倉基礎(chǔ)是最大分水嶺2.1 高頻SQL題型窗口函數(shù)是必拿分項唯品會筆試?yán)锏腟QL題難度中等偏上考的不是簡單select而是實際業(yè)務(wù)中高頻使用的分析場景。我復(fù)盤下來最常出現(xiàn)的題型有以下幾類每一類我都會附上核心解法和示例。第一類分組TopN問題比如“統(tǒng)計每個品類下銷量最高的前3個商品”。這類題的核心就是row_number() over(partition by ... order by ...)然后再套一層子查詢把rn過濾出來。當(dāng)年考的一道題大概是這樣的-- 表結(jié)構(gòu)orders(order_id, product_id, category_id, sales_amount) -- 需求統(tǒng)計每個品類下銷售額排名前3的商品 SELECT category_id, product_id, sales_amount FROM ( SELECT category_id, product_id, sales_amount, ROW_NUMBER() OVER(PARTITION BY category_id ORDER BY sales_amount DESC) AS rn FROM orders ) t WHERE t.rn 3;這里有個細(xì)節(jié)值得注意如果業(yè)務(wù)上存在銷售額并列的情況用ROW_NUMBER還是RANK要取決于需求。ROW_NUMBER是唯一遞增編號同分也會分出先后RANK同分會重復(fù)排名且后續(xù)排名會跳躍DENSE_RANK同分重復(fù)但后續(xù)排名不跳躍。面試官很可能會追問這個問題你得能說清楚三者的差別和適用場景。第二類連續(xù)登錄問題比如“找出連續(xù)登錄3天及以上的用戶”。標(biāo)準(zhǔn)的解法是使用lag或lead窗口函數(shù)或者用date_sub(login_date, rn)構(gòu)造連續(xù)分組。-- 表結(jié)構(gòu)user_login(user_id, login_date) -- 思路登錄日期減去行號若日期是連續(xù)的差值相同 SELECT user_id FROM ( SELECT user_id, login_date, DATE_SUB(login_date, ROW_NUMBER() OVER(PARTITION BY user_id ORDER BY login_date)) AS grp FROM user_login ) t GROUP BY user_id, grp HAVING COUNT(*) 3;這道題的變形很多比如“連續(xù)7天”“連續(xù)30天”“連續(xù)活躍用戶數(shù)”解法套路都一樣但需要你理解為什么date_sub之后分組能保持連續(xù)。這個原理如果說不清楚面試官會懷疑你是背題。第三類留存率與復(fù)購率計算這類題非常貼近電商業(yè)務(wù)。比如“計算每日新增用戶的次日留存率”。核心是自關(guān)聯(lián)或者left join按用戶首次活躍日期分組SELECT t1.first_date, COUNT(DISTINCT t1.user_id) AS new_users, COUNT(DISTINCT t2.user_id) AS retention_users, COUNT(DISTINCT t2.user_id) / COUNT(DISTINCT t1.user_id) AS retention_rate FROM ( SELECT user_id, MIN(login_date) AS first_date FROM user_act GROUP BY user_id ) t1 LEFT JOIN user_act t2 ON t1.user_id t2.user_id AND t2.login_date DATE_ADD(t1.first_date, 1) GROUP BY t1.first_date;這種題在筆試?yán)锊皇亲屇阏嫒ヅ芏强疾炷愕倪壿嬍欠袂逦日倚略鲈僬掖稳沼谢卦L的用戶最后算比率。做題時注意兩個坑一是分母要去重二是LEFT JOIN避免把新增用戶過濾掉。2.2 數(shù)倉建模設(shè)計題星型模型、雪花模型與拉鏈表除了SQL筆試還會出現(xiàn)簡答/設(shè)計題常見場景是“請為一個電商平臺設(shè)計訂單事實表和商品維度表并說明模型選型理由”。這一塊我當(dāng)時的回答思路可以給你參考選星型模型還是雪花模型核心看維度的規(guī)范化和查詢性能的平衡。星型模型維度表冗余、層次扁平適合OLAP查詢SQL寫起來簡單join次數(shù)少雪花模型維度表做了規(guī)范化拆分消除冗余但增加了join層級?；ヂ?lián)網(wǎng)數(shù)倉里星型模型更主流因為查詢性能和易用性優(yōu)先。事實表設(shè)計要區(qū)分事務(wù)事實表和周期快照事實表。訂單累計快照、每日庫存快照用周期快照表交易流水、點擊日志用事務(wù)事實表。拉鏈表是一個非常高頻的考點用于記錄維度屬性隨時間的變化。比如用戶等級、商品價格如果直接覆蓋更新就丟失歷史于是設(shè)計start_date和end_date兩個字段配合daily分區(qū)表做全量比對更新。筆試?yán)飼屇阍O(shè)計表結(jié)構(gòu)和更新邏輯你要能寫出“開鏈、關(guān)鏈、新增”三步SQL。當(dāng)時筆試還考了一道很有意思的題給定一份用戶訂單明細(xì)統(tǒng)計“每個用戶首次下單到第二次下單的平均間隔天數(shù)”。這題其實就是lead窗口函數(shù)取下一次下單時間再datediff計算間隔最后取均值。這類題看起來復(fù)雜拆解后就是窗口函數(shù)聚合很考察基本功。2.3 算法編程題以LeetCode中等難度為主數(shù)據(jù)開發(fā)崗的算法題不會像后端開發(fā)那樣出hard難題但中等難度的題目還是需要準(zhǔn)備的。我當(dāng)時碰到的是“給定一個無序數(shù)組求最長連續(xù)序列的長度”核心思路是去重后用HashSet從每個連續(xù)序列的起點開始遍歷時間復(fù)雜度O(n)。def longestConsecutive(nums): nums set(nums) max_len 0 for num in nums: if num - 1 not in nums: cur num length 1 while cur 1 in nums: cur 1 length 1 max_len max(max_len, length) return max_len刷題建議以LeetCode Top100里涉及數(shù)組、哈希表、字符串、鏈表的題目為主排序和雙指針也要熟。筆試平臺一般是?？途W(wǎng)模式上可能不是leetcode那種核心代碼模式而是需要自己處理輸入輸出這點提前練一練省得考場上手忙腳亂。3. 技術(shù)面核心環(huán)節(jié)離線鏈路與實時計算考察實錄3.1 Hive必問點存儲格式、分區(qū)分桶、UDF通過筆試之后我進(jìn)入了一面這輪主要考察的是大數(shù)據(jù)基礎(chǔ)功底。面試官從Hive開始問起層層遞進(jìn)。他先問“你用過哪些Hive文件存儲格式分別有什么優(yōu)缺點”這個問題看似基礎(chǔ)但能把兩者區(qū)別講清楚的人其實不多。我的回答思路是TextFile是默認(rèn)的純文本格式可讀性好但壓縮率和查詢性能都很差Parquet是列式存儲按列壓縮在查詢只需要部分列時能大幅減少IOORC也是列式存儲在Hive生態(tài)里壓縮比和查詢性能通常更好但Parquet在Spark生態(tài)中的兼容性更通用。所以具體選型要看技術(shù)?！绻疽訦ive為主ORC很常見如果以Spark為主Parquet更穩(wěn)妥。接著他拋出一個非常典型的業(yè)務(wù)問題“一張訂單表每天幾千萬條查詢某個用戶最近10筆訂單很慢怎么優(yōu)化”這題考察的就是分區(qū)和分桶。我的回答分三步第一按日期做分區(qū)裁剪查詢時限定最近一個月分區(qū)把掃描數(shù)據(jù)量降下來第二如果經(jīng)常按user_id查詢可以對user_id做分桶讓同一個用戶的數(shù)據(jù)落在同一個桶內(nèi)查詢時直接定位到桶第三在桶內(nèi)字段上建排序結(jié)合bucket pruning進(jìn)一步提升效率。然后面試官又追問了UDF的開發(fā)流程。UDF分三類UDF一對一、UDAF多對一聚合函數(shù)、UDTF一對多行轉(zhuǎn)列。我當(dāng)時手寫過身份證號解析的UDF就順帶介紹了繼承UDF類、重寫evaluate方法、打包上傳、create temporary function注冊的完整過程。3.2 Spark考察重點寬窄依賴、shuffle調(diào)優(yōu)、內(nèi)存模型Hive之后自然而然地進(jìn)入Spark。面試官問的第一個問題很有代表性“Spark寬依賴和窄依賴的區(qū)別以及為什么窄依賴可以流水線執(zhí)行”我當(dāng)時的回答窄依賴是指父RDD每個分區(qū)最多被子RDD的一個分區(qū)使用比如map、filter、union子RDD可以直接在父RDD分區(qū)上原地計算無需shuffle寬依賴是指父RDD每個分區(qū)可能被子RDD的多個分區(qū)使用典型是groupByKey、reduceByKey、join父分區(qū)的數(shù)據(jù)需要跨節(jié)點重新分發(fā)也就是shuffle。shuffle要落盤、要網(wǎng)絡(luò)傳輸是Spark作業(yè)性能瓶頸的根源所以優(yōu)化shuffle是Spark調(diào)優(yōu)的核心目標(biāo)。緊接著他問“你線上Spark任務(wù)遇到過數(shù)據(jù)傾斜嗎怎么定位和解決的”這是我強(qiáng)烈建議重點準(zhǔn)備的題因為幾乎必考。我復(fù)盤了一個真實案例現(xiàn)象是跑一個訂單維度的聚合任務(wù)其他executor幾十秒跑完某個executor跑了半小時最后OOM。定位思路是先看Spark UI上的Stage耗時再通過查看每個task處理的數(shù)據(jù)量發(fā)現(xiàn)某個task的輸入數(shù)據(jù)量是其他task的幾十倍基本確認(rèn)key分布嚴(yán)重不均。解決方案我說了三個過濾臟數(shù)據(jù)如果傾斜的key是空值或無明顯業(yè)務(wù)意義的數(shù)據(jù)比如空字符串、未知ID可以單獨過濾或加隨機(jī)前綴后再打散處理加隨機(jī)前綴兩階段聚合對傾斜key先加隨機(jī)數(shù)前綴進(jìn)行第一輪局部聚合再去掉前綴做第二輪全局聚合。適用于聚合類操作對join類問題無效廣播小表如果大表join小表時出現(xiàn)傾斜可以map端廣播小表避免shuffle。然后他讓我背一下Spark on YARN的資源分配參數(shù)和內(nèi)存模型。這部分如果沒實際調(diào)優(yōu)過很容易慌我列一下參數(shù)和含義spark.executor.memory控制executor堆內(nèi)內(nèi)存spark.executor.memoryOverhead控制堆外內(nèi)存默認(rèn)是堆內(nèi)存的10%用于JVM本身、字符串常量池、網(wǎng)絡(luò)緩沖等spark.executor.cores控制executor的CPU核數(shù)spark.executor.instances控制executor數(shù)量。內(nèi)存模型上Spark 1.6之后引入了統(tǒng)一內(nèi)存管理堆內(nèi)分為Storage內(nèi)存、Execution內(nèi)存和保留區(qū)域Storage和Execution可以互相借用避免出現(xiàn)一邊空間浪費(fèi)一邊GC頻繁的問題。3.3 Flink與實時計算Time、Watermark、Exactly-Once二面的時候面試官突然切到了實時計算。他問的是“你用過Flink嗎簡單講講Flink和Spark Streaming的區(qū)別?！边@題很考察認(rèn)知廣度。我的回答是Spark Streaming是基于微批的準(zhǔn)實時計算把流數(shù)據(jù)切成一個個小批次處理吞吐量高但延遲在秒級典型延遲在幾百毫秒到秒級Flink是真正的流式計算引擎事件逐條處理延遲可以做到毫秒級并且支持基于事件時間(event time)的窗口計算天然契合對亂序數(shù)據(jù)有要求的場景。另外Flink在狀態(tài)管理、精確一次語義(Exactly-Once)方面做得更徹底。然后他追問Watermark的作用。我用了一個通俗的類比來解釋W(xué)atermark是“我等多長時間就不再等了”的標(biāo)記。比如事件時間是12:00的窗口允許亂序5秒鐘那么當(dāng)Watermark推進(jìn)到12:00:05時就觸發(fā)計算12:00那個窗口的結(jié)果。如果一條遲到數(shù)據(jù)在Watermark之后才到達(dá)就只能被丟棄或進(jìn)入側(cè)輸出流。實際項目中要結(jié)合業(yè)務(wù)容忍度來設(shè)置亂序時間太短會導(dǎo)致結(jié)果不準(zhǔn)太長會延遲出結(jié)果。那輪面試快結(jié)束時他問我“你們實時任務(wù)怎么保證數(shù)據(jù)不丟不重”我說我們用的Kafka Flink方案Kafka的offset由Flink checkpoint機(jī)制管理開啟exactly-once模式后Flink會把狀態(tài)和offset一起做快照發(fā)生故障時從最近一次checkpoint恢復(fù)配合Kafka consumer事務(wù)性寫入可以做到端到端精確一次。不過這需要上下游都支持事務(wù)或冪等寫入否則只能做到至少一次(at-least-once)下游需要做去重。3.4 手寫SQL環(huán)節(jié)從數(shù)據(jù)傾斜到指標(biāo)設(shè)計二面里還有個手寫SQL環(huán)節(jié)面試官在白板上出了幾道題。其中最讓我印象深刻的一道是“統(tǒng)計連續(xù)7天有購買行為的用戶且這7天每天的購買金額都大于100元”。這道題把連續(xù)性問題條件過濾窗口函數(shù)結(jié)合在了一起。我的解法思路是先用where過濾掉金額≤100的記錄再按用戶分組用date_sub(login_date, row_number())構(gòu)造連續(xù)組最后having count(*) 7。關(guān)鍵在于“先過濾再算連續(xù)”如果先算連續(xù)再過濾邏輯就完全錯了。另一個手寫題是“計算某品類商品的GMV周同比”要求考慮節(jié)假日調(diào)整。這個題目本質(zhì)上在考察數(shù)據(jù)分析思維周同比是指本周累計GMV相對上周同期的變化但遇到春節(jié)、雙11這類大促周期簡單周同比會失真應(yīng)該用活動周期對齊再比較。面試官借此考察你是不是只懂技術(shù)、不懂業(yè)務(wù)這個表達(dá)很重要。4. 面試中的高頻追問與答題思路4.1 “講一下你簡歷里這個項目”的正確打開方式技術(shù)面一定會讓你介紹項目。我踩過很大的一個坑是第一次面試時把項目描述得像流水賬——先做了什么后做了什么最后實現(xiàn)了什么。面試官根本不感興趣。后來我總結(jié)了一套“項目講述公式”業(yè)務(wù)背景放在第一句用一句話說清楚這個項目解決了什么問題然后是技術(shù)架構(gòu)用三到五句話說明數(shù)據(jù)從哪來、經(jīng)過哪些環(huán)節(jié)、最后落到哪里接著是你具體負(fù)責(zé)的模塊要精確到表怎么設(shè)計、任務(wù)怎么寫、參數(shù)怎么調(diào)最后留一個鉤子主動拋出你在項目中遇到的一個難題和解決過程引導(dǎo)面試官往你熟悉的方向問。以我當(dāng)時做的“用戶行為分析數(shù)倉”項目為例我會這樣講業(yè)務(wù)背景是App端每日產(chǎn)生大量埋點日志業(yè)務(wù)方需要按小時維度查看用戶轉(zhuǎn)化漏斗但原有流程是日志落HDFS后第二天跑批時效性不夠。所以我在ODS層直接對接Kafka實時接入DWD層做清洗和session劃分DWS層做小時級聚合再通過預(yù)聚合結(jié)果供前端大屏查詢。項目中最棘手的問題是session劃分時存在大量超長session我用“間隔30分鐘無操作則切分”的策略處理并用Hive/Spark優(yōu)化了session劃分任務(wù)的數(shù)據(jù)傾斜。這樣一講面試官會主動問你session劃分的細(xì)節(jié)和傾斜優(yōu)化正好踩在你的準(zhǔn)備范圍內(nèi)。4.2 數(shù)據(jù)質(zhì)量與指標(biāo)一致性大廠面試的隱藏考點這類問題不會直接問“你怎么保障數(shù)據(jù)質(zhì)量”而是會通過場景題出現(xiàn)比如“運(yùn)營反饋昨天報表的GMV和財務(wù)部對不上你怎么排查”“你的數(shù)倉里訂單金額字段有的表叫order_amount有的表叫pay_amount怎么統(tǒng)一”“凌晨3點調(diào)度任務(wù)失敗了第二天早上才發(fā)現(xiàn)怎么避免”我的回答思路通常包含四個層面數(shù)據(jù)質(zhì)量校驗在任務(wù)里加入數(shù)據(jù)量波動監(jiān)控比如昨日分區(qū)行數(shù)相比前日波動超過20%則任務(wù)報警關(guān)鍵指標(biāo)設(shè)置閾值校驗比如訂單金額不為負(fù)。指標(biāo)口徑登記建立指標(biāo)字典每個指標(biāo)必須有統(tǒng)一定義。比如“GMV”指用戶支付成功的訂單金額包含退款但在統(tǒng)計周期內(nèi)尚未退款的訂單而“實付金額”是扣除退款后的凈額。這些口徑一定要在需求評審階段對齊并在代碼注釋和元數(shù)據(jù)系統(tǒng)里登記。對賬機(jī)制核心報表每天與業(yè)務(wù)庫進(jìn)行對賬Kafka實時鏈路會有實時與離線數(shù)據(jù)交叉比對如果實時結(jié)果與離線結(jié)果偏差超過閾值立即觸發(fā)告警。鏈路監(jiān)控用調(diào)度平臺自帶的任務(wù)依賴和告警功能設(shè)置任務(wù)失敗自動重跑和電話/短信告警配合數(shù)據(jù)質(zhì)量平臺做表級和字段級血緣追蹤。4.3 大廠面試的軟技能業(yè)務(wù)理解與溝通表達(dá)最后想提醒一點數(shù)據(jù)開發(fā)崗不是純技術(shù)崗。面試官非?？粗啬隳懿荒苈牰畼I(yè)務(wù)方說什么。這輪面試?yán)镉袀€問題是“如果商品運(yùn)營想分析‘高價值用戶’的購買偏好你怎么定義高價值用戶”如果只回答“根據(jù)消費(fèi)金額排序取前20%”那只是及格水平。更好的回答是先問清楚高價值用戶是看近30天消費(fèi)金額、消費(fèi)頻次、還是用戶生命周期價值(LTV)不同業(yè)務(wù)目標(biāo)下定義完全不同。先確認(rèn)口徑再談實現(xiàn)這本身就是數(shù)據(jù)開發(fā)的基本工作方式。5. 秋招投遞與面試節(jié)奏的實操建議5.1 簡歷怎么寫能更匹配數(shù)據(jù)開發(fā)崗簡歷這塊我給出三個具體建議。第一項目經(jīng)歷中一定要有明確的“數(shù)量級”——比如“處理日均5億條日志數(shù)據(jù)”“數(shù)倉共2000張表”“調(diào)度任務(wù)3000個”面試官對數(shù)字非常敏感沒有數(shù)量級描述會讓人覺得項目是玩具項目。第二技術(shù)棧要寫出“熟練、掌握、了解”的邊界不要全部寫成精通。面試官如果發(fā)現(xiàn)你寫了“精通Spark”卻又答不出shuffle原理反而會扣分。第三把“業(yè)務(wù)結(jié)果”寫進(jìn)簡歷比如“通過口徑統(tǒng)一將報表差錯率從5%降到0.5%”——這種描述能有效區(qū)分你和其他候選人。5.2 時間線管理提前批、正式批與內(nèi)推渠道當(dāng)時我投遞的是秋招提前批這類批次的優(yōu)勢是流程快、競爭相對小部分公司提前批不通過還能轉(zhuǎn)正式批。建議你重點關(guān)注幾個時間節(jié)點7月到8月是提前批開放期9月到10月是正式批集中筆試期。內(nèi)推不是必須的但有內(nèi)推可以讓簡歷優(yōu)先被看到避免簡歷石沉大海。找內(nèi)推的渠道一般是?？途W(wǎng)、公眾號、學(xué)長學(xué)姐、以及各大技術(shù)社區(qū)的內(nèi)推帖注意別為了內(nèi)推泄露個人敏感信息。5.3 心態(tài)調(diào)整與多線面試的經(jīng)驗秋招最崩潰的不是某一場面試掛了而是連續(xù)一周每天都有筆試面試時間根本排不開。我的做法是每周固定半天完整刷題其余碎片時間只看牛客網(wǎng)的面經(jīng)和錯題把每一輪的面試題目及時復(fù)盤記到備忘錄里避免同一類問題在下一場面試?yán)镌倏榱藨?yīng)對不同公司的流程沖突可以禮貌地和HR溝通調(diào)整面試時間絕大多數(shù)公司都能協(xié)調(diào)。說實話我當(dāng)時也在很多公司面試時遇到過答不上來的題?；仡^來看面試官有時候并不是想等你一個完美答案而是在看你怎么思考、怎么溝通、怎么在不會的情況下給出合理的分析路徑。數(shù)據(jù)開發(fā)崗尤甚——這個崗位每天面對的是臟數(shù)據(jù)、延遲任務(wù)、口徑爭議解決問題的思路比答案本身更重要。你如果能把這個態(tài)度表現(xiàn)出來面試就已經(jīng)成功了一大半。5.4 關(guān)于Offer選擇的個人體會最后再多說一句當(dāng)年我糾結(jié)很久的事數(shù)據(jù)開發(fā)崗最后拿到幾個Offer時怎么選。除了看薪資我更建議你關(guān)注三件事第一團(tuán)隊使用的技術(shù)棧是否足夠主流如果還在用純MapReduce寫數(shù)倉那你的成長速度會受影響第二數(shù)倉建設(shè)是否已經(jīng)有完整規(guī)范還是處于“人肉取數(shù)加工廠”階段這決定了你進(jìn)去后是寫代碼還是寫臨時SQL第三實時鏈路是否已經(jīng)落地如果有機(jī)會在生產(chǎn)環(huán)境接觸Flink對你后續(xù)的職業(yè)發(fā)展加成會很明顯。數(shù)據(jù)開發(fā)這個崗位門檻不高但天花板很高。筆試面試只是第一關(guān)真正拉開差距的是你進(jìn)入崗位后能不能從“會寫SQL”升級到“會設(shè)計數(shù)倉”再到“能推動數(shù)據(jù)規(guī)范和數(shù)據(jù)質(zhì)量建設(shè)”的人。這個成長路徑比秋招本身更值得提前想清楚。