データサイエンティスト面接の準備にはどのくらいの期間が必要ですか？

1年間面接を受けていないベテランDSにとって、集中的な準備の現実的な期間は6～8週間です。分析またはML工学からDSへの転職や、Meta/Google/Netflixでのシニアロールを目指している場合は、3～4ヶ月がより正直な見積もりです。3週間未満の場合はSQLスクリーンに引っかかります — 構文は十分に厳格であり、最近の練習なしでは偽造できません。

2026年にDS職を獲得するには深層学習を知る必要がありますか？

Meta、Airbnb、Uber、Lyftの製品DS職については — いいえ。MLケーススタディはツリーベースのランカー設計に関するもので、深層学習が出現した場合でも期待される深さは概念的です。Netflix、Stripe、AnthropicなどのML応用DS職については — はい、深さは本物です。採用情報を2回読み、採用担当者に明示的にそのロールがどのトラックにあるかを尋ねてください。同じ企業の『データサイエンティスト』というタイトルの下に、両方のトラックが存在します。

SQL vs Python：DS面接ではどちらがより多くテストされますか？

2026年では、特に製品DS追跡ではSQLが大幅にリードしています。ほとんどのループは専用の60分SQL画面を持ち、たまにPythonデータ操作問題があるだけです。Python習熟度はMLケーススタディラウンドで重要ですが、ライブコーディング部分はほぼ常にSQLです。準備の最後の1週間をどこに投資するかを選択する必要がある場合は、SQLを掘り下げてください。ROIはより高いです。

製品DSとML応用DS面接の違いは何ですか？

製品DS面接ではSQLと実験に～60%、製品/メトリクスセンスに～25%、モデリングに～15%を占める — そしてモデリングは概念的です。ML応用DS面接では、モデリング深度（特徴設計、評価方法論、オンライン評価）に～50%の重みを占め、ケーススタディラウンドはスキミングではなく3層深く進むことが期待されます。2026年にML応用DSループを実行している企業は小さなセット：Netflix、Stripe、Anthropic、Googleの一部。他はほぼすべて製品DSです。

ライブSQLスクリーン中にAIアシスタントを使用できますか？

技術的にはそうです。Acedlyのようなツールはほぼそのままのままで実行可能にします — 200ミリ秒以下のレイテンシ、CoderpadおよびHackerRankのエディター読み取り、SQL専用のマルチモデルルーティング。倫理的には異議が唱えられており、答えは企業の面接ポリシーとあなた自身の判断に依存します。同じ製品は、練習中の学習ツールとしては明らかに有用です。実際のラウンドで使用するかどうかは、その特定の雇用主について自分が下す個人的な決定です。Acedlyはツールではなく候補者が開示を制御するように構築されています。

2026年にはどの企業がまだDSを採用していますか？

正直なところ：5年前よりは少ないですが、このロールは死んでいません — より狭いです。Meta、Airbnb、Uber、Lyft、Stripe、DoorDash、およびFAANGアナリティクス部門は、依然として製品DSを積極的に採用しています。Netflix、Anthropic、OpenAI、およびDeepMindは、小数でML応用DSを採用しています。絞り込みは現実です：MLエンジニアが本番化を吸収し、分析エンジニアがダッシュボード作成を吸収し、2026年の『DS』掲示は、ますます製品DSまたは分析DSになっています。ロールの説明をよく読んでください — 『データサイエンティスト』というタイトルの多くの職務公告は、現在『Product Analyst』または『Analytics Engineer』と呼ばれていたものです。

ロールガイド16 min read

データサイエンティスト面接完全対策 2026 年版

2026 年データサイエンティスト面接の実践ガイド：SQL・統計・ML ケース・A/B テスト・FAANG のプロダクト・データハイブリッド面接。各ラウンドでのリアルタイム AI Copilot の活用方法。

Devon Park

Head of Research, Acedly

January 19, 2026に公開

2026年のDSインタビューがこのような形になった理由

