Triplebyteでは、多くのインタビューを実施しています。 現実には、過去2年間に900人以上のエンジニアにインタビューしました。 私の時間の使用はどれほど効果的ですか？ここで議論することができます（時々私は冷たい汗で目を覚まし、それを疑います）。 しかし、私の気持ちに関係なく、主なことは、面接プロセスを改善しようとしているということです。 これを行うために、履歴書（バックグラウンドブラインドの内部ビュー）を見ずにインタビューを行い、プログラミングスキルを決定し、メリットと推奨事項を評価しません。 エンジニアが私たちのインタビューに合格した後、彼らは私たちと一緒に働いている会社（Apple、Facebook、Dropbox、Stripeを含む）に直接最終インタビューのために送られます。 経歴については何も知らないエンジニアにインタビューし、さまざまな大手IT企業で彼らがどのように現れるかを見ていきます。 私の意見では、これはインタビューの有効性の最良のテストです。

この記事では、今までに理解できたことを示します。 技術面接の大部分は誤って編成されています。 これは言うのは簡単で、多くの記事がそれについて語っています。 これらの欠陥を修正することはより困難です。 この記事での私のタスクは、このタスクに対処し、採用マネージャーとテクニカルディレクターに具体的なアドバイスを提供することです。 面接は難しいことです。 しかし、プロセスを慎重に検討すれば、多くの問題を解決できると思います。 ここでは、技術的なスキルの評価について書いています。 今後の記事では、文化的適合性、行動面接、および非技術的評価について説明します。

現状

ほとんどのインタビューには、2つの主要なステップが含まれます。

• 候補者の選択。
• 個人的な最終面接。

選択の目的は、第一段階で候補者を除外し、エンジニアの面接時間を節約することです。 通常、採用担当者は選択プロセス中に候補者の履歴書をスキャンし（約10秒）、その後30分から1時間、電話で候補者と話します。 私たちと仕事をしている企業の80％は、候補者に宿題を出します（電話インタビューの代わりに、またはそれに加えて）。 興味深いことに、候補者の大半は選択段階で選別されます。 実際、当社と協力しているすべての企業の中で、候補者の50％以上が履歴書のスキャン後に除外され、さらに30％が電話インタビューと宿題の後に除外されています。 事前審査は、雇用プロセスが特に不機嫌な段階です。 採用担当者は膨大な数の履歴書に圧倒され、即座に決断を下さなければなりません。 ここでは、候補者のメリットとモデルとの比較の原則が施行されます。

個人的な最終面接は、ほとんどの場合、45〜60分の一連のセッションで構成され、各セッションには新しいインタビュアーが付きます。 これらは主に技術的なセッションです（さらに、文化的コンプライアンスと個人的な資質に関する各企業に対して1つまたは2つ）。 候補者の採用に関する最終決定は、候補者が去った後の総会議で行われ、人事マネージャーと候補者にインタビューしたすべての人が参加します。 実際、肯定的な決定のためには、それを主張する必要があり、残りは特別な異議はありません^[1] 。

最終的なインタビューの多くは、標準形式を拡張したものであり、互いに非常に異なっています。

提携している企業の39％は、マーカー付きのホワイトボードを使用しています。

52％を使用すると、自分のコンピューターで作業できます（残りの9％は、ホワイトボードまたはコンピューターを選択する際に一貫性がありません）。

55％はインタビュアーが質問を選択できるようにします（残りの45％は標準の質問バンクを使用します）。

40％は、候補者に提案するためにコンピューターサイエンスの学術的知識を見たいと考えています。

15％の企業は、コンピューターサイエンスの学術的知識を見たくありません（コンピューターサイエンスについて話すことは、候補者が効果を示さないことを示すものだと思います）。

80％では、面接に任意のプログラミング言語を使用できます（残りの20％は特定の言語の使用が必要です）。

5％は、インタビュー中にプログラミング言語の使用に関するすべての詳細を評価します。



