程式設計面試準備：模式、平台和練習方法

程式碼面試實際測試的內容（訊號 vs 噪音）

程式碼面試不是一場演算法考試。面試官早已知道答案。他們在測試的內容，大致按順序是：候選人能否澄清一個模糊的問題、能否選擇符合約束條件的資料結構、能否寫出在小輸入上第一次就能編譯並執行的程式碼，以及能否在受到質疑時不帶防禦性地解釋權衡。實際的演算法是這五項中最簡單的。

這很重要，因為大多數候選人在錯誤的方向上投入了過多精力。他們解決了四百道 LeetCode 題目，但當面試官打斷說「如果輸入無法裝入記憶體怎麼辦？」時就會卡住。他們記住了歸併排序遞迴，但說不出為什麼是 n log n 而不是 n 平方。他們寫出了最優解決方案，但隨後無法除錯一個單字元的打字錯誤，因為他們從未在真正的編輯器中從頭開始輸入過問題。

面試官尋找的訊號是一小組行為：

• 候選人在開始寫程式碼前用自己的話重新闡述問題。
• 候選人在宣告資料結構之前，先說出他們要使用哪個資料結構以及為什麼。
• 候選人按照一個人實際輸入程式碼的順序來寫程式碼——而不是教科書的排版順序。
• 候選人在聲稱完成之前，先手工執行一個小例子。
• 候選人在受到質疑時，說「你說得對」或「讓我想想」，而不是為錯誤答案辯護。

本指南中的所有內容都是為了培養這五種行為。這些模式、平台、語言選擇——它們都歸結為一個問題：你能否在陌生的機器上，在有人觀看的情況下，展示出你的思維方式像一名工程師，而不是一個記住瞭解決方案的人。

覆蓋~80%問題的八種資料結構模式

如果你看過過去兩年來自典型FAANG級別面試迴圈的電話篩選和現場面試問題，並按方法分組，同樣的八個模式會反覆出現。掌握這些模式比盲目解決兩倍的問題更有價值，因為當問題以你從未見過的方式表述時，模式識別能力才是真正支撐你的東西。

1. 雙指標

當問題在排序陣列、字串或連結串列上，需要找對、分割或就地重新排列時，雙指標就是答案。時間複雜度是輸入的線性，空間複雜度是常數。經典提示包括"已排序陣列上的兩數之和""就地刪除重複元素""裝最多水的容器"和"這個字串是迴文嗎"。如果問題說排序或迴文或就地，在嘗試其他方法之前一定要先考慮雙指標。

陷阱是無法維護不變數。每當指標移動時，你應該能用一句話說明它們之間的真實情況——例如，"左邊i的所有內容都是非重複的，右邊j的所有內容都是未處理的"。如果你無法闡述不變數，你的迴圈會出現偏差。

2. 滑動視窗

滑動視窗是雙指標的近親。當問題要求一個具有特定性質的連續子陣列或子字串時使用它——最長不重複字元子字串、包含所有字母的最小視窗、大小為k的最大和。兩個指標都向前移動；視窗在右側擴大，當性質被違反時在左側收縮。線性時間，常數或字母表大小的空間。

診斷方法是尋找連續、子陣列或子字串這些詞。要避免的錯誤是把它當作有快捷方式的巢狀迴圈——如果你發現自己在每一步都從頭重新計算視窗的內容，說明你已經退回到O(n²)，失去了意義。

3. 樹和圖的BFS與DFS

廣度優先搜尋用於無權圖中的最短路徑、樹的層序遍歷，以及任何答案取決於距離的問題。深度優先搜尋用於連通性、拓撲排序、環檢測和大多數遞迴樹問題。兩者的時間複雜度都是圖或樹的大小的線性函式。

在面試中，選擇通常從一個關鍵詞就可以看出來。最短、最少步數或級別——那是用佇列的BFS。所有路徑、計數連通分量、我們能到達嗎——那是用遞迴或顯式堆疊的DFS。要足夠熟練，以至於可以不假思索地寫出兩種的迭代形式。

4. 堆和前k

