過去数年間、私は開発を管理しており、定期的に新しい従業員を募集する必要があります。



平均的なIT業界の状況を見て、かなり否定的な評価をすることを敢えてします。私の意見では、インタビューは主観性とランダム性に満ちており、平均の選択の質は非常に平凡です-閉鎖されていない月、採用されたスタッフは期待に応えられないことがよくあります。



その理由は、インタビューを行う技術者のほとんどが人事管理の分野で教育を受けている（もちろん）か、少なくともそれについて何かを読んでいるという事実だと思います。 また、採用担当者はデータ分析についてほとんど理解していません。 その結果、これらのコンピテンシーのペアが1人でつながることはほとんどなく、採用担当者は 、最初に役立った目的や抽出する情報を理解せず、好きなインタビューの外部サインを繰り返すだけです。 その結果、コピーと貼り付けのたびに、意思決定の質が低下します。



技術的な専門性を考慮して、客観的なデータに基づいてプロセスを開発し、それを実装して私の部門の開発者を雇うことにより、選択の質を向上させ、同時に必要な時間を削減しようとしました。 その結果、このプロセスは有効性を実証し、私が働いていた企業に広く広まり、現在ではさまざまなプロファイルの専門家を採用するために使用されています。



数年前、私はすでにHR Unconferenceでそれについて話しました 。 しかし、スピーチの録音はなく、部門内の人を見つけることができない知人は詳細にますます興味を持っているので、私は最終的にすべてを詳細に描くことにし、同時にHabréに関する私の最初の投稿を公開し、読者の広いサークルと私の基礎を共有しました。



このプロセスの主な機能は次のとおりです。

• 新しい従業員を定期的に雇用する求人に最適です。設定に時間がかかりますが、定期的な雇用では非常に迅速に完済し、各候補者の意思決定プロセスを創造的なプロセスから候補者にとって数分かかるルーチンに変えます。より高品質のソリューションを提供します。
  
  
• これに伴い、候補者によるオファーの受け入れの割合が増加します。第1に、選択プロセス自体が候補者に好印象を与え、第2に、このプロセスを使用すると、すべての競合他社を先取りして、文字通り同じ日に人にオファーを出すことが可能になります彼が仕事に応募したとき。
  
  

それでは、典型的なプロセスから始めましょう。改善します。 これは通常そうです：

• 「必須の要件」で過負荷になっている空室。
  
  
• 最初の段階は履歴書によるスクリーニングです。
  
  
• それから、おそらく、最初のスクリーニングのための「エイチャー」との会話。
  
  
• その後、明確な計画のない長期にわたる技術面接を行い、実務経験について話し合い、arbitrary意的な詳細と「迅速なタスク」にまで深め、その結果として最終決定を下します。
  
  

自由なトピックに関する長い会話、隠れた才能を見分ける試みでの直感の使用、VKontakteプレイリストの分析など、非常に贅沢なテクニックが使用されることがあります（これらはすべて実際のケースです）。

ステップ1.空席をふるいにかける

まず、空席のテキストの改善を始めましょう。



空席の説明には、約12の「必須要件」がありますが、最終的には候補者が採用され、その半分だけが満たされます。 おなじみの状況？ この場合、要件が実際に必須であると考えることは可能ですか？



私の経験では、ほとんどの場合、これは雇用主の高い期待（偶然にも、数ヶ月の面接で誰も選べないという事実につながる）と、「必須要件」に該当するという事実のために起こります。彼の個人的なウィッシュリスト（「テスターであっても、bashに慣れていない人と仕事をすることはできません」;「開発者がgitに出会わなかった場合、彼は真剣に仕事をすることはなく、考慮しません」） 。 一部には、個人的なインタビューに多くの時間と労力がかかるという事実が原因でこのような要件が発生するため、履歴書を表示する段階でより疑わしい候補者を除外するためのヒューリスティックを探す必要があります。



だから、プロセスを改善するために必要なもの。

このステップでは、 本当に必要なものと必要なものを分離します。 これを行うことができない人を必須要件のリストからピンチして準備する準備はできていると思いますか？ はいの場合、そのような要件を目的の要件に転送します。 あまりにも多くの価値のない候補者が個人的な面接に参加することを恐れないでください。次のステップでこれから身を守ります。 今、何が必要で何が必要でないかを理解することが重要です。 わずかな食い違いのために、本当に価値のある応募者が排除されることを恐れてください。



