![]()
6362人上周在這道題上栽了跟頭。不是題目變難了,是很多人還沒意識到:矩陣遍歷的考法,已經從"會不會寫"進化到了"能不能一次寫對"。
LeetCode 54題「螺旋矩陣」自2016年上線,至今仍是Google、Meta、字節跳動的面試常客。一道看似簡單的數組題,平均通過率卻只有47.3%——比多數中等難度題目還低。
為什么面試官偏愛這道題
「螺旋矩陣」的陷阱不在算法復雜度,而在邊界條件的處理。候選人往往在白板上寫得飛快,卻在單行列矩陣、奇偶維度切換時翻車。
Google前工程師Vansh在解題筆記里打了個比方:這就像剝洋蔥,每一層剝完都要確認里面還有沒有芯。很多人剝到最后一層,要么多剝一次空氣,要么把芯落在里面。
題目要求很明確:給定m x n的矩陣,按順時針螺旋順序返回所有元素。輸入[[1,2,3],[4,5,6],[7,8,9]],輸出必須是[1,2,3,6,9,8,7,4,5]——順序錯一個,測試用例全掛。
2019年字節跳動秋招,這道題出現在3輪技術面中的2輪。一位拿到SSP的候選人事后復盤:「面試官看的不是你知不知道四個方向,而是你在寫完循環后,有沒有立刻收縮邊界。」
四個指針的生死線
![]()
標準解法的核心是用四個變量框住當前未遍歷的區域:startingRow(起始行)、endingRow(結束行)、startingCol(起始列)、endingCol(結束列)。
遍歷順序固定為四步:從左到右掃頂行,從上到下掃右列,從右到左掃底行,從下到上掃左列。每掃完一邊,對應的邊界向內收縮1。
真正的坑出現在第三步之后。當你掃完底行、準備向上掃左列時,必須檢查count是否已等于總元素數。對于3x3矩陣,掃完底行剛好結束;但對于3x4矩陣,此時還剩一列要處理。
Vansh在代碼注釋里標紅了這一點:「Crucial check: Always check if (count < total_elements) before starting the next phase」。這個if判斷漏掉,單行列測試用例必掛。
2023年LeetCode官方統計,54題的錯誤提交中,31%死于邊界收縮順序錯誤,24%死于漏掉count檢查,19%死于方向順序搞混。算法本身沒錯,錯在工程細節的完備性。
從面試題到生產代碼
這道題的現實映射很直接:圖像處理中的像素遍歷、游戲地圖的層疊渲染、Excel表格的選中區域計算,底層都是類似的邊界收縮邏輯。
Meta一位工程師透露,他們內部有個代碼規范叫"spiral discipline"——任何涉及多維數組遍歷的函數,必須顯式聲明邊界變量,禁止用i++硬編碼。這個規范的源頭,就是早年太多人在類似邏輯上踩坑。
![]()
國內某頭部云廠商2024年的校招面經顯示,這道題開始出現變種:要求原地修改矩陣而非返回新數組,或者要求逆時針螺旋。核心解法不變,但候選人需要5秒內反應過來如何調整方向順序。
一位面過6家大廠的算法競賽選手總結:「螺旋矩陣是面試官的試金石。他們能通過你寫代碼時的停頓位置,判斷你是背過答案還是真正理解。」
8年未變的考點,變了什么
2016年到2024年,這道題的難度標簽始終維持"中等"。但通過率從61%掉到47%,不是因為題目變了,是面試官的評判標準變了。
早期能寫出四層循環就算通過。現在,面試官會追問:空間復雜度能不能優化?能不能用遞歸改寫?如果矩陣是稀疏存儲怎么辦?
2024年3月,LeetCode社區有人發帖統計:用Python寫出最優解(時間O(mn)、空間O(1))的平均用時是12分鐘,但加上邊界檢查、異常處理、代碼注釋,能拖到25分鐘。而面試通常只給20分鐘。
Vansh的解題模板在GitHub收獲了2.3k星。他的代碼結構很直白:先算總數,再設四邊界,然后while循環套四個for循環,每個for循環后緊跟邊界收縮。沒有技巧,全是紀律。
一位拿到Google L4的讀者在評論區反饋:「面這道題時,我主動講了單行列的特殊處理,面試官直接跳過后續追問,開始聊項目。」
這道題還能考多久?LeetCode 2024年Q1的面試題庫報告顯示,54題的出現頻率仍排在前15%。它的價值不在于難度,而在于用最短的代碼量,暴露候選人的工程習慣。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.