データエンジニア面接質問：SQL、パイプライン、プレッシャー下での信頼性

このロールの面接ループは、1つの中心的な懸念を中心に構築されています。規模でデータを正しく移動および変換でき、誰かがそれを監視する必要がないかどうかです。それは4つの関連スキル領域として表示されます：SQLとデータモデリング、ETLおよびELTパターンにまたがるパイプライン設計、障害下での信頼性、そしてコードを書かない人々とトレードオフを伝えるための判断力です。

ほとんどのループは、ハンズオンSQLラウンド、パイプラインまたはデータプラットフォームに焦点を当てたシステム設計ラウンド、および壊れたデータ、不足している要件、データサイエンティストまたはアナリストとの意見の相違を処理する方法を調査する行動ラウンドを混在させます。一部の企業は、生のデータセットから小さなパイプラインを構築するテイクホーム演習も実施しており、ライブオーディエンスなしで同じスキルをテストします。

面接官は、クエリが正しい行を返すかどうかだけを採点していません。彼らはあなたが推論をどのように説明しているかを聞いています：セルフジョインよりもウィンドウ関数を選んだ理由、完全更新よりも増分ロードを選んだ理由、nullカウントだけでなく行数ドリフトをアラートする理由。正しい答えをつぶやく候補は、わずかに粗い答えを明確に説明する候補に負けることがよくあります。

面接前に、2〜3文で説明できる独自の仕事からパイプライン、テーブル、またはインシデントの短いリストを作成してください。SQL、設計、および行動ラウンド全体を通じて、それらを絶えず引き出します。

SQLは、ほとんどがSparkまたはdbtで実行されている企業でも、データエンジニアリング面接で最も一般的なゲートです。次のようなプロンプトを期待してください：各顧客の最新注文を返すクエリを書く、日付のギャップを見つける、毎日の収益の7日間の実行合計を計算する、または最新バージョンを失わずに行を重複排除します。

ウィンドウ関数は絶えず現れます。PARTITION BY句を使用したROW_NUMBER（）は、「キーあたりの最新レコード」の問題の標準ツールです。LAG（）とLEAD（）はギャップとアイランド、および変更検出の質問を処理します。ORDER BY句でのSUM（）は、セルフジョインなしの実行合計を処理します。面接官はまた、クエリプランを大声で推論する必要があります。オプティマイザーが選択する可能性のあるジョイン順序、インデックスが役立つ場所、および不良なジョインではなく欠落したパーティションフィルタのためにクエリが遅いのはいつですかということです。

データモデリングの質問は異なるスキルをテストします：競合する制約の下でのスキーマ設計。一般的なプロンプトは、電子商取引またはサブスクリプションデータセットのスタースキーマを設計することであり、注文またはイベントの事実テーブルと顧客、製品、および時間の寸法テーブルがあります。緩やかに変化する寸法の準備をしてください：Type 1更新（上書き）が正しいのに対し、「購入時の顧客セグメント」などのメトリックの履歴を保存するために Type 2（新しい行、有効日）が必要な場合です。

また、正規化のトレードオフを正当化することもできる必要があります。OLTPシステムは正規化されたテーブルを支持して書き込みの一貫性を保護します。分析ウェアハウスは、BIツールが5つのジョインではなく1つの広いテーブルをクエリできるようにするために、意図的に非正規化することが多いです。そのトレードオフに名前を付け、教科書のような答えから強い答えを分離する、1つのスタイルを普遍的に正しいものとして扱うのではなく。

パイプライン設計の質問は、生データがどのように信頼できるテーブルになるかをスケッチするよう求めています。一般的なプロンプト：クリックストリームイベントを取り込み、製品チームが毎朝クエリできる日次アクティブユーザーテーブルを生成するパイプラインを設計します。強力な答えは、ツールではなくソースから始まります。データはどこから発生するのか、どのくらいの頻度で到着するのか、許容可能なレイテンシーは何か、バッチが遅れたり、ストリームがドロップしたりした場合はどうなるのか。

ETLとELTを明示的に比較することを期待してください。ETLでは、ウェアハウスに読み込む前にデータを変換します。これは、より小さなボリュームまたは厳密なコンプライアンスニーズに適しています。ELTでは、最初に生データを読み込み、dbtなどのツールを使用してウェアハウス内で変換します。これは現在、ウェアハウスのコンピュートが安価で、再処理用の生の履歴を保持しているため、より一般的なパターンです。特定のデータソースに対してどちらかを選択する理由を説明できます。

オーケストレーション質問は、ハッピーパスだけでなく、障害について考えているかどうかをテストします。面接官は、Airflowやdag Aster などのツールでのDAG、タスクレベルのリトライ、中史でスキーマが変更されたバックフィル、新規または変更された行のみを処理し、実行ごとにテーブル全体を再処理しない増分ロードについて聞きたいと考えています。べき等性はお気に入りのフォローアップです：タスクが途中で失敗して再実行された場合、重複した行が生成されるか、同じ正しい結果が生成されるか。