當問題要求"最大的k個""最小的k個""流的中位數"或"合併k個排序列表"時，答案就是堆。一個大小為k的最小堆可以在O(n log k)時間內解決前k大問題。兩個堆——上半部分的最小堆和下半部分的最大堆——可以給你一個執行中位數。

這個模式對面試的價值主要在於解釋。你應該能在寫任何程式碼之前說，"我會保持一個大小為k的最小堆；我推入每個元素，當大小超過k時彈出；最後，堆包含答案。"那句話本身往往就是答案。

5. 對答案的二分查詢

普通的二分查詢——在排序陣列中找一個值——很少被問到，因為每個人都已經背下來了。有趣的變體是對答案的二分查詢：當問題具有單調謂詞時，對可能答案的範圍進行二分查詢，並在每個中點檢查可行性。

例子："將這個陣列分成k個連續的子陣列，最小化最大和""找到工人能閱讀的最少頁數，使所有書在m天內完成""最小化氣站之間的最大距離"。模式總是一樣的——定義一個關於x單調的謂詞feasible(x)，對x進行二分查詢，並返回謂詞成立的最小或最大的x。如果你能大聲說出謂詞，你就有了解決方案。

6. 動態規劃系列

動態規劃是最讓候選人害怕的模式，也是分類最清晰的模式。大多數DP問題分為五個系列之一：

• 一維狀態——爬樓梯、打家劫舍、斐波那契變體。狀態是一個索引；遞推關係取決於常數個前面的狀態。
• 二維網格——不同路徑、最小路徑和、編輯距離、最長公共子序列。狀態是一對索引。
• 背包——0/1背包、子集和、換零錢。狀態是"已考慮的專案×剩餘容量"。
• 區間DP——戳氣球、矩陣鏈乘法、迴文分割。狀態是定義範圍的一對索引。
• 樹上DP——打家劫舍III、二叉樹中的最長路徑。遞推關係是在父節點組合的子樹結果。

如果你能在前三十秒內識別出系列，遞推關係通常是機械的。陷阱是直接跳到程式碼——先在白板上寫遞推關係，然後是基本情況，然後是迭代順序，最後才是程式碼。反過來做，你會花剩下的時間修補bug。

7. 回溯

回溯是當問題要求所有解決方案時你採用的蠻力方法——所有排列、所有組合、所有子集、所有有效的數獨板、所有方式將字串分割成迴文、N皇後、單詞搜尋。結構是遞迴的：嘗試一個選擇，遞迴，撤銷選擇，嘗試下一個。

面試官要找的兩項技能是剪枝和撤銷步驟。剪枝決定了複雜度是指數級還是僅僅很大；撤銷則是正確與微妙缺陷的分界線。編碼前總要說出你的思路：「我做一個選擇，遞迴下去，然後在回溯時撤銷。」如果忘記撤銷，就會悄悄地破壞下一個分支的狀態。

8. 圖遍歷模式

除了基本的BFS和DFS，還有兩種圖模式經常出現，值得單獨介紹。拓撲排序 —— 用於課程安排類問題、涉及先決條件、截止期限和依賴關係解決。兩種實現方式是使用入度和佇列的Kahn演算法，以及基於DFS的後序遍歷。兩者都可以；選擇你最熟悉、能不假思索地寫出來的那種。

並查集（不相交集） —— 用於連通性問題、冗餘邊檢測、省份數量、帳戶合併，以及大多數「這兩個節點是否在同一連通分量中」的問題。配合路徑壓縮和按秩合併，每次操作的攤銷時間複雜度實際上是常數。記住這個八行實現；你會比想像中更頻繁地用到它。

這八種模式合起來——雙指標、滑動視窗、BFS/DFS、堆頂k個、二分搜尋答案、動態規劃家族、回溯、以及拓撲排序和並查集——涵蓋了你在每一輪編碼面試中遇到的大約百分之八十的問題。剩下的百分之二十主要是字典樹、線段樹和位操作，這些值得掌握但在一小時的面試中很少出現。

時間複雜度，準確討論：如何在白板上談論 Big-O