2026年のデータサイエンティストという職は、5年前のそれとは異なっています。構造的なシフトが両側から役割を圧縮しました。モデリング側では、MLエンジニアが本番化業務を吸収しました—本番環境にデプロイされるものはすべて、もはやDS職ではなくMLE職です。アナリティクス側では、dbtとウェアハウススキルに長けた「アナリティクスエンジニア」がダッシュボード構築とメトリック定義業務を吸収しました。その中間に残っているもの、そして現在ほとんどのDS職がある場所が、プロダクトデータサイエンスです—実験、メトリック設計、プロダクト意思決定を支える統計的厳密さを担当する職です。

これがインタビュー準備に重要な理由は、インタビュー形式が職の変化を追跡しているからです。5年前のDSループは60%モデリング、40% SQLでした。2026年では60% SQLと実験、25%プロダクトとメトリック理解、15%モデリングに近づいています。モデリングラウンドが登場する場合、それはますます「ケーススタディ」であり、単なるコーディング問題ではなくなっています。準備時の比率を間違えると、Kaggleのような競技に時間を使いすぎて、実際のインタビューでは「このメトリックが下がった理由を診断してください」と問われることになります。

もう一つのトラックもあります—研究科学者、MLエンジニア、応用データサイエンティストという異なる職種を持つ企業でのML応用DS職（Netflix、Stripe、Anthropic、DeepMindなど、DSというタイトルで採用している限定的なケース）です。これらのループは比率を逆転させて約50%のモデリング深度に戻し、ケーススタディラウンドは表面を掠める程度ではなく3層の深さが期待されます—特徴設計、評価方法論、オンライン評価。これらの職を目指しているなら、それに応じて準備してください。Meta やAirbnbを目指しているなら、そうしないでください。

2026年のDSインタビュールーブ、段階ごと

典型的な2026年のデータサイエンティストループは、3〜5週間にわたって4〜6段階で進みます。正確な構成は企業とトラックによって異なりますが、全体の形は一貫しています。

採用担当者スクリーン（30分）。 主にロジスティクスと給与期待に関するもので、「自分について教えてください」というプローブが数個含まれます。ここでの重要な信号は、自分が扱った問題の種類を平易な英語で説明できるかどうか—専門用語ばかりでなく、謙虚すぎもしない。測定可能なビジネス成果と結びついた、簡潔なプロジェクト説明が2〜3個あれば、次のラウンドに進めます。

SQLコーディングスクリーン（45〜60分）。 これは技術的なフィルタです。StrataScratch、DataLemur、Coderpad、HackerRankなど、企業に応じた環境でライブコーディングを行います。中程度のSQLの問題が2〜3個、時々Pythonのデータ操作問題が出ます。合格ラインは初回実行での正確性、適切な変数名、面接官が聞かなかったエッジケースの説明です。時間制限は現実的で、ほとんどの候補者はJOINを複雑にしすぎることで失敗します。

オンサイトまたはバーチャルオンサイト（4〜5ラウンド、各45分程度）。 ここでループは企業ごとに異なります：

Meta はSQLのディープダイブ、プロダクト・メトリックセンスラウンド、A/Bテストラウンド、行動ラウンド（「誇りに思うプロジェクトは何ですか」）を実施します。プロダクトラウンドが最も重く評価されます。
Google はより広範です：SQL、統計、MLケーススタディ、プロダクトラウンド、「Googleyness」の行動ラウンドです。MLケーススタディはMetaより重視されています。
Amazon はリーダーシップ原則に基づいています。すべてのラウンドにLP調査が組み込まれることを期待してください。SQLは短く、統計も短く、DS専門のラウンドは通常、LP言語で表現されたメトリック設計問題です。
Netflix は戦略的思考の異色例です—ラウンド数が少なく、ラウンドごとの信号が高く、執筆力が強く重視されます。分析結果を説明する1ページのメモを書くよう求められることもあります。
Airbnb はホスト側のメトリック（「ホストチャーンをどのように測定するか」）を重視し、長いプロダクトラウンドを実施します。
ML研究寄りの企業（DeepMind、Anthropic、OpenAI がDSタイトルで採用している限定的なケース）は、標準的なラウンドに加えて、論文討議ラウンドと深いモデリングラウンドを実施します。

採用マネージャーラウンド（45分）。 通常は最後に予定されますが、技術ラウンドの間に入ることもあります。あまり技術的ではなく、フィット感と最初の90日の構成方法についてです。シニアレベルの候補者は戦略的な質問を予想すべきです—「このチームが現在追跡していない最も重要なメトリックは何ですか」。

