一份被逐字抄下來的面試，先於結果被讀完了：失敗的9月，是一頁排好版的篩選介面

先從一個小細節看起。牛客網上，一位求職者以「失敗的9月和失敗的我」為題發文，附上一場測試開發實習生面試的逐字稿。稿子從一句「Hello」開始，接著是編了號的十九條提問，從「向量資料庫和 RAG 它倆的區別是啥呀」一路問到「解釋一下正弦和餘弦的差異」，最後停在面試官主動接過話頭、花了一大段解釋測開崗位職責的自白。整份稿子的時間點落在 9 月 24 日下午一點，原本排在 9 月 23 日，面試開始前十五分鐘被改期。

這份逐字稿值得看的，首先是它的「排版」。發文者把口語原封不動抄了下來：語氣詞、重複、跑偏的句子都留著。於是讀者看到的不是一份潔淨的題目清單，而是一場正在進行的對話的原始質地。面試官的每個問題裡幾乎都墊著「它倆」「對吧」「就是」，這些冗詞在正式的職缺說明裡會被刪乾淨，在逐字稿裡卻成了主要的閱讀材料。一場面試的真實介面，原來是這個樣子：鬆散、迂迴、問題與問題之間靠追問銜接，而不靠任何目錄。

提問的排序本身有結構可讀。前十題集中打「向量資料庫與 RAG」這一個技術區塊，從概念區別、與 MySQL 的優劣比較、索引原理，一路追到「向量怎麼理解」和正弦餘弦的數學基礎。第十一題忽然切到「用 Python 寫過什麼腳本」，第十二題之後整個轉向專案盤問：背景是什麼、解決什麼問題、整體架構、最終效果，四層追問一層壓一層。這種排法與我們先前觀察過的恆生電子筆試的篩選介面有相似的邏輯：題目不是隨機出現的，它們被安排成一個由淺入深、由名詞轉向個人經歷的漏鬥。差別在於筆試的漏鬥寫在系統裡，面試的漏鬥只存在於口頭，直到有人把它逐字抄下來，這個結構才第一次變得可見。

最有意思的段落是第十八題。求職者問「我的不足在哪裡」，面試官沒有回答，而是說「你問我這個問題，還不如我給你講講」，接著用比任何一道題都長的篇幅，解釋測開做什麼、測試案例是什麼、為什麼要懂 Redis 和 MQ。這段講解在稿子裡佔了將近三分之一的篇幅，而且語氣近乎授課。發文者在段落末尾用括號補了一句內心話：「這些我都知道啊，你又不問」。一句括號，把整場面試的錯位點了出來：雙方各自在講自己以為對方需要的內容。若把面試看作一個介面，這裡出現的是典型的回饋失效，使用者請求的是診斷，系統回傳的是說明書。

結果的部分，發文者寫得節制：九月面了三次騰訊、一次百度、一次快手、一次字節、一次傳音，「基本全部掛了」。傳音那關過了，但他不想去重慶，理由包括「有點偏」與「才 120 一天」。這一段的資訊密度反而最高，因為它把「失敗」拆成了兩種：一種是沒被選上，一種是被選上了但條件不值得去。逐字稿裡那場聊得不算差的對話，最終歸入前一種。發文者自己給不出解釋，只留下一句「也不知道為什麼都掛了」。

留言區提供了一個旁觀的讀法。有人指出題目高頻，「問的題怎麼和我以前的一次這麼像」；也有人注意到追問最密的是第二個專案，建議把背景、設計、效果壓成兩分鐘，再單獨準備「我負責哪段、怎麼驗證有效」。這條留言實際上在做的事，是把逐字稿當成一份可分析的文件，從提問密度反推篩選標準。它比發文者的自我歸因（「我真是一個 loser」）更貼近那場面試的結構：掛掉的原因未必在名詞答得全不全，而在專案敘事有沒有被組織成可追問的層次。

一份逐字抄寫的面試紀錄，價值正在於它沒有被修飾。它讓人看見篩選現場的原始介面：口語的、重複的、回饋錯位的。而當這份紀錄被放上牛客網，配上「失敗的9月」這個標題，它又多了一層設計：標題先把結論定調為失敗，正文卻讓讀者看見一場不算失敗的對話。這中間的落差，或許比任何一句「再沉澱一下」都更誠實。