提携しているすべての企業の中で、最終面接の22％が積極的な採用決定で終了しています。 （この数値は、候補者の独自の選択プロセスに基づいて、企業自体の内部統計から取得されます。トリプルバイトを通過する候補者については、53％のケースで肯定的な決定が行われます）。 提案の約65％が候補者に受け入れられます（そして、候補者は仕事を得ます）。 1年間の運用後、企業は新入社員の約30％に満足を表明し、約5％をレイオフしました^[2] 。

偽陰性および偽陽性の結果

では、現状の何が問題なのでしょうか？ 少なくとも、解雇された人々の割合は重要ではないと思われる。 問題を理解するには、インタビューが2つの理由で失敗したと見なされることを考慮する必要があります。 または、彼らは、後に解雇されなければならない悪いエンジニアを雇います（誤検知の結果）。 または、面接は、仕事を上手く行うことができる候補者を失格にします（偽陰性）。 雇用の失敗は、企業にとって明らかであり、費用がかかります（給与、管理コスト、およびチーム全体の士気）。 悪い雇用はチームからエネルギーを吸い込みます。 しかし、うまく仕事をすることができたが、チャンスが与えられなかった候補者は、反対に、見えないままです。 各ケースは常に混在しています。 物議を醸す状況でこの非対称のため、企業は非常に失敗しやすいです。

この効果は、インタビュープロセスの「ノイズ」によって悪化します。 1時間でプログラミングスキルを評価することは非常に困難です。 これに、サンプルと主観的な「本能的な」感情との比較の原則、および上記で説明した各企業の機能の複雑な混合を追加すると、非常にノイズの多い信号が得られます。

このようなノイズの多い信号で偽陽性率を低いレベルに保つために、企業は候補者を拒否するためにさらに傾く必要があります。 その結果、彼らは優れたエンジニアを奪われ、実際のスキルよりも価値を重視しており、インタビューに関与している人々にとっては気まずくてイライラすることがよくあります。 あなたの会社の全員が現在のポジションのために再インタビューする必要がある場合、彼らの何パーセントが合格しますか？ これは恐ろしい質問です。 答えは間違いなく、100％を大きく下回る数字になります。 候補者は、完璧に働くことができる企業に拒否されることに苦しみ、企業は才能を見つけることができないことに苦しんでいます。

明確にするために、私はインタビューの水準を下げるキャンペーンをしていません。 失敗はインタビューの本質です！ 企業が偽陰性の結果よりも偽陽性の結果を大いに恐れていると言っているわけでもありません。 悪い雇用は高価です。 私は、騒々しい信号が、失敗した雇用の恐怖と相まって、本当に高いレベルの偽陰性結果につながると主張しているだけであり、これは誰にとっても悪いことです。 解決策は、信号品質を改善することです。

特定のインタビューのノイズ低減技術

1.探しているスキルを決定します。

優れたプログラマーを定義するスキルの単一のセットはありません。 それどころか、多様なスキルセットの海があります。 すべての分野で一度に強いエンジニアはいません。 実際、Triplebyteでは、完全に切断されたスキルセットを備えた優秀で成功したプログラマをよく見かけます。 したがって、適切なインタビューを行うための最初のステップは、どのスキルセットがジョブに適しているかを判断することです。 いくつか質問をすることをお勧めします（これらは、Triplebyteでのサービスのために新しい会社を受け入れるときに尋ねる質問です）。

速くて反復的なプログラマーが必要ですか、それとも気配りのある精巧なプログラマーが必要ですか？

技術的な問題を解決したり、製品を作成したりする意欲のある人が必要ですか？

特定のテクノロジーのスキルや、仕事の過程で学ぶスマートプログラマーが必要ですか？

コンピューターサイエンス、数学、アルゴリズムの学術的知識は重要ですか？

並行性、Cメモリモデル、またはHTTPの知識は重要ですか？

これらの質問に対する正しい答えはありません。 各ケースで異なるオプションを選択する成功した企業と協力しています。 しかし、最も重要なことは、あなたのニーズに基づいて意識的な選択をすることです。 面接の質問をランダムに選択する（または候補者に選択させる）ことは避けてください。 これが起こると、会社のプログラミング文化は、ますます多くの開発者が会社にとって特に重要ではない特定のスキルまたは開発アプローチを持ち、このスキルを持たない（しかし他の重要なスキルを持つ）エンジニアが拒否される方向に陥ることがあります。

