技術面接の成約率を向上させるには、応募者にフィードバック（良いか悪いか）を与える

テッククランチイベント

実際のところ、面接後に建設的なフィードバックを受けたエンジニアから訴訟を起こされた企業は（少なくとも米国では）文字通りゼロです。

多くの訴訟は法廷外で解決されるため、そのデータを入手するのは非常に困難ですが、私たちが知っていることを考慮すると、有用なフィードバックを提供した後に訴えられる可能性は極めて低いです。

候補者が防御的になるのはどうでしょうか?

当社のプラットフォーム上のすべての面接官については、候補者の体験と面接官の調整という 2 つの主要な指標を追跡しています。

候補者エクスペリエンススコアは、特定の面接官と面談した後、候補者が再び面接を受ける可能性を測る指標です。面接官キャリブレーションスコアは、その後の本番面接での候補者の対応に基づいて、特定の面接官が厳しすぎるか、甘すぎるかを判断します。本番面接で不合格になった候補者に常に高い評価を与えている場合は、その面接官は甘すぎます。逆もまた同様です。

これらのスコアを総合すると、正直なフィードバックを提供することの価値を推論することができます。以下は、面接官の正確性に対する候補者エクスペリエンススコアの平均値をグラフ化したものです。これは、1,000人以上の面接官（約10万回の面接）のデータに基づいています。

候補者体験スコアは、面接官が厳しすぎず、甘すぎず、いわば「ちょうど良い」という点でピークに達します。その後は、どちら側でもスコアは劇的に低下します。

弊社のデータに基づき、適切なフィードバックを行えば、候補者は防御的になることはないと確信しています。正直なフィードバックを提供することのメリットは、リスクをはるかに上回ります。

正直な（そして時には厳しい）フィードバックを伝えるためのプレイブック

まず第一に、そして最も重要なことは、結果に焦点を合わせないことです。むしろ、すぐに具体的な内容を伝えましょう。そうすることで、候補者が防御的になることを防ぎ、フィードバックを実際に聞き、それを自分のものにする準備を整えることができます。

候補者に、良いか悪いかを伝えるのではなく、建設的で詳細なパフォーマンス評価に焦点を絞ってください。このようにフィードバックを再構成するにはある程度の練習が必要ですが、候補者は結果を伝えるようあなたに強要することはありません。

その代わりに、彼らの注意は細部へと向けられ、合否の判断は後付けのものになってしまいます（場合によっては全く意味をなさなくなります）。人は失敗したから守勢に立つのではなく、なぜ失敗したのか理解できず、無力感を感じているからこそ守勢に立つのです。

面接後に考慮すべき質問

• コーディングに入る前、またはシステムの設計を始める前に、制約について十分な質問をしましたか?
• 特定のコード スニペットまたはソリューションの一部を確認して、何を改善できたでしょうか。
• 彼らの解決策はもっと効率的だったのでしょうか?
• 彼らはトレードオフについて議論し、論じましたか?
• 彼らは時間や空間の複雑さについて議論する際に間違いを犯しましたか？その間違いとは何でしょうか？
• 選択したプログラミング言語を慣用的に使用しようとしたときに、何か間違いを犯しましたか (例: Python または JavaScript で反復処理する)?
• システム設計に関する質問に対して、なぜそのツールがその仕事に適切な選択なのかを説明することなく、特定のデータベース、ロードバランサー、またはツールをすぐに提案しましたか?

これらの質問に適切に答え、建設的なフィードバックを提供するためには、面接中にタイムスタンプ付きのメモを取ることが不可欠です。いつでもメモを見返して、「面接開始からわずか5分でコーディングを始められましたね。通常は、数分かけて質問する時間を取るのが良いでしょう」と伝えることができます。

具体的なフィードバックとは、まさに具体的であるということです。最も親切ではあるものの、最も手間のかかることの一つは、相手のコードをざっと読み、どこで間違えたのかを指摘し、改善点を指摘することです。

