Platform Engineerの面接質問

成熟したプラットフォームチームを持つ企業の採用担当者によると、候補者の60%が技術面接で不合格となる原因は、ツール固有の知識不足ではなく、システム設計思考の欠如とインフラ決定をビジネス用語で説明する能力の不足にあります[1]。Platform Engineeringの面接は一般的なDevOpsの面接と一つの重要な点で異なります：面接官はあなたがインフラを社内プロダクトとして考えているかどうかを評価します。Kubernetesプラットフォームに対する開発者の満足度をどのように測定したかを説明できる候補者は、クラスター設定の説明しかできない候補者とは根本的に異なるマインドセットを示しています。

重要なポイント

• 3段階の面接を想定してください：行動面接・カルチャーフィット、技術的深掘り、システム設計
• 行動面接の質問は、プラットフォーム＝プロダクト思考に焦点を当てます：開発者への共感、チーム間連携、インシデントリーダーシップ
• 技術的な質問はKubernetesの内部構造、IaC設計、オブザーバビリティアーキテクチャをテストします ― 表面的なツール使用だけではありません
• 状況面接のシナリオは、複数チームからの競合するプラットフォーム要求をどのように優先順位付けするかを評価します
• プラットフォームへの影響、インシデント対応、開発者体験の改善をカバーする4〜5のSTARストーリーを準備してください
• 企業のインフラ課題を調査したことを示す3〜5の質問を用意してください

行動面接の質問（STARフォーマット）

1. 開発者が当初抵抗したプラットフォーム機能を構築した経験を教えてください。どのように採用を推進しましたか？

**この質問の意図：** Platform Engineerは社内プロダクトを構築します。採用率が究極の指標です。この質問は、技術的な実装だけでなく、チェンジマネジメントと開発者への共感を理解しているかをテストします。

**強力なSTAR回答フレームワーク：**

• **Situation：** 開発者がデータベースプロビジョニングのために週50件以上のインフラチケットを作成しており、平均待ち時間は4時間でした
• **Task：** プラットフォームポータルを通じたセルフサービスのデータベースプロビジョニングシステムを提案しましたが、エンジニアリングチームはセキュリティと信頼性に懐疑的でした
• **Action：** 開発者インタビューを実施して懸念を理解し、協力的なチームとパイロットを構築し、プロビジョニングされたデータベースが手動で作成されたものと同じセキュリティ基準を満たしていることを実証し、パイロット後に採用指標を公開しました
• **Result：** 採用は3ヶ月で1チームから12チームに拡大しました。インフラチケットは67%減少しました。プロビジョニングに対する開発者の満足度は3.2/10から8.4/10に向上しました

2. インシデントコマンダーとして指揮した最も複雑な本番インシデントについて教えてください。根本原因は何で、どのような予防措置を実施しましたか？

**この質問の意図：** Platform Engineerは本番環境の信頼性に責任を持ちます。これはインシデントリーダーシップ、技術的デバッグの深さ、予防へのフォロースルーをテストします。

**強力なSTAR回答フレームワーク：**

• **Situation：** ピークトラフィック時に3つのEKSクラスター間で断続的なサービス間通信障害を引き起こすマルチクラスターネットワーク障害
• **Task：** 診断、緩和、200人以上の影響を受けたエンジニアへの通信を担当するインシデントコマンダー
• **Action：** Istioプロキシのエラーログと2時間前にデプロイされたCalico NetworkPolicyの変更を関連付け、名前空間間のトラフィックをブロックするポリシーを特定し、ポリシー変更をロールバックし、デプロイ前のネットワークポリシーテストフレームワークを実装しました
• **Result：** MTTRは23分（SLO内）。インシデント後：デプロイ前にNetworkPolicyの変更をテストマトリクスに対して検証するOPAポリシーを実装し、ネットワークポリシー関連のインシデントを四半期あたり4件から6ヶ月で0件に削減しました

3. 2つのプロダクトチームがプラットフォームに対して矛盾する要件を持っていた状況を説明してください。どのように解決しましたか？

**この質問の意図：** Platform Engineerは複数の社内顧客に同時にサービスを提供します。これは優先順位付け、ステークホルダー管理、プロダクト思考をテストします。

**強力な回答フレームワーク：** あるチームはMLワークロード用のGPUノードプールを必要とし、別のチームは追加の汎用コンピュート容量のために同じ予算を必要としていました。使用パターンを分析し、プリエンプティブルインスタンスとキューベースのスケジューリングを備えた共有GPUノードプールを提案して、両方のニーズを合計コストの60%で満たし、将来の競合のためのリソースガバナンスフレームワークを確立しました。

