🍜

Web エンジニア向け採用課題を作ってみた

2024/05/29に公開

Rails

はじめに

概要

※ 本記事はソースコードや技術的要素が少ないエッセイ的な内容になっています。

これまで弊社(HERO Innovation)ではエンジニアの採用を、書類選考と面接のみで実施していたのですが、今後の採用拡大計画に伴い、採用課題も導入することとなりました。

この記事では、課題作成にあたって検討したことや、実際に作成した課題について紹介します。導入したばかりということもあり運用後の効果はまだ不明なので、その点については別の記事で取り上げようと思います。

対象読者

採用課題の導入を検討している方
弊社採用課題に挑戦いただける方

補足

この記事は主に採用課題の作成プロセスにフォーカスを当てています。また、求めるスキルや募集条件については、事前に決定しているものとします。
Rails を使用した Web アプリケーションの機能実装を課題として作成したのですが、 Rails っぽい話はほぼないです。

プロセス1: 採用課題の目的を明確にする

まず第一に、なぜ採用課題を導入するのかという点を明確にしました。私たちの場合、一緒に働きたいと思えるエンジニアを採用すること、言い換えればミスマッチを防ぐことが今回の採用課題導入の目的でした。

私たちは、弊社が求めるエンジニア像と応募者の能力が一致しないことをミスマッチと呼んでいます。仮にすごいエンジニア代表 DHH がうちに応募してくれたとしても、ミスマッチになってしまうでしょう。

採用課題の目的まとめ

一緒に働きたいと思えるエンジニアを採用すること

あまり書けることも少ないのですが、個人的にはこのプロセスがもっとも重要だったと思っています。メンバー全員が納得いくまで話し合い、現状ある組織課題の解決を目的としました。

プロセス2: 課題を設計する

では、私たちが求めるエンジニア像とは何でしょうか。端的に言えば、相手の立場に立つ能力と、自分で考える能力があるエンジニアです。採用課題は、このエンジニア像に合致するかどうかを判断できるように設計しました。

エンジニアの採用課題というと、アルゴリズムやSQLの知識を問うものが多いですが、今回は自分たちの目的に沿って、実際の業務に近い機能実装に挑戦していただくことにしました。プログラミング的な知識よりも、実際の業務に即した課題にすることで、相手の立場に立ち、自分で考える能力があるエンジニアかどうかを見極めることができると考えたからです。

相手の立場に立つ能力とは、例えば機能実装ならユーザーの視点に立った実装ができるかどうか、メンバー間のコミュニケーションなら、レビューワーがレビューしやすい Pull Request を作成できるかどうかなどを指しています。この考え方は、私のお気に入りの一冊である『Team Geek ―Googleのギークたちはいかにしてチームを作るのか』に出てくる「HRT の原則」に影響を受けています。

数年前、私が受けたことのある採用課題は、簡単なメソッドを Ruby で実装するものと SQL の知識を問う問題でしたが、現在だと ChatGPT をはじめとした生成 AI に任せれば一瞬で回答が得られるようなものでした。こういった課題では私たちが求めるエンジニア像と一致するかどうかを判断するのは難しいです。また、私たちのチームでは業務で生成 AI を使うことを推奨しているので、その点も考慮し今回の課題を設計しました。

課題の設計まとめ

業務に即した機能実装を課題とすることで、求めるエンジニア像とマッチするかを判断できるようにする

プロセス3: 評価基準を考える

ある程度事前に評価の目安を設定しておくことも重要です。繰り返しになりますが、基本的には、私たちが求めるエンジニア像に合致するかどうか、という点で評価することにしました。

具体的には、保守性の高いコードになっているか、 PR の概要をしっかり書けているか、などです。ざっと、10~20項目くらい考えたのですが、事前に言われずにどの程度までやってくれるかという観点でも評価したいので、ここでは詳細は割愛します。

評価基準まとめ

どういった回答なら「求めるエンジニア像」に合致するのか、事前に明確にする

プロセス4: 課題を作成する

ここまで来ればあとは作成するだけです。前述した評価基準の項目を判定できるような課題を作成しました。

課題の一部を改変し、以下に抜粋します。

課題
Aの課題を解決してPRを作成してください。所要時間は1,2時間を想定しています。完答必須ではありません。可能な範囲でお取り組みください。

なお、PRやコミットの粒度は任意です。

A
記事作成のバリデーションを追加し、「タイトル」と「内容」に空文字を登録できないようにしてください。

期待すること
課題は不明瞭に記載してあります。詳細仕様はご自身でお考えのうえ、実装してください。ユーザーの視点にたった実装になっていると、より好ましいです。
PRは、レビュワーの視点にたったレビューしやすいPRになっていると、より好ましいです。

採用側も候補者様側も、どちらにも負担がかかりすぎない課題を意識しました。ここには記載していませんが、採用候補者間のやり取りを最小限にするため、必要事項はすべて README に記載し、レビューのフィードバックなどは面接時にディスカッション形式でおこなうようにしました。

課題作成まとめ

評価基準の項目を判定できるような課題を作成する
課題は採用側も候補者様側も、どちらにも負担がかかりすぎないようにする

おわりに

簡単にではありますが、採用課題の作成プロセスに関しては以上になります。

最初にも書いたとおり、まだ実運用は始まったばかりなのですが、この課題があれば求めるエンジニアと巡り会うことができるのではないかと期待しています。

今回紹介した細部については私たちのチームに合わせたものになっていますが、プロセスや考え方は他のチームでも活用いただけるかもしれません。ぜひ、採用課題の導入を検討している方は参考にしていただければと思います。

また、この記事を読んで弊社の採用課題に興味を持っていただけた方は、ぜひ以下のリンクからご応募ください。課題の前にはカジュアル面談なども設定できますので、お気軽にお問い合わせいただければと思います。