以下の簡単なチェックリストは、必要なものと必要なものを区別するのに役立ちます。

1. すべての従業員にこのスキルが必要ですか？ たとえば、システム上のタスクの一部は、Vue.jsを使用する内部管理パネルの改良に関連しています。 開発スタッフの半分だけがVue.jsを知っている場合、そのような計画のすべてのタスクを解決するのにリソースは十分ですか？
   
   
2. 人はこのスキルをすばやく習得できますか？ たとえば、部門での作業がgit flowに基づいている場合、このスキルを候補者に要求することは絶対に必要ではありません-gitを使用したことがない場合でも、誰でも最初の2営業日でgit flowを簡単に理解できます。
   
   

一般に、次のことに注意する必要があります。いずれにしても、IT専門家は何かを学ぶ必要があります。 たとえプロファイルが現在の要件と100％一致している人を魔法のように見つけたとしても、数か月後には状況が変わり、すべての人が満たすわけではない新しい要件が確実にあります。 研究する必要のある新しいライブラリがプロジェクトに表示される場合があります。 新しい技術、方法論、およびこれらすべてを導入し、従業員が理解する必要があります。 したがって、現時点で高度なトレーニングを行うよりも、人が良い学習曲線を示すことがはるかに重要です。



したがって、説明した操作の後、必須要件のリストに残るのは3〜5ポイントだけです。 これらは、すべての従業員が所有する必要があるスキルであり、同時に比較的迅速に習得することはできません。 開発者の仕事で何が起こるかの例を次に示します。

• プロジェクトで使用される主要なプログラミング言語に関する自信のある知識（実際、従業員がJavaをよりよくマスターするのを待つ時間はありません）。
  
  
• プロジェクトで使用されている主要な技術に関する自信のある知識。短期間で開発することは不可能です（たとえば、マルチスレッドプログラミング）。
  
  
• 高い開発速度（従業員ごとにタスクの実行速度が10倍異なる可能性があると噂されており、この指標は個人によって時間とともに大きく変化することはないと考えています）
  
  
• 高い学習能力（上で書いたように、良い学習曲線が最も重要な指標であると考えています）;
  
  
• 現在の従業員との個人的な資質との互換性（他のプラスでも、チームに合わない人を連れて行く価値はないと思います）。
  
  

今、あなたの仕事は確認することです。

ステップ2.必須要件の検証のための客観的なメカニズムを開発する

人は多くの認知的歪みを被るので、候補者を評価するという問題において客観的で偏見のないことはできません。





この点で、私は人的要因を排除し、可能な限り選択プロセスを客観化するよう努めます。 追加のプラスの効果は、プロセスが任意の人によって再現可能になり、インタビュー対象者の人格要因が候補者の結果に影響を与えなくなることです。



TripleByteは、候補者の選択に特化した会社であり、候補者と協力する方法について10の論文を提出し、それらを自分のマニフェストと呼びました。 私の経験では、これらの論文を100％確認しています。





正式な基準に従って客観的に比較できるようにする候補を評価するためのいくつかの方法を特定し、この比較の結果が候補の実際のレベルと非常に相関するようにしました。

1.回答オプションでテストする

回答オプションを使用して適切なテストを行うことは簡単ではありません。 不正行為者が最高得点を獲得できないようにするには、テストが次の基準を満たしている必要があります。

• 回答はグーグルであってはなりません（少なくとも割り当てられた時間内）-このため、良い質問には実際の知識は必要ありませんが、正しい答えに到達するためにトピックの深い理解に基づいた頭の操作が必要です。
  
  
• 質問にコードのブロックが含まれている場合、正しい答えを見つけるために実行することはできません。
  
  
• 質問は単純すぎてはいけません（この場合、それに対する答えは情報を与えません）。
  
  
• 質問は複雑すぎてはいけません（正解の割合が1 / _
  
  
  
  number_ofオプションに近い場合、 敗者を排除し、トピックをより悪く知っている人は排除しません）。
  
  
