良いエンジニアを採用するための方法論

判断軸

1. 成長しそうか

過去成長してきたか

• 年齢に比例したスキルを持っているか
  • その経歴で精力的にスキルアップしてきたと考えたときに、どのようなスキルを持っているのが適切か考える。
    • 例えば優秀なSEと優秀なコーダーは別であり、優秀なコーダーとしての能力がないSEが優秀でないとは言えない。
    • 過去成長してきた人であればある程度の業務内容の違いは吸収できると考える。
  • エンジニアリングの分野は広いため、面接者自身の経験で必須スキルを判断しない。
    • たとえば高負荷サービスを経験してない人に負荷対策知識について聞いて、成長性がないと判断はできないだろう。
    • 自分の得意分野でマウント取っても、自分の穴を埋める存在は取れない。

地頭の良さ

• 複雑な概念を理解する力を持っているか
• 複雑な概念を説明する力を持っているか
  • その人の触れてきた技術について、深いところまで理解しているかを、なぜ？なぜ？で掘っていく。
    • indexを貼ると早くなります。 ⇒ なぜ？
    • 過去触れてきた概念に関して浅い理解をしている人は、今後も浅い理解で仕事をすると考える。
  • その人の過去の経歴・行動に関して、なぜ？なぜ？で掘っていく

2. この仕事が出来そうか

• 今のスキルがマッチしているか
• 人間性が今の職場に合っていそうか
  • 求めるものは職場によって変わってくるので割愛
• 興味範囲と業務内容が合致しているか

興味範囲と業務内容の合致について

ここでは表面的な回答だけでなく、深くに込められた心理まで追求できているか注意する。
たとえば肉が好きだからという理由で焼肉屋のホールで働いて欲求を満たせる可能性は低い。
なぜなら肉の味が好きなのであれば、焼肉屋で働いてもその欲求を満たすことはできないからだ。
つまり「プログラミングが好き」という人がいたとしても、その先の部分で合致しない場合がある。
「自分の作ったもので身近な人が喜んでくれるのが好き」「より美しいコードの書き方を探していくのが好き」「パフォーマンスなど目に見える数値的な成果を出していくのが楽しい」「お金が儲かるから好き」など、プログラミングという体験の先に求めるものは人により異なってくる。

面接でする質問・課題について考え方

1. 何の資質を面接で見たいかを洗い出す

仮に優れたWebEngineerが欲しいとして、優れたWebEngineerが持っている能力を網羅的に洗い出す。

• コーディング
  • 拡張性
  • 可読性
  • 安全性（XSSなどセキュリティ面の知識も含む）
  • アルゴリズム知識
  • デザインパターン
  • ...
• RDBMS
  • MySQL
    • 負荷削減
      • partitioning
      • cache
      • query tuning
      • index
  • ...
• インフラ
  • ...
• マネジメント
  • ...
• ...

参考

各技術分野におけるスキルを網羅的にまとめてくださいっているかたがいるため、自分で用意せずともそちらを参照可能。
一度列挙しておくことで、社員の評価や教育（不足している技術課題が具体的にわかるため、自律的に勉強しやすい）にも役立てることができる。

• Developer Roadmaps
  • https://roadmap.sh/
• あなたがマスターしたのはいくつ？ Railsを習得するために必要な技術要素の一覧
  • https://qiita.com/jnchito/items/063e332cbe3023f52f93
• 2018年の最先端バックエンドエンジニアになろう
  • https://qiita.com/rana_kualu/items/19ab559dddbca6674417

2. 質問に落とし込む

その資質を持っていると判断するためには何を確認すれば良いのか考える。
それを確認するためには何を質問すれば良いのか考える。

質問集

※ ほぼ各種サイトからの引用

最初

• github、stackoverflowのアカウント、個人blogなどこちらであなたの技術が確認できるpublicなアウトプットがあるか。
  • コーディング課題等があればそちらで代替は可能。
  • やはり実際のアウトプットを見るのが一番確実なので、見れると安心する。

全般

• 前の会社で何をやってきましたか
  • 行動面接に繋げるための布石。過去のプロジェクトからそのときどんな問題が発生したか、それに対してどうやって対応してきたか。
• 転職理由はなんでしょうか
  • どういったときに転職しようと考える人なのか、入社後の転職リスク。会社に対して何を求めている・重視している人なのか。
• 将来はどういう道に進みたいでしょうか
  • 入社後の指向、組織にフィットするか。深堀りすることでその道に向かって努力をしているかどうかも見れる。
• 会社に求めるものはなんでしょうか
  • 入社後の指向、組織にフィットするか。明らかに優秀な人材でこっちからすり寄るときとか。
• どういったタイプの人と仕事をしたいと思っていますか
  • 人間関係のトラブルが起きやすい職場などで、マッチするか相性を測る。
• 仕事で気をつけている点はなんでしょうか
  • 割と回答に個性が出る。注意点として「気をつけている＝気をつけないとできない、自分が課題だと思っている点」である可能性も考慮に入れる。
• （回答の後に）つまり一言で言うと？
  • 物事を短く説明するためには、抽象度をあげて捉える必要がある。具体←→抽象の変換がスムーズな人は地頭が良いと言える。

行動面接

候補者の過去の行動を掘り下げることで、真の能力・志向性・誠実さを測る。

• チーム/会社を良くするために主体的に行った行動はありますか。
  • 主体性が求められていないような立場の人だと別の実装方法を提案したって回答が多く、個性が出ない。
