上個月剛走完 Lyft Software Engineer Intern / New Grad 的全部流程，最終拿到了 Offer。整個過程大概花了 5 周左右，總體感覺是： Lyft SDE 面試比較務實，不像某些公司那麼卷演算法，但對工程能力和系統思維要求挺高。
下面把我經歷的 OA 和 VO 兩部分完整分享給大家。
Lyft OA
平臺：HackerRank
時間：75 分鐘
題量：2 道 Coding 題
第一題是 Easy-Medium 難度，考字串處理和規則模擬，大概 15 分鐘就寫完了。
第二題是 Medium，是一道圖 + 貪心題，類似「司機和乘客的匹配問題」，需要考慮距離和等待時間。我當時用 BFS + 優先佇列做的，後面花了 35 分鐘左右才調通所有 case。
小Tips：Lyft 的 OA 時間還算友好，但第二題的建模比較重要。如果思路不對很容易卡住，建議先把樣例手動模擬幾遍再動手寫程式碼。
VO —— 共 4 輪，每輪 1 小時
第 1 輪：HM + Behavioral 輪
HM 先簡單介紹了組內正在做的業務方向（主要是 Lyft 的目的地推薦相關）。 之後大部分時間都在深挖我的簡歷，穿插了不少經典 BQ 問題，例如：
- 你和同事產生過 conflict 是怎麼處理的？
- 過往專案中遇到過的最大困難是什麼？是怎麼解決的？
這一輪主要看性格和文化匹配度，沒有特別難的問題。
第 2 輪：上機 Coding 輪
（具體是 Medium 難度的一道陣列 + 雜湊題）。 面試我的是一位國人面試官，人超級 nice，全程溝通順暢。他會先讓我把思路講清楚，確認沒問題後再開始寫程式碼，寫完還會一起 review 時間複雜度和邊界情況。
第 3 輪：ML System Infra 輪
面試官是一位 Senior Staff MLE，問題非常貼近 Lyft 真實業務： “在使用 Lyft App 時，如何給使用者推薦目的地（Destination Recommendation）？”
他全程非常友好，會不斷引導我往正確的方向思考。我們從資料採集、特徵工程、模型選擇、離線訓練、線上 serving、到 AB 測試和監控都聊了一遍。
第 4 輪：ML System Design 輪
和上一輪考察的是同一個核心問題——Destination Recommendation System。 這一輪更偏系統設計，重點討論了：
- 多模型並行訓練與 serving
- 實時特徵更新
- 大規模使用者冷啟動問題
- 系統可擴充套件性和容錯機制
Lyft 獨家真題分享
Rotting Oranges
這是面試最常考的中等題，核心考察廣度優先搜尋（BFS），因為腐爛是逐層擴散的，完美匹配 BFS 的層序遍歷特性。
題目
給你一個 m x n 的網格，每個格子有三種值：
- 0：空單元格
- 1：新鮮橘子
- 2：腐爛橘子
每分鐘，上下左右四個方向相鄰的新鮮橘子都會被腐爛。
返回讓所有橘子腐爛的最少分鐘數；如果無法讓所有橘子腐爛，返回 -1。
示例說明
- 輸入：
[[2,1,1],[1,1,0],[0,1,1]]→ 輸出：4 - 輸入：
[[2,1,1],[0,1,1],[1,0,1]]→ 輸出：-1（左下角橘子永遠爛不了） - 輸入：
[[0,2]]→ 輸出：0（沒有新鮮橘子）
解題步驟
- 初始化佇列：遍歷網格，把所有初始腐爛橘子加入佇列，同時統計新鮮橘子總數。
- 邊界判斷：如果沒有新鮮橘子，直接返回 0。
- BFS 擴散腐爛：
- 按層遍歷（每一層 = 1 分鐘）
- 每次取出當前層所有腐爛橘子，向四個方向擴散
- 遇到新鮮橘子就標記為腐爛，新鮮橘子數量 – 1，加入下一層佇列
- 結果判斷：遍歷結束後，如果新鮮橘子數 = 0 → 返回時間；否則返回 – 1。
Read N Characters Given read4 II – Call Multiple Times
這是一道硬核困難題，也是面試高頻設計題，核心難點在於：read 函式會被多次呼叫，必須儲存上一次讀取剩下的字元。
題目
你有一個 API 函式 read4(buf)：
- 作用：從檔案中最多讀取 4 個字元，存入
buf陣列 - 返回值：實際讀取到的字元數（檔案讀完了會返回 0）
要求：利用 read4 實現 read(buf, n) 函式：
- 功能：從檔案中精確讀取 n 個字元
- 關鍵：read 函式可能被呼叫多次！（必須記住上一次沒讀完的剩餘字元）
返回值：實際成功讀取的字元總數（讀完檔案了就返回剩餘長度）
解題思路
必須用 3 個「成員變數」儲存狀態（多次呼叫的關鍵）
- 快取陣列 buffer：存 read4 一次性讀出來的 4 個字元
- 快取指標 bufferPtr：指向快取中下一個要讀取的位置
- 快取長度 bufferCount：快取中實際有效的字元數
執行邏輯
- 先吃快取：如果上一次還有剩餘字元，優先用快取
- 再讀新的：快取用完了，才呼叫 read4 讀新的 4 個字元
- 邊讀邊存：把字元複製到目標 buf，直到讀夠 n 個 或 檔案讀完
- 留狀態：剩下的字元存在快取裡，給下一次呼叫使用
備考建議
如果你也在準備 Lyft MLE 2026（Intern / New Grad / 社招），歡迎留言或私信交流：
- 想看 K-Means 手寫程式碼或推薦系統設計筆記？
- 需要 ML System Design 的詳細框架？
- 想了解 Behavioral 的高頻問題準備方法？
另外，如果你時間緊張或想系統性準備，推薦 Programhelp 的專業助攻服務。他們提供 OA 代寫、VO 實時思路輔助 、全流程包過等支援，很多同學都是透過他們的幫助順利拿下 Lyft Offer。
祝大家 Lyft 面試順利，早日拿到心儀 Offer！
