ArcBlock の採用プロセスを簡単に突破する方法

著者：Robert Mao (ArcBlock CEO 兼チーフアーキテクト)

ArcBlock は長年にわたり設立・発展してきましたが、採用活動を止めたことはありません。異なる段階での違いは、欠員数とペースだけかもしれません。私たちのチーム構築の原則は「量より質」であり、厳格な採用評価によって ArcBlock は少数精鋭の効率的なチームを維持してきました。同時に、私たちは数多くの面接に多大な時間と労力を費やしてきましたが、時には候補者から ArcBlock の採用プロセスに対してわずかな不満の声が上がることもありました。以下の内容は、ArcBlock に興味をお持ちの候補者の皆様が、私たちの採用プロセスをより良く理解し、より簡単に面接を突破できるよう支援するためのものです。

ArcBlock の採用プロセス

ArcBlock の現在の採用プロセスは、Microsoft の採用プロセスを最適化したものです。

Microsoft の各グループのプロセスは若干異なりますが、全体としては非常に厳格です。採用する企業側は、多大な人員と時間を必要とします。私がかつて在籍していた Microsoft Research Institute（マイクロソフトリサーチ）は、非常に厳しい面接プロセスで知られていました。

面接当日、一般的に「不採用（no hire）」が 2 回出た場合は継続されず、それ以降の面接はすべてキャンセルされます。したがって、候補者が HR から 5 回の面接予定を知らされていたにもかかわらず、すべて行われなかった場合は、基本的に「不採用」を意味します。逆に、通常、最終面接まで到達した場合は、採用される可能性がかなり高いことを意味します。

Microsoft の面接では、各ラウンド間で意見交換が行われます。つまり、次の面接官は前のラウンドの結果を知っており、前のラウンドで「次のラウンドで重点的に確認すべき」と提案された事項も把握しています。ArcBlock もこの慣行に従っています。Google は異なるアプローチを採用しており、各ラウンドの面接は独立しており、その後委員会によって集合的に評価されると言われています。

ArcBlock の現在の採用プロセス：

私たちのプロセスも似ていますが、総時間は大幅に短縮されています。もう一つの特徴は、コーディングテストのセグメントがより高い要件を求めている一方で、より多くの時間を提供し、候補者が自分の能力をより十分に発揮できるようにしている点です。

ArcBlock のコーディングテスト

Microsoft であれスタートアップであれ、私たちの採用面接の方法にあまり賛成しない人に出会うことがあります。例えば、私たちのコーディングテストは、私たちの見解では最も重要な部分です。なぜなら、リラックスしたプレッシャーのない環境で、十分な自由度を持って、明確に定義された小さな問題を解決することが求められるからです。もちろん、一部の人にとってこの「自由」はまさに「不明確な目標」でもあります。実際、どちらの視点も正しいのですが、私たちがシミュレートしているのはチームの働き方であり、非常に詳細なタスク定義を好む個人は、他のチームでは高く評価される人材かもしれませんが、必ずしも ArcBlock のチームに適しているとは限りません。

過去にある大企業で働いていたとき、システム設計の質問を拒否した候補者に会ったことがあります。彼は、秘密保持契約を結ぶか採用するかしない限り、自分の「素晴らしい」アイデアは共有しないと主張しました。また、コーディングテストを要求することは、自分たちの技術を宣伝するための手段だと考える候補者や、私たちの手法を批判する記事を公開する人さえいました。これらは否定的に見えるかもしれませんが、実際にはこのスクリーニングプロセスの有効性を十分に証明しています。これらの候補者は確かに並外れたアイデアや個性を持っているかもしれませんが、少なくとも私たちとは異なる価値観や認識を持っていることが分かります。不適切な候補者を採用してお互いの時間を無駄にすることなく、早期に特定して終了させることは、双方にとって最大の利益です。

ArcBlock の面接：問題の詰め込みは不要

コーディングテストに加えて、面接の各ラウンドで候補者に「簡単な」コードを書いてもらいます。現在、テクノロジー企業でのプログラミング面接はすでに非常に一般的になっているため、皆さんも慣れているかもしれません。

