又到了校招季正好有不少人私信問我去年網易2023校招算法工程師的筆試情況。我參加的正是正式批第一批這套題做下來最大的感受是編程題不算偏但選擇題范圍寬而且時間卡得很緊。從投遞簡歷到筆試再到最終拿到意向書這條路我完整走了一遍所以想把這次筆試復盤和經驗整理出來。這篇東西不只在講某一道題的解法更想說明白校招筆試這套篩選邏輯是什么、算法工程師崗位在筆試里到底考什么、以及考前最后幾天應該怎么準備。無論你是正在準備秋招的應屆生還是打算往算法方向轉的同學按這個思路去準備至少不會在筆試環節吃大虧。1. 先把筆試這件事看透網易校招筆試的結構與隱藏邏輯1.1 題型結構選擇題和編程題分別篩選什么網易校招筆試一般安排在線上平臺限時完成整套卷子由選擇題和編程題兩部分組成。選擇題范圍覆蓋數據結構、操作系統、計算機網絡、數據庫這些計算機基礎算法崗還會額外摻入一些概率統計、機器學習基礎題。編程題通常在2到3道之間占分最大基本決定你能不能進入后續面試。很多人會有一個誤區算法工程師崗筆試最重要的是刷LeetCode選擇題隨便準備就行。我第一年也是這么想的結果差點在選擇題上翻車。校招選擇題考察的是“你大學四年到底學沒學過計算機基礎”編程題考察的是“給定一個明確問題你能不能快速寫好代碼”。兩者篩選維度不同但權重都很高。我復盤了一下網易這套筆試題選擇題里數據結構考察得很細比如鏈表的邊界操作、二叉樹的遍歷方式、哈希沖突的處理策略都是老生常談但特別容易混淆的知識點。操作系統則偏好進程線程區別、死鎖條件、虛擬內存計算機網絡則經常問TCP三次握手、擁塞控制、HTTP狀態碼。算法崗特有的概率題通常是貝葉斯公式、期望計算這種雖然不難但如果你很久沒碰數學現場容易發懵。1.2 崗位差異算法工程師筆試和后臺開發筆試不是一回事同樣是筆試后臺開發崗和算法崗的側重點有明顯差異。后臺開發更偏重工程能力編程題里會出現系統設計、并發處理、大數據量排序之類的場景算法崗的編程題更偏重數據結構與算法的基本功題目本身不涉及復雜業務但要求你能快速識別出題目背后是哪種算法模型。與此同時算法崗筆試的選擇題會多出一塊“機器學習基礎”內容。比如損失函數的選擇、過擬合的處理手段、常見分類模型的適用場景。這些知識點不需要你手推公式但你要懂核心思想。我在準備階段復盤了近兩年網易和其他大廠的算法崗筆試題發現一個規律它們對深度學習框架、具體模型結構的考察極少更多考察的是傳統機器學習算法和數學基礎。原因很簡單校招同學在校項目里用框架寫得天花亂墜但很多人連“交叉熵為什么能衡量分布差異”都答不上來筆試就是用來篩掉這種基礎不牢的簡歷。1.3 為什么大廠偏愛限時編程題有人會問為什么明明有簡歷篩選還要用一套硬核的限時編程題來篩人我的理解是這樣的編程題可以在最短時間內橫向比較大量候選人的代碼能力而且幾乎無法作弊。簡歷可以包裝項目可以注水但讓你限時在白板/網頁編輯器里從零寫一個函數幾斤幾兩一試便知。更重要的是限時編程題模擬的是真實工作場景。一位算法工程師日常并不只是調參訓模型大量時間花在數據清洗、特征工程、評估腳本和模型服務化上這些都要求扎實的編碼功底。我在筆試過程中深刻的體會是限時兩小時看起來充裕實際上三道編程題加二十幾道選擇題平均每道題的時間也就幾分鐘一旦某道題卡住整場節奏都會被拖垮。所以平時練習必須卡時間不能泡在IDE里慢慢磨。2. 高頻算法考點拆解字符串、圖論、動態規劃一個都不能放過2.1 字符串系KMP的next數組到底怎么算字符串題在算法工程師筆試里出現的概率極高尤其KMP算法幾乎成了必考題。網上總有傳言說KMP“面試不考、工作不用”但校招筆試就是喜歡考因為它是少有的既能考察“字符串匹配思維”又能在短代碼里體現算法精髓的知識點。先明確一下next數組的定義不同教材定義不同這里采用一種最常見的next[i]表示模式串p[0..i-1]這個子串的最長相等前后綴長度。也就是說對于每個位置i我們要算的是它前面那段字符里前綴和后綴最多能重合多長。計算邏輯可以用一個遞推過程def build_next(p): m len(p) nxt [0] * m j 0 for i in range(1, m): while j 0 and p[i] ! p[j]: j nxt[j - 1] if p[i] p[j]: j 1 nxt[i] j return nxt網上熱詞里有一道典型題對模式串 p abacaba求其next數組。我們用手算來一遍。i1子串是a最長相等前后綴長度為0i2子串是ab前綴a和后綴b不相等為0i3子串是aba前綴a等于后綴a長度為1i4子串是abac前綴a與后綴c不匹配前綴ab與ac也不匹配為0i5子串是abaca前綴a等于后綴a長度1i6子串是abacab前綴ab等于后綴ab長度2i7子串是abacaba前綴aba等于后綴aba長度3。所以next數組是 [0,0,0,1,0,1,2,3]如果按next[0]0length7則數組長度是7還是8取決于下標定義要看題目要求。這道看起來簡單的題實際錯誤率很高因為大家容易在i4和i5處算錯。這里想特別強調一件事手算next數組時不要跳步每一步都要把“當前子串的所有前綴和后綴列出來再比較”做一遍等熟練之后再在心里速算。筆試里如果遇到KMP變體最穩妥的辦法是直接寫出上面這個build_next函數再根據題目要求做匹配而不是在草稿紙上手推一套專用邏輯。2.2 圖論系Dijkstra與BFS/DFS的混合題型圖論題在校招筆試里出鏡率也很高網易尤其愛出最短路徑相關的題目。常考的特征是“給定一個n個節點m條邊的無向帶權圖求從起點到終點的最短路徑”。這種題最直接的解法就是Dijkstra算法但必須用堆優化版本否則在n達到10的5次方級別時會超時。堆優化Dijkstra的核心思想是用優先隊列維護當前未確定最短路的節點中距離最小的節點每次取出隊首節點并松弛其鄰邊如果某條邊能產生更短距離就更新并推入隊列。給你一份可以直接抄的模板import heapq def dijkstra(n, edges, start): graph [[] for _ in range(n)] for u, v, w in edges: graph[u].append((v, w)) graph[v].append((u, w)) dist [float(inf)] * n dist[start] 0 pq [(0, start)] while pq: d, u heapq.heappop(pq) if d dist[u]: continue for v, w in graph[u]: nd d w if nd dist[v]: dist[v] nd heapq.heappush(pq, (nd, v)) return dist這個模板我筆試時直接默寫出來節省了大量時間。不過要注意Dijkstra只適用于邊權非負的圖。如果題目中的邊權全部為1那根本不用Dijkstra直接BFS就能求最短路時間復雜度還更低。有同學看到“最短路”三個字就條件反射寫Dijkstra反而把簡單問題復雜化。筆試題還有一個常見套路是把網格地圖轉換為圖來求解。比如“給定一個二維矩陣0代表空地1代表障礙求從左上角到右下角的最短步數”這就是典型的BFS。如果你能把圖論模板背熟并理解BFS、Dijkstra的適用邊界圖論題基本不會丟分。2.3 動態規劃與貪心從“會背模板”到“會選狀態”動態規劃和貪心是算法工程師筆試的分水嶺。簡單題大家都會難題靠的就是狀態定義和轉移方程。網上熱詞里有大量關于排序、貪心、DP的內容說明這些知識點確實是校招刷題的高頻區。關于動態規劃我建議準備時抓住幾個高頻模型0-1背包、完全背包、最長遞增子序列、最長公共子序列、編輯距離、區間DP。每一類模型都要做到“能推導、能默寫、能變形”。比如0-1背包空間優化為滾動數組后內層循環為什么要倒序遍歷這個原理必須清楚因為一道題稍微變個條件比如要求恰好裝滿背包就需要你調整初始化和遍歷方向。貪心題目的難點在于證明貪心策略的正確性。筆試中很多貪心題看起來可以做但你沒證明就寫很容易掉進反例的坑。我的經驗是如果一個題看起來能貪心先花兩分鐘試著構造反例構造不出來再用貪心思路寫代碼。如果構造出了反例馬上轉DP或二分答案等其他思路。有一類典型案例是“會議室安排最多場次”的變體題貪心策略是按結束時間排序這背后的邏輯是每一步都選擇結束時間最早的會議為后續留下更多空間。這種證明必須掌握因為面試官很可能順著筆試題目追問“為什么這樣貪心是對的”。3. 在線筆試的求生細節很多人在提交之前就輸了3.1 輸入輸出格式讀題多花30秒調試省半小時筆試平臺通常不是LeetCode那種已經幫你封裝好函數的形式而是要求你從標準輸入讀數據再把結果打印到標準輸出。這意味著輸入輸出本身的處理就能卡住一批人。常見的有三種輸入場景第一種是單組測試直接讀固定格式的數據第二種是有T組測試每組做一遍同樣的邏輯第三種是不給你組數要求一直讀到文件末尾也就是EOF。這三種場景的讀法完全不同如果題目要求EOF結束而你只讀到第一組數據就會漏掉大量用例得到Wrong Answer。Python下可以用這種寫法來處理“若干組以EOF結束”的場景import sys for line in sys.stdin: n, m map(int, line.split()) solve(n, m)C則常用while (cin n m) { solve(n, m); }另外輸出格式也要注意有些題目要求每個結果之間用換行分隔有些要求最后一行也有換行。這些細節看起來不起眼但會導致Presentation Error。我筆試時習慣先看一遍樣例輸入輸出確認格式后再動筆寫邏輯這個習慣幫我避開了很多坑。3.2 復雜度估算拿到題先看數據范圍再定算法在線筆試和平時刷題有個很大的不同你沒法立刻知道數據范圍。題目描述里會給n、m的取值范圍這個信息極其關鍵直接決定了你該用哪種算法。我總結了一張自己常用的速查表數據規模可接受的時間復雜度典型算法思路n 20O(2^n) 或 O(n!)狀態壓縮、暴力搜索n 100O(n^3)Floyd、三重循環、區間DPn 1000O(n^2)樸素DP、雙指針n 10^5O(n log n) 或 O(n)排序貪心、堆、線段樹、滑動窗口n 10^9O(log n) 或 O(1)二分答案、矩陣快速冪、數學公式拿到題先看n的范圍再去想算法這個順序不能反。我見過太多人拿O(n^2)的去處理10^5量級的數據最后超時然后開始瘋狂優化常數其實從一開始方向就錯了。如果n是10^5而你想到了排序貪心的O(n log n)解法那這道題的思路基本就穩了。3.3 邊界與防御寫一個會“挑刺”的自己筆試程序最惡心的錯誤不是邏輯錯而是邊界情況沒處理好。空數組、單元素數組、全部元素相同、字符串首尾帶空格、坐標越界、整型溢出、浮點數相等比較這些都是提交后才會暴露的坑。我的習慣是代碼寫完后不急著提交花兩分鐘構造三組特殊用例——最小規模、最大規模、全是極端值。比如題目讓你求最長遞增子序列我就測一下n1的情況如果題目涉及求和我就測一下全為最大值的用例檢查會不會爆int范圍。Python的int沒有溢出問題但C里int和long long的切換很容易出問題。筆試現場時間緊迫一旦你只顧著寫主流程而忽略邊界很可能交完才發現自己的程序在n1時直接報錯。4. 現場還原三道有代表性的筆試編程題4.1 滑動窗口求滿足條件的最短子串網易筆試題中有一類出現頻率特別高的滑窗題題目大致是這樣的給定一個字符串s和一個目標字符串p求s中包含p所有字符的最短子串長度。這道題的考點就是滑動窗口它的思路比暴力要巧妙得多但代碼量也不大。實現思路用“需求表缺失計數”兩步走。先用哈希表記錄p中每個字符的需求量再用兩個指針left和right維護當前窗口。right每擴展一個字符如果該字符仍然“缺”就減少缺失計數當缺失計數歸零說明當前窗口已經覆蓋了p此時嘗試移動left縮小窗口直到窗口不再滿足條件。整個過程中記錄最短窗口長度即可。以下是參考代碼from collections import Counter def min_window(s, p): need Counter(p) missing len(p) left 0 res (float(inf), 0, 0) for right, ch in enumerate(s): if need[ch] 0: missing - 1 need[ch] - 1 if missing 0: while left right and need[s[left]] 0: need[s[left]] 1 left 1 if right - left 1 res[0]: res (right - left 1, left, right) need[s[left]] 1 missing 1 left 1 return if res[0] float(inf) else s[res[1]:res[2] 1]這個模板需要注意的是need中的計數會變成負數表示窗口內該字符數量超出需求這是判斷左指針能否收縮的關鍵。筆試時如果時間緊可以直接套模板但建議你自己在本地多跑幾組用例驗證一下因為“窗口內字符超出需求”和“窗口仍有效”這兩者的邏輯關系非常容易寫錯。4.2 堆優化Dijkstra網絡最短時延問題還有一道比較典型的圖論題題目大概是給定一個包含n個節點的網絡圖每一條邊都帶有傳輸時延現在從某個節點發出一條消息求消息廣播到所有節點所需的最短時間。這題的思路其實就是求從源節點出發到所有節點的最短路徑答案就是其中最長的最短距離。我直接套用了前面給出的堆優化Dijkstra模板然后取dist數組的最大值作為答案。寫起來大概只需要十分鐘。這道題之所以值得復盤是因為它考察的不只是Dijkstra本身還包括一個額外的轉化要求的是所有節點收到消息的時間不是某一個目標節點所以答案等于最短路中的最大值。很多同學把Dijkstra寫出來以后卻忘了取max白白丟分。順帶一提如果這個題改成“是否存在節點無法收到消息”那還需要檢查dist數組中是否有節點仍是無窮大。這類邊角條件往往就是筆試的隱藏分寫的時候一定要多問自己一句題目里有沒有類似“全部節點可達嗎”的隱含要求。4.3 排序之后的區間合并思維題往往更考驗代碼簡潔度網易筆試編程題里也會出現一些看起來并不“算法”的題比如區間合并給定一系列區間合并所有重疊區間輸出合并后的區間個數或總長度。題意很簡單但代碼寫得干不干凈很考驗基本功。解題步驟也很直接先把區間按左端點排序然后遍歷所有區間維護當前合并后的右邊界。如果當前區間左端點大于右邊界說明無法合并把當前區間收入結果否則更新右邊界為兩者中的較大值。參考代碼def merge(intervals): if not intervals: return [] intervals.sort(keylambda x: x[0]) res [] for l, r in intervals: if not res or l res[-1][1]: res.append([l, r]) else: res[-1][1] max(res[-1][1], r) return res這道題想提醒大家的是不是你只會高階算法就能拿高分能把簡單的數據結構題寫得又快又準往往才是筆試拿滿分的保障。現場答題時最怕“想太多”區間合并一上來就腦補線段樹優化結果不僅增加代碼量還可能因為復雜度過高而寫錯邊界反而不如基礎的排序加貪心。5. 算法工程師崗位的“隱藏考點”機器學習與大模型5.1 數學與機器學習基礎選擇題里藏著真功夫算法工程師筆試和普通開發崗筆試最大區別就是選擇題中會出現數學和機器學習內容。網易這筆試也不例外。我記得選擇題里出現了貝葉斯公式求后驗概率的題目還有一道關于交叉熵損失函數的選擇題選項分別是MSE、交叉熵、Hinge Loss等在不同場景下的表現。如果你只刷題不看機器學習基礎這兩道題基本沒法做。我建議大家準備時重點復習幾個模塊概率論中的貝葉斯公式、期望與方差、常見分布機器學習中的偏差與方差、過擬合與正則化、常見損失函數、決策樹與隨機森林的差異、SVM的核函數思想。很多內容不需要手動推導公式但你要能理解“為什么用這個”而不是“怎么算這個”。此外有一類認知題也常出現比如“當訓練集和測試集分布不一致時以下哪種處理方式最有效”。這種題沒有標準公式可以套考的是你對機器學習流程的整體理解。我的建議是遇到這種題不要憑記憶去猜而是從實際業務邏輯去推理。筆試出題人的邏輯其實很簡單他們想看你是不是只會在Jupyter Notebook里跑模型。5.2 大模型時代算法工程師正在被提出新要求2023年這批校招一個明顯的信號是大模型相關內容開始出現在算法工程師的考察范圍里。雖然網易筆試的編程題沒有直接讓你實現Transformer但選擇題里已經出現了關于注意力機制、推理加速等方向的基礎問題。熱詞里有“AI算法工程師必知必會 入門llama.cpp”這其實反映了行業對算法工程師的新期待不僅要會訓練模型還要懂推理部署和性能優化。如果你正在準備算法工程師校招我建議在大模型方向做三件事第一完全理解Transformer的self-attention機制知道Q、K、V從哪里來到哪里去第二了解常見的推理優化手段比如量化、剪枝、蒸餾、KV Cache至少知道它們分別解決什么問題第三動手跑通一個開源大模型的本地推理流程選一個輕量項目能夠講清楚從下載權重到調用推理接口的完整鏈路。哪怕筆試不直接考面試時也幾乎必問。6. 備考時間線與臨場策略我把自己的安排寫在這里6.1 提前三個月以刷題和基礎為主的儲備期校招筆試準備不能靠考前一周突擊我的時間線是提前三個月開始。前兩個月主要做兩件事一是把數據結構與算法的基礎知識系統過一遍包括數組、鏈表、棧、隊列、樹、圖、哈希表、排序、二分、動態規劃、貪心二是每天固定刷2到3道LeetCode中等難度題優先覆蓋高頻考點。我還做了一件事就是建立自己的“模板庫”。把KMP、Dijkstra、并查集、滑動窗口、二分答案、線段樹等常用算法整理成可以直接復用的代碼片段并且每段都自己默寫過至少三遍。筆試時直接調用這些模板能節省大量時間。注意模板庫不是抄一遍就完事的你要能默寫出來因為筆試平臺沒有你本地的代碼片段可復制。6.2 提前一個月真題、周賽和模擬環境最后一個月重心從“學”轉向“測”。我會每天做一場線上模擬筆試用牛客網或LeetCode周賽的限時模式練習要求自己兩小時內完成所有題目嚴格模擬真實的考試節奏。這個過程非常痛苦但也非常有效。第一次模擬我甚至沒有做完第一道題但練到第五次時已經能穩定在三道題中提交兩道并保證正確率。模擬時要注意一個細節真實筆試的在線編輯器通常不帶自動補全和語法檢查有些平臺連本地調試都不方便。所以我平時刷題時會特意在網頁編輯器中寫代碼不依賴IDE的提示這樣到了考場不會因為“代碼助手消失”而手忙腳亂。6.3 筆試當天時間管理、環境檢查和心態筆試當天我給自己定的策略是“先掃卷再動手”。拿到卷子先不急著寫代碼用5分鐘瀏覽所有題目評估每一道題的難度。然后按“會做的先做不會做的標記后做”的順序執行。選擇題通常會先快速過一遍遇到卡殼的不糾結直接蒙一個并標記等到最后有空余時間再回看。環境上也有幾個建議提前測試瀏覽器兼容性有些在線筆試平臺對瀏覽器有特殊要求關閉所有可能彈窗的軟件包括微信、郵件提醒避免考試過程中被切出頁面某些平臺會記錄切屏次數嚴重時直接判作弊。最后預留至少十分鐘檢查代碼里的print拼寫、輸入函數是否寫對、輸出格式是否和樣例一致。我見過不少同學算法思路完全正確卻因為printf寫成了print而全盤得零分這種損失太不值得。結尾一點個人體會真正經歷完整套流程后我最大的感受是校招筆試篩的從來不是“天才”而是“穩的人”。算法題誰都會說思路但能在限時、沒有IDE輔助、精神高度緊張的情況下把代碼一次寫對、把邊界測全、把復雜度算清楚這才是企業真正需要的能力。我個人在準備后期把大量時間從“刷新題”改成了“重復默寫模板和復盤錯題”這個轉變讓我在筆試現場心里踏實了很多。最后再分享一個實用小技巧筆試交卷前花10秒看一眼屏幕右下角的時間如果還有剩余把每道題的最小邊界用例在腦子里跑一遍往往能救回不少分。希望這篇復盤對你有用祝今年校招順利。