データエンジニアの面接質問 — 30以上の質問と専門家の回答

データエンジニアリングの求人は2020年以降60%以上増加しており、テクノロジー分野で最も急成長している専門分野の一つとなっています [1]。しかし、求人1件あたり平均118名の応募者、そして27%の面接から採用への転換率を考えると [2]、面接は依然として非常に競争が激しいです。現代のデータエンジニア面接はSQLの習熟度を超えています——スケーラブルなパイプラインの設計、アナリティクス用のデータモデリング、データ品質の管理、そしてSpark、Kafka、dbt、Airflowなどのツールを使った本番環境での運用能力がテストされます [3]。以下の質問は、初めてのデータスタックを構築するスタートアップからペタバイト規模のデータウェアハウスを管理する大企業まで、採用チームが使用するパターンを反映しています。

重要なポイント

• データエンジニアの面接はSQL、Python、データモデリング、ETL/ELTパイプライン設計、システムアーキテクチャにわたります [1]。
• SQLとPythonのコーディング課題に加え、ホワイトボードでのパイプライン設計セッションを予想してください。
• 行動面接の質問では、データ品質インシデント、ステークホルダーとのコミュニケーション、チーム間の協力への対応が問われます。
• モダンデータスタックツール（dbt、Airflow、Spark、Kafka、Snowflake、Databricks）の知識がますます求められています。
• データガバナンス、リネージ、オブザーバビリティの理解がシニア候補者を差別化します。

行動面接の質問

データエンジニアはエンジニアリングとアナリティクスの交差点に位置し、データサイエンティスト、アナリスト、プロダクトチームと協力しています。行動面接の質問は、現実の制約下でこれらの関係をどのように乗り越えるかを評価します [4]。

1. 構築したデータパイプラインが本番環境で障害を起こした経験を説明してください。どのように診断し修正しましたか？

STARを使用してください：Situation（日次ETLジョブが午前3時に失敗し、朝のアナリティクスダッシュボードが遅延した）、Task（営業時間前にデータの鮮度を復旧する）、Action（Airflowのログを確認し、ソースAPIのスキーマ変更が抽出ステップを破壊していることを特定し、スキーマ進化の処理を実装しアラートを追加した）、Result（90分以内にパイプラインを復旧し、スキーマ変更を自動的に検知する統合テストを追加した）。

2. データサイエンティストやアナリストとデータのモデリング方法について意見が合わなかった経験を教えてください。どのように解決しましたか？

トレードオフを説明してください——アナリストがクエリパフォーマンスのために幅広い非正規化テーブルを望んでいた一方で、あなたが保守性のために正規化されたディメンショナルモデルを支持していたかもしれません。代表的なクエリで両方のアプローチをテストし、両方のニーズを満たす妥協案（マテリアライズドビューまたは事前集計テーブル）を見つけた方法を説明してください。

3. レガシーのデータパイプラインを引き継ぎ、リファクタリングするか再構築するかを決定しなければならなかった状況を教えてください。

判断基準を評価してください：ドキュメントの品質、テストカバレッジ、ビジネスクリティカル性、移行中のダウンタイムのコスト。強い回答は「すべて書き直す」や「そのままにする」をデフォルトにするのではなく、体系的な評価を示します。

4. ダウンストリームの消費者に到達する前に問題を検知するデータ品質モニタリングを実装した経験を説明してください。

具体的なデータ品質チェックについて議論してください：NULL率モニタリング、鮮度SLA、行数の異常検知、スキーマバリデーション。Great Expectations、dbtテスト、Monte Carloなどのツールに言及してください。影響を数値化してください——「ソースシステムの変更による行数の40%減少を検知し、不正確な収益レポートの作成を防いだ」。

5. 非技術系のステークホルダーにデータエンジニアリングの概念を説明しなければならなかった経験を教えてください。

ETLプロセス、データレイテンシ、パイプラインの依存関係をビジネス用語で説明することは不可欠です。アナロジー、ダッシュボード、データ鮮度インジケーターを使用して、パイプラインの健全性を可視化し理解しやすくした方法を説明してください。