2.実際の仕事にできるだけ近い質問をします。

プロのプログラマーは、数週間から数か月間、大きくなりつつある問題を解決するために雇われます。 しかし、面接官には候補者を評価するための週または月がありません。 通常、それぞれ1時間です。 また、面接官は、候補者が強要されている間に小さな問題をどれだけ迅速に解決するかをチェックします。 これは別のスキルです。 はい、関連性があります（インタビューはまだ完全にランダムではありません）。 ただし、必要なものと完全に相関するわけではありません。 この違いを最小限に抑えることが、インタビューの質問を作成する目標です。

これは、面接での質問が候補者に期待する仕事（または評価しようとしているスキル）に可能な限り近い場合に達成できます。 たとえば、バックエンドのプログラマを探している場合は、候補者にAPIエンドポイントを開発して機能を追加するよう依頼してください。これは、幅を検索してグラフを横断する問題を解決するよりも確実に優れています。 アルゴリズムを知ることが心配な場合は、特定の問題を解決するためにアルゴリズムを適用するように依頼します（たとえば、削除時のパフォーマンスを向上させるために、おそらくBSTおよびHashMapをサポートする単純な検索インデックスを作成します）-これは、特定のポイントが属するかどうかを判断するタスクよりもほぼ確実に優れています凹多角形。 タスクのデバッグでは、ボード上の小さな問題を解決するように依頼するよりも、候補者に実際のコードベースで作業させる方がほとんど常に優れています。

また、マーカー付きのホワイトボードを使用することを支持する議論もあります。 インタビュアーとして、候補者がPythonで設定されたitertoolsのすべてのイテレーターを心から覚えているかどうかは関係ありません。 彼が問題を解決するためにこれらの反復子を適用する方法を見つけることができるかどうかは私にとって重要です。 候補者がボードに描画すると、正確な構文の制限から解放され、ロジックに集中できます。 しかし、最終的には、これは悪い議論だと思います。異なる形式を使用する正当な理由がないからです。 実際、候補者が自分のコンピューターで作業できるようにすることで、すべて同じ利点を得ることができますが、このコードの必須実行の条件を削除します（または、さらに良いのは、オープンブックインタビューを行うこと、つまり、Googleでヘルプ情報を検索する機能を使用することです）。

実際の作業を反映する質問を作成する場合、重要な注意事項があります。 質問に外部依存関係がないことが重要です。 たとえば、単純なRuby Webスクレイパーを作成するように依頼することは、現実の世界では良い問題のように思えます。 ただし、候補者がNokogiri（インストールが困難なRuby解析ライブラリ）をインストールする必要があり、ネイティブ拡張との戦いに30分を費やす必要がある場合、これはひどい就職面接です。 時間が失われるだけでなく、候補者のストレスレベルは屋根の上にあります。

3.すぐには答えられない複合的な質問をする。

面接の質問のもう1つの良いルールは、短く完全な回答がある質問を避けることです。つまり、候補者が事前にGlassdoorで読むことができる魔法のような情報があります。これにより、質問に簡単に答えることができます。 明らかに、これは質問のパズルや洞察を必要とする質問の数からすぐに除外されます。 さらに、質問はいくつかのステップで構成する必要があります。後続の各ステップは、中心的な問題に関する1回限りの質問ではなく、前の質問に基づいています。 なぜ他に役立つのか-全体的に良い印象を与えるが、いくつかの問題で立ち往生している候補者をどのように支援できるか自問してください。 1回限りの質問の場合、候補者に重要な支援を提供すると、面接は失敗します。 マルチパート複合タスクでは、1つの段階で支援を行うことができ、候補者は残りのステップを個別に正常に完了します。