• 仕事中に簡単にグーグルになることができるものの心で知識をチェックするべきではありません-頭の中にこの知識が存在しても、何も表示されません。 正解は知識ではなく理解を示すべきです。
  
  
• 候補者が私たちの仕事で使用されないことを確認しないでください（「一般的な博学」、高度なデータ構造とアルゴリズム、物理的プロセスをシミュレートする能力など）-質問は必須要件に従ってのみコンパイルする必要があります。
  
  
• 回答オプションの数は4から7までです-3つ以下の回答オプションでは、推測の確率が高すぎますが、7つを超える回答オプションでは、すべてのオプションを頭に入れずに混乱する可能性が高くなります。
  
  

時間の経過とともに、良い質問を書くのに役立ついくつかのテクニックを開発しました。

• いくつかの論文（1対1でグーグルしないように再構成）、そのうちの1つはfalse（または1つはtrue）-名前を付ける必要があります。
  
  
• コード/構成でエラーを見つけます（多くの物議を醸す問題、そのうちの1つはエラーで、残りは比較的まれなケースです）。
  
  
• コード/リクエスト/ ...そして、それが何をするかについてのオプションに答えます 実行して検証できないようにするために、コードは入力でいくつかの引数を受け入れ、それらなしでは機能しません。 別の「バインディング」が必要です。これがないと、起動しないか、正しく機能しません。
  
  
• code / request /...。挿入する行とコードバリアントがありません。 コードがタスクで指定されたタスクを解決するように、正しいオプションを代用してください。
  
  

PluralSight （以前のSmarterer）は、さまざまなトピックに関する回答オプションを備えた適応テストを提供します。次の質問は、以前の回答を考慮して複雑さに応じて選択されます。 最終的には、興味のあるトピックに関するいくつかのテストを解き、好きな質問に触発されて、独自の同様の質問を作成できます。



質問の良い例はTripleByteにもあります。質問テキストにはまったく異なるプログラミング言語のコード例が含まれていますが、これらの言語を知らなくてもすべての質問に答えることができます。 したがって、彼らは素早い知恵だけでなく、候補者の動機もチェックします-一部の人々は、コードを読もうとせずに、なじみのない言語の名前を見るとあきらめます。 私の経験では、人々はそのような質問の90％以上、または50以下に答えています。実際には中間結果はありません。





もちろん、スクリーンショット付きのコードブロックを提供して、実行を困難にします。



テストには、 TypeFormプラットフォームを使用します。 特に、プラットフォームはテストに費やされた合計時間を計算できますが、これは重要な要素です。 フォームは、会社の色でブランド化できます。 SurveyGizmoプラットフォームも気に入っています。以前はそれを使用していました。



この段階の主なタスクは、価値のない候補者のかなりの部分を排除することであり（したがって、より多くの見込み顧客をカバーする）、すべての可能性を残します。 つまり、偽陽性は偽陰性ほど怖くない。 したがって、テストに合格するための要件を少し過小評価するようにします（欠点ではなく、利点を特定します）。



履歴書によるスクリーニングを除外し、全員をテストに送ります！ これは会社の努力を必要とせず、良いテストは候補者にとっても喜びです。 履歴書が貧弱な優秀な候補者とよく会いました。また、履歴書を美しく表現する能力は、通常は候補者の仕事の質とはあまり相関しない別のスキルであると確信していました。 。

2.実用的なタスク

多くの企業は、インタビューで「私たちの街にハッチがいくつあるか」や「N計量用の偽コインを決定する方法」などのタスクを提供しますが、これらの質問に完全に答えた候補者が驚いたことに（つまり、明らかに、人生で多くのインタビューがありました）そして、そのようなタスクを暗記することで）うまく機能しません。 インタビューでそのようなタスクを使用することで長い間有名だったGoogleは、それらが機能しなかったことを最終的に認めました。



私は次の立場を堅持します。人がどれだけうまく働くかを理解するには、面接を受ける必要があります...彼を働かせてください！



このため、テストタスクは完全に適切であり、通常の作業アクティビティを可能な限り模倣します。 私はそれぞれの役職でそのようなタスクを開発しています。 以下は開発者のポジションの例です。









開発者にはさらにタスクのシーケンスが与えられます。 これらはオリンピアッドの問題ではありませんが、外見上はすべてが似ています！ これらは、候補者が職場でやらなければならないことを最もよく反映するタスクです。 たとえば、APIを介してさまざまな広告ネットワークのストリームに接続することを含むポジションの候補者については、 誰も正確に（候補者の初期ポジションを均等化するために） 作業しない APIを選択し、このAPIに関連するタスクを完了しました：