大多數候選人可以背誦雜湊表插入是 O(1)，歸併排序是 O(n log n)。但真正能做到面試中最重要事情的人少得多：從面前的程式碼推導複雜度，大聲說出來，毫不猶豫。

機械化程式是：

1. 識別迴圈和遞迴。 單個對輸入的迴圈是 O(n)。兩個巢狀迴圈遍歷相同輸入是 O(n²)。包含二分步驟的迴圈是 O(log n)。在每個層級進行線性工作的二分遞迴是 O(n log n)。
2. 巢狀時相乘，沿序列相加。 包含雜湊表查詢的迴圈總體是 O(n)，不是 O(n²)。迴圈後跟排序是 O(n + n log n) = O(n log n)。
3. 說出主導項。 O(n + log n) 是 O(n)。O(n² + n) 是 O(n²)。忽略低階項和常數因子。
4. 分別說明空間。 輔助記憶體是指程式碼在輸入之外分配的記憶體。遞迴佔用棧空間；雜湊表佔用 O(n) 空間；原地排序佔用 O(1) 額外空間。

大聲練習。有經驗的候選人的特徵是，他們在面試官提問前就說"這是 O(n log n) 時間和 O(n) 額外空間，由排序和輔助陣列主導"。主動說出來表示自信；被追問後才說，用防禦性語氣，表示你在猜測。

當面試官反駁時——他們經常會反駁，尤其是關於常數因子——正確的做法是回應具體的反駁，而不是重複漸近複雜度。"你說得對，這裡的常數因子很大，因為每次比較都做字串複製；如果我們預計算鍵，常數會下降大約 k 倍"是個好答案。"嗯，漸近地它仍然是 O(n log n)"是個壞答案。

即時編碼平台：面試的真實發生地

2026 年的招募人員在大約七個平台上分配編碼輪次。每個平台都有自己的怪癖；在一個平台上感覺自然的編輯器在另一個上可能很笨重。僅在你的 IDE 中練習是個錯誤——平台的怪癖會在高風險輪次中成為你的怪癖。

• LeetCode 是最大的問題庫，也是最接近面試問題通用語言的平台。編輯器對短問題還可以，對長問題不太舒適；測試執行器很快；討論帖是模式識別的低估資源。
• HackerRank 是大多數大型企業用於首次技術篩選的平台——包括金融、諮詢和傳統科技公司。語言支援廣泛，但編輯器更沉重，測試用例對輸入解析的要求更嚴格。
• Coderpad 是大多數現代軟體公司在實際面試中使用的即時協作沙箱。它支援許多語言的執行即輸入，併為系統設計討論內建繪圖工具。
• CodeSignal 執行通用編碼評估，多家大型僱主用作單一標準化分數。問題有時間限制且各式各樣；節奏控制是主要技能。
• InterviewBit 有按主題組織的精選問題軌道，方便一次專攻一個模式。編輯器比 Coderpad 更接近 LeetCode。
• HackerEarth 在印度和全球招募的公司中廣泛使用；問題質量參差不齊但平台可靠。
• Codility 是幾個歐洲公司的首選；測試套件不透明（你不總是看到哪個用例失敗），這讓它成為在沒有偵錯程式保護的情況下考量邊界情況紀律的有用代理。

在任何真實面試前，至少在兩個平台上練習。選一個用於廣度（LeetCode）和一個用於即時共用編輯器的體驗（Coderpad）。到你坐在真實輪次時，平台本身的認知成本應該接近零。

值得選擇的程式語言：何時選擇哪一種

你不需要掌握十二門程式語言來進行出色的面試。你需要一種你能思考的語言，以及對一兩種其他語言的基本閱讀理解。這是一份誠實的列表，大致按照大多數候選人應該考慮的順序。