4. エンジニアリングリーダーシップを、機能開発ではなくプラットフォームインフラへの投資に納得させなければならなかった経験を教えてください。

**この質問の意図：** プラットフォーム作業はプロダクト機能とエンジニアリング投資を争います。これはインフラの価値をビジネス用語で伝える能力をテストします。

**強力な回答フレームワーク：** 投資しないコストを定量化してください：手動プロビジョニングで失われる開発者の時間、設定ドリフトによるインシデント頻度、新しいエンジニアのオンボーディング時間。プラットフォーム投資を力の乗数として提示してください：「40万ドルのプラットフォーム投資は年間8,000開発者時間のインフラルーティン作業を排除し、フルタイムエンジニア4人分に相当します。」

5. 構築したプラットフォームの成功をどのように測定したか説明してください。どのような指標を追跡しましたか？

**この質問の意図：** プロダクト思考には測定が必要です。この質問は、プラットフォームをKPIを持つプロダクトとして扱っているか、単に動いているインフラとして扱っているかを明らかにします。

**強力な回答フレームワーク：** DORAメトリクス（デプロイ頻度、リードタイム、変更失敗率、MTTR）、開発者満足度調査（四半期ごとのNPSまたはCSAT）、セルフサービス採用率、新しいエンジニアの初回デプロイまでの時間、プラットフォーム稼働率SLO、デプロイあたりのインフラコストを追跡してください。

6. プラットフォームに関して行った技術的な決定が、後から間違いだったと気づいた経験を教えてください。どうしましたか？

**この質問の意図：** 知的誠実さ、学習志向、インフラスケールでの軌道修正能力をテストします。

**強力な回答フレームワーク：** 例：すべての設定管理にHelmを選択しましたが、後にKustomizeの方が環境オーバーレイに適していることに気づきました。ミスの影響を定量化し、移行計画を説明し、評価基準について何を学んだかを説明し、意思決定プロセスをどのように変更したか（例：明示的な評価基準を持つADRの実装）を説明してください。

技術的な質問

1. Kubernetesでpodがスケジュールされる際の一連の流れを、Deploymentマニフェストを適用した瞬間からコンテナが実行されるまで説明してください。

**評価されるポイント：** Kubernetes内部構造の知識の深さ。表面的な回答：「kubectlがAPIサーバーに送信して実行されます。」深い回答は以下をたどります：kubectl → APIサーバー（認証、認可、アドミッションコントローラー）→ etcd永続化 → スケジューラー（フィルタリング、スコアリング、バインディング）→ 選択されたノードのkubelet → コンテナランタイム（containerd）へのCRIコール → ネットワーキング用のCNIプラグイン → readinessプローブの通過 → エンドポイント登録。ボーナスポイントとして、プリエンプション、リソースリクエスト/リミットのスケジューリングへの影響、トポロジースプレッドコンストレイントに言及してください。

2. 15のプロダクトチームを持つ組織のためにTerraformモジュール戦略を設計する必要があります。モジュール、ステート、権限をどのように構造化しますか？

**評価されるポイント：** IaCアーキテクチャ思考であり、構文知識だけではありません。カバーすべき内容：モジュール構成（プリミティブ用のベースモジュール、パターン用の複合モジュール）、ステート分離（チーム別、環境別、またはサービス別のステートファイル）、リモートバックエンド設定（S3 + DynamoDBロッキング）、IAMとTerraform Cloud/Spaceliftワークスペースを通じたRBAC、モジュールバージョニングとリリースワークフロー、ドリフト検出戦略。

3. 30の名前空間にわたる500以上のpodを実行しているクラスターに対して、ゼロダウンタイムのKubernetesアップグレードをどのように実装するか説明してください。

**評価されるポイント：** 運用成熟度。カバーすべき内容：すべてのクリティカルワークロードに対するPodDisruptionBudgets、ノードプールのローリングアップデート（コードン、ドレイン、置換）、APIサーバーバージョンスキューポリシー（kubeletは1マイナーバージョン遅れることが可能）、アップグレード前の検証（kubentまたはplutoによる非推奨API検査）、カナリークラスター戦略（まず非本番をアップグレード、次にフリート全体の前に1つの本番クラスター）、アップグレード中のモニタリング（pod再起動率、エラー率、スケジューリングレイテンシー）、ロールバック手順。

4. 50のマイクロサービスに対応するプラットフォームのオブザーバビリティスタックをどのように設計しますか？メトリクス、ログ、トレースについて説明してください。

