スタッフエンジニアのインタビューループ：シニアループが見落としている本質
なぜスタッフループがシニアオファーを出すのか
スタッフエンジニア採用における最も一般的な失敗パターンは、シニアループにシステム設計ラウンドを追加しただけで「スタッフループ」と呼ぶことです。こうなると、すべての面接官がシニア基準で候補者を評価します。フィードバック面談は「強いシニアか」という議論になります。採用マネージャーはポジションがスタッフレベルだからという理由でスタッフを推し進めます。その結果、オファーはシニアレベルに下げられるか、6ヶ月以内にその職務に対応できない人がスタッフレベルで採用されることになります。
このパターンが繰り返される根本的な理由は、「シニア」の評価基準は十分に理解されているからです。堅実なコーディング、サービスの所有、ジュニアのメンタリング、エンドツーエンドの機能設計—こうした要素は明確です。一方、「スタッフ」の評価基準は曖昧です。スタッフエンジニアリングとは、正しい問題を選び出し、複数のチームをひとつのソリューションに結集させ、判断が高コストを招く領域での技術的トレードオフについて正しい決定を下す職能です。こうした能力は45分のコーディングセッションでは見えません。
本記事は、スタッフレベル以上の職位向けループ設計です。すでに実績のあるシニアループを運用していながら、シニアと本物のスタッフエンジニアを区別する追加的な要素をテストしたい方を対象としています。特定の企業規模を仮定していません。
スタッフを実際に区別する4つの評価軸
効果的なスタッフ評価基準は、以下の4つの軸に対し、シニア、スタッフ、シニアスタッフそれぞれでの明確なアンカーを定めてスコアリングします：
- 判断の範囲。 候補者は、未知の領域で、不完全な情報と相反する制約が与えられたとき、取り組むべき正しい問題を見出せるか。シニアエンジニアは与えられた問題を解きます。スタッフエンジニアは、どの問題を解くべきかを示します。
- アーキテクチャ決定の質。 候補者はコスト、レイテンシ、爆発半径、組織結合度といった実際のトレードオフが存在するレイヤーでシステムを考察し、文書で選択を正当化できるか。これは教科書的な設計パターンを思い出すのとは異なります。
- クロスチーム影響力。 候補者は自分の直属チーム以外の仕事の方向性を変えた経験を語り、その際に効果を発揮した具体的な手段—ドキュメント、会議、プロトタイプ—を説明できるか。「レビューでフィードバックした」ではスタッフレベルではありません。「3つの競合案をまとめた設計ドキュメントを書いた」ならそうです。
- 遠隔地の技術メンタリング。 候補者は自分が管理していないエンジニア、さらにはそのチームの専門外の領域において、その人たちのレベルを引き上げられるか。これがスタッフエンジニアと、単に経験を積んだシニアエンジニアを分ける本質的な違いです。
ループの各ステージは、これら1～2の軸を探るために設計されるべきであり、シニアバーを再度検証するためではありません。
ステージ別ループ設計
総所要時間：候補者側約6時間、面接官側約10時間。6つのステージで構成：
ステージ1：採用マネージャーによるスクリーン（60分）
採用マネージャーによる最初のスクリーンは、「フィット感」を確認する雑談ではなく、あなたのスタックにある実課題について深掘りする実務的な対話です。候補者が何かを提案する前に問題についての質問をせざるを得ないよう、プロンプトは十分にオープンな形で示します。採用マネージャーが聞き取るべきポイント：候補者は問題を解く前に問題を限定できるか。組織構造、オンコール費用、移行リスクといったシニアエンジニアが見落とす制約条件について質問するか。
このステージでリクルーター主導の「自己紹介」ラウンドを廃止します。簡潔な説明は別途20分間のスケジューリング通話で行ってください。
ステージ2：書面による設計ドキュメント（4～8時間、非同期）
スタッフループで最も予測力が高く、多くの企業が「候補者への負荷が大きい」を理由に省くステージです。実際にはそうではありません。シニア候補者は定期的に2時間のテイクホーム演習を完了します。スタッフ候補者も焦点を絞った設計演習を完了します。そのドキュメントは単なる評価材料ではなく、候補者自身が職務内容を判断するための重要な材料だからです。
出題例：あなたの領域からの実在的かつ意図的に不完全な問題。「支払いチームが現在アドホックなLambda関数で手作業しているオーケストレーション処理を、ワークフローエンジンで自動化したいです。3～8ページのドキュメントを書いて、あなたが推奨するアプローチを主張し、検討した代替案を示し、想定される3つの大きなリスクを特定してください。」
ドキュメントから読み取れることで、60分のホワイトボード面接では得られないこと：
- 候補者は、十分な時間がある場合、議論をどのように構成するか。
- 候補者は、あなたの組織の実際の制約に対応したトレードオフを挙げるか、それとも一般的な原則に逃げるか。
- 候補者はチームがまだ認識していない失敗シナリオを見出すか。
- 候補者は他のスタッフエンジニアに向けて文書を書く方法。これがスタッフの仕事の大部分です。
次のラウンド前に、独立したルーブリックでドキュメントをスコアリングします。弱いドキュメントは、ホワイトボードでの好成績では補えません。
ステージ3：設計ドキュメント深掘り面接（75分）
採用マネージャーとスタッフまたはプリンシパルエンジニアの2名がパネルとなり、候補者とドキュメントについて対話します。候補者はプレゼンテーションをしません。パネルは事前にドキュメントを読み、この75分をフォローアップの質問に充てます。構成：
- 最初の15分：代替案の検討。 「Step Functionsアプローチを排除した理由は？レイテンシ予算が5秒ではなく50ミリ秒だったら、何が変わりますか？」
- 次の30分：失敗モードの分析。 3つの具体的な条件下でシステムがどう壊れるかを一緒にトレースします。その過程で候補者がリアルタイムで自分の設計をどう修正するか観察します。
- 最後の30分：移行計画。 「現在47個の既存Lambdasをこのシステムに移行する必要があります。最初の90日間をどう進めますか？」
このステージは評価軸1と2を組み合わせてテストします。候補者は正しい問題を特定できたか。制約が変わるとき、その設計は本当に防御可能か。
ステージ4：コーディング面接（60分）
スタッフレベルであっても必須です。理由は2つ：コードを全く書けないスタッフエンジニアは稀かつ悪質であること、そしてこのラウンドで、候補者が実務で必要とされるシニアエンジニアとのペアプログラミングに対応できるか判定できること。
LeetCodeを使いません。実務的なコードのデバッグまたはリファクタリング課題を出題します—200～400行の実際的なコード、非自明なバグ、「見つけたときより良い状態にして返す」という明確な指示付き。シニア向けのコーディングルーブリックでスコアリングしますが、診断的思考力とコードレビュー能力をスループット重視より上に置きます。
バグを流暢に特定し、直さない追加問題を2つ以上挙げ、最小限で安全なリファクタリングを説明するスタッフ候補者は、仕事が要求する姿勢そのものです。スピードでシニア候補者を上回るような候補者ではなく。
ステージ5：クロスチーム影響力面接（60分）
ほとんどのスタッフループが実施せず、かつ最も確実に false positive（実は影響力のないシニアエンジニア）をスクリーンアウトするラウンドです。
構造化された行動面接形式で、4つの深い質問を用意し、それぞれが異なる影響メカニズムを掘り下げます：
- 「チーム内で不人気だった技術的立場について教えてください。自分の考えが変わったのか、それともチームが納得したのか？」
- 「プロジェクト化するべきではなかったプロジェクトを止めた経験を教えてください。携わった人たちの信頼を失わずに、どうやって進めましたか？」
- 「最近書いた技術ドキュメントで、別のチームが自分たちの仕事の基礎として採用したものについて説明してください。」
- 「自分が管理していないエンジニアで、当初は自分より優秀だった領域でメンタリングした経験を教えてください。何をしましたか？」
候補者の回答には、人、ドキュメント、会議、結果といった具体的な名前が出ているべきです。曖昧な回答—「方向性を揃えた、合意を形成した、リリースした」—はこのラウンドで不合格です。この職務は具体的なメカニズムに満ちています。面接もそうあるべきです。
ステージ6：バーレイザー面接（45分）
採用チーム外のスタッフまたはプリンシパルエンジニアが、チームの必要性ではなく、会社のスタッフバーに対して候補者を評価します。終了時の評価者の問い：「この人と、自分が大切だと思う問題で一緒に仕事をしたいか？」
デブリーフはスコアシートをロックした状態で同日中に実施してください。スタッフレベルでは形式が特に重要です。議論の焦点が「誰がコードを書けるか」ではなく「スコープと判断」にあり、これはまさに会議室にいるカリスマ的な面接官に流されやすい議論だからです。
ループに含めるべきではないもの
スタッフループが含まない方がよいもの、および各々が陥りやすい罠：
- 2つのコーディング面接。 1つで十分です。2番目は何も新しい情報をもたらさず、「採用する職務を理解していない」というメッセージを候補者に送ります。
- 「Twitterを設計して」というジェネリックなシステム設計面接。 一般的なプロンプトは暗記力をテストするだけです。あなたの実領域からの問題を出題し、候補者に実際に考えさせてください。
- 「リーダーシップ原則」という名前の別の行動面接。 すでに構造化された行動面接を実施しているなら、それを1つの十分に設計されたクロスチーム面接に統合する方が、薄っぺらい2つの面接を実施するより強いです。
- プレゼンテーション面接（役務にプレゼンテーションが含まれない限り）。 候補者に30分間の過去プロジェクト発表を要求するのは、その役職がエンジニアリング組織へのパブリックプレゼンテーションを必須としている場合に限って有効です。そうでなければ、それは的外れなスキルをテストします。
面接官のキャリブレーション：スタッフバーの理解
スタッフループ運用の最難関は、ループ設計ではなく、面接官がスコアリング基準を理解していることを確保することです。3つの具体的なステップ：
- 各評価軸のアンカー付きスコアリングガイドを作成する。 「アーキテクチャ決定品質」で3/4とは具体的に何か定義します—例えば「プロンプト無しで負荷分散トレードオフを指摘し、誤ると何が起きるか説明」。4なら「プロンプトにない制約を自ら見つけ出し、問題を再定義」など。これはシニアレベルで使う同じスコアカード規律ですが、アンカーが異なります。
- 本物の面接の前に、練習デブリーフを2回実施する。 最近のスタッフレベルのオファー2件（1つは受理、1つは辞退）をブラインドでスコアリングさせ、デブリーフします。目的は、本当の候補者が眼前にある前に、パネルがスタッフの定義について意見の相違がないか浮き彫りにすること。これはキャリブレーションであり、ほとんどのチームが省いて後悔する活動です。
- ダウンレベル率を追跡する。 ループがスタッフ応募者に対してスタッフオファーを30%、シニアオファーを50%の頻度で出しているなら、採用マネージャースクリーンが多くのシニア候補者を通しすぎています。ノーハイアが60%なら、インバウンドパイプラインの質に問題があります。どちらにせよ、メトリクスは改善点を示します。
実装のステップ
スタッフエンジニアループを新規に構築または改善する場合：
- 今週、4軸評価基準を作成する。 粗いアンカーで良いので、評価基準なしより遥かにましです。
- 書面設計ドキュメント段階を追加する。 最も予測力が高く、導入コストが最小のラウンドです。
- コーディング面接1つをクロスチーム影響力面接に置き換える。 トレードオフはほぼ確実に価値があります。
- 次の実面接の前に、過去の候補者でキャリブレーション面接を2回実施する。
- 遡及的に、最近採用したスタッフエンジニア3人を、新しい評価基準に照らして監査する。 2人がテストしなかった軸で低スコアなら、それが欠けているラウンドです。
スタッフ採用はシニア採用にシステム設計を追加したものではありません。別の評価基準、別のループ、別のデブリーフプロセスです。この違いを理解するチームは、実際にスタッフエンジニアの職務を果たせる人材を採用します。理解しないチームは別のタイトルを持つシニアエンジニアを採用し、建築的債務がなぜ増え続けるのか不思議に思うことになります。