• 候補者の注意;
  
  
• 複雑な回答を解析する機能。
  
  
• 不十分に書かれた仕様を理解する能力;
  
  
• APIが常に正しく動作するわけではないことを検出して回避策を適用する機能。
  
  
• インターネットで追加情報を検索する機能。
  
  
• 複雑なデータ構造を処理する機能。
  
  

一般的に、さまざまなAPIを使用する際に本当に対処しなければならないことすべて。 上記のAPIリンクでこれらすべてを見つけることができました。



まだアイデアを持っていない人にとって良い出発点は、 CryproPals.comサイトです 。このサイトには、暗号化を含む特別な知識を必要としない暗号化のテーマに関する簡単なタスクが含まれています。



管理者用に、負荷の目標を達成するために問題を理解し、構成を修正する必要がある仮想マシンを準備しました。 この場合の候補者の成功の鍵は、基本技術の基本知識、インターネット上の情報を検索し、ログを分析し、bashを効果的に使用する能力の組み合わせです。 Yandexは、 Yandex.Root Olympiadsの一部として同様のタスクを提供します。



テスターに​​はページが提供され、できるだけ多くの問題を見つけるように依頼されました。 同時に、問題は非常に異なる計画である可能性があります：境界値と脆弱性を入力するときのバグ、システムに大量のデータを入力するときの応答性の低下、jsコンソールのエラー、使いやすさの問題。 それはすべて、候補者にどのような能力を求めているかにかかっています。



アカウントマネージャーではもう少し複雑でしたが、実際的なタスクを定式化する方法も見つけました：合成クライアントの異議申し立てを行い、マネージャーに回答を書くよう依頼し、重要な設定のどれが回答に使用されたかをポイントで確認しました（たとえば、コミュニケーションは古いクライアントと行われ、会社の売上高のかなりの部分を占めることに注意してください。クライアントが自分にとって不利であるが有益なオプションを主張しているにもかかわらず、マネージャーがウィンウィンのソリューションを見つけようとすることが重要でした 短期的には会社のために）。



このタスクの重要な肯定的な特徴は、問題を解決するために、通常の作業プロセスと同様に、利用可能なあらゆる手段を使用できるため、候補者を管理する必要がないことです。

3.個人面接

個人面接は最も時間がかかり、最も主観的なものですので、その上で、私はそれ以前の段階ではチェックできないものだけをチェックしようとします。 通常、ビジネスは小さいままです。

• 候補者と現在の従業員との個人的な互換性を確認します。
  
  
• 兄が候補者のテストに合格しなかったことを確認してください。
  
  

後者は、合格したテストに関する追加の質問によって確認されます。なぜあなたはそのように答えたのですか。 そして、この入門編が変更された場合の回答の変更方法。 なぜ実際のタスクでこのような方法でこのようなことを実装したのでしょうか。



もちろん、そのような話はあまり起こりません（私はそのようなケースに出会ったことはないようです）、そして、いずれにせよ、トライアル期間ですべてがすぐに明らかになりますが、なぜそれをもたらします。 最終的に、採用担当者は採用された候補者に対しても支払わなければならない場合があるため、可能であればすぐに不正行為者を特定することが最善です。



ちなみに、個人的なインタビューの最初に、候補者が驚いたことに、最初に履歴書を開きました。

4.その他のオプション

候補者の資質を客観的にテストするために他のオプションを試すことができます。世界は上記の方法に制限されません。 私はしばらくの間テストタスクを使用しましたが、この段階は冗長であると判断し、放棄しました。 主なアイデアはテストがあるということではなく、実際的なタスクがあるということを忘れないでください-それらを使用してください。 そして、最初のステップであなたが候補者から本当に必要なものを理解し、それからこれをチェックする最も簡単な客観的な方法を見つけるべきであるという事実。

ステップ3.チューニング

このメカニズムがすぐに機能すると信じてはいけません。 それは決してありません。 このプロセスの「段階的な入力」の方法を使用します。



最初の段階では、レベルがよくわかっていて、結果を予測できる人のテストに合格するようお願いします。 通常、これらは現在および以前の同僚および友人であり、その専門性のレベルは私には完全に明らかです。 彼らに各段階をテストさせ、彼らの結果が私にとってどれほど予測可能であるかを見てもらいました。 たとえば、管理者タスクを開発者に与えて、その結果がパスよりも低くなるようにして、プロの管理者がパスの結果を取得するようにすることもできます。 理想的には、ほぼ100％のケースで十分に強い人が合格し、弱い人ができるだけ頻繁に合格しないように、予選ステージを作成する必要があります。