もう一つの有効なアプローチは、面接の質問に対する客観的なベンチマーク、つまり時間とヒントの数を共有することです。熟練した面接官は、複雑さを段階的に増やします。候補者が質問をうまく解いた後、リアルタイムで制約を変更します。候補者が質問をあっという間に答えてしまう場合は、面接中にこれを3、4回繰り返すこともあります。

つまり、パフォーマンスの低い候補者、平凡な候補者、そして本当に優秀な候補者に対して、制約の変更を何回実行できるかを正確に把握できるということです。

しかし、応募者はこのことを知りません。実際、面接では質問がどれほど複雑な層に分かれているかに気づかず、自分のパフォーマンスを過大評価してしまう人がいます。

このシナリオでは、候補者は時間切れ直前に最初のレイヤーを無事に終え、うまくできたと信じて終えるかもしれませんが、実際には面接官は、同じ時間で 3 つのレイヤーを完了した人々と比較したことになります。

これらすべての情報をどのように実用化しますか?

面接の最後に、優秀な候補者のベンチマークとなるものについて候補者に伝えましょう。例えば、「この問題に取り組んだ45分のうち、最も優秀な候補者は通常、約20分で総当たり方式の解決策を完成させ、線形時間で実行できるようになるまで最適化を行い（さらに10分かかります）、最後の15分で、入力を配列ではなく整数のストリームにする拡張を成功させます」といった具合です。

また、どれくらいのヒントが標準なのかを正確に伝えましょう。面接の各パートにどれくらいの時間がかけられるべきかと同じように、ヒントの数や詳細さに関しても、応募者は「標準」が何なのか全く分かりません。

たとえば、受験者がどのデータ構造を使用するかについてのヒント、そのデータ構造に関連する時間の複雑さについてのヒント、そしてよく発生するオフバイワンエラーについてのヒントを必要としていた場合、最も優秀な成績を収めた受験者は通常、これらのうちの 1 つについてのヒントを必要とし、3 つすべてについてのヒントを必要としないことを受験者に伝えるとよいでしょう。

ベンチマークを建設的に伝えるための鍵は、もちろん、実行時間、スペースの制約、または使用している成功の指標をできるだけ具体的に伝えることです。

面接官の中には、フィードバックを与える前に、面接の最後に候補者に詳細な自己評価を求める人もいます。これは高度なテクニックであり、同期フィードバックの実施に慣れていない場合は、最初の数回の面接では行わないことをお勧めします。

ただし、慣れてしまえば、このアプローチは候補者が最も支援を必要としている領域に焦点を絞る優れた方法になります。

自己評価方式を採用する場合は、候補者に誘導的な質問をするとよいでしょう。例えば、アルゴリズム面接の場合は、次のような質問をしてみましょう。

• 問題をどの程度うまく解決し、最適な解決策に到達できましたか?
• あなたのコードはどれくらいきれいでしたか?
• どこで苦労しましたか?

候補者が回答している間、メモを取り、それぞれのポイントについて一緒に詳しく説明します。例えば、候補者がコードの品質については高い評価をしているものの、問題解決能力については低い評価をしている場合、あなたは同意するか反対するかを述べ、両方について（前述のように）ベンチマークを与えることができます。

要約すれば

• 面接中は、できればタイムスタンプを付けて詳細なメモを取り、後で参照できるようにします。
• 合否をいきなり伝えるのではなく、具体的かつ建設的な意見をすぐに伝えましょう。そうすることで、応募者の注意を結果から逸らし、フィードバックを受け入れる態勢を整えることができます。
• 可能な限り、客観的なパフォーマンス基準を示しましょう。例えば、最も成績の良い受験者は通常、パート1を20分以内、パート2を10分以内、パート3を15分以内で終わらせることができると伝え、ヒントは最大1つに留めましょう。
• フィードバックを与えることに慣れてきたら、候補者に自分のパフォーマンスを評価してもらい、それを評価基準として使用してポイントごとに評価してみましょう。