エンジニアの面接にどう備えるか

僕のキャリアにおいて、面接官としても面接を受ける側としても、無数の経験をしてきた。テック業界の面接プロセスには多くの欠陥があることは、誰もが知るところだ。この記事のまとめは、実戦的な思考の視点を提供し、少しでも勝率を高めてもらうことを願って書いている。

僕も以前、様々な面接の振り返りを書いてきたが、昨今は AI の登場によって少なからぬ変化が起きている。例えば、多くの企業が面接時に候補者がどのように AI を活用して課題を解決するかを観察するようになっており、これがテック業界の面接の方向性を徐々に変えていくと確信している。

面接の出来は君の実力とはイコールではない

面接で最も人を落胆させるのは、権力関係が極めて一方通行になりがちな点にある。応募者側としては、相手が本当に求めている基準を見抜くのは非常に難しく、面接が終わった後は自己否定に陥りやすい。面接がうまくいかなかったからといって、決して君がダメなソフトウェアエンジニアだというわけではない。僕もかつて、コーディング課題を提出した後に小さな修正点に気づき、面接のチャンスを逃すのではないかと焦って、自分の考えのどこが間違っていたかをすぐに HR へメールで伝えたことがある。幸いその時は通過できた。

僕が言いたいのは、面接の選考プロセスでは突発的な出来事によってチャンスを逃してしまうことが往々にしてあるということだ。

僕が『雇用と面接』で触れたように、面接は本質的にはくじ引きに非常によく似ている。

リソースが限られている状況では、企業は不適格な人材を採用することによる膨大な管理コストや離職コストを避けるため、Recall（再現率）を犠牲にしてでも Precision（適合率）を高める戦略をとりがちだ。言い換えれば、企業は False Negative（優秀な人材を誤って落とすこと）のリスクを甘受してでも、False Positive（適さない人材を採用してしまうこと）を極力避けようとする。

このゲームのルールを理解すれば、面接がノイズに満ちたプロセスであることがわかるはずだ。そのノイズだらけのプロセスに基づいて自分自身の価値を定義してしまうことが、面接における精神的消耗の大きな原因の一つなのだ。

『インポスター症候群』でも書いたが、自己価値を面接の結果から切り離すことを学ぶのは、メンタルヘルスにとって極めて重要だ。面接において最も重要なことを一つ挙げるなら、それはメンタルのコントロールだろう。

テック業界の面接

僕が『測定が目標になるとき：窓税からPull Request数まで』で触れたグッドハートの法則（Goodhart’s law）がある。「測定指標が目標になった途端、それはもはや良い測定指標ではなくなる」。

現代のテック面接こそ、まさにこのグッドハートの法則の最も典型的な被害者だ。

30年前、マイクロソフトや Google がアルゴリズム問題やパズル問題を導入した時、本来は非定型的な問題を通じて、候補者の基本的な計算論的思考力やその場での課題分解能力を測る指標にするつもりだった。しかし、この代理指標が採用基準として固定化されると、システム全体が瞬く間に形骸化し、破綻してしまった。

Ruby on Rails の生みの親である DHH も、2017年のツイートで、ホワイトボードでバブルソートを書かせたら自分だって失敗するし、普段はネットでコードを検索しまくっているし、パズル問題も解かないと告白している。広く使われているフレームワークを作った張本人ですら、面接の試験問題が得意とは限らないのだ。

ホワイトボード上で即座にアルゴリズムを書けるかどうかと、優れたソフトウェア開発ができるかどうかは、結局のところ決してイコールでは結べない。

マニアックなアルゴリズムの暗記が高給取りへの切符となってしまったことで、不可避な3つの構造的歪みがもたらされた：

1. 高額な受験対策産業を生み出した：候補者は数千ドルと数百時間を費やし、人為的に作られた文化的儀式や解法テクニックを学ぶ。そしてそれらの記憶は、面接を突破して入社した後、1週間もすれば脳のガベージコレクションによって消去される
2. 高いランダム性とノイズ：匿名面接プラットフォーム Interviewing.io の創業者 Aline Lerner は、プラットフォーム上の数千件の技術面接データを分析した上で、技術面接の結果は極めて高い不確実性を持つと指摘している。平均的に優秀な人であっても、回によってパフォーマンスに大きなバラつきが生じるのだ

毎日 Google で検索しているエンジニアが毎週のように安定的で信頼性の高いアーキテクチャをデリバリーできる一方で、ホワイトボードに赤黒木をスラスラ書けるような人が、チームに入ったら基本的な Git コンフリクトの解消すら手こずることもある。

面接官は何を見ているのか