ストリーミング固有の質問は、リアルタイムの要件を持つ企業でより多く表示されます。Kafkaベースのストリーミングパイプラインとマイクロバッチアプローチを比較したり、exactly-onceと at-least-once配信セマンティクスを正確に説明したり、ダウンストリームでどの重複排除戦略を使用するかを説明したりするよう求められることがあります。システムがat-least-onceのみを保証する場合。

データエンジニア面接質問のデータの信頼性に関する質問は、通常、シナリオから始まります：ダッシュボードは今朝ゼロの収益を示しています。それをどのようにデバッグするかをご説明ください。良い答えは、ランダムに推測するのではなく、パイプラインを通じて逆方向で機能します。ソースシステムが実際にデータを生成したかどうか、取り込みジョブのログと行数、変換レイヤーが失敗したか、または静かにスキップされた実行、ダッシュボード自体が古いテーブルまたはキャッシュを指しているかどうかを確認します。

データ品質チェックは、独自のトピックとして頻繁に出現します。面接官は詳細に知りたいと思っています：必須フィールドのnullレート確認、過去のベースラインに対する行数異常検出、テーブルが予想される期間内に更新されていない場合のアラート、および上流のスキーマ変更後に孤立した外部キーをキャッチする参照チェック。dbtテストや Great Expectations などのツールがよく出現しますが、ツールに名前を付けることは、実際に確認する内容を説明し、そのチェックが気になる障害モードをキャッチする理由ほど重要ではありません。

また、データの鮮度に関するSLAおよびSLO、およびアラートをどのように設計して、適切な人が実際の問題についてページング され、予想される分散からのノイズでチームが溺れさせられないようにするかについても、期待する必要があります。しきい値の設定方法、重大度別のアラートのルーティング、毎日起動され、無視されるアラートを回避する方法について説明してください。

関連する行動スレッドは、事後対応です。レポートまたはモデルに達する前に誰かがそれをキャッチしなかった悪いデータを含むインシデントについて説明してください。面接官は、非難ではなく、所有権と処理変更をお聞きしています。強力な答えは根本原因、即座の修正、その後に追加された特定のセーフガード（新しい検証チェックや、バックフィルがどのようにレビューされるかの変更など）に名前を付けます。

データエンジニアの行動質問は、個人の英雄主義よりも少なく、パイプラインに依存する人々からの競合する需要をどのように処理するかにフォーカスします。一般的なプロンプトは次のとおりです：関係者がパイプラインが配信できるより速いデータが必要だった時間について説明してください。データサイエンティストまたはアナリストがスキーマまたはメトリック定義で不同意だった時間について説明してください。本番データのエラーを発見した時間について説明してください。既にレポートで使用されていました。

STARを使用しますが、アクションセクションをデータ作業に固有のものに保ちます。「レポートで既に使用されている悪いデータ」ストーリーについて、エラーをどのように発見したのか、誰にどのくらい迅速に伝えたのか、ダウンストリーム番号をどのように修正したのか、同じエラークラスが再びすり抜けないようにどの検証を追加したのかを説明してください。面接官は、マイナーな不便ではなく、ソフトウェアエンジニアが本番停止に対応する方法としてデータインシデントを扱うことを見たいと考えています。

スキーマまたはメトリック意見の不同意については、技術的な立場を保持しながらまだチームが生きることができる決定に到達できることを示しましょう。クエリパフォーマンス対ストレージコスト、またはより速い新しいデータソースのオンボーディング対より厳密なスキーマなど、防衛していたトレードオフを説明し、他の人を単に無視することなく、それをどのように解決したかを説明してください。

優先順位付けの質問もよく出現します。不安定なパイプラインを修正する、関係者が待っている新しいデータソースを構築する、古いモデルの技術債務を支払うことの間でどのように決定するかについて。信頼できる答えは、ビジネス上の影響、不安定なパイプラインが再び失敗した場合のブラスト半径、およびチームが毎回の変更を遅くするまでの技術債務をどのくらい長く許容できるかを比較します。

これらの質問は紙の上でより簡単に回答できます。ウィンドウ関数、パイプライン設計、またはインシデント事後対応を明確に話された文で説明することは、正しいSQLを書いたり正しいDAGを描いたりするのとは異なるスキルであり、面接官は答えと同じくらい説明をグレードします。

キーボードに触れる前にSQLソリューションの説明を練習してください：アプローチを述べ、使用するウィンドウ関数またはジョイン戦略に名前を付け、その後、クエリを書きます。パイプライン設計プロンプトについては、プレッシャーの下で構造が自動的になるように、その順序でソース、レイテンシー要件、変換ロジック、および失敗処理を通じて話す練習をしてください。行動ストーリーについては、技術的な詳細がモノローグに変わることなく具体的なままになるまでリハーサルしてください。

これらの質問のいくつかに自分自身を答えることを記録し、詰め物の言葉、要点に到達する前に冗長なセットアップ、またはパイプラインウォークスルーのスキップされたステップについて聞き直してください。SayNow AIは、あなたがデータエンジニア面接質問を大声で排出する際にあなたをリハーサルするのに役立ち、あなたの技術的推論が紙のページほど自信を持って来るように、明確さとペーシングに関するフィードバックを提供します。