37signals 拒絕以解謎為主的程式設計師招聘，改以實際試用衡量人選

2013 年 2 月，37signals 在公司部落格發表〈Why we don't hire programmers based on puzzles and tricks〉，該文同日登上 Hacker News。討論從瑣事導向招聘的失敗案例談起：一名微軟面試者曾依《How Would You Move Mount Fuji?》準備，卻被要求憑記憶寫出 C 的 strcmp()；Amazon 的面試偏重背誦 Big-O 與「數遍宇宙中所有星星」；面試官往往只是搜尋「programming interview questions」，卻不問這些答案能證明什麼。

37signals 的反制之道是直接否定這類做法：不以解謎和花招招聘。留言者把替代方案形容為「trying them out for size」——讓應徵者面對實際工作，而非人工設計的腦筋急轉彎。實務工作者以具體機制推動同一方向：ITA Software 發現，相較於閱讀某人離線寫的程式碼，當面問答的用處小得多；一位招聘經理則把面試設計成一天的結對工作，問三個問題——這個人能不能勝任工作、能不能融入團隊，以及遊戲規則改變時能不能適應？

這兩種篩選測試的東西不同。瑣事與腦筋急轉彎是可以準備的——市面上存在一整套路數的預期問題與準備書籍——它們篩選的是記憶力與人工壓力下的鎮定。留言者指出，洞察型思考者可能在一小時的程序性問答中失利，卻能在較長時間的實際任務中表現良好；而一名正處於恐慌發作中的應徵者可能過不了 FizzBuzz，卻仍是優秀的程式設計師。觀察實際工作能回答瑣事無法回答的問題：這個人如何閱讀不熟悉的程式碼庫、如何發現錯誤、如何寫程式，以及如何與陌生人合作。

捨棄解謎關卡：讓應徵者實際試用，由實際工作而非記憶力決定錄取

解謎篩選是可以準備的：一整套路數的預期問題與準備書籍讓應徵者得以演練，因此這項測試衡量的是準備程度與記憶力，而非工作能力。

讓應徵者實際試用能觀察真正的工作——閱讀真實的程式碼庫、發現錯誤、寫程式與協作——這是任何腦筋急轉彎都產生不了的證據。

人工壓力會扭曲結果：洞察型與焦慮型的應徵者可能過不了一小時的解謎，卻能在較長時間的實際工作中表現良好。

公開表態傳達了公司重視什麼，並開啟一場 442 則留言的辯論，在公眾面前對這個想法進行壓力測試。

當招聘篩選衡量的準備程度多於工作本身時，就該改變證據：讓應徵者實際試用，由表現決定

這篇文章在 Hacker News 獲得 648 分與 442 則留言，使 37signals 成為反解謎陣營的參照點。支持者說，困難的腦筋急轉彎能揭示壓力下的問題解決能力；反對者則以一天的結對工作、作為低成本負面篩選的 FizzBuzz，以及 ITA 閱讀離線程式碼的做法回應。試用做法被認為很好，但對仍需要解謎作為人才磁鐵的較不知名雇主而言並不實際。討論中並未出現任何經衡量的招聘結果；其效果是規範性的——「trying them out for size」成為瑣事面試的主要替代方案。