データエンジニア面接の質問、ラウンド別
文責 Aaron Cao · 更新
データエンジニアの面接ループは、高度なSQL、データモデリング、パイプラインとETLの設計、分散処理、行動面接のラウンドで構成される。結果の大半を左右するのはパイプライン設計のラウンドで、そこで問われるのは遅延データや再実行、障害への対処方法であり、どのツールが好みかではない。
データエンジニア面接のループにはどんなラウンドがあるか？
ソフトウェアエンジニアの面接と同じやり方で準備していて、何が違うのか気になっているかもしれない。このセクションでは、こうした面接で繰り返し使われるラウンドを整理し、本当に候補者を差別化する二つのラウンドに時間を使えるようにする。技術的なフィルターでオファーを逃すことはめったにない。
- SQL。ウィンドウ関数、重複排除、クエリ性能を、通常はライブで問われる。
- データモデリング。説明されたビジネスのためにテーブルを設計し、選んだ粒度を弁護する。
- パイプラインとETL設計。データ移動に絞った、自由形式のシステム設計ラウンド。
- 分散処理。あるフレームワークが実際にジョブをどう実行するか、そしてなぜ遅いのか。
- コーディング。PythonまたはScalaで、ソフトウェアエンジニアリングのラウンドより軽いことが多い。
- 行動面接。オンコール対応のインシデント、壊れたダッシュボード、そして昨日のうちに数字が欲しかったステークホルダー。
職種名はアナリティクスエンジニアリングやプラットフォーム系のロールと大きく重なるため、内訳は変わる。関連するロール別の質問集はロール別の面接質問ハブにある。
SQLとデータモデリングではどんな質問が出るか？
SQL
- テーブルの重複を排除し、キーごとに最新の行だけを残す。
- 30分の非アクティブ間隔を使って、ユーザーごとのセッション数を返すクエリを書く。
- 一つのクエリで累計値と前月比の変化を計算する。
- 昨日のスナップショットには存在するが、今日のスナップショットにはない行を見つける。
QUALIFYは何をするものか、それを使わずに書くとしたらどうするか。- このクエリは十億行をスキャンし、二十分かかる。どう診断するか。
- パーティショニングとクラスタリングの違いを説明し、それぞれがどんなときに役立つかを述べる。
データモデリング
- あるオンラインマーケットプレイスの注文履歴のためにテーブルを設計する。ファクトテーブルの粒度は何か。
- スタースキーマを説明し、さらに意図的に非正規化するのはどんなときかを述べる。
- 緩やかに変化するディメンションとは何か、タイプ二をどう実装するか。
- あるステークホルダーが、履歴レポートに顧客の現在の地域を反映させたいと言っている。何が壊れるか。
- 順序が崩れて届くイベントストリームをどうモデリングするか。
- 正規化されたモデルより幅の広いテーブルを選ぶのはどんなときか。
モデリングのラウンドで評価されるのは、粒度を決めてそれを弁護する姿勢だ。三つの候補設計を挙げるだけで一つも選ばない候補者は、妥当な設計を選んでその弱点を挙げる候補者より評価が下がる。
パイプラインと分散処理ではどんな質問が出るか？
パイプラインとETL設計
- 日次の取引データをレポート用にウェアハウスへロードするパイプラインを設計する。
- 上流のソースが昨日のデータをもう一度送ってきた。あなたのジョブには何が起きるか。
- パイプラインを冪等にするにはどうするか、そしてそれが再実行にとってなぜ重要か。
- 日次ロードを止めずに、二年分の履歴をどうバックフィルするか。
- パーティションが閉じてから三日後に、遅延データが届いた。どうするか。
- パイプラインは成功したのに、誤ったデータを生成したことをどう検知するか。
- 何を監視し、朝の三時に誰かを呼び出すのは何か。
分散処理とストリーミング
- シャッフルの原因は何か、なぜそれはコストが高いのか。
- ジョブが遅く、一つのタスクだけが他よりはるかに時間がかかっている。何が起きているか。
- データスキューを説明し、その対処法を二つ挙げる。
- スケジュールされたバッチジョブよりストリーミングを選ぶのはどんなときか。
- exactly once処理が実際に保証するものは何か、そしてそれが成り立たないのはどこか。
- ウィンドウ集計において、ウォーターマークは順序が崩れたイベントをどう扱うか。
これらの質問のうち、ツール名を挙げさせるものがいかに少ないかに注目してほしい。ツール名を挙げるのは回答の始まりであって、回答そのものではない。続く質問は常に「なぜ」であり、「何が壊れるか」だ。
これらをどう練習すればいいか？
こうしたリストを読むと見覚えは作れる。だが設計ラウンドが試すのは別の能力で、誰かに障害ケースで割り込まれながらもシステム全体を頭の中に保持し続けることだ。それは設計を声に出して語ることでしか身につかない。
- 十五分でパイプラインを描いて説明する。ソース、着地、変換、提供に加えて、各段階がどう失敗するか。
- 自分の設計を攻撃する。練習のたびに、再実行したら、遅延データが来たら、スキーマが変わったら何が起きるかを自問する。
- 規模の数字を用意しておく。日々の行数、サイズ、レイテンシ予算。まず想定する規模を述べることが評価される。
- SQLを手で書く。ライブラウンドでは、オートコンプリートも実行もできない、ただのエディタが使われることが多い。
- 一つのインシデントの話をきちんとリハーサルする。何が壊れたか、どう見つけたか、再発しないように何を変えたか。
バッチパイプラインで六年の経験を持つあるデータエンジニアは、フレームワークの内部構造を復習して準備したが、「上流のソースが昨日のファイルを再送してきた」という場面で行き詰まった。手作業で対処したことしかなく、それを言葉で説明したことが一度もなかったからだ。知識はあったが、口に出す答えがなかった。フォローアップ付きで設計ラウンドを練習することこそ、模擬面接モードが作られた理由だ。