• Python 是預設選擇。簡潔的語法、開箱即用的標準庫（collections.Counter、heapq、bisect）、無需冗餘程式碼，以及寬容的執行時環境。除非職位明確要求其他語言，否則推薦使用。
• JavaScript 和 TypeScript 適合前端和全棧職位。JavaScript 有友好的面試語法；TypeScript 增加了型別但會因為編譯器的提示而略微拖累你。只有在職位明確需要型別時才選擇 TypeScript。
• Java 是大型企業後端職位和任何面試官可能會用 Java 編寫的公司的安全選擇。冗長的語法是一種代價；型別系統能捕捉到 Python 無法捕捉的錯誤。
• C++ 是系統、基礎設施和遊戲引擎職位的正確選擇，也適合面試官期望看到迭代器和 std::priority_queue 的公司。指標運算和缺乏垃圾回收使你在時間壓力下有更多犯錯的可能。
• Go 在後端基礎設施和 DevOps 職位中越來越常見。面試中的語言訊號主要體現在併發問題上；如果你能編寫正確的 goroutine + channel 實現的生產者-消費者模式，你就證明了你理解這門語言。
• Rust 在面試中很少見但在系統密集型公司中出現越來越頻繁。borrow-checker 的摩擦是真實存在的；除非你特別練習過，否則不要為面試選擇 Rust。
• Kotlin 是 Android 和越來越多的 JVM 後端職位的正確選擇；語法比 Java 友好，標準庫更接近 Python 的。
• Ruby 在 Rails 密集型公司之外很少見；只有在職位使用它時才選擇。
• SQL 是自己的學科，出現在資料工程和分析面試中。視窗函式、公用表表達式以及 WHERE 和 HAVING 的區別是持續的差異化要點。
• PHP 仍然出現在擁有成熟 WordPress 或 Drupal 安裝的公司；除非職位明確要求，否則很少是正確的面試選擇。
• Scala 出現在資料平台公司（Spark、Akka）。函式式特性在面試答案中很強大，但前提是你已經精通。

候選人在程式語言上犯的最大錯誤是在壓力下更換語言。如果你花了六個月用 Python 練習，不要因為你認為公司"偏好"Java 就在面試的早上切換到 Java。他們偏好的是任何支援的語言編寫的正確、可工作的程式碼。使用你最熟悉的語言。

系統設計輪次：編碼準備的簡要框架

對於高階編碼迴圈，系統設計是輪次的另一半。45 分鐘的結構——澄清、評估、高層設計、深入設計、權衡——無論職位如何都是相同的，逐級期望轉變劇烈：L3 通常是物件導向設計（停車場、自動售貨機）；L4 是真實的分散式系統問題（短鏈服務、限流系統）；L5+ 是高階期望，即你主導輪次並主動指出權衡。

完整的級別階梯、五元件骨架以及推薦閱讀清單（Alex Xu 的 System Design Interview 和 Kleppmann 的 Designing Data-Intensive Applications）位於我們的軟體工程師面試指南中。對於專注於編碼的準備，將系統設計視為在模式熟練度之後的核心支柱：模式和 Big-O 是基本要求；系統設計是體現高階能力和中級能力差異的關鍵，它必須以不同的方式進行練習——通過編寫案例，而不是敲程式碼。

AI 如何改變程式設計面試準備

如今，AI 在程式設計面試準備中最實用的作用，也是最不起眼的一個——它為你提供了一個不知疲倦的程式碼審閱者，可以檢視你剛寫的解決方案、發現錯誤、將其分類到八種模式之一、並提出同一系列的後續問題。

有三個具體用法值得堅持應用：

模式識別練習。 將問題陳述貼上到模型中，在繼續閱讀之前問道："這是八種模式中的哪一種，為什麼？"將模型的答案與你自己的答案比較。解決五十個問題後，你的模式識別反應會比不經過這個元步驟而解決兩倍數量問題時更敏銳。

對自己的程式碼進行程式碼審閱。 提交後，要求模型像高階工程師在程式碼審閱中那樣批評你的程式碼。具體問："我遺漏了哪些邊界情況；變數命名是否清晰；是否有一行程式碼我在使用會使邏輯模糊；時間複雜度是否與約束條件匹配"。誠實的批評能夠克服"做得很好！"的反應。

