Amazonで約1,000回の面接を行って得た教訓

• Amazonで17年間勤務し、約1,000回の面接（うち約600回はBar Raiser面接）を行った経験をもとに、技術面接よりも行動面接が採用判断に与える影響を分析した内容
• 技術的に優秀な候補者が不採用になる主な理由は、技術不足ではなく自己表現の仕方の問題
• 面接準備時間の95%を技術準備に投じる一方で、行動面接の準備にはほとんど時間を使わないことが最大の盲点
• 面接は試験ではなく、「この人と一緒に働きたいか」を判断するオーディションに近い
• 企業が行動面接で評価する核心は役割適合性、組織適合性、そしてレベル判断であり、これを理解すればより良いストーリーを選べる

---

Bar Raiser面接で見つけた重要なパターン

• Bar Raiserは採用チーム外から参加する特別な訓練を受けた面接官で、新規採用者がAmazonの人材水準を引き上げるかを確認する役割
• すべての候補者に対する拒否権を持ち、インターンからPrincipal Engineerまであらゆるレベルの面接ループに参加
• 約50回のBar Raiser面接の後に明確になったパターン: オファーを得られなかった候補者の大半は、技術力不足ではなく自己表現の失敗が原因
• 最終ラウンドに到達した時点で技術スクリーニングや課題はすでに通過しているため、最終ラウンドの核心的な問いは「このチームはこの人と一緒に働きたいか」

• 教訓1: 一方の面接には過剰に、もう一方には準備不足

  • 平均的な候補者は技術準備に95%、残りに**5%**の時間を投じ、一部は非技術準備にまったく時間を使わない
  • 技術準備は具体的で進捗を測りやすいため魅力的だが、コーディング問題は初見の問題でもヒントを受けて推論できる
  • 一方、行動面接で「プロジェクトがうまくいかなかったときにどう対処したか」のような質問に対して、準備したストーリーがなければ即興で対応するのは不可能
    • ヒントもなく、リアルタイム推論もできず、準備がなければまとまりのない回答になりがち
  • コーディングラウンドをうまく通過した候補者が、経験に関する質問で崩れるパターンを何百回も目撃
    • ディブリーフでのフィードバック: 「具体的な回答が得られず、すべてのストーリーが曖昧で説得力に欠けていた」
  • 非技術準備は技術準備よりはるかに少ない時間で済む: 80〜100時間の面接準備のうち、週末1回分（約10時間）だけストーリー準備に充てても、行動面接の結果は完全に変わりうる
  • 技術準備のリターンは急激に逓減する一方で、ストーリー準備のリターンはほとんど誰もやっていないため指数関数的

• 教訓2: ストーリーの伝え方は、ストーリー自体と同じくらい重要

  • どれほど印象的な実績でも、伝え方が悪ければ完全に無駄になりうる。最もよくある失敗パターンは**"ramble and stumble"**（だらだら話してしどろもどろになること）
    • 候補者が話しながらその場でストーリーを組み立てているように見えたり、5分かけて文脈を説明したあと、抜けていた詳細をまた付け足したりするケース
  • 重要な業務プレゼンでは構成、流れ、要点を準備してリハーサルするのに、面接では即興で臨む人が多い
  • 面接用ストーリーの準備を「不自然」や「ごまかし」だと感じる傾向があるが、音楽家がコンサート前にリハーサルするように、練習は誠実さとは無関係
  • 実践方法: 「自己紹介」と「なぜこの会社で働きたいのか」の2つの質問から始める
    • 回答を書き、録画し、録画を見ながらどこで冗長になっているか、不要な口癖があるかを確認
    • 「この人と一緒に働きたい」と感じられるまで繰り返す
  • 30分のこの練習は、20時間のコーディング練習よりも面接成果を大きく改善しうる

• 教訓3: 面接は一緒に働くとどうなるかを見せるオーディション

  • 多くの候補者は面接を試験だと考えるが、模範解答があるわけではなく、面接官が印象を形成するプロセス
  • Bar Raiserの具体的な役割は、候補者がその職務にいる既存社員の上位50%より優れているかを判断すること
  • 面接で出されるコーディング問題は実務とは異なるが、行動質問は日々直面する状況（意見の対立の解消、プロジェクト危機への対応、不完全な情報での意思決定）を直接テストする
    • 「利害関係者に反対意見を伝えた経験」を尋ねるとき、面接官は次の企画会議にその人がいる姿を想像している
    • チーム内の対立への対処を説明するとき、「この人と同じ部屋にいたいか」と自問している
  • 試験のように面接へ臨む候補者は、面接官が聞きたがっている答えを推測して、滑らかで角のない回答を出す
    • 結果: 「この人と実際に働くとどうなのかがまったく見えない」という不確実性につながり、たいていは「No」になる
  • 実践方法: 面接官が聞きたいことではなく、自分のチームに加わろうとしている人から聞きたいことを基準にストーリーを準備する
    • 難しかった点や際どい判断も含めた実際のバージョンを率直に伝える

約1,000回の面接から得た核心的な結論

