魔法のチョークで描いた窓

コード中心面接

プロダクトエンジニアの採用活動において、私は「技術試験」を設計し、面接官の一人としてそれに参加しています。一般的にイメージされる「コーディング試験」とは少し違うため、私はこれを「コード中心面接」と呼んでいます。

「コード中心面接」は、候補者の方に課題に沿って制作いただいた成果物（コード）を起点に、設計から運用までの意思決定の過程を一緒に言語化していく面接です。また、候補者の方を評価するだけでなく、透明性をもって私たちの仕事の進め方をお伝えできる時間にもなるよう心がけています。

この面接を行う背景

プロダクトエンジニアとして私が採用したいのは、次の3つの領域を横断して活動できる人物です。

• ビジネス分析：曖昧な要求や断片的な情報から前提を整え、ストーリーとしてまとめ、最終的に実現したい「価値」を言語化すること
• モデリング：現実を説明するための、あるいは未来を構成するための「単位」を見出すこと
• エンジニアリング：マーケットに投入できる成果物として「形」を作ること

ここでポイントになるのは「抽象度の違う階層を上下する」能力です。ストーリー（抽象）からコード（具象）へ落としていく。逆に、コードの細部から設計や要求へさかのぼって問い直す。この往復運動ができるかどうかは、プロダクトエンジニアポジションの必須要件だと考えています。

あらかじめ制作いただくコードを中心に据えることで、この往復運動を再現しながら、横断的活動の各ステップについて議論しやすくなります。同時に、業界標準の知識や型を、生産性向上のために「援用」できているかも見えやすくなります。

具体的にどのような面接なのか

課題はどのようなものか

抽象度が高めの課題になりますが、一方で多くの人にとって共感しやすいテーマを選んでいます。これは、課題に取り組んでいただく過程でコンテクストの「補完」をしていただきたいからです。

面接の流れ

多くの場合、画面共有をいただきながらプレゼンテーションをしていただきます。この段階ではコードはもとより、特定のテクノロジーの話題には踏み込みません。一つの完成品として、候補者の方ご自身からそのメリットを説明していただきます。時間が許せば、こちらから仮定のユーザーストーリーを提示し、それを実現するための改修案を議論することもあります。

次にコードに移ります。プレゼンテーションの中に現れた概念が、どのように実装として落ちているのかを全員で確認します。未来の話もしながら、それらがどのようにスケール可能か、どこに限界が来そうかなどを一緒に見立てます。事前にコードは拝見しているため、こちらから気になっていた点を質問することもあります。この場合、基本的には「驚かされた点」「良いと思った点」について追加の説明を求める形を重視しています。

コードを一通り見終わった後は、「どう運用するか」「どう改善するか」といった仮想の改修案をもとに、画面やコードがどう変わるかを横断的に議論します。ときには、まったく別のソリューションがあり得ないか、といった方向へ話が飛躍することもあります。

この流れで面接を進めると、多くの場合、ここまでで40分が経過しています。

評価のポイント

コンテクストの「補完」（ビジネス分析）

実際の現場であれば、ここは分析対象を深掘りしていくフェーズです。ただ、架空の話をベースにした面接では、情報が足りないのは当然です。そこであえて「補完・創作」をしていただきます。その補完の仕方には、これまでの実務経験や、社会人としての観察眼が投影されます。たとえば、次のような観点が自然に出てくるかを見ます。

• ビジネスアプリケーション開発に携わっていれば自然に意識する一般的な要求が織り込まれているか
• 市中の製品を普段どのように分析しているか、過去のプロジェクトの事例などを踏まえて仮説が立てられているか

モデリング

ビジネスプロセスの中で、どのようなイベントが発生し、どのようなデータ構造が処理されるのかを見いだし、言語化できているかを見ます。そのモデリングの結果、現時点での要求を満たすことはもちろん、それらの要素を利用してビジネスを拡張するアイデアが描けそうか、持続可能なモデルになっているかもポイントです。

ここでいう「言語化」は、プログラミング言語で適切に表現できているかというより、思考を整理し、他者と共有できているかを意味しています。ですから、見出されたモデルをもとにした会話の質がとても重要です。

エンジニアリング

モデリング結果を、プログラミング言語・フレームワークの特性を活用しつつ、簡潔に実装できているかを見ます。特に「技術を援用できているか」を重視しています。つまり、場数を踏んだ人ほど持っている「型」が見られるか、そして状況に合わせてそれを適切に切り替えられるかを、会話の中で確認します。

加えて、見逃せないのがコスト意識です。テンプレ通りに実装したのではなく、ビジネス分析やモデリングの結果と整合性のある選択ができているか。時間的制約があるなかで、どこに時間をかけ、どこを割り切ったのかについて、合理的な説明があるかがポイントです。

総評・モノづくりの姿勢

面接全体を通じて、これはかなり重要なのですが、タスクをこなすのではなく「プロダクトをプロデュースする」姿勢が感じられたかを評価します。その姿勢が見えると、チームとして一緒にプロダクトを作り上げていけるイメージが一気に立ち上がります。面接のための課題に過ぎないことは事実なのですが。

また、これは評価とは別の話ですが、「仕事観」や「美学」のようなものを参加者全員でオープンに議論できたとき、面接としての成功を強く感じます。

終わりに（Tips）

最後に、面接を進行する上でのTipsです。

• 事前レビューで「粗探し」をしない
  • 成果物は事前にレビューできますが、候補者の方が確保できた時間などの制約は見えません。制約が不明な状態での粗探しは無意味です。
• 事前レビューは「強みの把握」を優先する
  • 感じ取った強みについては、面接で裏付けを得る必要があります。しっかりとリストアップしておきます。
  • 一方で弱みについては、逐一追加の情報が必要なケースはまれだと思いますので、優先度を下げます。
• スクリーニングは別の機会で
  • コード中心面接は「議論の質」を重視するため、技術面からのスクリーニング用途には不向きです。
  • それが必要な場合には、専用のコーディングテスト用ツールを利用するほうが生産的です。
• 能力を試す質問はしない
  • ワナや揚げ足取りになるような質問は極力避けます。雰囲気が悪くなり、「会話」「議論」の妨げになります。
  • 必要であれば、追加の架空の要件で議論してみたり、面接官自身の経験に意見を求めてみたりします。
• ポテンシャルは推測せず、プロフェッショナルとしてのアピールに注目する
  • 「会話」する時間が長くなる面接なので、印象評価やバイアスにとらわれた評価になる危険が高まります。
  • ポテンシャルを見ず、プロフェッショナルとしてのアピールにのみ注目します。
• レベルによって質問の仕方を変える
  • ジュニア寄りの方にはキーワードを織り交ぜ、話が広がるように支援します。
  • シニア寄りの方には簡潔に問い、経験に即して背景を察していただくようにします。

ところで、「コード中心面接」はAI時代でも有意義でしょうか――悩みながら面接をしていますが、いまのところAIを活用して制作されたコードを中心に良い議論はできています。この点について近いうちにフォローアップの記事が書けたらと思っています。

最後までお読みいただきありがとうございました。