プログラマの採用方法を改善するため、1カ月程前にTriplebyteを立ち上げました。昔から変わらず、履歴書、コードをホワイトボードに書かせるプログラミングテスト、そして直感など、これらを判断基準に面接を行う企業が多すぎます。私たちは、より良い採用方法について最初に考えたアイディアを マニフェスト に記しました。それから1カ月と少しが経過し、この30日間で、300回の面接を行いました。私たちはアイディアを実行に移し、どの方法が有効で、どの方法が有効ではないかを確認し、そのプロセスを繰り返すということを始めたのです。この投稿には、300回の面接を通して私たちが学んだことを書いていこうと思います。

投稿では、細かい内容についての説明が多くなりますが、キーとなる発見は以下の通りです。

1. 私たちが作ったオンラインのプログラミングクイズの結果を見れば、高い確率でプログラミング面接の結果を予測できる。
2. Fizz Buzz問題のような簡単なコーディング問題の結果では、プログラミング面接の結果を予測できる確率は低くなる。
3. 応募者が過去のプログラミングプロジェクトについて面接で話しても、そこからプログラミング面接の結果を予測することは難しい。

プロセス

私たちのプロセスには4つのステップがあります。

1. オンラインでの技術選考
2. 技術プロジェクトについて話す15分間の電話面接
3. 応募者がコーディングする45分間のスクリーンシェア面接
4. 応募者が比較的大規模なコーディングプロジェクトを行う2時間のスクリーンシェア面接

応募者は自分の開発環境と得意な言語を使い、自分のコンピュータでコーディングを行います。また、長い時間をかけて行う2つの面接では、両方とも応募者が短いリストの中から問題やプロジェクトを選びます。私たちは応募者の強みを見つけたいので、多くの応募者が取組みやすい課題を選べるようにしなければいけません。しかし、評価を標準化するためにリストに載せる選択肢は少ないままとします。それぞれの問題について、多くのデータを取得したいためです。

私たちが見たいのはプログラミングのプロセスと理解度であって、発想力を求めているわけではありません。そのため、それぞれの問題の設計やアルゴリズムを提供しています（これを応募者が利用しても減点にはなりません）。面接ではスコアカードを用いて評価します。今は評価するポイントが少し多すぎるのですが、問題ごとに多くのマイルストーンを設け、そこに応募者がたどり着いた時間をトラッキングしています。また、応募者の理解度、話が具体的か一般的か、緊張しているかなど、他にも多くの事柄にスコアをつけています（基本的に思いつくことは全て評価の対象です）。おそらく、これらの大部分はパフォーマンスの測定基準としてはひどいものですが、今後、どの測定基準が有効かを見極めるために、現在、私たちはこれらの全てを記録しています。

選考

私たちはの最初の実験として、履歴書を見ずに応募者を選考するということを試しましたが、大多数はその選考で不合格となりました。悲しい現実ですが、インターネットの求人広告に応募してくる人々に優秀な人材はほとんどいません。面接に費やす時間を無駄にしないためにも、採用過程における入口部分でフィルタにかける方法が必要です。昔から履歴書がその役割を果たしてきました。しかし、 Aline Lernerが示したように 履歴書は有効ではありません。履歴書の内容では、優秀なプログラマかどうかを確実に見分けることはできないのです。これは問題です。 企業に必要なのは、応募者の実際の能力を見て選考する方法です。応募者の過去の学歴や職歴を知ることではありません ^(1) 。この目的を達成するために、私たちは2つの選考ステップを試してみました。

1. Fizz Buzz問題のようなプログラミング課題。応募者は2つの簡単な問題について解答しました。私たちはそれぞれの解答にかかった時間をトラッキングし、更にそれぞれの正確性とコードの質を手動で等級分けしました。
2. 自動クイズ。複数選択方式ですが、実際のコードに対する理解が必要な問題を設定しました（例えば、ある関数を見て、どのバグが存在するかを選ぶなどといった問題です）。

私たちは、上述した2つのステップの結果と、それに続く45分間の技術的な面接の合格率について、両者の相関を調べました。 以下のグラフは300回の面接を行った後の相関関係を示しています。

*注釈
Correlation between screening steps and interview decisions
選考のステップと面接結果との相関関係
Correlation coefficient
相関係数
Quiz: composite score
クイズ：　総合スコア
Quiz: total score
クイズ：　合計スコア
Quiz: time to finish (inverse)
所要時間（逆相関）
Coding: code correct
コーディング：　コードの正確性
Coding: code clean
コーディング：　コードの美しさ
Coding: time to finish
コーディング：　所要時間
*

このグラフを見ると、クイズの結果から面接の合否を大いに予測できることが分かります。面接の成績の約半数（48％）はクイズのスコアで説明がつき、39％はクイズにかかった所要時間（速い方が好ましい）で説明がつきます。所要時間とスコアには漠然とした相関関係しかありません（正確には、速くなる傾向の方がわずかに強いというだけの意味です）。 つまり、所要時間とスコアをいわゆる総合スコアに結びつけられるということです。総合スコアは全ての項目の中で最も強い相関関係があり、面接の成績の54％（+/-17％）の説明がつきます ^(2) 。

ところが、Fizz Buzzスタイルのコーディングテストは同じような成績にはなりませんでした。信頼区間は大きいですが、面接結果との相関関係は薄いことを現在のデータが示しています。これには私も驚きました。私たちが行う面接（選考の効果を評価するために使っている方法）はコーディングに大きな重点を置いているため、応募者に実際のプラグラミングをしてもらうことは、テストとして有効であるように直感では感じます。しかし、データは異なる結果を示しています。コーディングテストは、完成させることが一段と難しかったのです。コーディングテストで脱落した応募者の数は、クイズの脱落者の2倍に上りました。