最初の採用担当者との通話からオファーまでの総時間投資は、3週間未満のことはめったになく、よく5〜6週間かかります。単一の重要な日ではなく、その期間を基準に準備スケジュールを組み立ててください。

2026年のSQLラウンド：実際に何が審査されているのか

SQLスクリーンは、ほとんどの候補者がオファーを失う場所です。「SQLを知っている」と「60分のSQLスクリーンに合格できる」の間のギャップは、候補者が考えているより大きいです。3つのカテゴリーの問題が主流です。

ウィンドウ関数 — ほぼ普遍的にテストされます。繰り返し出現する特定の関数：グループごとのトップNには ROW_NUMBER(), RANK(), DENSE_RANK()；期間対期間の変化には LAG() と LEAD()；累計には SUM() OVER (PARTITION BY ... ORDER BY ...)。考えずにグループごとのトップNクエリを書けなければ、失敗します。典型的な罠は、5行で済むウィンドウ関数を使わずに、自己結合または相関サブクエリを選んでしまうことです。

CTEと多段階変換 — 現代的なスタイルです。単一の結合より複雑なものは、CTEのチェーンとして表現されることが期待されており、明確に名前付けされ、各ステップが1つのことをします。インタビュアーは正確性と同様に可読性も評価しています。説明的な名前を持つ40行のCTEチェーンは、毎回12行のネストされたサブクエリソリューションに勝ります。

4つの標準的なパターン：

グループごとのトップN （各地域で支出が多い上位3顧客を見つける）— RANK() または ROW_NUMBER() を使用したウィンドウ関数、ランクでフィルタリング。
リテンション分析とコーホート分析 （1月のサインアップのうち何分の1が2月に戻ったか）— user_idでの自己結合と日付計算、またはアクティブ日フラグのウィンドウ関数。
ファネルコンバージョン （サインアップ → アクティベーション → 初回購入）— ステージングCTEと LEFT JOIN または EXISTS チェック、ステージ間のコンバージョン率の計算。
セッション化 （連続するイベントが30分以内である行をセッションにグループ化）— 時間差を計算するための LAG()、その後「新しいセッション」フラグの累積合計。

最も一般的な間違いは、粒度が間違っていることです。出力がユーザー日ごとに1行である場合と、誤ってイベントごとに1行を生成する場合、すべての下流カウントは桁違いに間違っています。クエリを書く前に、出力の粒度が何であるべきかを明確に述べ、その後小さな SELECT COUNT(*) で検証してください。

統計・確率ラウンド

統計ラウンドは企業によって最も異なります。理論的なものもあります（ベイズ導出、分布の性質）；応用的なものもあります（「このシナリオではどのようなテストを実行しますか？」）。3つのサブカテゴリーがほとんどの質問をカバーしています。

ベイズ確率/条件付き確率。 Monty Hallの問題は驚くほど頻繁に出題されており、その変種―「2つのコイン、1つは公平で1つは偏った。フリップして表が見える。P(biased)は何か？」―がほとんどの企業で出現します。機械的な手順は、ベイズの定理を書き出し、事前確率、尤度、証拠を特定して計算することです。ホワイトボードでこれを話しながら行うことが、実際にテストされるスキルです。答えを得ることは必要ですが、十分ではありません。

分布とそれらを仮定するタイミング。 正規近似は有用ですが、候補者はそれを過度に適用します。インタビュアーが聞きたいのは：「nが十分に大きいのでCLTが適用されるため、ここで正規を仮定しますが、残差をチェックして検証します。基礎データが重い尾を持っている場合は、t分布または非パラメトリック代替案を選びます。」仮定と検証に名前を付けることが、シニアレベルの信号です。

仮説検定。 標準的な「どのようなテストを実行しますか？」フレームワーク：メトリックタイプ（比率、平均、カウント、比率）を特定し、仮定（独立性、正規性、サンプルサイズ）をチェックし、テスト（比率のz検定、平均のt検定、カテゴリのカイ二乗検定、非正規のMann-Whitneyテスト）を選び、帰無仮説と対立仮説を述べ、有意水準を定義し、該当する場合は多重比較補正について議論してください。任意のシナリオでこれを90秒で説明できる必要があります。