過去 10 年間、多くのテック企業は面接で「高難易度」の頭を悩ませるアルゴリズム問題を提示することを好んできました。その結果、「問題を解きまくる（grinding problems）」という傾向が深刻化しました。しかし最近では、問題演習で回避できてしまうようなコーディングテストは一般的に行われなくなっており、ArcBlock も例外ではありません。前述のコーディングテストであれ、面接中のテストであれ（基本的に各ラウンドの面接でコードを書くことは避けられません）、私たちは比較的シンプルで直接的な質問で面接を行うよう努めています。アルゴリズムのテストであっても、「復習」なしでは答えられないような問題は避けるようにしています。

私が面接で使用した例を挙げると、例えば「整数文字列を整数に変換する関数を実装する（C 言語の itoa に相当）」というものがあります。これは非常にシンプルな質問で、アルゴリズムの知識がなくても実装できるはずです。しかし実際には、過去の面接の 80% 以上で、人々はこのコードを完全に正しく書くことができませんでした。主な理由は、いくつかの境界条件（符号付き整数の処理、非常に大きな整数の処理など）の考慮が不十分だったためです。

もう一つのタイプの質問は、回答が「オープン」な質問です。通常、非常にシンプルなプログラムから始まり、非常に難しい問題になるまで段階的に難易度を上げていきます。例えば、実際の面接では T9 入力方式の実装を使用します。最もシンプルなバージョンから始め、徐々に予測入力の実装を求め、さまざまな最適化バージョンを検討してもらいます。このタイプのオープンエンドな面接の質問には標準的な答えがなく、どんどん難しくなっていくため、個人の総合的な能力を十分にテストすることができます。

面接は双方向の選択プロセス

面接は企業が求職者を面接するだけでなく、求職者が企業を面接する場でもあります。

通常、IT 業界では、採用側と求職側の立場はかなり対等です。求職者としては、面接を通じてオファーを得たいと願うのは間違いありません。本当に好きな仕事かもしれませんし、チームの技術的な雰囲気や同僚に憧れているのかもしれませんから、緊急度が高くなるのは理解できます。実際、採用側としての企業も同様に切実です。完了させたり探索したりする必要があるタスクが多くあり、すぐに適任者を見つけたいと考えています。採用プロセス中、企業は候補者を理解するために最善を尽くします。候補者もまた、この機会を利用して会社についてより深く知り、そこが自分にとって適切な場所かどうかを判断すべきです。

面接中、私たちは候補者に「何か質問はありますか？」と尋ねることがあります。これは質問をする絶好の機会です。一般的に、60 分の面接では、私は 2～3 分ほど雑談し、その後 30～50 分をコーディングや設計に関する質問に費やし、残りの時間を質問への回答に充てます。

面接は「試験」ではなく、日常業務の縮図

面接中、困難に直面して行き詰まったらどうすればよいでしょうか？面接は試験ではなく、実際の業務を凝縮したものだということを忘れないでください。問題に行き詰まったときは、自分で解決しようとするか、助けを求めることができます。通常、面接官は面接中に喜んであなたをサポートします。

したがって、面接中は黙って考え込んだり、すぐにコーディングを始めたりするのではなく、自分の考えを声に出して伝えるようにしてください。自信がある場合でも、まず問題に対する理解と解決へのアプローチを簡潔に説明し、それからコーディングを始めてください。回答中に困難に遭遇した場合は、どこで行き詰まっているのか、どのような問題に直面しているのかを面接官に伝えてください。通常、面接官は助け舟を出してくれます。これは通常の業務と同じだと考えてください。あなたと同僚が協力して問題を解決する場合、チームとして、どのように行うつもりかを同僚に伝え、問題が発生したときは助けを求め、彼らと議論するはずです。