これは、質問がGlassdoorに送信される可能性があるためだけでなく、重要です。 さらに重要なことは、複合の問題がノイズを減らすことです。 良い候補者は、ストレスのためにある時点で行き詰まることがあります。 彼らを助け、回復プロセスを観察する能力は非常に重要です。 候補者が特定のプログラマーロジックにどれだけうまく対処できるかにかなりのノイズがあります。最近似たような問題に遭遇したかどうかによって異なりますが、これは単なるランダムな確率です。 マルチパート複合タスクは、このノイズの一部を除去します。 また、候補者が効果がどのように成長しているかを観察する機会を提供します。 ある段階での取り組みは、多くの場合、次の段階で問題を解決するのに役立ちます。 これは実際の開発プロセスの重要なダイナミクスであり、インタビュー中に調査することでノイズレベルが低下します。

例が必要な場合は、候補者に端末でゲーム「Four in a row」（一連の複数のステップ）を実装するように依頼する方が、マトリックスを回転するように依頼するよりも優れたタスクです（タスクを非常に簡単にするいくつかのトリックがあります）。 k-means法（相互に基づくいくつかの操作）によるクラスタリングは、ヒストグラムの下に収まる最大の長方形を決定するよりも優れたタスクになる可能性があります。

4.難しい質問を避ける

候補者が困難な問題を本当にうまく解決した場合、これは彼の能力について多くを語っています。 しかし、質問は複雑であるため、ほとんどの候補者は適切に答えることができません。 この場合、質問から受け取る情報の予想される量は、その複雑さに依存します。 最適なレベルの複雑さは、ほとんどのインタビュアーが信じているよりもはるかに低いという結論に達しました。

候補者の面接中に2つの情報源があるという事実により、効果が強化されます。1）質問に「正しい」答えを与えるかどうか、2）反省のプロセス、つまり、この答えを簡単に思いつく方法。 Triplebyteでは、これらの指標を収集します（回答の正確さの推定値と、これを行うために必要な労力の推定値を収集し、異なる企業の従業員の成功と相関する予測を行います）。 私たちが見つけたのは、一種の妥協です。 候補者がより複雑な質問に答えると、答えから直接より強いシグナルが得られます。 それよりも単純な質問の場合、プロセスと候補者がどれだけ苦しめられたかがより重要です。 信号の両方のソースが与えられると、最適なものは単純な質問に近くなります。

実際には、次のルールが作成されています。面接者自身が、候補者がこの問題を解決すると予想する時間の25％で問題を解決する必要があります。 したがって、1時間のインタビューのために新しいタスクを開発している場合、同僚は（警告なしで）15分で正しい答えを出すべきです。 現実の世界から多段階の問題を解決することを提案するという事実を考えると、最適な面接のタスクは実際に非常に理解可能でシンプルでなければなりません。

明確にするために、私は合格点を下げるという意味でバーを下げるキャンペーンをしていません。 私は、単純な質問と、候補者がそれらにどのように応答するかについてのさらなる評価に賛成するだけです。 私は簡単な質問と回答の非常に厳しい評価を表しています。 これが、経験上、信号を最適化する最適な方法です。 ほとんどの候補者のストレスを軽減するという追加の利点があります。

例を挙げます。 候補にキーと値のペアをリポジトリに配置するコマンドを使用して単純なコマンドラインインターフェイスを作成するように依頼する（候補が得意であれば追加機能を追加する）のは、算術式のパーサーを依頼するよりもおそらく良いでしょう。 そして、最も一般的なデータ構造（リスト、ハッシュ、多分ツリー）の問題は、スペース、アーチ（ツリー+ヒープ）、またはその他のあまり知られていない構造を持つリストの問題よりおそらく良いでしょう。

5.各候補者に同じ質問をする

インタビューの本質は、候補者を比較することです。 目標は、会社を助けることができる人とできない人の候補者を選別することです（そして、単一の空席を埋める場合-最良のものを選択してください）。 これを考えると、異なる候補者に異なる質問をすることは完全に非論理的です。 同じジョブの候補を異なる方法で評価すると、ノイズが増えます。

