こんにちは、スマートキャンプのエンジニアの瀧川です。
私はこのブログではBigQuery大好き芸人としてよく記事を書いてますが、実は普段の業務では30%くらいの時間をエンジニア採用に割いております。
今日は弊社で実践している技術試験及び技術面接について、どのような目的を持ってどのように設計したか、またそこにかける思いを書かせていただこうと思います。
弊社に興味を持っていただき選考を受けようとしている方はもちろんですが、自社で技術の見極めに課題がある採用担当者の方などにも参考になれば嬉しいです！
※ 今回は中途採用に限って書いていきます。
※ 弊社の採用フロー全体については別途エントリーがあるので、興味があれば見てみてください。
背景
現在の選考フロー
こちらのエントリーにも書いてある通りですが、ざっくりと以下のようなフローを取ることが多いです。
(候補者の方によって期待値調整の面談を挟んだりといった調整が入ることがあります)
- カジュアル面談
- 技術面接
- カルチャーマッチ面接
- 最終面接
「1. カジュアル面談」は候補者の方に弊社の事業・文化・技術などへの理解を深めて頂く事を主な目的としており、選考要素はありません。
「2. 技術面接」については後述しますが、候補者の方の技術力をはじめ、技術的な志向性やロジカルシンキングなどを見させていいただきます。
「3. カルチャーマッチ面接」は候補者の方が弊社のカルチャーにマッチするかどうかを判断する機会となっています。主に弊社の行動指針であるSOCS(Smart thinking, Ownership, Collaboration, Speed)を基準として判断させていただきます。
「4. 最終面接」は弊社のCEOと経営視点での期待値や事業の展望などについてお話しいただき、その中で人柄などを判断する機会となっています。
技術面接で知りたいこと
前述したフローを見てわかると思いますが、色んな視点で候補者の方のマッチ度を計っていくことになります。
※ 候補者の方に負担がかかってしまう事や選考の途中で他社に決まってしまう事を減らすためにも、技術面はなるべく一回の面接で判断したいと考えています。
では候補者の方の技術面についてなにが知りたいのでしょうか？
前提として採用のゴールは中長期的に活躍してもらえそうか、というのが一番重要だと考えています。
その上で技術面を分解すると下のようになるかと思います。
- 今いるメンバーとの志向性のマッチ度
- 例) ビジネス志向があるか、技術がどれくらい好きか
- 現時点での活躍想定
- 例) どのタスクにアサインできるか
- 技術的にやりたい方向性と自社で実現できる(できそうな)ことのマッチ度
- 例) 難しいことをやりたいのか、新しいことがやりたいのか
- 中長期的に想定される技術課題への対応力
- 例) 過去に課題を乗り越えたか、未知の課題に対してどうアプローチするか
要約すると「切磋琢磨できるメンバーがいて、現状のスキルが活かせて、中長期的に成長できそう」という状況が自社と候補者両方にとって良い状態で、かつ技術的にマッチ度の高い状態だと考えています。
いままでの課題
最初は候補者の方の経歴から気になったことを聞くだけだったのですが、上記の視点で聞き漏れてしまうことがあったり、相手とのコミュニケーションの中で意図した質問をすること難しく属人化してしまうといった課題がありました。
これらを改善するために質問のテンプレートを用意し、そのテンプレートに沿って網羅的に質問することで知りたいことを把握しようとしました。
しかしその方法では網羅度は高まるものの一つ一つの話題を深堀りしきれず、志向性や課題への対応力などはあまり確認できていませんでした。
その後はテンプレートを改善したり、噂に聞くホワイトボード試験を導入してみましたが、どうしてもその面接の時間内で「網羅的かつ志向性まで深ぼった質問を属人化せず実現」することは難しいという結論になりました。
そこで次は事前に技術試験を受けていただくことで上記の課題を解消しようとしました。
※ ホワイトボード試験はその場で課題となるアプリケーションの仕様を説明して、設計や実装手順などを説明していただく形で実施しましたが、相手の得意な話に寄ってしまい聞きたいことが聞けなかったりと、今回の目的にはあわなかったのですぐに辞めてしまいました
課題解決のために事前技術試験の導入
改めて事前の技術試験を導入することのメリットや期待値は以下だと考えています。
- 候補者の方の志向性についても多く知ることができる
- 事前に推測した候補者の方の特性をもとに質問を準備できる
- どういった回答が来るのかも予測しやすいため、その回答に対してさらに質問も考えておける
- 面接の流れが型化されるので属人化や抜け漏れが解消される
技術試験というと点数をもとに合否を判断するイメージがありますが、弊社では上記のようなことを期待して導入してるため正答率などはほぼ見ていません。
余談ですが技術試験を導入するにあたって、試験問題の作成や候補者の方に提出して頂くためのフローと仕組みを作る必要がありました。 それらに少なからずコストがかかることが予想されましたが、trackを利用することで技術試験の導入や運用・管理のコストを大幅に下げることが出来ました。
trackは候補者の方がWeb上で技術試験が受けられるサービスとなっています。 出題側としては受験者の管理が容易でコーディング試験を解く過程まで見ることができたり、用意されている問題が豊富だったりといったメリットを感じています。
導入した技術試験の構成
何度か実践をしながら改善を行い、現在は以下のような設計で落ち着きました。
(改めて書いてみるとこれだけ長い時間を弊社のためにかけていただけているのは本当にありがたいことで、その分私たちもできるだけ候補者の方の懸念や期待に応えられるように気を引き締めないといけないと感じます)
- 知識を問うクイズ(最大15分)
- コーディングテスト(最大90分)
- 筆記テスト(どちらかを選択)(最大30分)
- インフラ系
- アプリケーション系
次にそれぞれどういった意図で出題しているか、具体的な設問を考える上でのコツなどを説明します。
知識を問うクイズ
こちらはWebアプリケーション開発に携わる上での知識を問う幅広いクイズを出題しています。
意図としては目的でも書いた通り、候補者の方のスキルや経験を網羅的に把握するために用意しています。
そのためこのクイズの問題を考える上で一番大切にしているのは、面接時に話を広げやすいか、広げたときに効率的に情報を引き出せそうかという点になります。
例えばデータベースの設計に関する問題を出したら、面接時の質問では設計の経験の有無、パフォーマンスに対する知見、利用したことのあるデータベースの種類といった形で聞けると技術の幅がわかると考えています。
あとはあえて知っている人のほうが少ないような問題を選ぶこともあります。
例えばAWSのニッチなサービスの用途についての質問などですね。
その意図としては、回答の選択肢を、サービスを知らなくても消去法で回答できるようにすることで、未知の課題に対してロジカルに対応できるかを見ることができると考えています。
回答が間違っていたとしても、面接時に回答の思考プロセスを確認して共感できればいいなと思っています。
コーディングテスト
こちらはよくあるアルゴリズムを組むコーディングテストを採用しています。
とはいっても競プロで出題されるようなゴリゴリの問題ではなく、そこまで 難しくはないけど普通に書いていると複雑になってしまう ような問題を選ぶようにしています。
例えば色んな形式の入力値を変換して出力したり、ビジネスロジックとしてあり得るような問題がいいかなと考えています。
その意図としては、もちろん効率のよいコードが書けるというのは大事なエンジニアのスキルだと思いますが、チームでコードを書く上ではそれだけでは不足していると考えています。
例えば関数をどういった粒度で切り出しているのか、関数を切り出した意図は何なのか、関数の引数と返り値をどのように設計しているか、言語のどういった機能を使っているかなど特徴が出ると思います。
そこから、候補者の方がどんな知識を持っているのか(オブジェクト指向や関数型)、どんな経験をしてきたのか(エラーハンドリングや設計思想)を推測できると考えています。
たとえコードが正答でなかったとしても、上記の知識や経験が弊社で活かせるものであればマッチしているという判断になります。
もちろん試験は試験、チーム開発はチーム開発という思いで回答いただく方もいるので、そこのすり合わせは面接でするという形になります。
筆記テスト
こちらはインフラ系かアプリケーション系の2つの問題を用意しており、どちらかを選択してご回答頂いています。
2つから選択いただいている理由としては時間が長くなりすぎるということもありますが、弊社ではインフラ専任といった役割の分け方をしておらず、募集する際も区別していないため、どちらに自信があるのかを見るためという側面もあります。
筆記テストを採用している意図としては、まずフォーマットを指定せず自由記述としているのである程度の性格や特性が把握できる点があります。
例えば優先度などを明確にしているか、疑問点などが書いてあるか、複数パターンを考慮しているかなど人によって特徴が出るので、そこからその人が何を重要視して考えるかを推定できると考えています。
(今までの経歴によっても特徴は変わって、受託開発だとドキュメントも納品物の一つで...といったこともあるので、経歴を踏まえて見るのがよいと思います)
その特徴が自分を含め今いるメンバーの志向性と近いか遠いかを判断して、面接時に確認するという流れになります。
また内容に具体性が欠けていた場合は、候補者の方にとって経験や知識がないシチュエーションだと考えられるため、未知の課題に対してロジカルに考えられているかに重点を置いて見るようにしています。
次に各問題について。
インフラ系について、特定のシチュエーション下での設計やインシデントへの対応などを回答いただくような問題にしています。
設問を考える上で意識していることは、実際に自社のサービスで起きたこと、もしくは起きうることを題材とするようにしています。
そうすることで候補者の方がどれくらい自社のインフラ構成に馴染みがあるか、即活躍できるかなどが判断できると考えています。
また、実際に起きたことであれば自社メンバーがどのように対応したかといった情報もあるので、そことの差分も見ることができます。
アプリケーション系についてもほぼ同様で、特定のシチュエーション下でのアーキテクチャ設計や実装方法を問う問題にし、実際のサービスに則した題材としています。
試験結果を踏まえて技術面接
以上のことを踏まえて、技術面接という形で直接話を聞き、事前に推測したことを元に判断していくことになります。
面接は60分~90分程度で実施し、前半40分程度技術試験からの質問、後半20~50分程度経歴についての質問といった配分にしています。
導入効果
導入して半年ほど経ち、そこそこの人数の方に受けていただいたので(圧倒的感謝)、その中でどういった効果があったか、どう感じているかを書いていきます。
まずは当初課題に感じていた属人化や抜け漏れについてはかなり解消することができ、面接を開発メンバーに任せたりとスケールできるようになりました。
また候補者の方についても今までは「技術力はおそらく高い」といった粗い認識しかできていなかったところが、「技術の幅」「知識の深さ」「志向性」といった観点で分解して認識できるようになり、マッチ度の判断がしやすくなりました。
加えて候補者の方のマッチ度の高い点、マッチ度の低い点が明確になり、候補者の方へのアトラクト(訴求)がしやすくなったり、次の面接への引き継ぎもしやすくなる効果もありました。
別の視点で、開始する前は技術試験は受験者が増えれば、試験内容が流出することもあるだろうし、同じような問題を解いた方がいてもおかしくないということで、定期的に問題を差し替える必要があるかなというイメージがありました。
しかし、今回弊社で導入した目的を鑑みると、あくまで面接に主眼を置いているため差し替える必要性も薄いと考えています。
と、ここまで良かった点を書いたのですが、導入してから上に書いたようなメリットを感じられるようになるまではハードルがありました。
一つは、問題を考え、それを一定数の方に受験いただき、面接をして、その結果をもとに問題を改善するといったサイクルを回すコストが高いと感じています。
母数がそこまで多くなく、実際の候補者の方で上を実施していく必要があるので、あまりよくない問題を出してしまうと面接も進めにくくなりますし、候補者の方も回答しにくく悪い印象をもたれる懸念もありました。
そのため最初から完成度の高い問題を出す必要があり、そこのコストは高かったです。
ただ一度しっかりとした問題を考えることができれば、その後の運用は安定するので、とてもメリットの多い施策だったと感じています。
まとめ
今回弊社で導入した技術試験について、どういった思いで実施しているのか、どういったことを考えて設計しているのかを書かせていただきました。
もし読んでくださった方の中で、弊社に興味を持っている方がいれば、この記事を参考にして私達が何を重要視しているかなどを知っていただけたなら嬉しく思います。
また採用に携わって似たような課題をお持ちの方がいらっしゃいましたら、ぜひ少しでも参考になれば幸いです！
We are hiring!