ほぼすべての面接官は、あなたに障害を作るのではなく、実際にはあなたが合格することを願っています。これは実は企業の面接における「秘密」です。面接に来るすべての人に対して、私は心からあなたがスムーズに合格することを願っています。ですから、面接官の心理はあなたを困らせることではなく、あなたが実力を発揮して面接に合格することを心から願っているのです。あなたがスムーズに合格すれば、私たちはより多くの人を面接するために時間を費やすことなく、すぐに欠員を補充できます。特定のポジションについては、多くの人を面接し、長い時間と労力を費やしてきた場合、この願いはさらに切実なものになります。

ArcBlock は内部でどのように面接を評価しているか？

ハイテク企業にとって、人材は最も重要な資産です。間違った人を採用することは、会社にとって大きな損失となる可能性があり、時にはその損失は計り知れません。そのため、採用プロセスを厳格に管理することは非常に重要です。

私たちの採用面接の評価には、Yes（採用）か No（不採用）の 2 つの選択肢しかありません。Strong Hire（強く採用を推奨）や Strong No Hire（強く不採用を推奨）もあります（Strong No Hire が 1 つでもあれば、結論は必ず不採用になります）。曖昧な判断や、他人に判断を委ねるような不確実な評価は認められません。

私が Microsoft の最初の採用トレーニングで深い印象を受けた原則は、「迷ったら、採用しない（Whenever in doubt, No hire.）」というものでした。この原則は ArcBlock にも受け継がれているため、面接で確信が持てなかったり、何かが違うと感じたりした場合は、不採用となります。

これほど厳格な要件を求めているのは、私たちが「完璧な」人間だけを探しているからでしょうか？実はそうではありません。実際、私たちは面接で明らかに問題を露呈した人を採用することもあります。完璧な人間などいませんし、面接中にアルゴリズムでたまにミスをしたからといって、あなたを拒絶することはありません。多くの場合、それは理解できることです。しかし、例えば、ある面接候補者が非常に高いコミュニケーション能力を示し、過去の多くのブログや記事で優れた理解力を発揮していても、私たちのコーディングやアルゴリズムのテストで数回にわたって振るわなかった場合、私たちは疑問を抱きます。一度疑問を抱くと、通常は採用しないことを選択します。

採用されなかったからといって、あなたの能力に問題があるわけではない

求職者が採用されなかったことは、その求職者の能力に問題があることを示すものではなく、単にその職務や会社のチームに合っていなかったというだけのことです。私たちの面接や他の会社の面接に合格しなかったすべての学生への私のアドバイスは、それを気に病まないことです。自信を失う必要はありません。焦点を切り替え、自分により適した他のポジションを見つけることに集中してください。

私たちの採用プロセスが気に入らない方、特にコーディングテストの手法に意見がある方、各ラウンドの面接で非常にシンプルなコードを書かなければならないことが自分の豊かな経験と一致しないと感じる方は、私たちの働き方やスタイルがあなたと合っていないことを示しているに過ぎません。お互いの時間を節約するために、適宜辞退していただいて構いません。私たちのやり方に同意しないからといって、あなたの見解が間違っているわけではなく、単に私たちの仕事のスタイルが一致していないことを示しているだけです。

ArcBlock の採用プロセスは、実用主義と経験主義の産物であり、私たちの過去の仕事から蓄積された自己認識によるベストプラクティスです。これは将来の実践の中で継続的に調整され、反復されていきます。私たちの目標は、双方が相互の発展に適していると感じる人材を見つけることです。

もしあなたが ArcBlock に参加したばかりなら、上記のプロセスを経てきたことでしょう。おめでとうございます！将来、あなたは ArcBlock チームで再びこのプロセスを経験することになるでしょう。ただし、今度は別の立場、つまり採用担当者としてです。

説明：ArcBlock の採用および面接トレーニングに関するこの記事は、一般の方々と私たちの内部チームの両方を対象としています。新しい IT 時代において、私たちは内部チーム構築において徐々にオープンで透明な戦略を採用していきます。トレーニングの内容やコースは内部と外部で区別されることはなく、過去の内部トレーニングの資料やビデオも徐々に整理して公開していく予定です。