インタビュアーが候補者ごとに異なる質問を選択する理由は、インタビュアーの個人的な好みにあると思います。 IT企業のエンジニアは通常、インタビューを嫌います。 これは、彼らがたまにしかしないことであり、メインの作業からはそらされます。 各候補者の質問を標準化するために、インタビュアーはこれらの問題を研究し、評価と報告のシステムを習得するためにより多くの時間を費やす必要があります。 また、質問が変わるたびに、この手順を再度実行する必要があります。 そして、常に同じ質問をすることはもう少し退屈です。

残念ながら、ここのインタビュアーにとって唯一の方法は、より多くの努力をすることです。 均一性は、適切なインタビューを行うための重要な要素です。つまり、各候補者に同じ質問をし、レポートを標準化します。 他に選択肢はありません。

6.複数のパスの可能性を検討する

これは前の段落と矛盾しますが、インタビューのいくつかの完全に異なるバージョンの可能性を考慮してください。 最初から、インタビューを設計するとき、どの候補者のスキルが関連するかを考えてください。 しかし、答えのいくつかは互いに矛盾する可能性があります！ たとえば、企業が数学に精通しているエンジニアを必要としているが、非常に生産的/反復的なエンジニアも必要としている場合、それは非常に普通の状況です（同じポジションでも）。 そのような場合は、インタビューを実施するいくつかの方法を検討してください。 ここで重要なのは、タスクの規模により各パスを完全に標準化できることです。 Triplebyteで行うことは次のとおりです。 候補者にインタビューのどのバージョンを好むかを単純に尋ねることができるという結論に達しました。

7.候補者の履歴書があなたに影響を与えないようにしてください

要約は完全に無意味ではありません。 MITとスタンフォード大学の卒業生は、GoogleとAppleの経験を持っているか、持っているが、他のグループよりもグループとして本当に優れている。 問題は、エンジニアの大部分（私を含む）がこのグループに属していないことです。 したがって、企業がこれらの信号に過度に依存している場合、ほとんどの資格のある候補者は合格します。 予備学位の段階である程度履歴書を検討することは理にかなっているかもしれません。 Triplebyteではこれを行いません（「ブラインドテスト」での評価はすべて、個人の経験とメリットを考慮せずに完全に行われます）。 しかし、事前選択段階で履歴書にある程度の重みを与えることは理にかなっています。

しかし、インタビューの段階で履歴書を考慮することはもはや意味がありません。 そして、これが実際に起こる方法であるというデータがあります。 「盲検テスト」で同じ評価を行った結果、大学の卒業証書を取得した候補者は、履歴書にブランド名のない候補者よりも30％頻繁に企業に面接できます。 候補者がマサチューセッツ工科大学の卒業証書を持っていることを面接官が知っている場合、面接中に欠点に目をつぶる可能性が高くなります。

これはノイズであり、回避する必要があります。 最も簡単な方法は、面接官に渡す前に、大学と企業の名前を履歴書から単に削除することです。 会話中に大学や企業に言及する候補者もいますが、この情報を考慮せずに常にインタビューを行います。候補者は技術テストの過程でこれらの事実にほとんど注意を払いません。

8.候補者をあざ笑うな

インタビューに失敗する最も悪い方法の1つは、インタビューがit笑的に終わるときです。 インタビュアーは候補者の能力を評価するだけでなく、グループまたはチームのメンバーになり、グループの新しいメンバーを受け入れます。 この2番目の能力では、彼らは一種の通過儀礼を行います。 はい、インタビュー自体がストレスを引き起こしますが、私たち全員がこのストレスを経験したので、候補者はそれを経験しなければなりません。 候補者がタスクに対処しないと、状況は悪化します。 インタビュアーとして、候補者が頭を壁にぶつけて、答えが明らかな問題を解決するのを見ることに非常に失望することがあります！ 暑くてゆるくなることがあります。 もちろん、これは候補者のストレスを増加させるだけです-そして、彼が問題を解決することはさらに難しくなります。

そのような状況を許可しない方が良いです。 解決策は、問題について話し合い、それを克服する方法をインタビュアーにトレーニングすることです。 ここで1つのトリックを使用します：候補者がまったく失敗した場合、目標が人を評価することである評価モードから、候補者が質問への答えを理解することであるトレーニングモードに切り替える必要があります。 あるモードから別のモードへのメンタルスイッチングは非常に役立ちます。 トレーニングモードでは、情報を非表示にしたり、親しみやすさ以外の感情を示す理由はありません。

