面接の全体像と答え方

例えば「営業のレポートを作り直した」という経験なら、次のように話します。それまでは各担当者が業務 DB から毎週 CSV を出し、スプレッドシートで集計していて、人によって数字が違い、作るのに半日かかっていました。そこで注文と顧客を DWH に毎晩取り込み、dbt で「売上」の定義を1つにまとめた mart とダッシュボードを作り、主キーの重複や件数の急変をテストで見張るようにしました。

結果として、レポート作りの時間はほぼなくなり、会議で数字が食い違うことがなくなりました。ダッシュボードの閲覧数も追っていて、営業の大半が毎週見るようになったことを確かめています。一方で、最初は定義を合意しないまま作り始めて手戻りがあったので、今は作る前に指標の定義を文章で合意するようにしています。このように「前の状態 → したこと → 測った変化 → 学び」の順で、自分の経験の数字に置き換えて話します。

例えば、次のような話し方をします。CDC の取り込みが週末に止まり、月曜の朝まで誰も気づかず、週末の売上が0と表示されたことがありました。原因は、読み手が止まっている間に PostgreSQL のレプリケーションスロットが WAL をため続け、業務 DB のディスクも圧迫しかけていたことでした。

その場では、取り込みを再開して週末分を取り直し、利用者には影響の範囲を説明しました。変えたことは3つで、取り込みの遅延とスロットの大きさに監視とアラートを入れたこと、テーブルの鮮度のチェックを入れて「更新が止まった」ことに数時間で気づけるようにしたこと、復旧の手順を書いて誰でも対応できるようにしたことです。

例えば、営業から「ダッシュボードを1分ごとに更新してほしい」と頼まれたときの話をします。そのまま作ると DWH の料金が大きく増えるので、まず「1分ごとの数字で何を決めるのか」を聞きました。すると、実際に必要なのはセールの当日だけで、普段は1時間ごとで足りることが分かりました。

そこで、普段は毎時、セールの日だけ15分ごとに更新する案と、それぞれの費用を見せて合意しました。要望を断るのではなく、目的に立ち返って選択肢と費用を並べ、利用者に選んでもらうのが大事だと考えています。