跳至主要內容
SHAO MEDIA

一份發錯的筆試卷先被點開了:京東 0926 筆試,是一個會出錯的介面

從京東9月26日校招筆試發錯題目的事件看起,觀察一份筆試通知如何在崗位名稱、郵件措辭與撤回重發之間被設計成一個可出錯的招募介面。

科技 設計評論 約 6 分鐘
本章章節
  1. 崗位名稱,是這套介面唯一的錨點
  2. 撥不通的電話,與討論串裡的除錯
  3. 配卷這一步,是最該被看見卻最看不見的一步
  4. 一場筆試的信任,是在細節裡被核對出來的

九月二十六日,京東校招筆試開考。一位投遞後端工程師的考生點開題目,發現卷上寫的是「具身智慧與機器人開發」。他撥了京東校招的電話,沒人接。同一時間,牛客網的討論串裡,河南、安徽、浙江、黑龍江的考生陸續回報同樣的錯置:投前端開發的收到了軟體開發的卷,投後端的收到了機器人開發的卷。幾小時後,有人收到通知郵件,寫明試卷發錯、已撤回重發;也有人說第二次重發過來的卷,還是不對。

這是一則招募烏龍,但換個角度看,它也是一份介面的實錄。一場筆試從投遞、配卷、發送到開考,中間經過好幾層系統,每一層都有一個畫面:投遞紀錄頁上寫著你選的崗位,筆試通知郵件裡寫著另一個崗位,考試系統裡又裝著一份題庫。當三者對不起來時,考生第一時間能做的,對照郵件與投遞紀錄、打電話、上牛客發帖,本身就是一套沒被設計好的除錯流程。

崗位名稱,是這套介面唯一的錨點

先從最小的細節看起。考生怎麼知道自己被發錯了卷?靠的是崗位名稱這幾個字。「後端工程師」與「具身智慧與機器人開發」之間的落差,任何非技術背景的人都能一眼讀出。這說明在整場筆試的介面裡,崗位名稱承擔了幾乎全部的核對功能。

系統設計上有個常見的對照:銀行轉帳時,帳號與戶名會被要求同時顯示、相互印證;掛號看診時,姓名與科別並列印在單據上。招募筆試的通知郵件通常只做到了前者的一半,告訴你考試時間與入口,崗位資訊往往只是一行附註,甚至省略。考生對「我考的是哪個崗位的卷」這件事,沒有第二個可交叉比對的欄位。錯配因此可以在系統內部安靜地流動,直到開考那一刻,才被考生的眼睛攔下。

牛客網這則討論串裡的措辭也值得看。考生用的是「不匹配」「發錯了」「掛羊頭賣狗肉」這些詞。前三個描述系統失誤,最後一個描述蓄意錯置。同一個畫面,使用者讀出的意圖完全不同,而介面沒有提供任何東西讓人判斷該讀成哪一種。通知郵件裡那句「已撤回重發」,是事件中唯一一段官方措辭,短、被動、不解釋原因。相較於產品圈常見的錯誤訊息設計規範,說清楚發生了什麼、影響誰、下一步做什麼,這句話什麼都沒說,只完成了一個動作聲明。

而第二次重發仍然不對的那則回報,是整個事件裡最耐人尋味的一筆。它說明錯配可能發生在配卷的源頭,那個把投遞崗位對應到題庫的映射表,而不只是某一次發送的失誤。重發只是把同一份錯誤再執行一次。一個會重複出錯的流程,通常表示錯誤不在流程的末端,而在流程的定義裡。

撥不通的電話,與討論串裡的除錯

那位考生說,給京東校招打電話一直沒人接。這個細節比試卷發錯本身更值得注意。大型校招的筆試日,本來就是異常狀況的尖峯時刻:連結失效、系統當機、卷別錯發,都是可預期的事件。一個把幾十萬份試卷在同一天配送到幾十萬個帳號的系統,卻沒有為這一天配置對應容量的查詢通道,這是資源配置的問題,也是設計優先序的問題。

於是除錯的工作被推給了使用者。牛客網的討論串變成了臨時的狀態面板:湖北的考生在等,黑龍江的考生收到了重發郵件,河南與安徽的考生確認「我也是」。眾人靠著回報地區與崗位,拼湊出這次錯發的範圍。這種自發的眾包核對,其實是使用者替系統補上了一個它該有的功能:一個顯示異常範圍與處理進度的公告頁。

這與我們先前觀察過的秋招面試體感評比長帖有相似的結構。當官方通道不給資訊時,考生社羣會自己生成一個介面,用措辭、排序與回報來填充系統的沉默。招募流程的設計者往往低估了這件事:使用者在流程裡失去的掌控感,一定會在某個地方被找回來,只是那個地方不在品牌的掌控之內。

配卷這一步,是最該被看見卻最看不見的一步

把整場校招筆試拆開來看:投遞頁是精心設計的,崗位描述、薪資範圍、工作地點,排版清楚;筆試系統本身也是,計時器、題目切換、程式題的程式碼編輯器,都是產品級的介面。唯獨投遞完成到試卷送達之間那一段,對使用者完全不可見。崗位如何映射到題庫、題庫有幾套、配對由誰核驗,這些都發生在幕後。

發錯卷的事件把這個盲區戳了一個洞。考生第一次有機會意識到,原來自己收到的試卷是被某個映射規則決定的,而那個規則是會錯的。更具體地說,這次錯配的方向頗有意味:投傳統後端、前端的考生,收到了具身智慧與機器人開發的卷。具身智慧是這兩年最熱的招聘方向之一,題庫很可能因此被新建或改動過。新建的題庫遇上老資料結構裡的崗位分類,映射出錯的機率自然上升。這當然只是合理推測,但它指向一個常見的工程現實:介面看得見的部分常被反覆打磨,看不見的資料對應關係卻往往只在出事時才被檢查。

從更廣的脈絡看,這場筆試本身也帶著今年的行業印記。同一時期的牛客討論區裡,演算法崗的考生抱怨投了一百多家大半倒在篩選,Agent 開發崗的面經佔據熱榜多個位置,考生複習的重點從資料結構轉向圖譜抽取與向量庫選型。題庫的方向在變,崗位的分類在變,而承載這些變化的匹配系統,顯然沒有跟上同樣的更新速度。這也解釋了為什麼錯發的是具身智慧的卷:它是最新的那一塊拼圖,邊緣還沒磨平。

一場筆試的信任,是在細節裡被核對出來的

最後回到那位考生的處境。他做對了所有能做的事:核對崗位名稱、打電話、發帖求證。但這些行為之所以必要,是因為系統沒有替他做。一次撤回重發可以修正試卷,卻修不了第二次重發仍然不對的那種感受。考生對一場筆試的信任,建立在幾個很小的確認點上:郵件裡的崗位和我投的一樣、卷上的題目和我準備的方向一樣、出了問題有人接電話。這三個確認點,這次事件裡一個都不穩。

招募是一個品牌把「我們是誰」傳遞給未來同事的過程,筆試是這個過程裡接觸面最大的一次。校招簡報可以做得漂亮,僱主品牌影片可以拍得動人,但一份發錯的試卷、一通沒人接的電話,會比所有行銷素材都更誠實地告訴考生這家公司如何對待流程裡的人。京東這次的修正動作不算慢,幾小時內撤回重發。真正的功課不在於修正得快,而在於讓崗位名稱、試卷與考生預期,在一開始就被設計成會相互核對的東西。看得到的介面都已經很好了,剩下的,是那些一直沒被看見的部分。

主題 介面與互動設計

標籤 #京東校招筆試設計、#招募流程介面、#郵件通知設計

相關報導