37signalsはパズル型のプログラマー採用を拒否し、候補者を実際に試した

2013年2月、37signalsは会社のブログで「なぜ私たちはパズルやトリックでプログラマーを採用しないのか」を公開し、その投稿は同日Hacker Newsに登場した。議論は知識偏重型の採用の失敗から始まった。マイクロソフトの面接を受けたある人物は『How Would You Move Mount Fuji?』で準備していたが、Cのstrcmp()を記憶から書くよう求められた。Amazonの面接はBig-Oの暗唱や「宇宙の星をすべて数えよ」に頼っていた。そして面接官はしばしば、その答えが何を証明するのかを問うことなく、ただ「プログラミング面接問題」を検索するだけだった。

37signalsの対抗策は、そのジャンル自体を拒否することだった。パズルやトリックに基づく採用はしない。コメント投稿者たちはその代替を「試着させる」こと、つまり合成された頭の体操ではなく実際の仕事の前に候補者を置くことだと表現した。実務家たちも具体的な仕組みで同じ方向を推した。ITA Softwareは対面でのクイズ形式よりも、誰かがオフラインで書いたコードを読むほうがはるかに有用だと分かった。ある採用マネージャーは、1日ペア作業を中心に面接を組み立て、3つの問いを投げかけた。その仕事ができるか、チームに合うか、状況が変わったときに適応できるか、である。

この2つの選考は異なるものを測る。知識問題や頭の体操は対策可能であり、予想される質問や準備本の膨大な伝承が存在する。そしてそれらは、人工的なプレッシャーの下での記憶力と冷静さを選別する。コメント投稿者たちは、洞察型の思考をする人が1時間の手順的な質問では失敗しても、より長い実際の課題ではうまくやれること、またパニック発作の最中にある候補者がFizzBuzzで失敗しても優れたプログラマーであり続けられることを指摘した。観察された仕事は、知識問題では答えられない問いに答える。その人物が未知のコードベースをどう読み、誤りを見つけ、コードを書き、見知らぬ人たちとどう働くか、である。

パズルという試練を捨て、候補者を実際に試し、記憶力ではなく実際の仕事に採用を決めさせる

パズル型の選考は対策可能である。予想される質問や準備本の伝承により候補者は練習できるため、その試験は仕事の能力ではなく準備と記憶を測る。

候補者を実際に試すことは、実際の仕事を観察する。本物のコードベースを読み、誤りを見つけ、コードを書き、協働する。頭の体操では生み出せない証拠である。

人工的なプレッシャーは結果を歪める。洞察型の候補者や不安の強い候補者は1時間のパズルでは失敗しても、より長い期間の実際の仕事ではうまくやれる。

この公的な立場は会社が何を重視するかを示し、442件のコメントの議論を呼び起こして、その考えを公の場で試した。

採用選考が仕事そのものよりも準備を測っているなら、証拠を変えよ。候補者を実際の仕事で試し、成果に決めさせよ

このエッセイはHacker Newsで648ポイントと442件のコメントを集め、37signalsを反パズル派の参照点にした。擁護者たちは難しい頭の体操がプレッシャー下での問題解決を明らかにすると述べた。反対者たちは1日のペア作業、安価な負のフィルターとしてのFizzBuzz、ITAのオフラインコードを読む慣行を対抗策として挙げた。試用アプローチは良いと評されたが、人材を引き寄せるために依然としてパズルを必要とする知名度の低い雇用主には非現実的だと言われた。議論の中に測定された採用結果は現れない。その効果は規範的なものだった。「試着させる」ことが知識問題型の面接の主要な代替案となった。