安定した相関関係を達成できる場合は、第2段階である戦闘検証に進みます。 最初の5〜10人の候補者は、資格段階での結果に関係なく、個人面接に持ち込みます。個人面接では、テストでテストされた各基準に従って、出席者全員に互いに独立して評価を与えるようお願いします。 同時に、出席している同僚は、テストでの候補者の結果、および互いの評価を知りません（グループ思考の影響を最小限に抑えるため）。 予選段階を通過した候補者が1つずつ失敗し、個人面接を受けた場合は、電話をかけるのをやめることができます。



資格のある段階と個人インタビューの結果との相関が低い場合は、問題を特定して修正するようにしてください。



回答オプションを使用したテストでは、次を実行します。

• 誰もが答える質問を見つけます それらを除外するか、より難しくします。そうしないと、情報を伝えません。
  
  
• おおよそランダムに回答オプションに分類されるレベルで回答される質問を見つけます。 それらを除外するか簡略化します。 この質問は、候補者の約50〜60％が回答した場合に最も多くの情報を提供します。
  
  
• 正しい答えが単純な基準で焦げているかどうかを確認します。 たとえば、常に最長の回答を選択した場合、テストで得点するポイントはいくつですか？ ほとんどの場合、これについて考えたことがない場合、正しい答えのほとんどが最も長くなります。
  
  
• 個々の質問と候補者の最終印象および他の段階を通過した結果との相関関係をカウントします（相関関係の計算機能は、スプレッドシートですぐに使用できます）。 ゼロまたは負の相関に近い質問は、削除または改善する必要があります。ほとんどの場合、何らかの問題があり、必要なものをチェックしません。
  
  
• 強い人が質問に間違って答えた場合、このオプションを選んだ理由を個人インタビューで確認してください。 何かを考慮していないか、質問がエラーで構成されているか、あいまいさを含んでいるか、単に何もチェックしていません。
  
  
• 削除されたすべての質問の代わりに、新しい質問を考えて、その数を大まかに保存します。
  
  

実際のタスクでは、ランダムな要因を排除してみてください。 例えば、そのような困難があり、それとの衝突は候補について悪いことを何も言わないが、結果に強い否定的な影響を与える。 たとえば、APIを使用したタスクでは、APIの作成者がAPIを操作するためのライブラリを提供したが、実際には機能しませんでした。 それを使用しようとした人は多くの時間を失い、悪い結果に終わりました。 タスクでは、このライブラリを使用する必要がないというヒントを作成しました。 結局のところ、先験的にそれを使用しようとする試みは間違った行動ではないので、結果に悪影響を与えるべきではありません。



テストは最初は常に良いとは限りませんが、ほとんどの場合、テストと実践を完全に機能させるには1回の改良で十分です。

ステップ4.委任

システムが適切に配置されている場合、テスト段階での回答オプションとのすべての対話は、人事マネージャーやオフィスマネージャーなど、組織のすべての従業員に完全に委任できます。 2番目の段階はどの人でも実行できますが、実際には、その人は会社についての候補者の質問に答えるために新しい従業員が求められているのと同じ立場をとっており、そのため2番目の段階を完了するようにやる気を起こさせます。 候補者とのコミュニケーションには、この段階で5〜10分かかります。



委任するとき、選択の客観性が低下しないことを確認してください-採用された各候補者の正式な結果を記録することを必須にします。

まとめ

システムが整ったら、個人面接を受けてシステムに入った人の半数以上を受け入れることができます。 このようにして募集されたすべての候補者は試用期間を過ぎ、私は彼らを優秀で効果的な従業員と呼ぶことができます。

スタッフを拡大する必要があるとすぐに、上記のシステムを使用した次の新しい従業員の効果的な検索は非常に簡単かつ迅速になります：主なことは、候補者の着信ストリームを整理することであり、このストリームから最適なオプションを選択することは、できるだけ早く、痛みなしに解決される非常に簡単なタスクになります選択の。



したがって、基本的な手順を繰り返します。

1. 必須要件のリストを批判的に見て、いくつかの主要な要件のみを残そうとします。
   
   
2. , — , ; , ;
   
   
3. , ;
   
   
4. , .