こんにちは、Habr！ 数か月前、私の同僚
は 、チームを5回拡張すること
について話しました。2020年の終わりまでに50人から250人の開発者になりました。 ご想像のとおり、現在、採用に多くの注意を払っています。 同時に、私たちは「量で取る」準備ができていません。全員を一列に雇って、「それなら私たちはそれを理解します」と言います。 今後数年間、人々が本当に私たちのチームの一員になることが重要です。 かつて私たちを新しい形式のインタビューに導いたのは、この動機でした-テストの日。 彼については、カットの下で議論されます。
数字でネタバレ。1.5年間、私たちは40人以上を雇い、4人の開発者だけが私たちを去りました。1人はビジネスを始め、残りはヨーロッパに移りました。
イントロ
候補者と私がお互いをよく知ることができるように、非常に長い雇用パイプラインがあります。
ちなみに、後者は非常に重要です。
サーシャは心と心の会話の達人であり、最も厳しく控えめなオタクでさえ率直な会話に持ち込む方法を知っています。
これらすべてに加えて、候補者と試験日を過ごします。 どうして別の日？ 候補者について何を知りたいのか、候補者に何を見せたいのか？ そして誰がこれにまったく同意しますか？！
ドードーでのテスト日
テスト日の開始は簡単な決定ではありませんでした。 HRチームは、採用パイプラインがさらに長くなったことに満足していませんでした。「優秀なスペシャリストはそれほど多くは行かないでしょう。すでにいくつかのオファーがあります！」 しかし、別の意見がありました。 テスト日は、潜在的な従業員がそこで仕事をすることなく、会社の実際の状況について学ぶユニークな機会です。 例：
- 実際の労働条件について学びます 。 どんな仕事、家具、コンピューター。 IT従業員が座っている部屋に窓があります（結局、彼らはしばしば窓のない部屋に置きます：「とにかく、彼らは一日中モニターを見ています」）。
- 誰と仕事をしなければならないかを見つけてください 。 インタビューリーダーのTimlidは素晴らしいですが、チームとして働く必要があります。 そして、申し出を受け入れる前にそれが誰で構成されているかを確認することは間違いなく不要ではありません。 あなたが開発者の一人とペアになり、他のカップルをスパイし、これらの人々と並んで仕事をすることができるかどうかを理解する機会があると想像してください。
文字通り「サイドバイサイド」。 ペアプログラミングを積極的に練習しています。 特に最近私たちのところに来た開発者にとっては、ペアで作業する方がはるかに効果的です。 そして、テスト当日は、ペアワークの「テストドライブ」を直接行うユニークな機会を提供します。 - あなたが本当にしなければならないことを見つけてください 。 空室に示されているこれらの最先端技術のリストはすべて素晴らしいものであり、私たちにとってはラプンツェル編組よりも長いです。 しかし、それはあなたがとられる現在のタスクにめったに関連しません。 バックログ、製品コードを見て、あなたがしなければならないこととあなたがそれを自分でやりたいかどうか
を理解するために泣くのはいいでしょう。 - 使用しなければならないツールについて学びます 。 コーディングルールとその遵守方法について実際に学習します。 たとえば、Visual StudioではなくRiderで作業するのが慣例です。 私たちのところに来るかどうかを決めるとき、それは非常に重要になるでしょう。 同様のニュアンスは、ほぼすべての場所に存在し（原則として、歴史的な理由により）、雇用契約に署名する前にそれらについて知ることをお勧めします。
- チームでの本当の仕事の日がどうなるかを調べてください 。 まともなチームでは、少なくとも毎日のスタンドアップがあります。 チームのメンバーが互いにどのようにコミュニケーションを取り、その雰囲気がどのようなものかを理解するために、彼らがどのように進むかを見ることが重要です。 ドードーでは、もう少し先に進んで、候補者を当日の一般公開活動、devForum、計画、またはレビューに招待します。 毎日何かが起こっているので、潜在的な同僚同士の相互作用をより広く見る機会があります。
候補者にとって、テスト日はまず第一に、彼がこの会社で働く準備ができているかどうかについて十分な情報に基づいた決定をする機会です。 ゼロ広告のでたらめ、唯一の本当の事実。
すべての場所でそのような機会があったので、最終的にはその場所に行かないでしょう。 そして、今では灰色がはるかに少なくなります。
もちろん、テスト日は、企業がビジネスの候補者を見る機会でもあります。
- 「インタビューマスター」を確実に認識したい これを行うための最良の方法は、実際の作業の過程で人を見ることです。 彼はどのくらい早く新しいコードをナビゲートし始めますか？ コードを読むことは、ある推定では、開発者の時間の最大70％です。 同時に、彼がそのタスクでどのようなソリューションを提供するか、どのようにコードを書くか、そして彼が受け入れられた標準に従うかどうかを見ます。
- 私たちは、人がいかに活動的であり、ソリューションのイニシエーターとして行動できるかを理解したいと考えています 。 もちろん、なじみのないコードのソリューションをすぐに提供し始めることは困難です。 しかし、 Dodo ISのような大規模システムでは、1年の作業の後に見慣れないコードに遭遇します。 テストの最下部にいる人が「来て、どうやってやるのか見せて」という表情で座っている場合、これは悪い兆候です。
- 私たちは、人がどの程度「快適」に働いているかを知りたいと思っています 。 これはペアリングの際に特に重要です。潜在的な同僚はパートナーから「キーボードを引き裂く」でしょうか？ 彼は自分の決定の正しさを冷静に説得することができますか、それとも彼の間違いを説明することができますか？ ペアワークは知性の非常に密接な相互作用であり、新しい従業員はそのような相互作用において「有毒」であってはなりません。
上記に基づいて、「テスト日」は5時間未満にすることはできません。 また、昼食の候補者を取ります。これにより、非公式のコミュニケーションで潜在的な同僚を見る機会が与えられます。 そして、オフィスの外の候補者を見てみましょう。
同時に、このプラクティスを連続してすべての空席に拡張することは意味がありません。 たとえば、私たちは後輩のためにテスト日を費やしていません。初心者の開発者は、コードに飛び込んだりタスクに取り組んだりするために真剣なチームの努力が必要です。 ある日、彼らの可能性を示すことはできません。
テストタスクの代替として、テスト日の形式を考え出しました。 多くの人にとって、完了したテストタスク（特に開発者にとって）が答えよりも質問を残すことは明らかだと思います。 同時に、多くの優秀な候補者が単に彼に採点されます。
結果
実際、1.5年で40人以上を雇い、4人の開発者だけが私たちを去りました。1人は自分のビジネスを始め、残りはヨーロッパに移りました。
人気のあるテスト日の質問
テスト日の事実は、候補者の間で驚くべきことです。 ショックから回復した彼らは、基本的に同じ質問をします。 私はそれらを電撃の形で答えます。 読者にとっても興味深いと思います、私の読者：
- テスト日は支払われますか？ いや
- 別の都市にいる場合はどうなりますか？ 欠員がオフィスでの仕事に関係している場合は、テスト日にこのオフィスに来る必要があります。 論理的です。 そうしないと、上記のリストから何かを見つけることができなくなります。
- 夕食に行かなければなりませんか？ いや あなたは自分のものを持って行くことができます-あなたが常に自分のものを持っていることを計画している場合、それはさらに良いです。 キッチンがディナーに適しているかどうかを確認できます。
- 何を持っていきますか？ 冬には、シフトを取る必要があります-それはより便利になります。 これ以上。
テスト日を試してみませんか？ 来て、使ってください！