• 採用される人は、部屋に入って自分の仕事と能力について明確なストーリーを伝え、面接官に「この人と一緒に働きたい」と感じさせる人
• ストーリーを伝える力は練習で向上するスキルであり、多くの人はそれを準備可能な領域だと考えていないため練習しない
• 少し準備するだけで、キャリアでできるほぼ他のどんなことよりも大きな効果がある

企業が行動面接で見ているもの

• 技術力だけでオファーは決まらず、企業は行動面接を通じて2つの核心的な問いに答えようとする: 「役割と会社に適しているか？」 と 「どのレベルで最も効果的か？」
• 適合性（fit）が合わなければ技術的に優れていても不採用になり、レベル判断がずれるとダウンレベルまたは資格不足として見送られる

• 適合性を理解する: 役割適合性と組織適合性

  • 役割適合性（Role Fit）: そのポジション特有の課題や業務条件に対応できるかどうか
    • 急成長スタートアップのバックエンド職と大企業のバックエンド職では、技術は似ていても求められるものが異なる
  • 組織適合性（Company Fit）: その組織の環境で成功できるかどうか
    • 働き方、意思決定の方法、価値観が会社の仕事の進め方と一致するかを評価する

• 企業が適合性のシグナルを見極める方法

  • 「うちの会社に合いますか？」と直接聞くことはできないため、候補者のストーリーから整合または不一致のシグナルを探る
  • 役割適合性のシグナル: 曖昧な要求を扱うことへの抵抗のなさ、チーム間調整能力、高速な反復とフィードバック反映など
  • 組織適合性のシグナル: 候補者の選択と、その説明の仕方に表れる
    • bias for actionを重視する会社は、不完全な情報でも素早く動いたストーリーを好む
    • customer obsessionを重視する会社は、ユーザーニーズを深く掘り下げた事例を求める
    • radical transparencyを強調する会社は、不都合でも情報をオープンに共有したストーリーを探す
  • 同じストーリーでも会社によって異なるシグナルを送る: 3週間かけてソリューションを完璧に磨いた事例が、ある会社では品質重視、別の会社では分析麻痺と解釈されうる

• よくあるミスフィットのタイプ

  • 独立性 vs. 協業: 一人で問題を解決して戻ってくるスタイル vs. 各段階でチームを巻き込むスタイル
    • すべてのストーリーが単独作業なら合意重視の企業では懸念になり、逆にすべてのストーリーがグループ確認なら個人オーナーシップ重視の企業では懸念になる
  • スピード vs. 慎重さ: スタートアップの高速実験とMVP vs. 医療・金融分野の慎重な検証
    • コード品質に対する見方の違いも含む: クリーンなアーキテクチャに追加時間を投じるか、期限内に動くソリューションを優先するか
  • 卓越性 vs. 実用主義: 技術的完全性とクリーンなアーキテクチャを最優先するか、不完全でも期限内に出す実用的なソリューションを優先するか
  • 革新 vs. 安定性: 新しい解決策の創出や既存のやり方への挑戦 vs. 実証済みシステムの維持・最適化
  • 率直さ vs. 外交性: 考えをそのまま言うradical candor文化 vs. 調和と面子を重んじる文化
  • データ vs. 直感: あらゆる意思決定にデータ根拠を求める文化 vs. 経験に基づく判断を信頼する文化
  • スペシャリスト vs. ゼネラリスト: 大企業での一つのドメインにおける深い専門性 vs. 小規模企業での多様な役割を担う能力

レベルを決める4つの次元

• すべてのストーリーに表れる4つの次元を通じて候補者のレベルを評価し、それらが組み合わさって最も効果的に機能する位置を示す

• Scope（範囲）

  • 仕事が影響を与える人の数と広がりを測る
  • Entry Level: 個人の生産性向上、少人数のチームメンバー支援
  • Mid Level: チームの運営方法の一部に影響
  • Senior Level: チーム全体に直接影響し、少なくとも1つの他チームへの影響拡大が始まる。プロダクト・デザインパートナーと密接に協業
  • Staff Level: 少なくとも2つのチームに直接影響し、より広い組織へ拡大。エンジニアリングを越えてプロダクト・デザイン・プログラム管理領域まで影響
  • Principal Level: 複数チームまたは組織の大きな部門の運営方法を変え、ビジネス戦略にまで影響を広げる

• Contribution（貢献）

  • 「私」と「私たち」の境界を明確に区別し、本人が実際に何をしたかを測る
  • Entry Level: 割り当てられた作業を実行し、明確に定義された機能に完全な責任を持つ
  • Mid Level: 問題の特定から実装まで完全なソリューションをオーナーシップを持って進めつつ、他者を導く
  • Senior Level: 調整が必要なイニシアチブを主導し、要件が不明確または方向性が不確かな状況でも前進させる
  • Staff Level: チーム横断のイニシアチブを主導し、技術的方向性を定め、利害関係者の優先順位が衝突する状況に対応する
  • Principal Level: 組織能力を生み出し、新しい働き方を確立し、問題そのものを定義しなければならない高度に曖昧な環境で活動する