信頼区間。 罠は解釈です。「この区間に真の平均が含まれる確率は95%である」は間違っています ―頻度主義的信頼区間はパラメータについての確率ステートメントを行いません。正しいステートメントは：「この実験を何度も繰り返した場合、構築された区間の95%が真の平均を含むでしょう。」これを間違えると、統計に精通したインタビュアーはそれに気付きます。

A/Bテストと実験：基本中の基本

これはプロダクトDS企業（Meta、Airbnb、Uber）で最も重視されるラウンドです。最低限、以下の評価基準が期待されます：

仮説 — どのような結果が起こると予想し、その理由は何か。行動メカニズムに基づいており、「これはうまくいくと思う」というだけではありません。
メトリクス — 主要成功指標、副次指標、ガードレール指標。シニア候補者は質問される前に常にガードレール指標を指定します。
パワー計算 — 80%のパワーで5%の有意水準でX%のリフトを検出するには何サンプル必要か。計算機を使わずに「n ≈ 16 × σ² / δ²」という経験則を使って推定できるはずです（各グループあたり）。
ランダム化単位 — ユーザー、セッション、デバイス？インタビュアーはここを掘り下げます。慎重に選んでください。
ガードレールとSRMチェック — サンプル比率ミスマッチ（実際の分割が意図した50/50から外れていること）が破損した実験の最も一般的な兆候であり、シニア候補者は結果を報告する前にそれをチェックします。
分析 — ポイント推定値、信頼区間、p値（必要に応じて多重比較補正付き）、統計的有意性と実用的有意性の区別。
決定 — 導入する、導入しない、反復する。トレードオフを明確に説明してください。

インタビュアーが掘り下げるトラップ：

新規性効果。 処理版は最初の1週間は素晴らしく見えますが、ユーザーが新機能を探索しているだけだったため、3週目には低下します。
ネットワーク効果。 古典的なFacebookニューズフィードの落とし穴 — 処理版が誰が何を見るかを変更する場合、ユーザーレベルでランダム化することはできません。コントロールグループが処理されたユーザーの行動に汚染されるからです。インタビュアーは時々「マーケットプレイスのランキング変更をテストしていたとしたら？」と表現することがあり、ネットワーク干渉フレーミングを聞きたいのです。
希釈化。 10%のユーザーしか機能を見ない場合、全体的なリフトは10%のグループのリフト × 10%です。これを忘れると、「5%のリフト」がマーケティング主張に変わり、詳しく調べると成り立ちません。
主要指標 vs ガードレール指標のトレードオフ。 「収益は増加するがDAUは減少したら？」シニアの回答には、ガードレール指標の弾力性と時間軸に関する質問が含まれます — 長期的なエンゲージメントを損なう短期的な収益増加はめったに価値がありません。

実例説明 — 新しいホームページフィードの実験設計 — 約8〜10分かかるはずです。これが自動的にできるようになるまで練習してください。

MLケーススタディ（プロダクトDSの観点）

プロダクトDSループでMLが出現する場合、コーディングラウンドではなくケーススタディとして出現します。フレーミングは常に「Xのランカー設計」の変種です — フィードランキング、検索結果、推奨事項、広告選択。期待される構造：

ビジネス目標 — 実際に何を最適化しているのか。エンゲージメント、収益、長期的リテンション？シニアの信号は、プロキシメトリクスが短期的であっても長期的な目標を名前付けることです。
ラベル — 正と負のクラスは何か。ラベルはどのように生成され、どのようなバイアスが導入されるか。（位置バイアス、選択バイアス、コールドスタート問題）
特徴量 — 3〜5つのカテゴリ：ユーザー特徴、アイテム特徴、文脈特徴、相互作用特徴、および（シーケンス対応モデルの場合）最近の履歴特徴。
モデルクラス — 標準的な主力としての勾配ブースティングツリー、データと信号が正当化する場合のディープラーニング。シニア候補者はトレードオフを名前付けます — 解釈可能性、学習コスト、オンライン提供レイテンシ — 流行しているものに飛びつくのではなく。
オフライン評価 — 分類のためのAUC-ROC、ランキングのためのNDCG、回帰のためのRMSE。トラップはここで止まることです。オフラインメトリクスはオンラインビジネスメトリクスとの相関が弱く、シニア候補者がこれを指摘します。
オンライン評価 — A/Bテスト設計、主要指標とガードレール指標、実験ラウンドへのフィードバックループ。