面接を一方通行の試験だと思わないでほしい。それはむしろインタラクティブな技術的対話に近い。面接官は通常、いくつかのコアとなる問いを持って君を観察している。僕の場合、事前に用意した指標があり、面接を進める中でそれらを掘り下げていく。例えば以下のようなものだ：

• 基礎能力：基礎がしっかり身についているか。細かい点に不案内な場合でも、実践力や論理的思考で素早く補えるか。候補者が不慣れな問題に直面した際、僕はむしろ AI との対話を通してどう解決していくかを直接見せてもらうよう促すことすらある
• カルチャーフィット：多くの企業にはカルチャードキュメントがあり、仕事に対する期待や基準が示されている。応募する企業の Web サイトにそういったページがあれば、事前に一読しておくことをお勧めする
• コラボレーションと自発的な認識合わせ：チームは通常、他者と協調し、能動的にコミュニケーションを取って認識を合わせられる人材を求めている。これは企業がその時点で募集しているポジションにもよるが、仕事において協力は避けて通れないものだ
• 問題解決能力：未知かつ不確実な課題に直面した際、能動的に要件を明確にし、検証可能な範囲にまで問題を分解できるか

続いては、設計に関する質問だ。よくある面接の問いとしては、「これまでに経験した中で最も印象深く、難易度が高かったプロジェクトについて教えてください」といったものがあり、そこからさらに掘り下げていく：

• そのプロジェクトで君が果たした役割は何だったか？ 当時の要件は？ どんなパフォーマンスボトルネックに遭遇したか？ なぜ従来のやり方ではうまくいかなかったのか？
• トレードオフの明確な議論：エンジニアリングの世界に銀の弾丸はない。A を選ぶか、それとも B を選ぶか？ パフォーマンス、可読性、開発速度の間でどのような妥協をしたのか？ もし当時の状況に戻れるとしたら、どのような異なる決断を下すか？

この質問が有効なのは、名前だけ連ねていただけでは全てのディテールに答えることが到底できないからだ。一方で、実際に課題を解決した経験があれば、細部まで熟知しているはずだ。面接官もその受け答えから、君のレベルや経験がどの程度か、自社が求める水準に達しているかを把握することができる。

面接で自分をどう証明するか？

面接においては、自分をマーケター（セールス）の役割だと捉えるとよい。これは誇大広告をしろという意味ではなく、面接での最大の目的はこの職務を遂行する能力があることを証明することにあるからだ。適性があるかどうかを検証するのは企業側の仕事であり、君の目標は自分の能力を提示し、かつその企業が自分に合っているかを見極めることだ。

面接官からヒントを出されたときは、それを責められたと受け取らないでほしい。大半の面接官は君を論破しようとしているのではなく、彼らもまた疲弊した会社員であり、話の合う同僚を見つけたいと思っているだけなのだ。これは、その会社が自分に合っているかを観察する絶好の機会でもある。

以下に、実践できるいくつかの戦略を挙げる：

情報の獲得

初期のエージェントや採用マネージャーとの面談において、「このポジションで成果を出せる人には、通常どのような特質が求められますか？」と直接聞いてみるのもいい。その手がかりを得ておけば、その後の面接でより的を絞って強みをアピールできる。例えばインフラ周りの人材を重視している企業なら、職務経歴書や自己紹介でインフラの改善実績やハンズオンの経験についてより手厚く触れることができる。

プロジェクトの経験から語る

まずは最も直感的でシンプルな方法で基本機能を成立させ、その後の深掘りに応じて計算量や複雑性を最適化していく。

プロジェクトの経験を語るなら、まずはハイレベルな背景と課題から切り出し、その後に技術的な詳細へと踏み込むといい。当時の要件は何だったのか？ どんなパフォーマンスボトルネックに遭遇したか？ なぜ従来の手法ではうまくいかなかったのか？

自発的な認識合わせ

多くのコミュニケーション問題は、本質的には単なる情報や認識のギャップに過ぎない。

面接官に自ら詳細を確認しよう。「アーキテクチャの議論はどの程度の深さまで掘り下げますか？」「データ量は大体どのくらいの規模を想定していますか？」こうした確認は方向性を定めるのに役立ち、的外れな憶測を減らすことができる。

トレードオフを議論する

エンジニアリングの世界に銀の弾丸はない。A を選ぶか B を選ぶか？ パフォーマンス、可読性、開発スピードの間でどんな妥協をしたのか？ 当時の状況に立ち戻れるとしたら、今ならどんな異なる判断を下すだろうか？

未知に正直に向き合う