6. ソースシステムからのデータが信頼性が低い、または一貫性がなかった状況にどのように対処しましたか？

取り込み層でのバリデーションの実装、ソースとターゲット間の照合チェックの作成、データカタログでのデータ品質問題の文書化、および不良データを黙って伝播するのではなく既知の制限をダウンストリームユーザーに伝達することについて議論してください。

技術的な質問

技術的な質問はSQL、分散システム、データモデリング、パイプラインアーキテクチャの深さをテストします [5]。

1. ETLとELTの違いを説明してください。それぞれどのような場合に選択しますか？

ETL（Extract, Transform, Load）はデータウェアハウスにロードする前にデータを変換します——ウェアハウスの計算能力が限られている場合や、変換に複雑なビジネスロジックが必要な場合に適しています。ELT（Extract, Load, Transform）は生データを先にロードし、ウェアハウス内で変換します——変換のための弾力的な計算能力を持つモダンなカラムナーウェアハウス（Snowflake、BigQuery、Redshift）で推奨されます [3]。dbtがELTの「T」の標準ツールとなった経緯について議論してください。

2. 各部門で2番目に高い給与を見つけるSQLクエリを書いてください。

ウィンドウ関数を使用します：SELECT department, employee, salary FROM (SELECT department, employee, salary, DENSE_RANK() OVER (PARTITION BY department ORDER BY salary DESC) as rank FROM employees) ranked WHERE rank = 2。DENSE_RANKが同順位を正しく処理する理由と、RANKやROW_NUMBERが異なる結果を返す可能性がある理由について議論してください。

3. ソースシステムから変更されたレコードのみを処理するインクリメンタルデータパイプラインをどのように設計しますか？

Change Data Capture（CDC）戦略について議論してください：タイムスタンプベースのインクリメンタルロード（updated_atカラムの使用）、ログベースのCDC（Debeziumによるデータベースのwrite-ahead logの読み取り）、ハッシュベースの比較。課題に対処してください：遅延到着データ、タイムスタンプベースのアプローチでは見えない削除、exactly-once処理の保証 [1]。

4. スタースキーマとスノーフレークスキーマの違いを説明してください。それぞれいつ使用しますか？

スタースキーマには非正規化されたディメンションテーブルに接続された中央のファクトテーブルがあります——より単純なクエリ、より高速な読み取り、BIツールに最適です。スノーフレークスキーマはディメンションテーブルをサブディメンションに正規化します——ストレージの冗長性を削減しますが、クエリの複雑さが増加します。スタースキーマはクエリパフォーマンスが重要なアナリティクスワークロードに推奨されます。スノーフレークスキーマはストレージ効率とデータ整合性が優先される環境に適しています。

5. Apache Kafkaは従来のメッセージキュー（RabbitMQなど）とどのように異なりますか？データパイプラインにKafkaを選択するのはどのような場合ですか？

Kafkaは永続的で順序付けられた再生可能なログを持つ分散イベントストリーミングプラットフォームです。RabbitMQは確認セマンティクスによるポイントツーポイント配信に最適化されたメッセージブローカーです。高スループットのイベントストリーミング、ログ集約、複数のコンシューマーが同じデータを独立して読み取る必要があるシナリオ（ファンアウト）にはKafkaを選択してください。複雑なルーティングとexactly-once配信要件を持つタスクキューにはRabbitMQを選択してください [5]。

6. データパーティショニングとは何ですか？データウェアハウスでのクエリパフォーマンスをどのように改善しますか？

パーティショニングはキー（日付、地域、顧客ID）に基づいて大きなテーブルをセグメントに分割します。パーティションキーでフィルタリングするクエリは関連するセグメントのみをスキャンし、I/Oと計算コストを削減します。パーティショニング戦略について議論してください：時系列データのレンジパーティショニング、均等分散のためのハッシュパーティショニング、一般的なクエリパターンに合致するパーティションキーの選択の重要性。

