駆け出しエンジニアの採用選考
言葉の定義
私がイメージする駆け出しエンジニアさんは、以下の様な条件の方です。
- 大学、高専などが情報系ではない
- 就労経験がプログラマー以外
- ここ1年ほど独学 or プログラミング教室(TechCampなど)に通った
- 就職活動中
書類選考
多いときで月50人ぐらいの方の書類を採用部門の部長としてみさせていただいています。人事のフィルタリングも一応入っています。人事フィルタリングは採用が切羽詰まると緩めて少しでも多くの方を見たりします。採用に余裕がある場合は逆に人事フィルタリングを強くしてもらうこともあります。
書類選考をしていると、駆け出しエンジニアの方の書類もあります。だいたい月10人ぐらいでしょうか。その中で、どういった基準で選考しているのかを紹介します。
- 経歴などは基本的には0カウントのことが多いです。
- コンサルなどでPM経験などがある場合は、PM職や管理職を採用したい時にはプラスに見ることもあります。
- プログラミングスクールや独学などで、駆け出しエンジニアの方であると認識します。
- 所謂、ポートフォリオを確認できる情報が無ければ、この段階で謝絶してしまいます。
- ポートフォリオ(サイト)やGithubがあれば参照します。
- ポートフォリオであれば、ソースを確認したり動作をさせたりします
- URL設計をどうしているか
- CSSやJSの読み込みをどうしているか
- Webpackなどを使ってminifyなどの最適化をしているか
- 構造化できているか
- HTML5などの先端技術を使っているか
- Githubであれば、コードを見ます。
- 変数名が意味のあるものになっているか
- インデントが適切化
- クラスやメソッドなどコード設計を考えているか
- コメントなどは適切か
- 例外処理など、引数のバリデーションチェックをしているか
- SQLインジェクションのようなコードを書いていないか
- ポートフォリオであれば、ソースを確認したり動作をさせたりします
- 基本的には経験者を求めているので、駆け出しエンジニアの方の場合は職務経歴では経験がないので、提出された成果物からポテンシャルであったり、即戦力になりえるか(とはいえ、文法はわかってる?とかみたいなJuniorエンジニアとしての即戦力て意味合い)を見ています。
- 反面、著しいマイナス要素もないかもみています。
- そして、フィーリングで良い方かもしてないからダメもとで合ってみようで面接の連絡を人事に依頼します。
面接
面接は企業によって重要視することが違うので、千差万別ではあるのですが、大きくは以下の様な内容を確認しているのではないでしょうか。
- エンジニアとしてお仕事ができる能力があるか
- 中途採用の場合は、手取足取り教える余力がないので、最低限のエンジニアリング能力が必要です
- 簡単な会話で理解できるか、自分でリファレンスみて調べられる
- 説明するにしても、そんなところから?みたいなレベル感ではないこと
- 自分で学んでキャッチアップできるか
- 中途採用の場合は、手取足取り教える余力がないので、最低限のエンジニアリング能力が必要です
- 会話が成立するか
- 会話がかみ合わないと、お仕事がやりにくいので会話が成立することは大切です。
- 質問への回答がずれていると心配になります
- 婉曲的に再度聞いてもずれてると、とても心配になります。
- 質問者も人なので曖昧だったり、本人が何を聞きたいのかわからない質問をしてしまうことがあります。
- それを意味を確認せずに会話をすすめるとお互い頓珍漢な会話になります。
- 性格的なところが企業が求める方向性に合致しているか
- これは本当企業によってばらばらです。
- 私の過去に所属した企業でも違っていました
- 企業の方針やミッション、業務への共感を大切にしている場合は、そこへの共感度。
- 成果を出すことを重要視してる場合は、何が何でもやりきる熱血差に期待
- 休みの日に勉強することを期待
- 上記はそれぞれ別々の企業で期待する思想でした。なので、まぁ創業者インタビューとかは見とくといいかもしれません。
裏事情
面接にはたいていの企業には以下の様な内容が注意事項として面接官に指示がおりていることが多いです。
- NGでも面接は30分は実施してください
- NGでもNGの瞬間から当社の顧客or将来の顧客の可能性があるので、顧客対応のように接してください
- 圧迫面接しない(これは企業によるかも。個人的には圧迫面接する企業さんは辞退しちゃいます)
- ネガティブなことは言わない
その為、よっぽどのことが無ければ、私の面接受講者は人事からの結果連絡までは、落ちたと明確にわかるケースは少ないと思います。
エンジニアリング力の確認
中途採用の方であれば、過去の経験などから能力を確認しますが駆け出しエンジニアの方の場合は、ポートフォリオやGithubでしか確認ができないので、そこに終始します。プログラミング教室の話は聞いても差がないので、そこは聞かないことが多いです。
- 作成するのに使用している技術スタックを説明してください
- その技術スタックを選択した理由はありますか
- このコードを何をするためのものですか
- それを実現するために、どのような機能が必要ですか
- どのような設計にしましたか
- テーブル構造はどうしましたか
- 特に注意して作成した部分はどこですか
- 難しかったところはどこですか
- エラーが表示されたら、どうやって解決させましたか
会話をしながら、システム理解を確認するために深堀をしていきます。
- 上記の質問は、深堀をするきっかけを探すために質問をしていて、全部を聞くわけではないです。
- テーブル設計の話から、どんなテーブルを用意して、どんな列にしたのか。
- なんで、そういう設計にしたのか
- 例えば、こういう追加機能依頼がきたら、どうテーブル設計をするのかetc
- 技術選択の話から、なぜそれを選んだのかを確認していく
- Webpackをつかっていたら、何故使っているのか。
- minifyなどをしている場合は、何故しているのか、何故したほうがいいのか
- ORマッパーを使っていたら、それの利点と素のSQL発行との差の確認
- Ruby on Railsをスクールで学ばれた方で、DBを全然意識できてなくて、SQLもわからないという方もいらしゃったので
と、言うように駆け出しエンジニアの方でもピンキリなので、どれぐらいの駆け出しエンジニアなのかを確認するために話をしていきます。出てきた回答からさらに突っ込んで会話してほりさげていきます。
- これは意地悪とかではないです
- 実際に普段仕事していてもエンジニア同士で、技術選択の話や、設計の話はして、それを議論します
- その時に、Googleで出てきたコードをコピーしたと言われると議論にならないので…
- 実務でエンジニアをするときにエンジニアとしての会話ができるために、どんどんドリルダウンして話せるかが大切。
性格やその他の確認
ポートフォリオやGithubのコードについて質問していて、たまにほとんど会話が広がらない方がいます。とりあえず参考書を見様見真似でつくって理解はできてないので会話が広がらないケースです。この場合、そのあたりの話題が5分とか10分で終わってしまいます。
そーすると一大事です。30分は面接をしないといけないので、残り20~25分(内、ラスト5分ぐらいは面接受講者から面接官へのQ&Aで稼げる)を何らかの話題でつながないといけません。
- エンジニアを目指している理由
- プログラミングスクールの感想
- 前職で辛かったこと
- 前職退職理由
- 当社を志望した理由
- 当社でやりたいこと
- 最近興味をもった技術ニュース
- 最近勉強していること
- 他の選考状況
などなど、時間を消化できる話題を一生懸命さがします。それでも万策尽きた場合は、エンジニアとしていく場合には、こういう技術が今注目集まってるよみたいな話をして時間を消費します。
Discussion