**評価されるポイント：** オブザーバビリティアーキテクチャ。カバーすべき内容：メトリクスレイヤー（フェデレーションまたは長期保存のためのThanosを備えたPrometheus、SLO用のレコーディングルール）、ログ（Fluent Bit DaemonSet → 適切な保持ポリシーを持つLoki、構造化ログの標準）、トレース（OpenTelemetry SDKインストルメンテーション → コレクター → Tempo/Jaeger）、相関（メトリクスとトレースを関連付けるエクゼンプラー、ログ内のトレースID）、アラート（閾値アラートではなくSLOベースのエラーバジェットアラート）、セルフサービス（チームスコープのダッシュボードと変数テンプレートを備えたGrafana）。

5. 開発者がデプロイに45分かかると報告しています。どのように診断して最適化しますか？

**評価されるポイント：** 体系的なデバッグと最適化。パイプラインをたどってください：コードチェックアウト時間、依存関係のインストール（キャッシュ戦略）、ビルド時間（マルチステージDockerビルド、ビルドキャッシュ、レイヤー最適化）、テスト実行（並列テストランナー、テスト分割）、イメージプッシュ時間（レジストリの近接性、レイヤーの重複排除）、ArgoCD同期時間（sync waves、resource hooks）、podスケジューリング時間（イメージプル、initコンテナ、readinessプローブ）。最適化する前にボトルネックを特定してください ― 現在の内訳を聞いてください。

6. KyvernoとOPA/Gatekeeperの違いを説明してください。それぞれをいつ選びますか？

**評価されるポイント：** セキュリティツールの深さ。OPA/GatekeeperはRegoポリシー言語を使用し（強力だが学習曲線が急）、アドミッションWebhookとして実行され、複雑なクロスリソースポリシーに優れています。KyvernoはKubernetesネイティブのYAMLポリシーを使用し（学習曲線が緩やか）、検証、変更、生成ポリシーをサポートし、Kubernetesの概念とより自然に統合されます。既存のRego専門知識がある組織や複雑なポリシー要件にはGatekeeperを選択してください。導入摩擦を抑えたKubernetesネイティブのポリシー管理を求めるチームにはKyvernoを選択してください。

7. ArgoCDのリコンシリエーションはどのように機能し、200以上のアプリケーションを持つマルチクラスター環境ではどのように設定しますか？

**評価されるポイント：** GitOpsの深さ。カバーすべき内容：ArgoCDは設定可能な間隔（デフォルト3分）でgitリポジトリをポーリングし、望ましい状態（git）をライブ状態（クラスター）と比較し、差分をリコンサイルします。スケーリングのために：ジェネレーター（git、cluster、matrix）を備えたApplicationSets、階層管理のためのApp of Appsパターン、マルチテナントアクセス制御のためのプロジェクトレベルRBAC、ノイジーなリソースのリソース除外、本番変更管理のための同期ウィンドウ。必要に応じて、より高速なリコンシリエーションのためのWebhookベースの同期トリガーについて議論してください。

状況面接の質問

1. 5人のプラットフォームチームが8つのプロダクトチームから同時にリクエストを受けています。どのように優先順位を付けますか？

**評価されるポイント：** プロダクトマネジメントとステークホルダースキル。フレームワーク：影響度（影響を受ける開発者数×問題の深刻度）、緊急度（デプロイをブロックしているvs.あると良い）、戦略的整合性（全社的なイニシアチブを支援vs.単一チームのニーズ）で分類してください。透明な取り込みプロセスを確立してください：チームリードとの週次優先順位付けミーティング、公開されたプラットフォームロードマップ、異なるリクエストタイプに対する明確なSLA（P0ブロッキング問題：当日対応、機能リクエスト：スプリント計画）。

2. 新しいCTOが6ヶ月以内にインフラ全体をAWSからGCPに移行したいと考えています。どのように評価し、計画しますか？

**評価されるポイント：** プレッシャー下での戦略的思考。影響評価から始めてください：使用中のすべてのAWSサービスの棚卸し、GCP相当品の特定、データ転送コストとタイムラインの見積もり。リスクを評価してください：クリーンなGCP相当品がないサービスの特定（例：特定のマネージドサービス）。段階的なアプローチを提案してください：まずTerraformモジュールを通じてインフラを抽象化し（クラウド固有の結合を削減）、概念実証として非クリティカルなサービスを移行し、次にロールバック機能を備えた本番サービスを移行してください。非現実的な場合は、証拠をもって6ヶ月のタイムラインに異議を唱えてください。