7. アップストリームのソースがデータフォーマットを変更した場合、データパイプラインでのスキーマ進化をどのように処理しますか？

スキーマレジストリを実装します（KafkaのConfluent Schema Registry、またはAvro/Parquetスキーマ進化）。前方互換性と後方互換性のルールを定義します。スキーマ強制なしで生データを受け入れるランディングゾーンを使用し、ステージング層でバリデーションと変換を行います。スキーマ変更時にアラートを出し、破損データを伝播するのではなく処理を停止するサーキットブレーカーを実装します [3]。

状況面接の質問

状況面接の質問は現実的なパイプラインの課題を提示し、問題解決アプローチを評価します [4]。

1. 日次パイプラインの完了に6時間かかりますが、ビジネスは2時間ごとのデータ更新を必要としています。どのようにアプローチしますか？

時間がどこで費やされているかを分析してください——抽出、変換、ロードのどれですか？フルテーブルリロードをインクリメンタル処理に置き換えます。独立した変換を並列化します。重い変換をウェアハウスに移動（ELT）して、その弾力的な計算能力を活用することを検討します。SLAがほぼリアルタイムを要求する場合、最も重要なテーブルについてストリーミングの代替案を評価します。

2. データサイエンティストが機械学習モデルの精度が突然低下したと報告しています。データ品質の問題を疑っています。どのように調査しますか？

パイプラインのメタデータを確認します：最新の実行は正常に完了しましたか？行数、NULL率、値の分布を過去のベースラインと比較します。ソースシステムの変更（スキーマ変更、ビジネスルールの更新）を確認します。データリネージツールを使用して、モデルの入力特徴量をソーステーブルまで追跡し、分布のシフトがどこで発生したかを特定します。

3. 現在10GBのデータを持つスタートアップ向けにデータプラットフォームを設計していますが、18ヶ月以内に10TBに達する見込みです。過剰設計せずに成長に対応するアーキテクチャをどのように設計しますか？

弾力的にスケールするマネージドクラウドウェアハウス（Snowflake、BigQuery）から始めます。ウェアハウスの計算能力とスケールするdbtを変換に使用します。オーケストレーションはAirflowまたはDagsterを最初から実装します——後から追加するのはより困難です。将来の拡張をサポートするディメンショナルモデルを設計します。データ量が実際にそれを要求するまで、Sparkクラスターのような早期最適化は避けてください。

4. 2つの異なるチームが同じソースデータを必要としていますが、異なる変換と鮮度要件があります。パイプラインの重複をどのように避けますか？

共有のブロンズ/シルバー/ゴールドのメダリオンアーキテクチャを実装します。生データをブロンズ層に一度取り込み、シルバー層で共通のクレンジングを適用し、各チームに独自のゴールド層の変換を構築させます。利用可能なデータセットを文書化し、チームが冗長な取り込みパイプラインを構築するのを防ぐためにデータカタログを使用します。

5. パイプラインは1分間に100リクエストのレート制限があるAPIを使用していますが、毎日100万レコードを抽出する必要があります。抽出をどのように設計しますか？

抽出コードにエクスポネンシャルバックオフ付きのレート制限を実装します。インクリメンタルプルのためにカーソルベースのオフセットによるページネーションを使用します。レート制限内のスループットを最大化するため、オフピーク時間に抽出をスケジュールします。変更されていないデータの再取得を避けるためにAPIレスポンスをキャッシュします。APIがバルクエクスポートエンドポイントをサポートしている場合は、レコード単位のフェッチの代わりにそれを使用します。

面接官への質問

データエンジニアはデータプラットフォームの成熟度とチームのエンジニアリング文化を評価すべきです [1]。