真實面試中的即時協助。 這就是 Acedly 的用途：面試官在 Zoom 上提出問題，助手轉錄問題、識別模式、根據你的履歷草擬答題思路、並在面試官看不到的螢幕上顯示——通常在兩百毫秒以內。助手不會為你寫程式碼；它會展現正確的模式和正確的起始結構，這樣你的認知預算就可以用於鍵入解決方案而不是記住這是滑動視窗還是雙指標。

所有三種用法中的誤區都是讓模型替你思考。這些練習之所以有效，是因為你先承諾一個答案，然後檢查；程式碼審閱有效是因為你已經編寫了程式碼；即時協助有效是因為你已經練習了這些模式，只需要一個提示來觸發回憶。如果使用錯誤，AI 替代了你的大腦。如果使用正確，它將簿記外部化，所以你的大腦可以自由地做它真正擅長的部分。

AI 輔助準備與 LeetCode 刷題與模擬面試平台與教科書的對比

大多數候選人會將這四種方法混合使用。問題不是哪一個最好——而是哪一種組合符合你的弱點。以下是誠實的對比。

Feature	AI 輔助準備	LeetCode 刷題	模擬面試平台	教科書 (CLRS, EPI)
最適合	模式識別、程式碼審閱、即時協助	數量和廣度	時間壓力和口頭表述	基礎、證明和深度
獲得第一個有用訊號的時間	同一會話	約 50 個問題後	2–3 次模擬面試後	多周
發現盲點	是的，通過分類錯誤	僅通過直覺	是的，通過面試官反饋	否（被動閱讀）
培養大聲說出的技能	部分（基於文本）	弱	強	無
在陌生平台上快速打字的技能	間接	強	強	無
成本	訂閱（通常每月 < $50）	免費或 LeetCode Premium	按次費用，通常 $50–$150	書本成本、時間
風險	過度依賴、跳過打字	因機械重複而無法識別模式	教練風格差異	緩慢、容易淺嘗

大多數工作工程師最終採用的綜合方案是：通過緩慢閱讀教科書掌握基礎、在通勤和週末時間用 LeetCode 提高數量、用 AI 輔助審閱進行模式識別和錯誤發現、以及在真實面試前兩週進行少量付費模擬面試。單獨使用這些方法中的任何一個都不夠；組合才是關鍵。

一份真正有效的四周備考計劃

如果你在面試前有四周的時間，下面的計劃是一份可行的分配方案。這不是唯一的方式，但它具有正確的框架 — 首先學習模式，其次掌握平台，第三深入系統設計，最後進行模擬面試。

• 第1周 — 模式。 每天兩小時。工作日每天選擇八個模式之一。在該模式中解決五個中等難度的問題。為每個問題寫一句總結。到週末，你應該能夠從第一次閱讀就識別每個模式。
• 第2周 — 平台語言熟悉度。 停止多樣化。在 LeetCode 上解決十五個問題，在公司實際使用的平台上解決十個問題（HackerRank、Coderpad 或 CodeSignal）。訓練的技能是打字速度和編輯器熟悉度，而不是演算法。
• 第3周 — 系統設計。 每個工作日花四十五分鐘進行一個不同的設計問題。每次都使用五階段結構。錄製自己的表現；回放。前三次不理想。到第五次，這個結構開始感覺自動化。
• 第4周 — 模擬和休息。 本週前半進行兩場付費模擬面試。後半部分：休息。做一些較輕鬆的問題、系統設計複習、睡眠。不要在最後48小時內突擊；邊際收益是負的。

根據你自己的差距調整重點。如果你有八年的系統設計經驗而 LeetCode 練習有限，交換第一週和第三週。如果你早期職業生涯中有很強的電腦科學背景，加倍平台熟悉度周。不變的是休息周 — 每個候選人都低估了最後48小時睡眠的重要性。

常見問題

我真的需要解決多少個 LeetCode 問題？

編碼面試中我應該使用 Python、Java 還是 C++？

系統設計面試與編碼輪有什麼區別？

使用 AI 準備編碼面試是否被認為作弊？

我應該多早開始編碼面試準備？

我今晚能做的最有槓桿作用的單一事情是什麼？