3. Kubernetesクラスターが営業時間中に断続的なpodの退去を経験しています。調査手順を説明してください。

**評価されるポイント：** 体系的なトラブルシューティング。kubectl describe nodeを通じてノードレベルのリソースプレッシャー（メモリ、ディスク、PID制限）を確認し、Kubeletの退去イベントを探してください。リソースリクエストと実際の使用量を比較してください ― リクエストのないpodが最初に退去されます。ノイジーネイバー効果（共有ノードで過剰にリソースを消費するpod）を確認してください。Karpenter/Cluster Autoscalerのログでスケーリング遅延を確認してください。DaemonSetのリソース競合を確認してください。将来のオーバープロビジョニングを防ぐためにResource QuotasとLimitRangesを実装してください。

4. Terraformステートファイルの40%が6ヶ月間適用されておらず、ドリフトが蓄積していることを発見しました。修復計画は何ですか？

**評価されるポイント：** IaCの運用規律。盲目的にterraform applyを実行しないでください ― 人々が依存しているリソースを破壊する可能性があります。各ステートファイルに対してterraform planから始め、ドリフトを分類してください：(1) Terraform外で行われた意図的な変更（インポートまたはコード更新が必要）、(2) 意図しないドリフト（適用が必要）、(3) 放棄されたリソース（クリーンアップが必要）。再発を防ぐために継続的なドリフト検出（Spacelift、Atlantis、またはスケジュールされたplan実行）を実装してください。ガバナンスポリシーを確立してください：すべてのインフラ変更はTerraform PRを通じて行う必要があります。

5. エンジニアリングVPが、デバッグのためにチームに本番Kubernetesクラスターへの直接アクセスを要求しています。どのように対処しますか？

**評価されるポイント：** セキュリティ判断とステークホルダーコミュニケーション。直接的なクラスターアクセスはセキュリティと監査のリスクを生み出します。代替案を提案してください：RBACを通じた名前空間に限定された読み取り専用のkubectlアクセス、podレベルのオブザーバビリティを備えたGrafanaダッシュボード、実行中のpodを変更せずにシェルアクセスを提供するデバッグコンテナワークフロー（エフェメラルコンテナ）、クラスター認証情報なしで可視性を提供するログ集約。彼らが固執する場合は、監査ログ（Teleport、Boundary）と自動失効を備えた時間制限付きアクセスを実装してください。

面接官が使用する評価基準

**技術的深さ（40%）：** システムがコンポーネントレベルでどのように機能するかを説明できますか？設定するだけでなく。podスケジューリングとTerraformアーキテクチャの質問がこれをテストします。

**システム設計（25%）：** 複数のチームにスケールで提供するプラットフォームコンポーネントを設計できますか？オブザーバビリティスタックとマルチクラスターArgoCDの質問がこれをテストします。

**プロダクトとコミュニケーション（20%）：** インフラの決定をビジネス用語で説明できますか？競合する要求に優先順位を付けられますか？行動面接の質問と優先順位付けシナリオがこれをテストします。

**インシデントと運用（15%）：** 本番の問題を体系的に診断し、再発を防止できますか？インシデントコマンダーの質問とpod退去シナリオがこれをテストします。

Platform EngineeringのためのSTARメソッド例

**テンプレート：**

• **Situation：** 具体的な数字でコンテキストを設定する（会社規模、チームサイズ、インフラ規模）
• **Task：** あなたの具体的な責任を定義する（チームのではなく）
• **Action：** 取った具体的なステップを説明する（ツール、決定、コミュニケーション）
• **Result：** 結果を定量化する（メトリクス、採用率、コスト削減、時間節約）

**例：セルフサービスプラットフォームの構築**

• **S：** [会社]（300人のエンジニア、40のマイクロサービス）で、開発者はインフラプロビジョニングに平均3日間待ち、月に200件以上のチケットを作成していました
• **T：** プロビジョニングのボトルネックを解消するセルフサービスインフラカタログの設計を任されました
• **A：** 12のマネージドリソーステンプレート（データベース、キャッシュ、キュー、ストレージバケット）を備えたCrossplaneベースのカタログを構築し、開発者フレンドリーなUIのためにBackstageと統合し、本番リソース用の承認ワークフローを実装し、ビデオウォークスルー付きの包括的なドキュメントを作成しました
• **R：** プロビジョニング時間が3日から15分に短縮されました。月間インフラチケットは78%減少しました。プロビジョニングに対する開発者の満足度は2.8/10から8.6/10に向上しました。カタログは最初の四半期に150件以上のプロビジョニングリクエストを設定ミスゼロで処理しました

