私は両方の立場を経験してきた。面接官が黙ってうなずく中、ホワイトボードにシステム設計を描いたこともある。そして、候補者がホワイトボードに通知システムを設計するのを見守る側にもなった。
候補者が準備するものと、面接官が実際に評価するものとの間には、驚くほどの隔たりがある。
候補者が準備するもの
- LeetCodeの難問
- マイナーなアルゴリズムのトリビア
- 「〜したときの経験を教えてください」
- 暗記したシステム設計の回答
面接官が実際に評価するもの
曖昧さへの対処法。 システム設計の問題を与えられたとき、私が最初にすることは質問をして明確にすることだ。「ユーザー数は？レイテンシ要件は？予算は？」。質問もせずに箱を描き始める候補者は危険信号だ。要件を理解せずに構築する——そして仕事でも同じことをする。
トレードオフの認識。 完璧なアーキテクチャは存在しない。すべての選択にはコストが伴う。候補者が「メッセージキューにはKafkaを使うべきです」と言ったとき、私は「なぜSQSではないのですか？」と尋ねる。トレードオフを明確に説明できれば（Kafka：高スループット、運用オーバーヘッド大、リプレイに優れる；SQS：シンプル、マネージド、ほとんどのケースで十分）、彼らはエンジニアリングを理解している。「Kafkaは業界標準です」と言うなら、それはカルゴカルトだ。
障害モードの思考。 「このサービスがダウンしたらどうなりますか？」「ダウンしません」という答えが返ってきたら、その人は本番システムを運用したことがないと分かる。すべてのものはダウンする。問題は、それに備えて設計しているかどうかだ。
コミュニケーションの明確さ。 非技術者にも設計を説明できるか？シニア職では、プロダクトマネージャー、デザイナー、経営陣とのコミュニケーションが求められる。他のエンジニアにしか説明できないなら、成長の限界に達している。
私がする質問（と実際にテストしていること）
「最近取り組んだ、誇れるプロジェクトについて教えてください。」
テストしていること：一貫したストーリーを語れるか？技術だけでなく制約条件にも触れるか？チームの功績を認めるか、それともすべて自分の手柄にするか？違うやり方をした点について言及するか？
「本番環境で500エラーが発生しています。デバッグのプロセスを教えてください。」
テストしていること：体系的なアプローチを持っているか、それとも当てずっぽうか？最初にログとメトリクスを確認するか、それともコードを変更し始めるか？影響範囲を考慮しているか？
「[X]のシステムを設計してください。時間は45分です。」
テストしていること：最初に質問をするか？要件から始めるか、それとも技術から始めるか？監視、エラー処理、スケーリングに言及するか——それとも正常系だけか？
面接官になって変わったこと
候補者だった頃、私は面接官が「正解」を求めていると思っていた。面接官になって学んだのは、正解など存在しないということだ。評価しているのは思考プロセスなのだ。
シンプルなシステムを設計し、その限界を認め、いつ複雑さを追加するかを説明できる候補者の方が、説明できない複雑なシステムを設計する候補者より優れている。
私のアドバイス（両方の立場から）
候補者へ：
- 設計を始める前に、3〜5つの質問をして明確にすること
- シンプルに始めて、求められたら複雑さを追加すること
- 自発的に障害モードに言及すること（「このサービスがダウンした場合、こうなります」）
- 主要な決定ごとにトレードオフを説明すること
- 知らないことは正直に認めること——「Kafkaを大規模に使ったことはありませんが、スループットの利点は理解しています。このユースケースではSQSから始めて、リプレイが必要になったら移行します」
面接官へ：
- 特定の技術知識をテストせず、エンジニアリングの判断力をテストすること
- 「違うやり方はありますか？」と尋ねること——優秀なエンジニアは自分の仕事に強い意見を持っている
- 候補者がミスから立ち直る余地を与えること——間違えたときの対応の仕方こそ、正解すること以上に多くのことを教えてくれる
最高の面接は、一緒に仕事をしているような感覚になる。最悪の面接は、尋問のように感じられる。前者を目指して設計しよう。