9.平均または最小ではなく、最大スキルに基づいて決定を下す

これまでのところ、最終面接での決定についてではなく、個々の問題についてのみ話しました。 ここでの私のアドバイスは、平均レベルや最小レベルではなく、候補者が（あなたにとって重要なすべてのスキルの中で）示した最大スキルに基づいて決定を下すことです。

あなたはおそらく、意図的にまたはそうではなく、すでにこれを行っているでしょう！ 最終決定は、インタビューを実施したすべての人の総会で行われ、少なくとも1人のインタビュアーがこれを強く推奨し、残りが強く反対しない場合、候補者に提案が行われます。 1人のインタビュアーを印象付けるには、候補者がインタビューの1つのセクションで自慢するだけで十分です。 データから判断すると、最大スキルは、企業のインタビューの少なくとも1つのセクションで良好なパフォーマンスを示すために強く相関する属性です。 ただし、求人を受け取るために、候補者は自分自身に対して他の面接官を設定する必要もありません。 候補者が質問に答えるときに本当に愚かに見えた場合、それらからのカテゴリー的な異議が表示される場合があります。

ここでは、単に高いノイズレベルを扱っています。 高度な資格を持つエンジニアの活動分野は非常に多いため、一度にすべての分野で卓越性を達成できる人はほとんどいません。 これは、正しい（または間違った）質問をすると、どんなエンジニアでも愚かに見える可能性があることを意味します。 その後、少なくとも1つのインタビューが強力な知識のゾーン（最大スキル）に触れ、重大な弱点のエリアに触れなかった場合、候補者はオファーを受け取ります。 問題は、これによりノイズレベルが増加することです。 ネットワークテクノロジーに関する質問の後で馬鹿げたように見えたために1つのインタビューに失敗した同じエンジニアは、このトピックが取り上げられなかった残りのインタビューを見事に通過します。

私の意見では、企業は最大限のスキルに集中し、インタビューの別々のセクションで成績が悪い従業員を雇うことに抵抗しないことが最善です。 つまり、候補者に有利な強い議論を探し、彼が弱い技術分野についてあまり心配しないことです。 ここで私は明確にカテゴリー化されたくありません。 もちろん、会社にとって非常に重要な技術分野もあります。 そして、すべての従業員がこれらの分野で一定レベルの知識を持つべきであるというあなたの決定は理にかなっています。 しかし、候補者の最大限のスキルに焦点を合わせると、面接中のノイズが本当に減ります。

インタビューさえするのはなぜですか？

最後に質問したいのは、なぜインタビューが行われるのかということです。 多くの読者がすでに歯を食いしばって言っていると確信しています。 宿題を使うだけです！ 最後に、非常に成功している会社の中には、試用期間（候補者がチームと1週間働く）を適用するか、個人インタビューを宿題に完全に置き換えるものがあります。 試用期間は非常に理にかなっています。 1週間だけ新しい従業員と一緒に過ごす（またはチームが彼と一緒に重要なプロジェクトを遂行するのを見る）と、ほとんどの場合、候補者のスキルを1時間だけ観察して問題を解決するよりも優れた評価が得られます。 ただし、試用期間が標準のインタビューに取って代わることを妨げる2つの問題があります。

1. 試用期間は企業にとって高価です。 仕事を見つけたいと思うすべての人が一週間かかることはできません。 試用期間を誰に任せるかを決めるには、面接を実施する必要があります。
   
2. 試用期間（および家庭での実施のための大規模プロジェクト）は、候補者にとって費用がかかります。 たとえ仕事が支払われたとしても、誰もが時間を過ごすわけではありません。 たとえば、エンジニアがフルタイムで働いており、休暇を取る機会がない場合。 そして機会があったとしても、多くはそれを望んでいません。 エンジニアがすでに仕事に就いている場合、彼は試用期間の不確実性を受け入れる傾向があまりありません。 これは、Triplebyteの候補の例で明らかにわかります。 優秀な候補者の多く（すでに他の企業からの申し出を受けている）は、単に大規模なプロジェクトを実施せず、試用期間に同意しません。

