面試官問了一整串歌曲 ID，而你家廚房只是在燉一鍋湯

十月十三日，一位求職者在牛客網分享了網易雲音樂全棧一面的面經。題目從語言選擇聊到專案，聊到意圖識別會不會出錯，聊到百萬級歌曲 ID 要怎麼判斷標籤，再一路問到 JVM、垃圾回收器、HashMap 的結構。整份紀錄讀下來，像一份很長的備料清單。

你大概也有過這種經驗。晚上想燉一鍋湯，先把排骨焯水，撇掉浮沫，再下薑片、蔥段，轉小火，蓋上鍋蓋。看起來簡單，但每一個步驟被追問下去，都有得講：水要冷水下鍋還是滾水，沫子要不要撈乾淨，火轉多小才算小。面試官的連環提問，其實就是這樣，他們不滿足於「我會燉湯」，他們想知道你懂不懂那鍋湯為什麼是這個味道。

意圖識別，跟聞味道一樣，不會每次都準

面經裡有一題很有味道：意圖識別，它識別的一定準確嗎？還有，有沒有使用者一次想問兩個意圖的情況？

這像極了你在廚房聞鍋裡的氣味。多半時候你聞得出是醬油燒焦了還是糖色過頭，但也有模稜兩可的時候，聞起來像豆瓣醬，又像味噌。會做菜的人不會只靠鼻子，還會看顏色、嚐一口、翻一下鍋底。系統判斷使用者的意圖也是同樣的道理，單一訊號不準，就得多驗幾層。使用者一次問兩件事，就像一鍋裡同時燉了兩種肉，你得想辦法分開處理，否則味道全糊在一起。

面經裡還被問到，使用者點了不滿意，後續會有什麼措施。這在餐桌上叫回頭客的功課。一道菜被嫌太鹹，好的廚房會記下來，下一桌少放半匙鹽。這種事不能靠感覺，得有人記錄、有人調整，正如我們先前寫過的機器替你守著爐火的故事，等待與修正，從來都是廚房裡最日常的功夫。

百萬首歌，跟市場裡那攤揀不完的菜

最扎實的一段，是那道百萬級歌曲 ID 的設計題：判斷傳入的歌曲是否存在某標籤，存在才走後續流程，而且要「判斷一定存在」。緊接著還有追問：指定版權方下幾百萬條歌曲，每次只能查一千條，怎麼遍歷全部資料？該拿哪個欄位當遊標？

換到市場裡，這就是一攤揀不完的菜。幾百萬根豆角躺在那裡，你不可能一次抱回家，只能一捆一捆挑。挑的時候得有個排序的依據，不能這把看完又隨手抓下一把，否則同一把豆角可能被你看三遍，有的卻永遠漏掉。遊標欄位的選擇，就是你決定按什麼順序走完這一整攤：按編號、按長度、按進貨時間，順序定了，一趟下來每根都被翻過，且只翻過一次。

「判斷一定存在」這五個字，廚房裡也懂。你說這鍋湯一定放了鹽，最好是你親手放的，而且嚐過。大概是存在，跟一定存在，中間隔著的就是試喫那一口。

基礎題，是那鍋燉了很久的高湯

面試的後半段全是基礎：JVM、雙親委派模型能不能被打破、HashMap 一點七和一點八的差別、垃圾回收器知道哪些。

基礎題最像高湯。表面上是一鍋清清的水，喝起來才知道有沒有東西。雞骨、豬骨、乾貨，小火燉上大半天，湯色清、味道厚，什麼菜都能拿它來吊味。垃圾回收這種題目尤其如此，聽起來離做菜很遠，其實就是廚房裡的收拾：哪些東西還要用、哪些已經沒人記得，什麼時候清、怎麼清才不耽誤下一道菜。這種功夫沒有戲劇性，卻決定了廚房能不能一直開下去，也像另一場面試裡被問了五十三分鐘的基礎功夫，每天都在複習，只是你自己沒發現。

最後一題倒是輕鬆：你平時怎麼用 AI 輔助工作。這就像問你買不買現成的高湯塊。用了，省時間；但真正的好湯，還是得知道從骨頭開始怎麼燉。

面經貼出來後，留言區有人在問面了多久、是秋招還是日常實習，也有人感嘆 Python 的題庫似乎不如 Java 齊全。這些追問與感嘆，跟飯後收拾碗盤時的閒聊很像。一場面試結束了，無論結果如何，廚房的燈還亮著，明天還要開火。湯燉過了，味道記住了，下一鍋會更穩。