🏢

エンジニア採用面接で考えたこと

2024/01/25に公開

昨年末に人生ではじめて面接を担当したので、考えたことを書いていきます。

大前提

面接をやるにあたって、個人的に心がけたのは「勘違いしない」ということです。
ネット上で流れてくる人事みたいな人間にはなりたくないな、と。

https://x.com/Rina_pan_pan/status/1710104917300695251?s=20

ただ採用する側になってみて、確かにこれは担当者を勘違いさせる魔力があるなと感じました。
良くないですね。

ただやっぱ採用って組織やチームとしてはめちゃくちゃ重要な活動なので、そこにコミットするのは大切。
特に小さな会社であればあるほど。

前提

今回の採用に関しては、iOSエンジニアの中途採用でした。
新卒採用だったらまた基準は違うと思います。

やるべきこと

面接に臨む前に、履歴書・職務経歴書は熟読しました。
SNSアカウント/Github/ポートフォリオサイトがあれば、それもサラッと見て。

面接そのものは実際そんな大事じゃないのかなと改めて思ったりもしました。
書類からある程度ペルソナができていて、その検証作業のような気がします。
1時間やそこらで人間の深いところなんてわかんないですし、騙そうと思えばいくらでも騙せると思いますし。

採用の鉄則

IT企業の採用において、「迷ったら見送る」「採用基準は下げない」というのが鉄則みたいです。
そうはいっても、現実問題、応募がそんなこなくて、現場は人欲しいので、会社の状況によってはそうも言ってられないことはあると思います。
応募が来ない場合、採用広報をがんばって、ちゃんと母集団形成するのが鉄則らしいです。

採用基準

続いて採用基準。
スキル・コミュニケーション・カルチャーマッチの3点ぐらいにざっくりわけられるかなと思いました。
各項目について、箇条書きしていきます。

スキル

  • Githubアカウント見て、コード見るのが一番早くて安心感がある
    • 論より証拠
    • 仕事より雑に書いてたとしても、それでもレベル感は把握できる
  • アーキテクチャー/テストの意識があるか
    • ただ特定のアーキテクチャーへの思想が強すぎるとか、TDDを絶対視してるとかは危ないかも
    • 原理主義の傾向がある人は避ける

コミュニケーション

  • HRTの原則で行動できているか
  • 有害性が高い人は真っ先に弾きたい
    • Brilliant Jerk(優秀だが攻撃的で周りに悪影響を与える人材)は避ける
  • 受動的すぎる人もなるべく避けたい
    • が、エンジニア採用だと、優秀な人ほど面接の印象が受け身に見えがち
    • 実績で判断するのが良いか
  • 質問に対して、適切な回答が来る、というのは大事
    • 質問がわかりづらいパターンもあるので、そこはふりかえる

カルチャーマッチ

  • その人のやりたいことと会社&ポディションがマッチするか
  • 担当することになるプロダクトに興味あるか
    • 必須条件ではないが、あった方が本人のモチベになるので結果的には良いと思う
  • 単純にノリが合いそうかどうか
    • 多様性の担保も大事だが、あまり攻めすぎると早期離職や人間関係悪化が起こる

コーディングテスト

スキルの項目について。
スキルを重視するのであれば、コーディングテストをすべきでは?とお思いの方もいるかと思います。
たとえば、ゆめみがコーディングテストの課題を公開してくれてたりするので、これを流用してもいいかもしれません。

https://github.com/yumemi-inc/ios-engineer-codecheck

更にオリジナルで課題つくるとか、米系テック企業のような純粋なアルゴリズム力を問うタイプの課題を使うとか、
そこまでやるとより正確に技術力を測れると思います。
ただコーディングテストは、出題する側も相応のコストを払うことになります。
課題を用意するのも大変ですし、採点も大変ですし。

100人規模の会社だと、このコストがあんまり回収できない気がします。
もっと会社の規模が大きくなると、費用対効果が出てくると思います。

あと、これは僕の個人的な考えなんですけど、2019年頃はコーディングテスト賛成派だったんですが、最近ちょっと微妙になってきました。

その手のコーディングテストをきちんとやってるGoogleの出してるプロダクトが年々微妙になっていって、なんか機能してない���じゃないか?と思ってしまいます。
一つ仮説としては、コーディングテストが運用できるぐらいの大企業になった会社は、
大企業病にかかって、いくら優秀な技術者を得てもプロダクトを改善できない?というのがあります。

あと競技プログラミングでは頻出アルゴリズムをいかに素早く当てはめるかみたいになりがちなんですが、
このプロセスが実際のプロダクト開発と乖離が大きい点も気になります。
これに関しては、
「普段は確かに役に立たないけれど、ただ効率的なアルゴリズムを知っていることでプロダクトの質が上がっている」
という説明で納得していたんですが、最近はこれ本当か?と正直思っています。

コーディングテストの是非は、ちょっと別の話題なので、本題に戻します。

質問

面接といえば質問ですね。

人によって聞くことは変わると思うんですが、
「直近で一番大きかった案件はなんですか?」
という質問は、テンプレみたいに全員に聞きました。

「本当は全案件を聞きたいところですが、そんな時間はないですし、
職務経歴書に一覧は載ってて、だいたいわかるので、一番アピール力が高い案件を深掘りしましょう」というのが意図です。

この質問からスキルやコミュニケーションの確認ができます。
「アプリにxxxを導入したということですが、xxxを使うとしたらここで困ると思うんですが、その点はどうしました?」
「どういうチーム体制で開発してたんですか?レビュー体制は?」
などなど。

あとは本人のやりたいこと、現職への不満点、会社に求めることあたりは聞いておきたいですね。

質問アンチパターン

あんま良くないと思う質問。

  • 普通にダメな質問
    • 親・宗教・健康などのセンシティブ情報
  • 大喜利質問
    • 「私にこのペンを売ってください」みたいな質問
    • 意味がない。質問する側の自己満足
  • 「それウチじゃなくてもできますよね?」
    • そらそうやろ
    • カルチャーマッチを問えてるようで問えてない
  • 書類に書いてあることをそのまま聞く
    • 聞くとしたら「書類に〜と書いてありますが、もっと詳しく聞かせていただけますか?」

(了)

Discussion