「心」「技」「体」で見る技術者面接の設計
最近、「◯◯さんは採用面接にも関わられているんですか〜」という事を聞かれることが何回かあり、あらためて自分の採用面接の取り組み方について整理するタイミングがありました。
この記事では、以前、だいたい2年前くらいに、技術者面接の面接官としての姿勢や、フォーマットについて整理するために作成した資料を元に記載します。今と多少価値観が異なる部分もありますが、自分はどのような形で採用面接に関わっているかを自分なりに振り返るために記録に残します。
採用プロセスは非常に長く複雑なプロセスになり全部を網羅するのは大変なので、この記事では主にIT技術者が関わることが多い「1次面接」あたりにフォーカスをおいています。
技術者面接（1次面接）の目的
専門職であるIT技術職について、技術者面接は 「心技体」 ともに職務を満たす水準にあるかを見極める場、と認識しています。
・心： 仕事の目的、誠実さ、モチベーション
・技： スキル（アルゴリズム、コーディング能力、システム構築能力、問題解決能力）、それを裏付けする経験
・体： 職業エンジニアとしての基礎体力（集中力、論理的思考能力、探究心、粘り強さ、コミュニケーション能力、継続性、etc）
概ね、「技」 と 「体」 は連動している傾向があります。
「技」 は不足しているが 「体」 に見るべきところがある人は、経験を積むことで技術者として成長する傾向があります。
（よく「ポテンシャル採用」として採用される人は、この部分に見るべき点がある人のケースが多いです。そして育て方が上手くいけば伸びるケースも多い）
「技」 が優れているように見えるが 「体」 の部分が不足している人は、責任ある立場・結果を求められる場での経験が不足していたり、そういう場を避けてきた人というケースもあります。
（もちろん修羅場含めた経験を積むことで解消することも多い）
「技」「体」 が優れていても 「心」 に課題がありそうな人は、組織の中でよからぬ行動に出る可能性があります。
といっても 「心」 だけ誠実でモチベーションが高くても 「技」「体」 が不足していると現場ではついていけないこともあるかもしれません。
ということで、基本的には 「心」「技」「体」 のバランスが整っていることを見極めるのが面接では大事となります。
多くの会社における１次面接は、応募者に対する技術的な評価を行う場なので、主に 「技」「体」 について十分水準に足りているかを確認する場として考えるのが、全体の流れとしてはスムーズになると思われます。
そして「心」の部分、カルチャーマッチという言葉などに置き換えても良いですが、この点は１次面接以降、最終面接などで確認されるケースも多いと思います。
実際は会社ごとの採用プロセスの設計に多分に左右されると思います。
技術者評価の方法
スキル・経験と、エンジニアとしての基礎体力をバランスよく見るためには、面接において以下で述べるような流れで実施することをおすすめします。
重要さの順番で並べていますが、実際の面接での実施順は柔軟に変更するのが良いと思います。
1. Coding Test
多くの会社ではコーディングテストは一次面接前の「足切り」に用いていることが多い印象です。多くは、オンラインツールを用いて課題を提出し、テストケースが All Green にならないなど水準に満たない場合は落選、といった形。
基本的にコーディングテストでは、基礎的なアルゴリズム能力やプログラミング能力、そして課題の読解力などを評価します。
また短時間でどこまでつきつめて物事を考え、コードに表現をしているか、エンジニアとしての集中力や論理性についても評価します。
そして、一次面接時にもコーディングテストをテーマに時間を割くことで、応募者のスキルを把握することができます。以下では、コーディングテストが実施され、通過した応募者に対して、1次面接でどのように対応するかを例に記載しています。
0.コーディングテストの内容チェック（事前）
面接の前に、一応以下については確認しておきます
・課題が正しく動作するか否か
・動作内容が仕様と合致しているか
この辺で問題があったりズレがある場合は、即評価につなげるのではなく、以下の感想戦の質問の材料にします。
1.コーディングテストの感想戦
以下のようなことを質問します。ここでのやり取りで基礎的なアルゴリズム能力、プログラミング能力について判断します。
・どのくらい時間がかかったか？
・なぜこの言語を選んだか？
・問題文を解く上で工夫をしたところはどこか？
・どこが難しかったか。もしくは分かりづらかったか？
・時間がもっとあったら、どの辺を直したいか？
・etc...
2.コーディングテストの拡張
コーディングテストで実装した内容を、より洗練させて、プロダクションレベルにするために何が必要かを質問します。より実戦経験に基づいた能力を判断します。
・本番で動作させるためにどのように実装を変更するか？
・想定回答： ログ出力やエラーハンドリングをきちんと行う。テストをもっと書く。クラス設計をしっかりする、性能・スケーラビリティや保守性を考慮したコードにする。等
・自分で仕様を決めて良いとした場合、アルゴリズムを変えたいと思う箇所はあるか？
・etc...
注意：コーディングテストで評価しない事
以下については、評価対象に加えないことを推奨します。
・個別の言語の習熟度
あえて普段は仕事で使ってないプログラム言語で書いてくることも人によってはある。 そのため言語の習熟度についてはそこまで深入りしない。
（パッケージングツールで今流行の○○を使ってない、この☓☓というライブラリを使ってない、最近主流の△△という構文を用いてない、等）
・変数名やシンタックスなど、プログラムの書き方
アルゴリズムの評価が最も大事な観点なので、評価には加えない
あまりにひどい変数の付け方をしてたりしたら指摘してあげても良いかも
・細かいバグ
気づいても、評価には加えない。どういう考えでどういうイメージでアルゴリズムを書こうとしたか、の方が評価としては大事。
「時間がもっとあったら、どの辺を直したいか」等の質問をした時に、本人が無自覚だった場合は、そっと指摘してあげてもよいかも
2. System Design Interview
いわゆる 「ホワイトボードディスカッション」
ホワイトボード上にシステムの概要図や要件など抽象的な条件を記載し提示した上で、その構築方法や改善案などを尋ねる方法を指します。
この方法を通して、技術を用いたシステム構築能力や課題解決能力、およびそれらの経験についてを評価します。
また、この課題はディスカッションをしながら進めていくので、課題解決の際の論理性やコミュニケーションスキルについても評価をします。
System Design Interview については以下の記事なども参考にしてくさい。
System Design Interview の進め方
まず、課題を提示した上で、応募者とディスカッションや質疑応答をしながら進めていきます。
ツールとしては、口頭でやり取り可能であれば口頭でも良いと思いますが、必要であれば Jamboard などの相互インタラックション可能なホワイトボードツールを使うことをおすすめします。
1. [面接官側] システムの提示
まず、課題となるシステムを提示します。
どんなシステムを提示するかは臨機応変で良いと思いますが、例については当項目の末尾に例示します。
2. [応募者側] システムについて質問
１で提示されたシステムに対して、不明点などについて質疑応答を繰り返しながらシステムのスコープを明確にしていきます。
その中で考えなければいけない軸は以下のようなものがあり、それらについてディスカッションをしながら相互同意を重ねていきます。
・システム規模(DAU/MAU、データサイズ、ピークトラフィックなど)
・必要とする機能
・対応デバイス、OS
・もっとも大事な機能はなにか
・etc...
3. [応募者側] システム構築案について説明
２までの流れの中で理解したシステム要件に基づき、応募者が考えるシステム構成を説明します。
必要であれば、 Jamboard などにシステムの素案について記載してもらいます。
4. [面接官側] システム構築案に対して質問
３で提示されたシステムについて、面接官側で深堀りした質問をします。
おおむね、以下の観点で質問をしていく形になると思います。
・ユーザーアクセスが増えた時にどう拡張するか
・扱うデータが増えた時にどのように拡張するか
・機能を追加する時に、どのような形で拡張をするか
・etc...
課題例
以下は適当に考えた例ですが、会社の中の実際のシステムでの課題に紐付いた内容を例示すると、課題を提出する側としても理解度も高く、実践的な話になると思います。
・外部の企業に使用してもらう機能を Web API として提供しようと考えている。どのような構成で構築するか。
・インターフェースは JSON
・サーバーは冗長構成を保つために複数構成にする
・データの永続化は RDB や KVS などを使用する
・トラフィックが急激に増えた時に対応できる構成にできるだけしたい
・Web API で受け付けたリクエスト内容について、同期的に処理をするのではなく、非同期処理で動かせるようにしたい。どのような構成で構築するか。
・どのような形で非同期処理を実現するかは自由
・非同期処理に失敗した場合のリカバリー手段については検討すること
・非同期処理の性能はできるだけ拡張性をもたせたい
・Web API で受け付けた処理に基づき、外部の企業が提供している API を呼び出す必要がある。どのような構成で構築するか
・外部企業の API は Rate Limit が設けられているため、その事を考慮した仕組みにすること
・外部企業の API のメンテナンスや障害発生を見越した構成にすること
・呼び出し処理に失敗した場合のリカバリー手段についても検討すること
注意：見るべき点
もちろん誰が見ても理想的で完璧なシステム構成を提示できることが望ましいですが、短い時間でのやり取りなので誤解や勘違いなども生じることが多く、提示されたシステムの完成度や採用した技術スタックの妥当性についてはあまりあら捜しをしないほうが良いです。
どちらかというと 「システムを考える際のプロセス」 について注視して見るべきと思います。
・与えられた課題に対して、どの程度の解決策の引き出しを持っているか
・その引き出しを組み合わせて、どのような考え方でシステムをデザインしようとしているか
・どの程度、面接官側の意図する内容が言葉として咀嚼できているか
また、やり方として、Coding Test のツールを使って System Design Interview に類する質問を課題として出し、面接の場ではその感想戦・ディスカッションを行う、という形も効率が良いかもしれません。
３. 過去の経歴についての質疑応答
過去の経歴についての質問はどこの現場でもよく行われていると思うので、ここではあまり記載しません。
「誠実さ」について
心技体の「心」の部分についてはあまり一次面接では深堀りしなくて良いと思いますが、以下の点については注意しつつ質疑応答をしたほうが良いと思います。
・経歴書に書かれている内容は、本当にその人が行った事なのか？
・自分以外の他人の実績ではないか？経歴を盛るために自分の実績として記載してはいないか？
・技術的な点について深堀りして、的外れだったり浅い回答しか返ってこない時は怪しい
・質問に対してストレートに回答がされているか。話がそらされていないか？
・深堀りされると弱い点については、ついついごまかそうという心理が働く
・意地悪しすぎる必要もないけど、話がそらされてると思ったら何度か繰り返して同じ質問を深堀りしたほうが良いかも。
・途中で仕事を放り投げていないか？最後までやり遂げられているか？
・システムを最後まで作り切ることと、中途で離脱することでは、得られる経験やスキルにも差がでますし、エンジニアとしての体力にも差が出がちです。
・途中で離脱した理由があまり好ましく無いものだった場合、同じ事を繰り返す可能性もあります。
・もちろん色々な諸事情があるので、途中でやむを得ず離脱しないといけないケースもあることについては配慮が必要。
経歴を「盛る」ということについては、以前以下のような記事でも軽く振れていますので、興味がある方はご覧ください。
組み合わせ例
実施の面接の中で、上記の組み合わせは自由で良いと思いますが、ある程度網羅的に技術者を評価するためには３つの要素を組み合わせた面接にするのが望ましいとは思います。
一次面接はおおむね１時間の枠で実施しているので、組み合わせの例として、以下のような時間配分だと機能すると思います。
この記事が気に入ったらサポートをしてみませんか？