エンジニア採用でやってはいけないこと/やっていること

2020年3月11日 22:45

エンジニア採用自体は2012年頃からやっていて2013年は自チームの採用責任者をやったらスタートアップ2社でエンジニア採用の責任者をやってきました。

色々と面談をやってきて1つわかったことは面談もスキルでエンジニアとして優秀でも面談が得意とは限らないことです。
なので、面談も数をこなしてその分、振り返りをすればスキルとして身につくものだと考えています。

長年採用周りをやってきた中で見えてきたやってはいけないこととやっていることをまとめました。

やってはいけないこと

人がいないからといって妥協して採用する
私も採用をやり始めた当初は結構、これをやってしまっていました。
目の前にプロジェクトがあって人がいない状況だと焦ってしまいこの人と働きたいなと思えてなくても妥協して採用してしまうことをやってしまいました。

結果、良いチームの中に1人だけ能力が追いついてない人材が入りチームが崩壊するという事が発生しました。

1人だけ技術的は話についていけなかったり理解力がなかったりしてメンバーからクレームをもらう事が多かったので妥協してはダメだということを学びました。

yes,noで答えられる質問をすること
例えばgitが出来ますか？MVVMの経験はありますか？などyes,noで答えられる質問だと深堀りが出来ないので相手の思考や能力が見えません。

例えば

弊社はMVVMを採用しているのですが、MVVMを使うメリットは何があると思いますか？

このような感じで相手の思考を聞けるような質問をすることを意識しています。面談という限られた場で相手との相性や思考性を確認したいのでそこが引き出せるような質問をするように心がけています。

他には

・エンジニアとしてのこだわりは何がありますか？
・あなたにとってのいいシステムの定義はなんですか？
・過去、一番成長できた案件を教えてください
・過去に担当したシステムを図解して説明ください
・障害報告書は何を意識して書くかを教えてください
・今、所属している会社もしくはチームの課題はなんですか？
・過去に解決した問題でこれは自分でもこれはよく解決が出来たというものを教えてください

などをよく聞いています。
これを聞いて深堀りしていきます。

あとは、以前、エンジニア面談でどんなことを聞いているかを相談したことがありその際に事実と意見がわかれているかは見たほうがよいというアドバイスを受けたことがありました。
障害報告書の質問ってまさにそれを意図していたなと思ってハッとしました。

会社の状況を正しく伝えない
チームや会社の課題などを正しく伝えないと参画後にあとで聞いてなかったということが発生するので問題点や改善など含めて正しく伝えるようにした方がよいです。

周りのエンジニアの話を聞いていると参画してから聞いてなかった、この状態を聞いてたら参画しなかったと言う事を多く聞くので正しく伝えられてないところもそれなりにあるんじゃないかなと感じてます。

やっていること

どんな人材を求めているかを明確にしておく
これは求めているレベル感だったり考え方をまとめてgitにcommitしてあります。一部を抜粋するとこんな感じです。

これを記載することで面談する際に見るポイントが面談する人によってずれるということを防いでいます。もちろん中にいるエンジニアはこれが出来るという前提で仕事をしています。

# スキルセット

* テストコードを書くことを前提として開発を進めている
* Selenium、Behat、PHP Unit、Jestなどを利用している
* CIを利用したテスト自動化の経験がある
* branch managementを行っていてrebase等も理解をしている
* PullRequestベースの開発ができる
* Forkした自分のリポジトリとFork元のリポジトリを区別できる
* ブランチの作成やリモートリポジトリへのPushが独力でできる
* Conflictを解消できる
* Git Flowによるチーム開発経験

# マインドセット

* プロダクト志向であること
* プロダクトに対してオーナーシップを持てる方
* プロダクトを良くするために何が必要か自分の意見が言える方
* 主体性
* 受動的に指示されたタスクをこなすだけでは不十分
* ゴール設定がされたら、それに達するやりかたは自ら考える
* ただ動くものではなく全体最適や役割を明確が出来る
* 実装は出来るがやるべきではないと判断が出来る
* 技術面での好奇心・向上心
* 世の中の技術トレンドを追っかけている
* 知識だけでなく、実際にサンプルを動かして特性を理解している
* 経験済みの技術に固執せず、新しい技術領域へのチャレンジができる
* 自身の成果物に対するフィードバックを受け入れられること
* 設計・実装ポリシーの説明能力
* なぜこのような実装にしたか、その論拠を説明できること
* セルフマネジメント/チームワーク
* 自分が担当するタスクの所要時間見積もり・進捗把握
* 遅延時の報告やリカバリ方法の相談
* 正しくめんどくさがれる人
* 非効率な事を効率化する
* 今やるべきことか、タスクの優先度を意識できる
* ディスカッションが正しく出来る
* 自身の考えを相手に伝えきる
* 相手に自分の意図が伝わったことの確認をする
* 自分の意図が伝わっていなければ、表現を変えて伝わるように試みる
* 相手の意見を聞き入れる/さえぎらない
* 発言時に否定から入らない
* 事実と意見をわけて話が出来る
* チケットベースのタスク管理ができる
* 能動的にコミュニケーションがとれる

一緒に働くメンバーと合わせる
理由としては3つあります。

1. メンバーにも納得して受け入れて欲しい
2. メンバーとの相性を見たい
3. メンバーに一緒に働けるイメージが持てるかもしくは働きたいと思えるか

作業をする際は私よりも実際にはメンバーと多くコミュニケーションを取ることが多いのでこれを実践しています。
また、過去事例として私が合わないかなと思ってもメンバーが一緒に働きたいということで採用した結果、うまくハマったケースもあります。

あとはメンバー自体が採用に参加することで面談スキルが上がっていくというのも狙いとしはあります。先にも書いたように面談はスキルです。

コードテストを行う
これは必ずではないのですが、基本的にはやるようにはしています。

ルールとしては以下です。

・問題はその場でgitのURLを共有する
・時間は30分
・検索は自由にしてよい
・質問は自由にしてよい
・言語は得意なもので良い
・終わったあとに説明してもらう

プログラムの書き方はもちろんなのですが、検索や質問を自由にすることによって普段からどんな検索をするのか仕様の確認はどれくらいして理解力がどれくらいあるのかなどを見ています。

特に検索や理解力のところは詰まった時などにどうするかが見えるのでここが一番、みたいポイントとなります。

前職ではこれをやり始めてから採用するメンバーの質がとても上がったという実績もありかなり効果的だったと感じました。

中には話すのが上手で実際にはコードはあまり書けない人もいますし、話すのが苦手だけどコードを書いたり質問は適切にできるという人もいるので実践で見るというところも重要だと考えています。

この記事が気に入ったらサポートをしてみませんか？