わからないことは素直に認めよう。知ったかぶりだけは絶対に禁物だ。シニアエンジニアには一瞬で見抜かれる。特定のツールに詳しくないことを認めた上で、自分ならどう調べ、どう道筋を立てていくかを説明する方が、かえって謙虚さ（Humble）と問題解決に対する地力を示すことができる。

アピール（Showoff）の機会を逃さない

面接官が必ずしも君の最も得意な分野をピンポイントで聞いてくれるとは限らない。もし質問が君の経験に関連しているなら、回答した後に「以前対応したある課題と非常によく似ているのですが、詳しくお話ししましょうか？」と一言添えてみるといい。相手に深掘りの機会を与えつつ、それが相手の知りたい方向性に合っているかも確認できる。

あるいは、過去のプロジェクトでどのようにボトルネックを特定したか、インフラコストを削減したか、ミスが発生しやすかったデプロイフローをいかに信頼性の高いものにしたかを話すのもよい。使った技術を羅列するだけでなく、何を発見し、何を実行し、問題が本当に改善されたことをどうやって確認したのかを明確に伝えるのだ。

数値データがあるなら、改善前後の差分と計測条件を提示する。数値がない場合でも、具体的な変化を説明すればよい。チーム全体で達成した成果であれば、その中のどの判断と作業を自分が担ったのかを面接官に明確に伝えるべきだ。

面接は双方向なものだ

『2017年前端面試心得』でも実感したが、面接は決して一方的な試練ではない。面接官の態度、時間に対する敬意、質問の深さは、往々にしてチーム内部の日常を直接反映している。君は毎日8時間を共に過ごす仲間を選んでいるのだ。

面接の終盤にある逆質問の時間に、いくつか聞いてみることを勧める。僕はこの確認作業を「Smell Test」と呼んでいる：

• 昇進メカニズム：「チームで最近昇進した人は、主にどのような成果を上げたからですか？」
• 許容のデッドライン：「チームメンバーが不適任と判断されたり、退職を促されたりするのは、通常どのような状況が起きた時ですか？」
• 意思決定の対立：「大きな技術選定やアーキテクチャの設計でチーム内に深刻な対立が生じた時、普段どのように最終決定を下していますか？ disagree and commit はできていますか？」
• 日常の開発運用：「現在チームでは、コードを書き終えてから本番環境にリリースされるまでにどんなステップを踏んでいますか？ 自動テストや自動デプロイは導入されていますか？」
• 企業カルチャー：「最近、経営陣などの上層部がプロダクト開発に直接介入してきたような事例はありましたか？」

もし相手の回答が言葉を濁していたり、防衛的な態度だったり、あるいは面接官が終始上から目線で候補者を打ち負かそうとしてくるようなら、たとえ内定（Offer）が出たとしても、そこが本当に自分の身を置きたい環境なのか真剣に考え直した方がいい。

日本の面接

上記の原則を踏まえた上で、日本の面接についても少し触れておきたい。礼儀や年功序列が重んじられる日本の職場環境では、面接を通過するためにある種の「演技」が必要になることがある。

企業の面接プロセスには、その会社の文化が色濃く反映される。もしある企業が重視しているのが礼儀作法、完璧な尊敬語や謙譲語、長時間の残業ができるかどうかであるなら、入社後もそうした職場文化に向き合うことになる。選ぶ基準は人それぞれだが、この手の企業では往々にして次のような問題が生じやすい：

• 評価基準が曖昧：「できて当たり前だろう」「とりあえず根性だろう」といった精神論で上司から要求される
• 自らの保身や権力の維持が最優先：君の活躍が上司や同僚の地位・権力を脅かしかねないと察知されると、協力するどころか抵抗や排除に回ることがある
• 形式的なマナーの重視：毎朝の朝礼や気勢上げ、オフィスに入る時に大声で「おはようございます」と叫ばされるといった形で現れる

僕が仕事を選ぶ際には、技術や課題解決を軸に置いた企業に加わりたいと考えているため、通常この手の会社は選考から外している。面接に臨む際は、自分の中で絶対に妥協できない条件や就業環境をあらかじめリストアップしておき、スクリーニングに役立てることを強くお勧めする。

2019年に僕が書いた『日本でのソフトウェアエンジニア就活体験記』も参考にしてみてほしい。

最後に、皆さんの面接がうまくいくことを祈っている！ 面接は決して楽なものではないが、それでもしっかりと準備を重ねることで勝率を上げられるものだ。人為的に作られた儀式的な選考のせいで、自分自身のすべてを否定する必要は全くない。面接で直面した困難や悩みなどがあれば、ぜひ気軽にメールで僕にシェアしてほしい！