面接官に細かく掘り下げられたとき、自分のプロジェクトをどう説明するか

自分のプロジェクトです。コードの大半を書き、いちばん厄介なバグを夜中の 2 時に直し、その場の誰よりもよく知っている。だからこそ、キャッシュをなぜその方法で無効化しているのかと面接官に聞かれ、わかりきっていたはずの答えが文の途中で崩れていくと、ひどく驚きます。

心理学者はこの差を測っており、仕組みを知れば、ずっと備えやすくなります。

自分の仕事が説明しにくい理由

よく知られた一連の研究で、Leonid Rozenblit と Frank Keil はイェール大学の大学院生に、ファスナー、水洗トイレ、シリンダー錠、ヘリコプターといった身近な装置をどれほど理解しているかを 7 段階で評価してもらいました。続いて学生たちはそれぞれの仕組みを順を追って書き、もう一度理解度を評価しました。評価は下がりました。シリンダー錠をどうやってピッキングするかなど、仕組みを本当に知らないと答えられない診断的な質問のあとには、さらに下がりました。最後に専門家の説明を読み、もともとどれだけ知っていたかを振り返って評価しても、評価は低いままでした。最初の理解の感覚が、単に高すぎたのです（Rozenblit と Keil、2002）。

著者らはこれを説明深度の錯覚と呼んでいます。この錯覚は事実、手順、物語よりも説明の場合にずっと強く表れ、著者らが挙げた理由はソフトウェアのプロジェクトに驚くほどよく当てはまります。作業中はシステムが目の前にあるので、調べればわかることを知っていると感じてしまいます。上の層を理解していれば、下の層もわかっていると思い込みます。全体を最初から最後まで説明する機会はめったにないので、自分の説明がどこで途切れるのかを知ることがありません。

面接が尋ねるのは、まさにその診断的な質問です。

面接官が掘り下げるもの

Amazon の採用担当者は、いちばんよくある失敗をはっきり指摘しています。候補者の話が十分に深くないのです。質問ごとに一つの状況を、数字、そのプロジェクトに関わった人、出した成果を含めて詳しく話してほしいと言います。また、面接はあなたが何をしたかを知るための場なので、行動は一人称で説明するよう求めています（Amazon の採用担当者）。同社の行動指針の一つ、Dive Deep は、細部を把握し続けることを求めています（Amazon）。

どこで面接を受けても、同じ形を想定しておきましょう。あなたが短く全体を話し、面接官が一段ずつ深くなる質問を重ねます。全体の説明は簡単な部分で、評価されるのはそのあとの質問です。

2 分で話すプロジェクト説明

課題と、それに困っていた人から話し始めます。難しさの原因になった制約を含めて、1〜2 文で話します。

患者向けポータルの検索に 1 秒近くかかり、春のリリース後、それについての問い合わせが倍になっていました。

自分が担当したことと、ほかの人がしたことを、それぞれ一文で言います。2 分の大半は 2〜3 個の判断に使い、それぞれ選ばなかった案も挙げます。選ばなかった案のある判断は判断力を示し、ツールを並べても何も示せません。

レプリカを増やす手もありました。遅いのはランキングで、レプリカは読み込みにしか効かないので、事前計算したインデックスを選びました。

最後は結果と数字、そして変えたいことで締めます。

p95 は約 800 ミリ秒から 200 ミリ秒未満になりました。もう一度やるなら、インデックスを再構築するジョブに最初からバックプレッシャーを入れます。

そこで話を止め、どの話題を続けるかは面接官に選んでもらいます。

深掘りの質問に備える

プロジェクトの深掘りでほぼ毎回出てくる質問がいくつかあり、どれも面接の前に 1〜2 文で答えを書いておく価値があります。なぜこの設計にしたのか、わかりやすい別の案を選ばなかったのはなぜか。いちばん難しかったバグは何で、どうやって見つけたか。うまくいったとどうやってわかったか、何を測ったか。依存先が止まったとき、ジョブが途中で再起動したとき、入力が 10 倍になったときにどうなるか。自分で書いた部分、決めた部分、レビューした部分はどこか。もう一度やるなら何を変えるか。

Rozenblit と Keil のテストは自分にも使えます。プロジェクトの中心となる流れ、たとえば一つのリクエストやジョブの最初から最後までを選び、コードを開かずに順を追って書き出します。その流れについて、途中でサービスが再起動したらどうなるか、といった診断的な質問を一つ加えて答えます。ためらったところはすべて、これから聞かれる深掘りの質問です。コードを開いて足りないところを埋め、声に出して言える一文で答えを書いておきましょう。

よいプロジェクトを台無しにするミス

いちばん多いのは、技術の名前を並べることです。React、Node、Postgres、Redis という名前からは、あなたがどう考えるかは伝わりません。その次に多いのは、最初から最後までチーム全体の話をすることで、面接で話すべきなのは自分の担当部分です。数字が一つも出てこない説明もよくあります。レイテンシ、ユーザー数、金額、短縮した時間、エラー率のどれか一つで十分です。実際より多くを自分の仕事として語る人もいますが、次の質問は一段深くなります。すべての構成要素を説明する人もいます。いちばん面白い判断を含む 2 つを選び、残りは質問に任せましょう。

ファイルに仕事の一部を任せる

私たちが Prepped を作った理由の一つがこれです。Prepped の面接にプロジェクトのフォルダーや GitHub リポジトリを追加すると、準備の段階でファイルを読み、コードについて聞かれそうな質問への回答を、それぞれどのファイルにもとづくかを示して下書きします。ファイルが裏づけない部分には印が付くので、何を確かめればよいかがわかります。面接質問集には、課題、自分の役割、主な判断、結果からなるプロジェクト説明の構成もあり、説明が 2 分に収まるまで練習できます。