1. 「現在のデータスタックはどのようになっていますか——ウェアハウス、オーケストレーション、変換、オブザーバビリティツールは？」 — 技術環境とモダナイゼーションの状況を明らかにします。
2. 「データ品質を現在どのように管理していますか？既存のデータ品質モニタリングフレームワークはありますか？」 — データガバナンスの成熟度を示します。
3. 「チーム内のデータエンジニアとデータサイエンティスト、アナリストの比率はどのくらいですか？」 — データエンジニアがデータ消費者と統合されているか、サイロ化されているかを示します。
4. 「データパイプラインの障害に対するオンコール体制はどのようになっていますか？」 — 運用負荷とワークライフバランスの期待を評価します。
5. 「データカタログやデータリネージツールは導入されていますか？」 — 発見可能性と文書化の実践を明らかにします。
6. 「チームが現在直面している最大のデータエンジニアリングの課題は何ですか？」 — その役割があなたのスキルと興味に合っているかどうかの洞察を提供します。

面接のフォーマットと予想されること

データエンジニアの面接は通常、コーディング能力とシステム設計思考の両方を評価する4〜5ラウンドで構成されます [3]。

リクルータースクリーニング（30分）： 経験、給与の期待、全般的な技術的バックグラウンドについての議論。

SQLコーディングラウンド（60分）： 共有環境でSQLクエリを書きます——ウィンドウ関数、CTE、集計、結合。クエリ実行計画に関する最適化の議論を予想してください。

Python/プログラミングラウンド（60分）： データ処理ロジックの実装——ファイルのパース、データ構造の変換、または簡単なパイプラインコンポーネントの構築。クリーンでテスト可能なコードに焦点を当てます。

システムデザインラウンド（60〜90分）： データパイプラインまたはデータプラットフォームをエンドツーエンドで設計します。一般的なプロンプト：リアルタイムアナリティクスシステムの設計、マルチプロダクト企業向けデータレイクの構築、イベント駆動データプラットフォームの設計。

行動面接ラウンド（45〜60分）： コラボレーション、インシデント対応、非技術系ステークホルダーとのコミュニケーションに関する質問。

準備方法

データエンジニアの面接準備は、SQLの練習、パイプライン設計の学習、ツール固有の知識を組み合わせるべきです [5]。

SQLをマスターする： ウィンドウ関数、CTE、セルフジョイン、クエリ最適化を練習します。LeetCodeのデータベース問題、HackerRank SQL、Stratascratchなどのプラットフォームを使用してください。IDEなしで複雑なクエリを書けるようになってください。

データモデリングを学ぶ： スタースキーマ、スノーフレークスキーマ、Slowly Changing Dimensions（タイプ1、2、3）、メダリオンアーキテクチャ（ブロンズ/シルバー/ゴールド）を理解してください。ホワイトボードでディメンショナルモデルを設計できるよう準備してください。

ツールを知る： 求人票に記載されているツールについて議論できるよう準備してください。Sparkの場合、RDD対DataFrame、パーティショニング、シャッフル操作を理解してください。Airflowの場合、DAG、オペレーター、センサー、XComを理解してください。dbtの場合、モデル、テスト、マクロ、インクリメンタルマテリアライゼーションを理解してください。

パイプライン設計を練習する： 5つのエンドツーエンドパイプライン設計を確認してください：バッチETL、リアルタイムストリーミング、CDCベースのレプリケーション、APIベースの抽出、データウェアハウスのマイグレーション。それぞれについて、ツール、障害モード、モニタリング戦略を特定してください。

データ品質のストーリーを準備する： 発見し、調査し、解決したデータ品質問題の具体的な例を用意してください。これらの問題を検知（または見逃した）ことのビジネスインパクトを数値化してください。

分散システムの概念を復習する： データシステムに適用されるパーティショニング、レプリケーション、一貫性モデル、CAPの定理を理解してください。Martin KleppmannのDesigning Data-Intensive Applicationsなどの書籍は非常に価値ある準備になります。

よくある面接の間違い

データエンジニアリング候補者を頻繁に不合格にするこれらの落とし穴を避けてください [4]。

1. 正しいが最適化されていないSQLを書く。 正しい結果を返すが不必要にテーブル全体をスキャンするクエリは、本番環境への意識の欠如を示します。常にインデックス、パーティショニング、実行計画について議論してください。

