一份 SQL 先被排上了卷面：恆生電子的筆試，是一套被設計過的篩選介面

先從一個小細節看起。九月二十三日晚上，牛客網上出現一篇標題只有六個字的帖子：「恆生電子，涼涼」。發文時間是 21 點出頭，地區顯示河南。這個時間點本身就值得留意：多數公司的線上筆試安排在晚間七點到九點，考生交卷後的情緒，會在接下來的一小時內湧向討論區。一場筆試結束的瞬間，考卷的設計好壞，第一次有了公開的回饋版面。

這篇帖子後面跟著二十幾則回覆，來自黑龍江、貴州、山東、四川、江蘇、廣東、重慶、陝西、湖北各地的考生。把他們的抱怨排在一起看，會發現抱怨的內容高度集中：一份卷子裡，單選、不定選、填空之外，三道編程題的第一道是 SQL，第二道是滑動窗口，第三道是帶半價條件的 01 背包。真正把考生擊潰的，多數人指的都是那道 SQL。

這裡要談的不是題目難度本身，而是這份考卷作為一套介面的設計。一家金融科技公司把 SQL 放在編程題第一位，把演算法放在後面，這個排序本身就是一則自我介紹：我們要的人，先得會查資料庫。但排序之外，這場筆試真正暴露的設計問題，藏在更細的地方。

通過率是一種即時的視覺回饋

考生留言裡最耐人尋味的一句是：「第三題我同樣的代碼，一直提交，然後通過率就一直在 80 和 40 之間跳」。另一個人說最後一題「怎麼改通過率都是 90.91」，還有人卡在 68%。

這些數字是線上測評系統最核心的介面元素。考生按下提交，系統回傳一個百分比，這個百分比決定了考生接下來的行為：改哪裡、重交幾次、還是直接放棄。問題在於，這個回饋的粒度太粗了。同一段代碼得到飄忽不定的通過率，多半是測試用例裡有隨機資料或者評測機負載造成的時間波動，但介面上只顯示一個裸數字，不顯示原因。考生面對的是一個不穩定的儀表，卻被要求根據它做出穩定的判斷。

有位湖北考生寫得更具體：「java卡常這塊，隨機數交了幾十次才過」。交了幾十次，表示這個介面的重試成本被設計得極低，低到鼓勵考生用擲骰子的方式通過評測。當通過可以靠運氣疊出來，這個數字作為篩選依據的效度就打了折扣。這是很多競賽式測評平臺的通病，只是在一場正式的校招筆試裡，它被放大成了考生之間最直接的共同經歷。

一道被設計過的背包題

第三題的討論串是整個帖子裡技術含量最高的部分，也是觀察題目設計最好的樣本。題目本身是 01 背包的變形：每件商品可以選原價，也可以使用一次半價優惠。一位廣東考生在回覆裡給出了清晰的解法描述：維護兩個背包陣列，一個登記還沒用過半價的狀態，另一個登記已經用過半價的狀態，每件商品有條件地從第一個陣列轉移到第二個。

這段回覆寫得比很多教科書清楚。一位湖北考生甚至直接貼出了用兩個 bitset 做位運算壓縮的寫法，一行轉移式裡同時包含原價與半價兩種位移。對照之下，發帖人自己說「被 sql 打崩了」，第三題只在腦中想了半天而沒有寫完。

同一道題，在不同考生手上展開成完全不同的畫面。這正好說明一道好的變形題的價值：它不改變基礎框架（背包還是背包），只加一個狀態維度（半價用過沒有），就能把背模板的人和真正理解狀態轉移的人分開。從出題的角度看，這道題是整份卷子裡設計得最扎實的一件作品。相比之下，那道讓多數人直接跳過的 SQL，篩選的方式粗暴得多：會就是會，不會連部分分都很難摸到。有人提到「測試用例一直說 score 是 0」，連除錯的線索都被切斷了。

這種篩選介面的措辭與回饋方式，決定了考生體驗的下限。口音可以在面試回覆裡成為一種篩選條件，SQL 也可以在筆試系統裡成為一堵沒有門把的牆，兩者的共同點是，被篩掉的人得不到任何關於自己為何被篩掉的資訊。可以參考我們先前寫過的一句口音太重先被寫進了面試的回覆裡的分析，篩選機制的設計品質，往往體現在它如何對待落選者。

一份卷子，多種崗位

山東一位考生的留言點出了另一個結構問題：「本來想著代碼不行還能看看 SQL，結果這麼難，為啥測試開發一個卷子啊」。

這句話背後是一個常見的設計決策：公司為了評測效率，讓不同崗位共用同一份筆試卷。從主辦方角度看，一份卷子覆蓋單選、不定選、填空、SQL、演算法，理論上能量測多種能力；但從考生角度看，這份卷子的資訊架構沒有對齊他的身分。一個應聘測試開發的人，拿到的是一份演算法競賽式的卷面，他的真實工作內容與卷面內容之間的落差，沒有任何介面元素來緩衝。

北京考生說「選擇題一題都不會」，黑龍江考生在最後一題的 90.91% 前停手。這些斷裂的體驗都指向同一件事：卷面的題型編排假設了一種理想考生，這種考生資料庫熟、演算法熟、連位運算優化都熟。現實裡這種人很少，於是整份考卷的實際功能從「測量能力」滑向「製造挫敗」，而挫敗感又即時轉化為討論區上的公開抱怨。

篩選的設計，最終會被討論區評分

回到開頭那六個字。「涼涼」是考生對這場筆試的總評分，它出現的時間距離交卷不到一小時。在這一小時裡，一份考卷經歷了完整的使用者測試：三種題型的排序是否合理、通過率回饋是否穩定、SQL 的難度是否匹配崗位、變形題的區分度是否足夠，每個設計決策都被二十幾位匿名使用者用回覆評了分。

其中評分最高的是那道背包題，考生們自發地在回覆區交換解法、貼代碼、討論複雜度，一個失敗的筆試現場長出了一個小型的技術討論串。評分最低的是 SQL 題和那個飄忽的通過率，前者被形容為「太變態」，後者讓人交了幾十次。

一場筆試的設計水準，最終不在於它篩掉多少人，而在於被篩掉的人事後如何描述這個過程。恆生電子這份卷子裡，一道好的變形題證明了出題人有能力做出有層次的篩選，但一道無回饋的 SQL 和一個不穩定的評測介面，把這份能力蓋住了。留下的公開印象就是那兩個字。對一家以金融軟體為業的公司來說，這個結果本身，就是一份值得讀的使用者報告。