レベル別に期待される正直な深さ：L4（ジュニア）では各ステップを説明できます。L5（ミッド）では各ステップでトレードオフについて議論できます。L6（シニア）では、このケーススタディが異なった2〜3つのステップを特定できます — 教科書的なフレーミングと比べて何が難しいのか — そしてそれにどう対処するかを提案できます。

プロダクト/メトリクスラウンド：DAU低下

プロダクトDSインタビューを実施するほぼすべての企業で尋ねられるシグネチャー的なプロダクトラウンドは、「DAUが週比で5%低下しました。診断方法を説明してください」という形式です。

期待されるフレームワーク（ライブで実行）：

まずデータを検証してください。 メトリクスは実際に低下していますか、それともこれは計測上の問題ですか？ログパイプラインをチェック、上流の変更をチェック、部分的な日データを探してください。
セグメント化してください。 地理、プラットフォーム、OS、国、ユーザーコホート、獲得チャネル別に。低下はめったに均一ではありません。セグメントを見つけることで原因を特定できます。
行動別に分解してください。 DAU = 新規ユーザー + リターンユーザー。新規ユーザーのサインアップが低下しましたか？リターンユーザーのリテンションが低下しましたか？これらは完全に異なる原因を持っています。
ファネル別に分解してください。 各行動グループ内で：アプリオープン数が低下しましたか？オープン-エンゲージメント率が低下しましたか？各ステップは異なる上流の原因を持っています。
外部イベントと相互参照してください。 プロダクト起動（貴社と競合他社）、ニュースサイクル、休日、有料マーケティングの変更、インフラストラクチャインシデント。
仮説を立て、検証を設計してください。 候補となる説明が得られたら、どのデータがそれを反証しますか？

MetaとGoogleでは、期待される出力は「メトリクスツリー」です — メトリクスの視覚的分解で、すべての入力と相対的な変更の大きさを示しています。シニア候補者は話す前にツリーを描き、その後で説明します。ジュニア候補者は最初に話し、ツリーまで到達しません。

リアルタイムAIアシスタントがDS面接ラウンドで役立つ場面と役立たない場面

これについて率直に言いましょう。DSのループには、AI支援があればほぼ最後までいける場面と、AIに頼ると詐欺のように聞こえる場面があります。以下は、当社がユーザーに説明する内容です。

DS面接ラウンド別のAI支援の適合性

Feature	SQL	統計	A/Bテスト	ML事例	プロダクト/指標	行動
AI支援の品質	優れている	良好	強い	強い	中程度	強い
レイテンシ要件	200ms未満（ライブコーディング）	会話形式	会話形式	会話形式	会話形式	会話形式
ステルス性要件	高い（画面共有）	中程度	中程度	中程度	中程度	中程度
倫理的快適性	議論の余地あり	許容できる	許容できる	許容できる	許容できる	個人的判断
推奨される使用方法	スクリプトをほぼ逐語的に	思考補助	フレームワークプロンプト	アウトライン+自分で埋める	ブレーンストーミング；自分で説明する	アウトラインのみ—自分の言葉で話す

正直な要約：SQLスクリーンはAI支援が最も仕事を肩代わりする可能性が高い場面です—構文は厳密で、プロンプトから動作するクエリまでの編集距離は小さく、Acelyのような優れたアシスタントはエディタを直接読み取ります。統計とA/Bテストのラウンドでは、AIは正しいフレームワークと正しいテストを明らかにするのに極めて有用ですが、インタビュアーが質問を掘り下げるときに答えを擁護する必要があります。プロダクト/指標ラウンドではAIはブレーンストーミングパートナーですが、あなたの代わりに答えを擁護することはできません—インタビュアーは「なぜこのセグメントではなくあのセグメント？」と聞き、あなたは意見を持つ必要があります。行動ラウンドではAIは構造（状況-タスク-アクション-結果）を作成できますが、コンテンツはあなたのもの、あなたの声でなければならない、そうしなければ準備済みのように聞こえます。