• 過去1年間にあなたが上司にした提案を2つ教えてください。その案はどういう経緯で出てきたのですか。その後の経過はどうでしたか。
• 過去2年間にあなたが仕事上成長するためにやったことを3つ挙げてください。
• 技術や知識を最新に保つためにどのような努力をしていますか？
• もし自分が上司ならどんな提案をしますか。
• ここ数年の状況から学んだことは何ですか？
• あなたにとっての理想の仕事とはどのようなものですか？
• もしも可能であれば、今までの経歴にかかわるどの決断を取り消したいですか？
• 仕事上でこうすれば良かったと思ったことはありますか？
• 過去の仕事の中で一番頑張ったものはどれですか？
  • そこからどんな問題があってそれをどうやって解決していったかという具体例まで、相手の一番得意な土壌で戦うので相手の経歴を尊重してる。
• 過去のプロジェクトで一番失敗したと思うのは何でしょうか？
  • 失敗を認めない（人のせいにするなど）人は良くないケースが多いと言われている。
  • ただ面接時に人のせいにしてた人が優秀だったケースもあるので、あくまで考え方を知る程度に抑えた方が良い。
• その失敗に対してどのような対応をしましたか？／今そのときに戻れるとしたらどうしますか？
• 今過去のプロジェクトに戻るとしたら何をしますか。
  • 何かを行った後に、日々反省・改善をしているか。

状況的面接

あるシチュエーションを提示し、それに対してどういうアクションを取るか聞く。
実際の現場に近い状況を仮定することで、候補者が実際の業務でどういう立ち回りをするかを推測する。

• 期限前日に仕様の認識間違いが起きて、もう間に合わないような状況になったときどうしますか。
  • 現状をどうやって解決するかは最低限として、原因分析、再発を防止策の立案までしてほしい。
• チームメンバーのコードの品質クオリティが低いという問題が起きています。どうしますか？
• あなたのチームのアウトプットの品質が悪いからもう仕事はお願いできないと取引先に言われました。どうしますか？
• やる気のないメンバーが居て、周りのモチベーションをさげています。どうしますか？
  • 引用元がどういう回答を期待したのか分からないが、そのメンバーに話を聞いて原因追求という回答ばかりになってしまう。あまり個人差のでない質問だった。
  • 「相談の結果○○と言われました、どうしますか？」みたいな追撃があると良いかも。
• チームに軋轢が生じた場合、あなたはどのように対処しますか？
• 自分の提案がノーと言われたときどういう対応をしますか？

技術全般

• 相手より自分のほうが詳しい分野を探し出し、その分野について説明を求める。
  • 曖昧なことを言ったり、あてずっぽうで答える人はアウト。当てずっぽう＜分かりません＜私の推測によれば〜

coding

• classとinstanceの違いは？
• interfaceとabstractについて説明してください。
  • こういう類の質問は教科書的なため、「上手く説明できない＝実践力がない」とは言いづらい。実践力が見たいならもっと現場的な質問の方や課題の方が良い。
  • 技術力を見るというよりは「非エンジニアや初学者に対する説明力」を問う質問かもしれない。
• どういうときにinterfaceを、どういうときにabstractを使用しますか？
• for($i = 0; $i < count($user_list); $i++) {...}　何がダメ？
• あなたがチームリーダーだとして、自分のプロダクトをリリースするまでにどのようなテストのフローを取りますか。

RDBMS

• テーブル設計課題を出して、テーブル設計をしてもらう
• もし仕様が○○に変わったら何を変えますか
  • 仕様変更に正しく対応できるかなどを見る。
• 仮にこのサービスが何年間も運用され、ユーザの数も膨大に増えたとしたらどんな対策をとりますか
  • 負荷対策の知識を確認する

Infra

• 仮にあなたが担当した施策のリリース後ページが重すぎて開けないという状況に陥ったらどういうフローを取りますか
  • どんな指標を監視するのか、その指標を見るために何をするのか、なぜその指標を見るのか。
• 過去担当したサービスのサーバ構成及び、なぜそのような構成を取っているのかを説明してください

個人的な反省

過去行ってきたことから判断しない

嘘や誇大表現も言えるので、経験がありますか？できますか？という質問をベースに判断をしない。
必ず深掘りをして、どのように行ってきたのか、なぜそれを行ったのか、本当に知っているのかを見極める。

過去の経歴の裏を考える

その人は基本的には一番良い経歴・経験を話す。
一般的に優秀な人はどんどん仕事を任せられるため、幅広い仕事を経験することが多い。
そのため、一番良い経歴・経験の幅が狭い場合（同じ成功体験や作業内容についてひたすら話すようなケースの場合）、それ以外の経験をやらせてもらえなかっただけの理由がある可能性が高い。

曖昧な回答を見逃さない

適当に答える＜分からない＜私の推測によれば〜
権限的に見れないとかではなく自分の仕事範囲をしっかり理解していないのであれば、その先も適当な認識で仕事を進める人である可能性が高い。

技術的に秀でた何かを感じてから採用する

エンジニアとして技術は避けては通れないところで、過去やってきた範囲で成熟した技術がない人は厳しいと考える。
技術が全てでないにしても何も秀でた技術がない時点でエンジニアとして価値を発揮することは難しいため、必ず技術面で秀でた何かを感じてから採用する。

妥協はしない

人が足りない状況でも、人が増えることで仕事が増えることもある。

追記

ブログの方で、より詳しく記載しました！
https://dorarep.page/articles/engineer-interview

参考

優れたエンジニアを採用できないワケ
良くある面接の質問集
グーグルが採用面接で聞く質問リストとは
採用面接において応募者の真の力を見極めるための質問10+選
フロントエンド面接対策ハンドブック
構造化面接を実施する