面接官への質問

1. **「プラットフォームチームはどのように成功を測定していますか？どのようなKPIやSLOを追跡していますか？」** ― プロダクトマインドセットがあるか、リアクティブなサポート機能として運用しているかをテストします。
2. **「プラットフォームチームが優先的に取り組んでいる現在の開発者体験の課題は何ですか？」** ― 開発者のニーズを考えていることを示し、実際に行う作業を明らかにします。
3. **「プラットフォームチームはプロダクトチームに対してどのように構造化されていますか？Team Topologiesモデルに従っていますか？」** ― 組織的な認識を示し、チームの自律性を評価するのに役立ちます。
4. **「現在のデプロイ頻度はどのくらいで、ボトルネックはどこにありますか？」** ― DORAメトリクスで考え、測定可能な改善に焦点を当てていることを示します。
5. **「チームが最近行った最も物議を醸したインフラの決定は何ですか？」** ― 意思決定文化、技術的負債への認識、議論への開放性を明らかにします。
6. **「プラットフォームチームのオンコールはどのようなものですか？エンジニアはどのくらいの頻度でアラートを受け、平均的なインシデントの深刻度はどのくらいですか？」** ― 運用成熟度とワークライフバランスを明らかにする実践的な質問です。
7. **「重要なプラットフォーム変更のためのアーキテクチャレビューやRFCプロセスはありますか？」** ― 慎重な意思決定とドキュメント文化を重視していることを示します。

最終的なポイント

Platform Engineeringの面接は3つの次元を評価します：Kubernetes、IaC、クラウドインフラにおける技術的深さ、開発者体験とプラットフォーム採用に関するプロダクト思考、インシデント対応とシステムデバッグにおける運用成熟度です。測定可能なプラットフォーム成果（ツール使用だけでなく）に関するSTARストーリーを構築し、複数のインフラコンポーネントにまたがるシステム設計の質問を練習し、企業のエンジニアリングブログ、オープンソースリポジトリ、カンファレンストークを通じて企業固有のインフラ課題を調査することで準備してください。際立つ候補者は、何を構築したかだけでなく、なぜそれを構築したか、どのように成功を測定したか、次回は何を変えるかを説明します。

よくある質問

Platform Engineerのポジションでは何回の面接ラウンドを想定すべきですか？

通常4〜5ラウンドです：リクルータースクリーニング（30分）、採用マネージャーとの行動面接（45〜60分）、シニアエンジニアとの技術的深掘り（60〜90分）、Staff以上のエンジニアとのシステム設計（60分）、チーム/カルチャーフィットパネル（45〜60分）。一部の企業は、事前スクリーニングまたはライブ技術ラウンドの代替として持ち帰り課題（Terraformモジュール設計、Kubernetesトラブルシューティングシナリオ）を追加します。プロセス全体の期間：最初のコンタクトからオファーまで2〜4週間。

スタートアップと大企業では異なる準備をすべきですか？

はい。スタートアップは幅広さとスピードを重視します ― 専門チームメンバーを待つことなく、複数のドメイン（CI/CD、オブザーバビリティ、Kubernetes、セキュリティ）でゼロからプラットフォームを構築できるエンジニアを求めています。大企業は特定のドメインの深さと、スケールで確立されたパターン内で作業する能力を重視します。スタートアップの面接は実践的な演習（何かを構築/修正する）を含むことが多く、大企業の面接はホワイトボードでのシステム設計セッションに傾向します。

Platform Engineeringの面接でGoプログラミング能力はどの程度重要ですか？

中級レベル以上ではますます重要になっています。企業がカスタムKubernetesオペレーター、Terraformプロバイダー、またはCLIツールを構築している場合、Goは事実上必須です。ジュニアの候補者はPythonとBashの能力を出発点として示すことができます。Goの質問が出る場合、通常はKubernetes client-goライブラリの理解、リコンシリエーションループの記述、インフラツールに関連するGoの並行性パターンの理解に焦点を当てます。

企業が使用する特定のツールの経験がない場合はどうすればよいですか？

転用可能な概念に焦点を当ててください。ArgoCDを知っていて企業がFluxを使用している場合、GitOpsの原則とリコンシリエーションパターンを説明してください ― 概念は同一です。AWSを知っていて企業がGCPを使用している場合、Kubernetes（プロバイダーに依存しない）とTerraformモジュール設計パターンについて議論してください。適切に運営されている企業の面接官は、ツール固有の経験よりも概念的な理解を評価します。なぜなら、ツールは原則よりも速く変化するからです。

**引用：** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.