2. パイプライン設計でデータ品質を無視する。 バリデーション、モニタリング、アラートのないパイプラインは不完全です。システム設計の回答には常にデータ品質チェックを含めてください。

3. 持っていないスケールのために過剰設計する。 10GBの日次負荷にKafkaとSparkを提案することは、10TBの日次負荷にシンプルなスクリプトを使うことと同じくらいの間違いです。アーキテクチャを実際のデータ量と成長軌道に合わせてください。

4. ビジネスコンテキストを理解しない。 データパイプラインはビジネスの意思決定に奉仕します。技術的には堅実だがビジネス的に無関係なソリューションを設計する候補者はポイントを外しています。データを誰が消費し、どのような意思決定を推進するかについて明確化の質問をしてください。

5. バッチとストリーミングを交換可能として扱う。 それぞれに複雑さ、コスト、レイテンシにおいて異なるトレードオフがあります。各アプローチがいつ適切か、そして一方を選択することの運用上の影響について明確にしてください。

6. 運用上の懸念を怠る。 パイプラインのモニタリング、アラート、リトライロジック、デッドレターキュー、バックフィル手順はオプションではありません——これらがパイプラインを本番環境に対応させるものです [3]。

重要なポイント

データエンジニアの面接は、必要とする人々に信頼性の高いタイムリーなデータを提供するデータシステムを設計、構築、運用する能力を評価します。SQLをマスターし、モダンデータスタックツールを理解し、エンドツーエンドのパイプライン設計を練習して準備してください。際立つ候補者は、データ品質、運用レジリエンス、ビジネスインパクトについて考える人です——ハッピーパスだけではありません。

レジュメが適切なデータエンジニアリングスキルを強調していることを確認したいですか？ ResumeGeniの無料ATSスコアチェッカーをお試しください。応募前にデータエンジニアのレジュメを最適化できます。

よくある質問

データエンジニアの面接にはどのプログラミング言語を知っておくべきですか？ SQLは不可欠です。Pythonはほとんどの役割で期待されます。ScalaはSpark中心の環境で価値があります。Javaは一部のエンタープライズ環境で使われています [5]。

データエンジニアリングの面接でクラウド経験はどのくらい重要ですか？ 非常に重要です。ほとんどのモダンなデータエンジニアリングの役割では、少なくとも1つのクラウドプラットフォーム（AWS、GCP、またはAzure）とクラウドネイティブなデータサービス（Redshift、BigQuery、Snowflake、Databricks）の経験が求められます [1]。

データエンジニアの面接にはライブコーディングがありますか？ はい。少なくとも1ラウンドのライブSQLコーディングと、データ変換ロジックに焦点を当てたPythonコーディングラウンドを予想してください [3]。

データエンジニアに対する最も一般的なシステム設計の質問は何ですか？ インクリメンタル処理を伴うバッチデータパイプラインの設計、またはリアルタイムイベントストリーミングシステムの設計が、最も一般的な2つのプロンプトです。

既存のパイプラインでしか作業したことがない場合、システム設計ラウンドにどう準備しますか？ オープンソースのアーキテクチャを学び、Netflix、Uber、Airbnbなどの企業のエンジニアリングブログ記事を読み、設計判断を声に出して説明する練習をしてください。重要なスキルはトレードオフを明確に表現することであり、アーキテクチャを暗記することではありません。

データエンジニアリングの面接にdbtを学ぶべきですか？ はい——dbtはモダンデータスタックの標準ツールとなっています。モデル、テスト、インクリメンタルマテリアライゼーションの理解は、ほとんどのアナリティクスエンジニアリングおよびデータエンジニアリングの役割で期待されます [5]。

データエンジニアリングの面接にはどのような資格が役立ちますか？ クラウド認定資格（AWS Data Analytics Specialty、GCP Professional Data Engineer、Azure Data Engineer Associate）はプラットフォーム固有の知識を示し、多くの雇用主に評価されています。