試用期間は、一部の候補者にとって優れたオプションであることがわかりました。スケールが面接のさまざまな方法を使用できる場合、試用期間を追加することは素晴らしいアイデアだと思います。ただし、インタビューを完全に置き換えることは実際的ではありません。

過去の実務経験についての議論も、技術面接の代わりと見なされることがよくあります。ロジックは次のとおりです。候補者が将来、作業を正常に完了するようにするために、過去に何をしたかを確認してください。 Triplebyteでは、この手法を試しました。残念ながら、彼女は良い結果を示しませんでした。コミュニケーション能力（自分自身を売る能力）は、候補者の技術的能力よりも強いシグナルであることが判明しました。あまりにも多くの場合、美しく話す候補者が自分の役割を誇張する（チーム全体の結果を割り当てる）ときや、謙虚な人が自分の長所を過小評価するときに状況が発生します。十分な時間と十分な質問がある場合は、最後まで到達できます。しかし、私たちは見つけました標準的な時間制限では、過去の経験の議論はインタビューの普遍的な代替ではありません。これは、会話の始めに氷を溶かし、人間の興味の意味を理解する（コミュニケーションスキルと文化的関連性を評価する）良い方法です。しかし、過去の経験についての議論は、インタビューの完全な代替としては適していません。

インタビューのプログラミングについて良いこと！

この記事をもっと楽しいメモで締めくくりたいと思います。インタビューのすべての欠点に加えて、彼らはまだ大きな利益をもたらします。

インタビューは能力を直接評価するものです。先生として働く友達がいます。彼らは、教師のインタビューは主にコミュニケーション能力（自分を売る能力）と履歴書/推薦の評価であると言います。どうやら、この状況は多くの、多くの職業にあります。シリコンバレーは理想的な実力主義ではありません。しかし、少なくとも私たちは重要なスキルを直接測定しようとしています。そのようなスキルを持っている人は誰でも、教育や仕事の経験に関係なく優れた専門家になることができるという考えを固守しています。履歴書の評価はしばしば邪魔になります。しかし、Triplebyteでは、この問題をさまざまな方法で克服し、非標準的な履歴書を持つ多数の人々がIT部門で優れた仕事をするのを支援しています。 Triplebyteのような会社が、たとえば法的分野で働くことができるとは思わない。彼らは履歴書や推奨事項に大きく依存しています。

プログラマーもインタビューを好む。これは非常に物議をかもしているトピックですが（おそらく異なる視点を持つプログラマーがいるでしょう）、候補者を評価するための代替方法を実験したとき、ほとんどのプログラマーは依然として標準インタビューを選択しました。そして、試用期間や宿題を提供している企業に興味があるプログラマーはごく一部であることがわかりました。これは良いことも悪いこともありますが、明らかに、プログラマーへのインタビューはどこにも行きません。他の方法は良い追加機能ですが、プログラマを評価する主な方法としてインタビューに取って代わる可能性は低いです。チャーチルが引用するのが間違っている場合：「インタビューは、エンジニアを評価するための最悪の方法ですが、私たちが時々試みる他の方法を除きます。」

おわりに

面接は簡単なことではありません。人間は絶望的に複雑です。ある意味では、4時間のインタビューで人の能力を評価しようとする試みは愚かに思えます。ここで謙虚でいることは重要だと思います。面接プロセスは、頻繁に失敗する運命にあります。人々は複雑すぎます。

---

[1]もちろん、さまざまなオプションがあります。反対の端にあるのは、各インタビュアーから全員一致の肯定的な決定を必要とする企業と、人事マネージャーが個別に決定する企業です。↑

[2]これらは、企業自身の候補者に関する社内統計からの数値です。そして、それらは会社によって大きく異なります（例えば、解雇された人の割合は1％から30％まで異なります）。トリプルバイトの候補は、はるかに優れた数値を持っています。現在、候補者は面接の53％後に求人を受け取り、解雇レベルは2％です。↑