こんにちは。株式会社ハイヤールー代表の葛岡(@kkosukeee)です。毎週、失敗しないエンジニア採用についてオウンドメディアに記事を投稿しています。第11弾は優秀なエンジニアを選考プロセスで見極めるのに必要な選考で見るべき技術的なポイントを、筆者の体験に基づき※社内ノウハウ集よりご紹介します。
本記事ではコーディングスキルや設計力の様な技術的な見るべきポイントの概要と、なぜ・どのように見るべきかを詳細に説明し、次記事ではコミュニケーション能力やカルチャーフィット等、非技術的な項目に関して説明します。
エンジニア採用に関わる人事の方、これからエンジニア組織を作っていく経営者の方などに参考となる記事になっていますので是非ご一読下さい。
（これまでの記事はコチラ👇）
- 第一弾: エンジニアレベルの定義について
- 第二弾: エンジニア採用媒体について
- 第三弾: 採用マーケティングについて
- 第四弾: 採用マーケティング事例
- 第五弾: タレントプール、DOs/DON’Ts
- 第六弾: 選考手法の紹介
- 第七弾: Google選考事例
- 第八弾: Facebook選考事例
- 第九弾: ディー・エヌ・エー選考事例
- 第十弾: メルカリ選考事例
※採用ノウハウ集とは弊社がプロダクト開発前に100社程を対象にエンジニア採用に関してヒアリングした結果と創業メンバーの実体験をもとに社内向けに書かれた約50ページほどのDocs
面接で見るべき3つの技術的なポイント
これまで第七弾から第十弾に渡り、海外企業であるGoogleやFacebook、国内企業であるDeNAやメルカリの先行事例に関して記事でご紹介しました（まだの方はこちら：Google, Facebook, DeNA, メルカリ）。以下は筆者の実際の経験を元に、強いエンジニアリング組織を持つ企業が選考において見ている3つの技術的なポイントについて（What?）、なぜ必要で（Why?）、どのように見るべきか（How?）の詳細について説明します。
（以下ノウハウ集抜粋）
コーディングスキル
What?
基礎的なコンピューターサイエンスの知識を持って、手際よくコードが書けるかを評価する指標。プログラミング言語等問わず、配列やハッシュマップへの理解はあるかなど、一般的な知識を問う。アルゴリズムであれば正しく理解しているか、Pros/Consを正しく認識して効率的なコードを書けているか等を見る。
高いコーディング力を持つエンジニアは複雑な要件を分解して一からコードに起こすことができたりする。一方でコーディングスキルが低いと、後に負債と化す様なプログラムを作ることになったり、複雑な要件に答えられるような開発ができないことがある。
Why?
コーディング力はエンジニアにとって基礎になる部分で、算数ができないのに応用数学をやるのと一緒で、複雑なプログラムやシステムを設計する上で必須の基礎であるため必ず採用時には評価すべき指標である。
コーディングスキルが欠如しているエンジニアを採用してしまうと、唐突にプロダクトの品質が下がるということはないが、徐々に負債が蓄積されていき、気づいた頃には手がつけられない状態になるようなことが発生するため、最低限の目線合わせは必ず行うべき。
How?
実際にコードを書いてもらうケースがより効果的であり、国内外問わず簡単な関数を実装してもらうようなアルゴリズム形式のコーディング試験などが実践されている。GoogleやFacebookのように、45分程の面接でコーディング課題を2問程解いてもらい、バグのないコードを書けているかや基礎的なコーディングに関するデータ構造やアルゴリズムの知識が備わっているか等を評価するケースが多い。
専門知識（iOS, MLなど）
What?
コーディングスキルの指標では見れない、理解の深さを評価する指標。採用されるポジションを考慮し、採用後に業務する上で自走できるだけの十分なスキルが備わっているか等を技術課題や口頭面接を通じて評価する。
地頭が良ければ専門知識はある程度時間が解決してくれる側面もあるが、専門知識が欠如しているエンジニアを採用してしまうと、自走できるまでのリードタイムが非常に長く、候補者としてもオンボーディングにかなりの労力を費やすことになるため、即戦力採用では見ておきたい指標である。
Why?
コーディング力や地頭が良くても、専門知識を習得するには必ず時間がかかるがゆえ、これまでのキャリアや研究などでどのくらいその領域について詳しいかを選考を通じて評価することで、すぐに自走できるような即戦力の採用をすることが可能となるため。
How?
技術的なディスカッションを行う口頭面接を用いて専門的な知識を問うような設問を候補者に投げかけ知識を問うケースや、数時間程度で解けるような専門知識が必要な技術課題を候補者に解いてもらい、提出してもらった課題から候補者の専門的な知識を問うケースもある。
実際にGoogleのMLポジションに応募した際の面接では、コーディング試験を通してホワイトボードでGoogle製のML frameworkで機械学習のモデルを作る際にどのようにグラフ構造を作るかなどをエンジニアと45分で行った。
設計力
What?
これまでの二つの指標はいずれもプログラムを書く際に必要なスキルや知識を問うものであったが、設計力はより俯瞰で大規模なシステムや、複雑なシステムを設計できるかを判断するための指標。大規模システムを過去に設計したことがあるか、システム構成に関する知識はあるか等の観点から口頭面接やドローイングツール(miro等)を使い評価する。
Hire/No Hireの判断で使うケースももちろんあるが、海外では採用のための指標ではなく、採用後のグレードなどを決めるための指標として評価するケースも多い（Googleのリクルーターによる情報）。リーダーポジション等を採用する際には特に重要な指標であり、採用するポジションが高ければ高いほど重要性を増す。
Why?
コードは書けてもシステムの設計はしたことがないというエンジニアに関しては、現場レベルでは活躍するかもしれないが、今後テックリード、エンジニアリングマネージャー等として活躍するためには、システムの設計や新規プロダクト・機能の仕様設計等の知識・スキルは必ず求められるため、※L3以上のエンジニアでは必ず評価すべき。
※L3（Level 3）とは弊社が定義した5段階のエンジニアレベル中の定義であり、L1（Level 1）からL5（Level 5）まで、経験年数や年収感や所属企業などで定性的に評価されるレベル：https://blog.hireroo.io/entry/2022/01/19/102911
How?
「Twitterのタイムラインを設計してください」といった課題を出し、候補者と一緒に面接官がシステムを設計するような、ホワイトボード等を用いたシステムデザイン面接と言われる形式を実践している企業が多い（コロナ以降Miro等を用いてオンラインで行うケースが多い）。
正解のないOpen Questionなため、厳密に正解・不正解がなく、フォローアップ等を通して議論が膨らむ問題を企業がいくつか用意し、ポジションにあった課題を対話形式で解くことが一般的。
技術的項目評価テーブル
これまで面接を通して見るべきエンジニアの技術的な項目や見極める方法について説明しました。ここではそれらの項目毎に、候補者を実際の面接で評価する際に役立つ4段階の評価テーブルをご紹介します。GoogleやFacebook等もこれまでの記事で紹介したとおり、構造化面接を実施する中で事前に以下のような評価基準を定めることで属人化しない採用を実現しています。
それぞれの企業で悪いから非常に良いまで、定義が多少異なる場合もあるかと思いますので、必要に応じて修正し、自社で評価する際にお使いください。ただし、4段階から5段階に変えることはおすすめしません。これは5段階に評価にすると3に収束しがちで、最終的にHire/No Hireの判断を下すのに有益な上ではないためです。
| 悪い | 普通 | 良い | 非常に良い | |
|---|---|---|---|---|
| コーディングスキル | 基礎的な文法やデータ構造を理解しておらず、問題を正しく解くことができない。コードにはバグが含まれ実行が不可能。 | 愚直な解法で問題を解くことはできるが、計算量等は特に考慮されておらず、エッジケースの考慮などもかけている。 | 愚直な解法をバグなしで実装できボトルネックを把握した上、与えたヒントを元に最適化することができる。 | 計算量やメモリ使用量、各解法のトレードオフを考慮した上最適解を高い可読性のコードで実装することができる。 |
| 専門知識（iOS, ML） | 基礎的な対象技術に関する知識が欠落しており、最低限の実装ができない。 | 基礎的な対象技術に関する知識はあり、いくつか問題はあるが最低限の実装が愚直にできる。 | 細かいパフォーマンスのチューニングなどは考慮されていないが複雑な実装をすることができる。 | 対象技術の原理を理解しており、細かいパフォーマンスのチューニング等を考慮した複雑な実装をすることができる。 |
| 設計力 | システムに関する基礎的な知識が欠落しており、最低限の条件を満たすシステムを設計ができない。 | スケーラビリティや問題の本質を考慮できていないが、最低限要件を満たすシステムを設計することができる。 | スケーラビリティや問題の本質を考慮し、要件を満たすシステムを設計することができるが、信頼性や一貫性には少し改善の余地がある。 | 問題の本質を理解し、要件を満たすべく適材適所最適な技術選定を行い、信頼性、一貫性、スケーラビリティを考慮したシステムを設計することができる。 |
まとめ
最後まで読んでいただきありがとうございます。本記事ではエンジニアの選考を通して見るべき3つの技術的なポイントについて説明しました。筆者がこれまで経験した採用フローの中では、いずれの企業もそれらの項目をコーディング試験や、システムデザイン試験等、様々な面接手法を通して評価しており、それらの手法についても簡単に説明しました。
優秀なエンジニアを採用するために見るべきポイントは技術的な項目だけでなく、非技術的な項目も多数存在しております。次回の記事では面接で見るべき非技術的なポイントに関してご紹介しますのでそちらも乞うご期待ください。
また弊社が提供するコーディング試験サービス『HireRoo（ハイヤールー）』では、本記事で紹介したコーディングスキルを評価するためのアルゴリズム形式問題から、専門知識を問う技術特化形式問題や選択形式問題、更には設計力を評価するシステムデザイン形式問題まで、全てがAll in Oneで一つのツールでお使いいただけます。
もし読者の方で「選考時に候補者の技術力を測れない」、「過去にミスマッチが起きて、もう絶対起こしたくない！」等の課題を持たれている方がおられましたら、お気軽にお問い合わせください。それではまた次回！