ライブなDS面接ラウンド中のAcedly

Acelyはライブの人間インタビュー向けに設計されており、あなたが開示を制御できます。特に、データサイエンティスト向けのラウンドでは、3つのことが重要です：

レイテンシ。 中央値の端から端までのレイテンシは約98 msです—発話終了から最初にレンダリングされるトークンまで測定されます。このバジェットはSQLコーディングスクリーンで最も重要です。そこでは、「AIが役立つ」と「AIが遅すぎて役立たない」の違いが、自分の答えを書くことと既存の答えをコピーすることの違いなのです。

コーディングプラットフォームエディタ読み取り。 ほとんどのDSスクリーンはCoderpadまたはHackerRankで実行されます—両方とも検証済みサーフェスです。Acelyは問題文、スキーマ、候補者が書いた部分的なクエリを読み取り、3つすべてをグラウンディングコンテキストとして使用します。オーディオのみをリッスンするコパイロットはスキーマをテーブルに残します。つまり、より悪いSQLの提案につながります。

マルチモデルルーティング。 SQLの質問はDeepSeekにルーティングされてコード生成を行い、統計確率はClaudeにルーティングされて推論品質を、プロダクト/指標ラウンドはGPTにルーティングされてより広いビジネスコンテキストを提供します。ルーターはセッション単位ではなく、質問単位で選択します。

8つの検証済みプラットフォーム。 Zoom、Microsoft Teams、Google Meet、Webex、Lark/Feishu、Amazon Chime、Coderpad、HackerRank。これらを合わせると、2026年の専門的なDS面接サーフェスのおよそ95%をカバーしています。

SQLを含む12以上のプログラミング言語。 Python、R、SQL（PostgreSQL、MySQL、BigQuery、Snowflakeダイアレクト）、Scala、Java、JavaScript/TypeScript、Go、Rust、C++、Julia、MATLAB、Bash。SQLダイアレクト検出が重要なのは、ウィンドウ関数構文がPostgresとMySQLの間で微妙に異なるためです。

4週間のデータサイエンティスト面接準備計画

4週間の時間がある場合、以下のスケジュールは実用的な配分です。非標準的なトラックを目指している場合は、ウェイトを調整してください。

週1 — SQLドリル。 1日2時間。StrataScratchまたはDataLemurで50問、ウィンドウ関数、リテンション/コホート分析、ファネルクエリに偏らせます。各問題に1文のポストモーテムを書きます：どのパターン、どのウィンドウ関数、粒度は何か。週末までに、最初の1文からtop-N-per-groupを認識できるようになるはずです。

週2 — 統計、確率、A/Bテスト。 1時間の理論学習（分布、仮説検定、ベイズの復習）、1時間の実務練習 — 10個のクラシックなA/Bテストプロンプト（サンプルサイズ、新奇効果、ネットワーク効果、希釈）を実行します。7ステップのルーブリックを声に出して練習し、自動化するまで続けます。読書：Kohavi、Tang、XuのTrustworthy Online Controlled Experimentsは、質問されるほぼすべてをカバーしています。

週3 — 製品とメトリクスモックケース。 1日3件のモックケース、各30分、様々なメトリクスについて。DAUドロップ、エンゲージメント低下、コンバージョン率低下、チャーンスパイク。毎回メトリクスツリーフレームワークを使用します。自分を録画して、再生します。最初の3つは悪く、10番目は自動です。

週4 — 企業別対応。 Metaを目指している場合は、Decode and Conquerトラックから製品ケースを掘り下げます。Googleを目指している場合は、SQL、統計、MLケースにわたって拡大します。Amazonを目指している場合は、各原則ごとに2つのストーリーを含むLPマップポートフォリオを準備します。最後の48時間：休息。簡単な問題、睡眠、仕事を完了したことを認識する精神的リフレッシュ。

すべての週を通じて、最も効果の高い習慣は1つ：解く各問題に1文のポストモーテムを書く。50問後、独自のパターン認識履歴のローリングテーブルが得られます。100問後は、睡眠中にDAUドロップを診断しています。