最近剛結束 Apple Frontend Engineer 的一輪技術面，這一輪主要圍繞 Coding + Behavioral 展開，沒有出現 System Design，但不代表 Apple 不考——很多候選人是在後續輪次才遇到，所以準備時千萬別放鬆。下面直接覆盤核心內容，給正在準備 Apple 面試的同學一點參考。
Coding 面試題回顧
這一輪只有一道核心演算法題，但限制條件非常關鍵。
題目大意是：給定一個大約 75 個元素的整數陣列，需要對陣列進行去重，並對結果進行排序。其中去重的要求是，如果某個元素在陣列中重複出現，需要將重複值進行 zero out 處理（比如置為 0 或標記移除）。同時明確規定，不能使用任何原生排序函式，包括 sort、quicksort 等。
乍一看 N 很小，隨便寫個氣泡排序也能過，但面試官一開始就強調，這道題不能只考慮“能不能跑”，而是要從複雜度角度給出合理解法。
解題整體思路
我在面試中是把問題拆成兩個階段來思考：先處理去重，再處理排序。面試官對這種拆解方式是認可的，也會順著你的思路繼續追問。
在去重階段，比較直接的做法是使用一個 Hash Set 來記錄已經出現過的元素。遍歷陣列時，如果當前元素已經在 Set 中出現過，就對該位置進行 zero out 處理；如果沒有出現過，就把該元素加入 Set。這樣一遍掃描就能完成去重，時間複雜度是 O(N)，邏輯也非常清晰。
面試官在這一階段會比較在意兩個點：第一，zero out 的定義是否會影響後續排序；第二，0 本身是否可能是合法資料。如果你能主動提到這些邊界情況，並說明你的處理方式，會明顯加分。完成去重之後，接下來就是排序問題。由於禁止使用原生排序函式，本質上是在考你是否真正理解排序演算法，而不是隻會調庫。
我當時選擇的是手寫歸併排序。原因也很簡單：時間複雜度穩定在 O(N log N)，實現邏輯清楚，在面試場景下不容易出邊界 bug。面試官也會比較容易跟著你的遞迴邏輯走，而不是在細節上反覆打斷。
隱藏加分點
在排序階段，面試官有追問一句：“如果我告訴你，陣列裡的數字範圍很小，比如 0 到 100，你會怎麼最佳化？”
這是一個非常典型的 Apple 風格追問。
在這種前提下，其實可以直接使用計數排序。透過一個固定大小的計數陣列統計每個數出現的次數，再按順序回填結果，整體時間複雜度可以做到 O(N)。如果你能意識到這是一個可以利用資料分佈特徵進行最佳化的場景，面試官一般會給出非常正面的反饋。
這一點本質上考的不是你背了多少演算法，而是你有沒有根據“輸入特徵”調整解法的能力。
Behavioral 面試回顧
這一輪的 BQ 屬於 Apple 非常常見、但並不容易答好的型別。重點問題是 Most Proud Project，也就是讓你講一個自己最自豪的專案經歷。
面試官真正想考察的並不是專案本身有多複雜，而是你是否對自己做過的事情有清晰認知，是否真正理解這個專案的價值。回答時一定要注意，不要一直用“我們團隊做了什麼”，而是要突出“我具體做了什麼”。尤其是在技術選型、關鍵決策、效能最佳化或問題解決上的個人貢獻。
我個人非常推薦用 STAR 原則來組織語言，但不要生硬套模板。重點是把 Result 講清楚，最好能用資料量化結果，比如效能提升比例、錯誤率下降幅度、使用者體驗改進效果等。
一點補充說明
我們這邊平時整理了不少真實 Apple、Meta、Google 等一線大廠的面試題和追問套路，包括類似這種看起來簡單但很吃基本功的 coding 題。想提前掌握高頻題型、梳理答題框架，或者在實戰中需要 面試輔助 都可以來聯絡我們。如果你是那種題型大致會、但容易在面試壓力下失誤的情況，可以多給自己留一層保險。準備得越充分，現場發揮就越穩定，這一點在 Apple 面試裡尤其明顯。