会話　VS　コーディング

私たちはこの会社を始める前に、技術的な採用方法を経験したことがある多くの優秀な人々と話をして面接のためのアイディアを収集しました。私が一番気に入ったのは、ソースコードを見ることも含めて、応募者たちに技術的なプロジェクトについて徹底的に話してもらうというアイディアでした。この方法は応募者が最も不快に思わない、彼らに最も配慮したアプローチのように思われました。

しかし、このアプローチを始めてすぐ、問題に気付きました。大半の応募者がパスしてしまったのです。フィルタをかけたつもりが、これではフィルタの役目を果たしていません。そこで、面接時間を延長し、より深い話をして、Googleのハングアウトでコードを見るように試みました。それでも応募者は高い確率でパスしてしまいました。

問題は、私たちが応募者からプロジェクトの話を聞いても、確信を持って応募者を落とすだけの十分な兆候をつかめなかったことです。そのため、続いて応募者にコードを書いてもらう面接を始めました。 すると突如、素晴らしいプロジェクトの話を上手にしていた応募者たちが著しい割合で失敗していったのです。比較的、簡単なプログラミングの問題が出された場合は特に、そのような結果になりました。 反対に、非常につまらないプロジェクトの話をした（または、どのような仕事をしてきたのか想像するのが難しいほどコミュニケーションが下手な）応募者たちは、実際のプログラミングにおいて優秀な成績を見せました。

合計で90回、経験を話してもらう面接を行った結果、いくつかの要素（応募者が優秀に見えること、プロジェクトをよく理解していること、自信を持っていること、プロジェクトが素晴らしいものだったこと）にスコアをつけました。そして、これらの要素と45分間にわたるプログラミング面接の成績との相関関係を調べました。自信を持っているという要素に関しては、本質的な相関関係はゼロでした。優秀に見えること、プロジェクトをよく理解していること、そしてプロジェクトが素晴らしかったことという要素は、それぞれ約20％の相関関係がありました。 言い換えると、応募者に経験を聞く面接は、コーディングテストでの合格を予測することに関しては自動化したクイズに及ばなかったのです。

応募者に過去の経験をもっと深く話してもらうようにすれば、意味があるでしょう。これは、私が友人の中で誰が素晴らしいプログラマか見分ける方法でもあります。しかし、 コーディングについての話を基にして、実際のコーディング能力を合理的に判断するには、45分という面接の時間は短すぎる、 ということに私たちは気付きました。

面接時間と面接官の意見

最終テストは、私たちが面接のどの時点で決定を行っているか調べることでした。Google社の人事部門でバイスプレジデントを務めるLaszlo Bockは、「多くの面接において最初の数分間で決定され、残りの時間はその決定を裏付けするための時間として使われる」と、述べています。私たちの場合はこれが当てはまらないことを確かめる必要がありました。それを検証するため、私たちは面接用ソフトウェアを改良して、各面接中の5分ごとに応募者についての評価を尋ねてくるポップアップ機能を追加しました。そうして記録された意見を全体として見れば、各面接のどの時点で決定を行ったのかが正確に分かります。

その結果、45分間の面接のうち50％において、最初の20分で”決定した”（合格となる応募者について肯定的になった、あるいは不合格となる応募者について否定的になった）ことが分かりました。一方、20％では、最後の5分まで最終的な意見が決まりませんでした。2時間の面接でも似たような結果になりました。60％では肯定、否定のいずれも最初の20分で決まりましたが、10％ではほぼ2時間かかっていました（残念なことに、この場合は肯定が否定に変わっていましたが、それは確信の持てない人材を企業に送るわけにはいかないことが理由です） ^(3) 。

結論

とんでもない1カ月でした。GuillaumeとHarjと私は、ほとんど全ての時間を面接に費やしました。面接の一日が終わった後、土曜日の夜10時に、どうしてこの会社を始めたのかと考えることもありました。ですが、このブログ記事を書いていて思い出したのです。採用の決定は重要事項であるにもかかわらず、あまりにも多くの企業が自社の従来のやり方で満足しています。最初の30日間で、私たちは履歴書による選考の代わりとなる方法を見つけ出し、それが有効なことを示しました。プログラミング経験についての面接（多くの企業で採用）が特に有効なわけではないことも分かりました。そして、いつ、なぜ決定を行うかの測定に役立つソフトウェアを作りました。

私たちは現在、最終段階の面接での決定に関する様々な実験を評価しているところです。その際には、確かに循環論法になってしまう危険があります（私たちの傾向について慎重に述べているだけかもしれません）。どこかから始めなくてはいけませんが、実際のコードの書き方を評価の基礎とすることは、良い考えのように思われます。 本当に面白い発見は、この全ての分析を、面接結果でなく実際の仕事のパフォーマンスに基づいてやり直した時に、明らかになります。 それこそが、この会社を始めた理由なのです。

その次には、自分の時間に行うプロジェクトを応募者に与える実験（面接での不安を考慮すると、私はこの方法もぜひ選べるようにしたいのです）、そして既存のコードベースを応募者に扱ってもらう面接の実験を行いたいと考えています。また、クイズの有効性を高められるか調べるため、もっと難しい問題を追加する予定です。これらの考えについて、皆さんのご意見をぜひお聞かせください。メールの宛先は founders@triplebyte.com です。

この記事の草稿を読んでくれたEmmett Shear、Greg Brockman、そしてRobby Walkerに感謝します。