• Impact（インパクト）

  • その仕事の結果として何が良くなったかを示し、技術的成果をビジネスやユーザーの結果につなぐ数値を含めることが重要
  • Entry Level: 個人の生産性向上、繰り返し作業時間の短縮、バグ防止など
  • Mid Level: 特定領域でのチーム効率向上、デプロイ時間短縮、ツール作成などの定量化可能な改善
  • Senior Level: チーム全体の働き方を変え、隣接チームへ広がり、プロダクト成果・ユーザー体験・運用コストまで影響を拡大
  • Staff Level: 複数チームの運営改善、売上・顧客維持・リリース速度などビジネス指標につなげられる影響
  • Principal Level: 組織能力を生み出し、戦略的変化を主導し、ビジネス成果と戦略的能力で測られる

• Difficulty（難易度）

  • 解決した問題の複雑さ、制約条件、トレードオフを反映し、影響が大きくても簡単な問題より、難しい問題をうまく解いたほうが印象に残る
  • Entry Level: 確立されたパターンの中の直感的な問題、新技術の学習や不慣れなコードのデバッグ程度
  • Mid Level: 可動要素が増え、解決策がより不明確な問題。相反する要件やこれまで見たことのない技術的複雑性に対処する
  • Senior Level: 複数システムが相互作用する制約を管理し、チームレベルのアーキテクチャ判断を行い、技術面とビジネス面の両方を考慮する必要がある
  • Staff Level: 複数チームにまたがる相反するトレードオフを管理し、チーム間で本当に衝突するニーズがあるときに多様な技術的アプローチの均衡を取る
  • Principal Level: 組織的ニーズ間の根本的なトレードオフに対処し、確立されたパターンや前例のない新しい問題を解決し、経営陣の承認が必要な会社戦略レベルの判断を行う

企業が本当に重視していることをリサーチする

• 完璧な情報を得るのは不可能だが、少し集中的にリサーチするだけで、ほかの候補者の大半が見落とす洞察を得られる

• リクルーターを活用する

  • 多くの候補者はリクルーターを単なる関門として扱うが、実際には最高の内部情報源
  • リクルーターの成果は候補者が受諾したオファー数に基づくため、候補者の成功を望んでいる
  • 直接聞くべきこと: 「この会社の現在の課題は何か?」「この役割で最も重要な能力は?」「面接準備資料を共有してもらえるか?」
  • 準備資料にある例示質問は、実際の面接で聞かれる可能性が高い

• 公開情報を活用する

  • 求人票で繰り返される言葉は、企業が重視する点を示す: "fast-paced" と "compliance" はまったく異なるシグナル
  • 確認先: エンジニアリングブログ（どんな成果を称賛しているか）、テックトーク・カンファレンス（発表テーマ）、オープンソース貢献（何を公開しているか）、技術文書（公開APIドキュメントの品質）、ステータスページ・ポストモーテム（失敗から学ぶ文化があるか）
  • エンジニアリングブログがなくても、製品リリースのパターン（開発速度）や技術選定（革新 vs. 安定性）から優先順位を把握できる

• 議論のパターンを分析する

  • Glassdoor、Blind、Redditでは個別の不満は無視し、複数の投稿にまたがるパターンを探す
  • 「会議が多すぎる」という不満は、協業・合意重視の文化、あるいは会議過多による生産性低下を示唆する
  • 「自律性」への称賛は、意思決定時に逐一確認せず信頼される環境を示唆する

• 現職者と話す

  • 表面的なカルチャー質問ではなく、具体的な質問が必要
    • 「昇進する人は何をして昇進しているのか?」
    • 「どんな行動がネガティブなフィードバックを受けるのか?」
    • 「意見が対立したとき、チームはどうやって決めるのか?」
    • 「ここで働いていて最も驚いたことは?」
  • 現職者は、会社のWebサイトからは決して分からない真実を伝えてくれる: customer obsessionが実際にはコードを書く前にユーザーデータを確認することを意味したり、ownershipが深夜2時に本番障害対応で待機することを意味したりするかもしれない

• リサーチの究極の目的

  • あらゆるリサーチの目的は1つ、面接で共感を得られるストーリーが何かを把握すること
  • スピードを重視するなら素早く出して改善したストーリーを強調し、技術的深さを重視するなら根本原因を掘り下げた事例を強調し、協業を重視するならチーム横断の仕事に焦点を当てる
  • リサーチは、その会社が自分に合っているかを判断する助けにもなる: 自然に示せない、あるいは伸ばしたいと思わない行動を重視する会社なら、その役割を追う必要はないかもしれない

総合

• 企業は仕事を遂行できるかどうかだけでなく、特定の環境での成功可能性と、最も効果的なレベルを評価している
• 適合性を理解することは、会社の価値観と最もよく結びつく経験を選ぶ助けになる
• レベルを理解することは、ストーリーを適切に位置づける助けになる: 同じプロジェクトでも、実際の貢献とフレーミング次第で、entry-levelの実行、mid-levelのオーナーシップ、senior-levelのリーダーシップとして異なって見える
• 目標はどんなオファーでもいいことではなく、成功を後押しする適切な会社で、適切なレベルの、適切なオファーを得ること