SQL面接対策の初心者向けガイド。SELECT、WHERE、GROUP BY、JOIN、NULLの要点を30分で整理し、スクリーニングで固まらない答え方まで学べるので、直前対策に最適です。
一晩しかありません。1週間でも、週末でもなく、たった一晩で SQL に取り残されている感覚を止めて、スクリーニング面接に入っても固まらないくらいの準備感を持ちたい。朗報は、初級レベルの sql basic interview questions は、実はかなり限られた小さな論点を何度も巡っていることです。残念なのは、多くの学習リソースが「80問のリスト」を渡して終わりにしてしまうことですが、それでは役に立つものを何も覚えられないのが最速です。
このガイドは少し違う進め方をします。面接官が実際に質問を投げる順番に沿って、SELECT と WHERE から始め、GROUP BY と HAVING を経て、最後に JOIN、キー、そして候補者の点を静かに落とす NULL の落とし穴へと進みます。最後の 30 分 अभ्यासシーケンスを実践すれば、明確な答えを口に出して言えるようになります。面接で本当に試されるのはそこです。
まず覚えるべき SQL の基本 10 個
面接のために、初心者が最初に暗記すべき SQL の核となる基本は何ですか？
多くの初心者が陥る落とし穴は、基本的な質問に答えられるようになる前に、全部を網羅しようとすることです。SQL の面接用基本項目には自然な優先順位があり、これを無視すると、GROUP BY の意味があいまいなままウィンドウ関数に 2 時間費やすことになります。
本当に重要な最初のセットは、順に言うと、SELECT と FROM（どのデータを取るかを指定する）、WHERE（行を絞り込む）、ORDER BY（結果を並べ替える）、GROUP BY（カテゴリごとに集計する）、HAVING（集計後に絞り込む）、そして主キー・一意キー・外部キーの 3 種類です。サブクエリ、CTE、ウィンドウ関数、ストアドプロシージャなどは、すべてこれらの上に乗っています。まず土台を固めてください。
実際の採用現場で見ても、初級レベルで過剰に準備されがちなのはサブクエリです。候補者は相関サブクエリの説明はできるのに、HAVING がなぜ存在するのかを聞かれるとつまずきます。逆に、いつも準備不足なのが NULL の挙動です。ほぼすべてのスクリーニングで登場し、それ以外はしっかりしている候補者でも引っかかりやすい論点です。
これまで SQL を使ったことがない人に、SQL をどう説明しますか？
いちばんわかりやすい平易な言い方は、こんな感じです。「SQL は、データベースに質問するための言語です。データベースは情報をテーブルに保存します。行と列があるので、スプレッドシートのようなものです。SQL で『この条件を満たすこのテーブルの行を、この順番でください』と指定できます。」
具体例としては、employees と departments を使うと説明しやすいです。`employees` テーブルには `name`、`salary`、`department_id` などの列があります。`departments` テーブルには `department_id` と `department_name` があります。SQL は、これらのテーブルをつなげて、欲しい行だけを取り出すためのものです。テーブル、行、列、質問という枠組みで話せば、初心者向けの回答として十分ですし、暗記した感じではなく自然に聞こえます。
基本的な面接では、どの SQL トピックが最初に出てきて、どれは後回しにできますか？
SHRM の採用実務ガイダンス や一般的に公開されている技術面接の評価基準によると、初級 SQL のスクリーニングは、ほぼ必ず複数テーブルの話に入る前に、単一テーブルのクエリから始まります。つまり、SELECT、WHERE、ORDER BY、GROUP BY、HAVING が最初の関門です。JOIN はその次です。サブクエリやパフォーマンス関連は、その後、あるいは初級ラウンドでは出ないこともあります。
時間があれば後回しでよいものは、CTE、ウィンドウ関数、インデックスとクエリ最適化、ストアドプロシージャ、そしてデータベースごとの構文差です。これらは中級・上級向けの話です。初心者のスクリーニングでは、知っていれば加点にはなりますが、必須ではありません。
クエリの基本を、長々とせずに答える方法
SELECT と FROM を 30 秒でどう説明しますか？
そのまま口に出して通る答えはこうです。「SELECT は、データベースに見たい列を指定します。FROM は、どのテーブルを見るかを指定します。たとえば `SELECT name, salary FROM employees` なら、employees テーブルの各行からその 2 列だけを取ってきます。」
次によく来る質問は、「全列を取りたいときは？」です。答えは `SELECT *` ですが、すぐに「ただし実務では不要なデータまで取るので、できれば避けます」と補足してください。その一言があるだけで、構文を知っているだけでなく、実務上のトレードオフも理解していることが伝わります。基本的な SQL 面接では、この違いが合格ラインと強い回答の分かれ目になることが多いです。
WHERE と HAVING を混同せずに説明するにはどうすればいいですか？
WHERE は、グループ化や集計の前に行を絞り込みます。これが両者の本質的な違いで、そのまま言い切る価値があります。
具体例で言うと、「`orders` テーブルがあります。`WHERE amount > 100` なら、100ドルを超える注文だけを取ります。つまり個々の行を絞っているわけです。これが WHERE です。」候補者がよくやる間違いは、GROUP BY の後に WHERE を使おうとすることですが、SQL ではそれはできません。WHERE はグループを知りません。行しか知りません。`WHERE は行を見る、HAVING はグループを見る` というイメージを持てば、面接でこの違いを聞かれても迷わず答えられます。PostgreSQL の集計に関する公式ドキュメント でも、この順序は明確です。WHERE が先、HAVING が後です。
ORDER BY と GROUP BY を 1 分以内でわかりやすく説明するには？
この 2 つは結果の見え方を変えるので混同されがちですが、役割はまったく違います。
ORDER BY は並べ替えです。`ORDER BY salary DESC` は、同じ行を給与の高い順から低い順に並べるだけです。結合もしなければ集計もしません。出力の順番を入れ替えているだけです。GROUP BY は集計です。`GROUP BY department_id` は、同じ部署の行を 1 行にまとめるので、部署ごとの人数や平均給与のような集計質問ができるようになります。片方は順位付け、もう片方はまとめ上げです。地域別売上合計のレポートなら GROUP BY、営業担当者の上位 10 名を出すレポートなら ORDER BY を使います。
面接官が短く答えてほしがるとき、HAVING をどう説明しますか？
ひとことで言うなら、「HAVING は GROUP BY の結果を絞り込むもので、WHERE が個々の行を絞り込むのと同じ関係です。」です。すぐに例を付けてください。その一文だけだと、丸暗記した定義に聞こえてしまうからです。
例: 「営業担当者ごとに売上をまとめて、合計売上が 10,000ドルを超える担当者だけを見たいとします。このとき WHERE は使えません。まだその合計値を持つ個別の行が存在しないからです。代わりに、GROUP BY の後で `HAVING SUM(amount) > 10000` を使います。」この答えは、フォローアップにも耐えられる具体性があり、しかも長すぎません。
あいまいな答えと鋭い答えの違いはここです。あいまい: 「HAVING はグループ版の WHERE です。」鋭い: 「WHERE はグループ化の前に行を絞る。HAVING は集計後の結果を絞る。WHERE で SUM や COUNT のような集計関数を使おうとすると、SQL はエラーになります。WHERE の段階では、その集計はまだ計算されていないからです。」後者ならフォローアップにも耐えます。前者では耐えられません。
キー、制約、そして面接官がテーブル理解を見極めるために使う論点
主キー、ユニークキー、外部キーの違いは何ですか？
キーに関する初級 SQL の質問は、実際に何を制約しているのかに結び付けるまで、定義が似ていて引っかかりやすいです。
主キー: テーブル内の各行を一意に識別します。NULL は不可で、1 テーブルに 1 つしか持てません。`employees` テーブルなら `employee_id` が主キーです。各従業員に 1 つだけ割り当てられ、2 人で共有することはありません。ユニークキー: 一意性を保証しますが、多くのデータベースでは NULL を許可でき、1 テーブルに複数設定できます。`email` 列は典型的なユニークキーです。2 人のユーザーが同じメールアドレスを持つことはできませんが、この列は主キーとは別です。外部キー: 1 つのテーブルを別のテーブルに関連付けます。`employees` の `department_id` 列は、`departments` テーブルの `department_id` を参照する外部キーです。存在しない部署に従業員を割り当てることを防ぎます。
SQL の制約は、実際のテーブルで何をしているのですか？
制約は、悪いデータがテーブルに入る前に止めるガードレールだと考えてください。NOT NULL は、列を空欄にできないという意味です。必須値なしで行を挿入しようとすると、データベースが拒否します。CHECK は条件を加えます。`CHECK (age >= 18)` なら、18 歳未満の行は挿入できません。UNIQUE は、列内の重複値を防ぎます。PRIMARY KEY は、NOT NULL と UNIQUE を 1 つにまとめた制約です。
最もわかりやすい実例はサインアップフォームです。`users` テーブルでは `email` を UNIQUE にして重複アカウントを防ぎ、`username` を NOT NULL にして未入力登録を防ぎ、`user_id` を PRIMARY KEY にします。こうした制約がなければ、重複メール、空のユーザー名、識別子のない行といった悪いデータが静かに紛れ込み、後から直すほうが、最初からテーブルで防ぐよりはるかに高くつきます。MySQL の制約に関するドキュメント では、方言ごとの正確な構文まで詳しく確認できます。
初級レベルで、面接官が正規化を気にするのはなぜですか？
初級レベルでいう正規化は 1 つの意味しかありません。同じ事実を複数の場所に保存しないことです。`customers` テーブルと `orders` テーブルがあるなら、顧客の住所は `customers` に置くべきで、`orders` の各行に繰り返して入れるものではありません。顧客が引っ越したら、1 行を更新するだけで済みます。数百行を直す必要はありません。
初級スキーマでよくある間違いは、`customer_name` や `customer_email` を `orders` テーブルに直接入れてしまうことです。そうすると顧客がメールアドレスを変更したとき、過去に作成したすべての注文を更新しなければならず、1 つでも漏れればデータが不整合になります。初心者向けの面接で正規化を問われたときに 1NF、2NF、3NF を暗記している必要はありません。「各事実を 1 か所に保つようにして、更新をきれいに保ちます」と言えれば十分です。
JOIN、サブクエリ、そして初心者がつまずきやすい境目
初級の面接で、INNER JOIN と LEFT JOIN はいつ使い分ければいいですか？
まずは単純なルールです。INNER JOIN は、両方のテーブルで一致する行だけを返します。LEFT JOIN は、左側のテーブルの全行を返し、右側で一致する行を付け足します。一致しない場合、右側は NULL で埋まります。
ここで単純なルールが効かなくなる場面があります。`customers` テーブルと `orders` テーブルがあり、注文したことがない顧客も含めて全顧客を見たいなら、INNER JOIN ではその顧客が静かに消えてしまいます。LEFT JOIN なら残り、注文欄には NULL が入ります。初心者向けの SQL 面接では、欠けている行が重要なシナリオがほぼ必ず出ます。注文のない顧客、上司のいない従業員、売上のない商品などです。自分に聞くべき問いは、「一致しないときに行が消えてもよいか？」です。よければ INNER JOIN。だめなら LEFT JOIN です。PostgreSQL の JOIN 種別に関するドキュメント で、挙動の全体像がわかりやすく説明されています。
サブクエリを、怖く聞こえないように説明するには？
サブクエリは、クエリの中にあるクエリです。内側のクエリが先に実行されて結果を作り、外側のクエリがその結果を使います。考え方はそれだけです。
具体例にするとわかりやすいです。「平均給与より高い給料の従業員をすべて見つけたい」とします。平均値を 1 つのクエリで計算してから、その数値を使って 2 つ目のクエリを書くこともできます。あるいは、1 ステップでこう書けます。`SELECT name FROM employees WHERE salary > (SELECT AVG(salary) FROM employees)`。内側のクエリが平均を計算し、外側のクエリがそれを使います。2 ステップ、1 文です。
面接で JOIN とサブクエリを素早く見分けるには？
覚え方はこうです。結果に両方のテーブルの列が必要なら JOIN を使います。別のテーブルから値だけを取ってきて、絞り込みや比較に使うだけならサブクエリを使います。
たとえば、従業員と部署名を並べて一覧にしたいなら、`employees` と `departments` の両方の列が必要なので JOIN です。最終出力に `orders` テーブルの列は要らず、上位の支出者だけを知りたいなら、サブクエリのほうがすっきりする場合があります。実際の面接では、JOIN が期待されていた場面でサブクエリを書いた候補者が、ロジックは正しいとして部分点をもらいつつも、書き直しを求められました。面接官は、JOIN のほうが読みやすく、インデックスも効かせやすいことを理解しているかを見たかったのです。両方のパターンを知り、なぜその方を選んだのかを説明できることが、合格ラインと強い回答の分かれ目です。
NULL、DISTINCT、集計関数：小さな落とし穴で点を落とさないために
なぜ NULL は初心者の SQL 回答を壊し続けるのですか？
NULL は 0 ではありません。空文字でもありません。値が不明、または存在しないことを意味し、その違いが通常の比較ロジックを壊します。
`WHERE salary = NULL` は、たとえ給与が NULL の行があっても、絶対に行を返しません。SQL では `WHERE salary IS NULL` と書く必要があります。理由は、NULL と何かを比較した結果は、たとえ相手が NULL でも TRUE や FALSE ではなく NULL になるからです。そのため、フィルターは静かに全行を落としてしまいます。面接用の SQL 基礎では、ほぼ必ず 1 問は NULL の質問が出ますが、うまく答えるならこうです。「NULL は不明値なので、= では見つけられません。IS NULL または IS NOT NULL を使う必要があります。」実際のデータクレンジング例として、応答時間の平均を出したときに妙に高い数値になったのは、NULL の応答時間が 0 として扱われたのではなく、集計関数によって除外されていたことを見落としていたから、というケースがあります。
データ問題を隠さずに DISTINCT を使うにはどうすればいいですか？
DISTINCT は、結果から重複行を取り除きます。注意点は、なぜ重複があるのかを理解せず、汚れた結果をきれいに見せるために使ってしまうことです。
`contacts` テーブルで `SELECT DISTINCT email` を実行して `SELECT email` より少ない行数しか返らないなら、データには重複メールがあります。DISTINCT は、重複が想定されていて無害なときに使う正しい手段です。たとえば、売上テーブルから国名のユニーク一覧を取りたい場合などです。逆に、重複がデータ品質の問題を示していて、発生源で直すべきときには不適切です。面接で DISTINCT を使うなら、重複がなぜあるのか、そしてそれを消してよいのかを説明できるようにしてください。
NULL があるとき、SUM、COUNT、AVG、MIN、MAX は何を見落としますか？
初心者が忘れがちなルールは、ほとんどの集計関数は NULL を完全に無視することです。`AVG(salary)` は NULL でない給与だけで平均を計算し、NULL を 0 として扱いません。`COUNT(salary)` は NULL でない給与だけを数えます。`COUNT(*)` は NULL に関係なく全行を数えます。
小さな表の例です。給与が 50,000、60,000、NULL、70,000、NULL の 5 人の従業員がいるとします。`AVG(salary)` は 60,000 を返します。5 人ではなく、3 つの値の平均だからです。`COUNT(salary)` は 3、`COUNT(*)` は 5 を返します。AVG が 5 人全員を反映すると期待していたなら、その数値は間違いです。直すには、集計前に NULL を 0 に置き換える `COALESCE(salary, 0)` を使うのが一般的です。ただし、0 が本当に業務上正しい解釈である場合に限ります。
実際に定着する 30 分の練習手順
一晩しかないなら、最初の 10 分をどう使うべきですか？
0〜10 分は、理解ではなく想起の時間です。紙でもテキストエディタでもよいので、5 つの基本句を順に書き出してください。SELECT、FROM、WHERE、GROUP BY、HAVING、ORDER BY です。次に、それぞれが何をするかを 1 文で書きます。調べずにやってください。記憶から書けないものこそ、最初に復習すべきものです。
スクリーニングレベルの基本 SQL 面接は、ほぼ必ずこれらの句から始まります。1 文で説明できて、使った簡単なクエリを書けるなら、最初の関門はクリアです。これは読み込みではなく、想起練習です。学習科学の研究でも、米国心理科学協会の間隔反復に関する資料 が示す通り、時間制限下での定着には受動的な復習より能動的想起のほうが有効です。
完全な初心者なら、10〜20 分で何を練習すべきですか？
単一テーブルのクエリに、フィルタと集計を組み合わせて練習します。次の問題を使ってください。「`sales` テーブルに `salesperson`、`region`、`amount` の列があります。地域ごとの総売上を表示し、ただし総売上が 50,000 ドルを超える地域だけを返すクエリを書いてください。」
この 1 問で、SELECT、FROM、GROUP BY、HAVING、SUM の集計を順番に使う必要があります。クエリを書いてください。声に出して読み上げてください。次に条件を少し変えます。しきい値を変えたり、ORDER BY を追加して地域を順位付けしたりしてください。目標は完璧な SQL を書くことではありません。句をまたいでも固まらずに移動できるようになることです。
面接直前の最後の 10 分で、何を詰め込むべきですか？
JOIN と 1 つのサブクエリに切り替えます。問題: 「`customer_id` でつながる `customers` と `orders` テーブルがあります。注文したことがない顧客も含めて、すべての顧客を返すクエリを書いてください。」これで LEFT JOIN を選ぶ必要があります。次に、「最も多く注文した顧客を見つけてください。」これはサブクエリでも、JOIN と ORDER BY、LIMIT の組み合わせでも解けます。両方試してください。
各クエリのあと、答えを 1 文で声に出して言ってください。「注文がない顧客も残したかったので、ここでは LEFT JOIN を使いました。」この口頭での要約こそ、面接官が聞きたいものです。初級 SQL 面接のコーチングをしていると、クエリは書けるのに説明できない候補者は、必ず追加質問で深掘りされます。逆に、説明から入り、その後にクエリを書く候補者は、通過が速い傾向があります。
その次に来やすいフォローアップ
基本的な SQL 質問に答えたあと、どんなフォローアップが来ますか？
面接官がよくやる次の一手は、その回答が暗記なのか理解なのかを試すことです。GROUP BY を説明したら、「GROUP BY に含まれていない列を SELECT したらどうなりますか？」と聞かれます（SQL はエラーになるか、方言によっては任意の値を返します）。INNER JOIN を説明したら、「右側に一致する行が複数あったらどうなりますか？」と聞かれます（左側の行が一致の数だけ重複します）。
通常のスクリーニングでは、次のような確認が来ると思ってください。「クエリで見せてもらえますか？」「ここに NULL があったらどうなりますか？」「なぜサブクエリではなくその方法を選んだのですか？」パターンはいつも同じで、今出した定義より 1 段深いところを見ています。
その場でクエリを書けと言われたら、どう答えますか？
正しいことを言うのと、ライブでクエリを組み立てるのは別スキルです。その場で書くよう求められたら、思考を口に出しながら進めてください。「まず SELECT で必要な列を決めて、次に FROM でテーブル名を指定し、そのあと GROUP BY の前に絞り込む WHERE を追加します。」この実況は 2 つの役に立ちます。考え方を示せることと、黙り込まずに少し考える時間を稼げることです。
今すぐ紙で使える練習問題: 「`employees` テーブルに `name`、`department`、`salary` があります。5 人以上いる部署だけを対象に、部署ごとの平均給与を求めるクエリを書いてください。」調べずに書いてみてください。詰まったら、何をしたいのかを声に出してください。面接官は、あなたが正しく考えていると見えれば、ヒントをくれることが多いです。
1 つの SQL 方言しか知らない場合は、どう対応しますか？
そのまま、遠慮せずに伝えてください。「主に PostgreSQL を使ってきたので、その構文で書きます。ただ、方言依存の部分があれば指摘できます。」これなら、きちんとした профессионального な答えです。違いがよくわからないのに MySQL の構文で書いてしまい、面接官に特定の関数について聞かれて困るよりずっと良いです。
初級レベルでの方言差は、実際には大きくありません。行数制限の LIMIT と TOP の違い、文字列関数の一部の違い、そしていくつかの NULL 処理の細かな差くらいです。W3Schools の SQL リファレンス によると、SELECT、WHERE、JOIN、GROUP BY といった基本的な DML 構文は MySQL、PostgreSQL、SQL Server の間で十分に共通しているため、どの方言でも初心者の回答としては通ります。少しかじっただけの方言に対して、使いこなせるふりをしすぎるほうがリスクです。
Verve AI で SQL のコーディング面接を成功させる方法
SQL 面接対策でいちばん難しいのは、構文を学ぶことではありません。見られている状況で、圧のかかったまま、書きながらクエリを明確に説明することです。答えは知っているのに、それを滑らかに出せない。このギャップを埋めるために作られているのが Verve AI Interview Copilot です。
Verve AI Interview Copilot は、HackerRank、LeetCode、CodeSignal の SQL 問題を解いている最中でも、ライブの技術面接中でも、画面をリアルタイムで読み取ります。しかも、一般的なプロンプトではなく、実際に画面に出ている内容に基づいて提案を出します。クエリの途中で「HAVING と WHERE のどっちを使うんだっけ」と固まったときも、沈黙が気まずくなる前に、その場で違いを提示できます。Secondary Copilot 機能は、圧が上がったときに周辺トピックへ脱線せず、1 つの問題に集中し続けるのを助けます。そして、デスクトップアプリは OS レベルで画面共有に映らないため、サポートはあなたと画面の間だけで完結します。一晩だけ準備して SQL スクリーニングに入る初心者にとって、決まり文句ではなく実際に起きていることに反応する仕組みがあるのは、暗記だけでは得られない構造的な優位性です。
まとめ
基本的なスクリーニングラウンドの前に、SQL を全部知っている必要はありません。面接官が何度も戻ってくる少数の論点、つまり SELECT から HAVING まで、3 種類のキー、LEFT JOIN と INNER JOIN の使い分け、そして集計回答を静かに壊す NULL の落とし穴を知っていれば十分です。それなら管理可能な範囲で、しかも一晩あれば身につけられます。
30 分の流れを 1 回やってみてください。クエリを紙に書き、答えを声に出してください。目指すのは、教科書を読んだ人のように話すことではありません。実際にこれらのツールを使ってきて、それぞれがなぜ存在するのかを知っている人のように話すことです。その状態で面接に入れば、基本で止まることはありません。
Verve AI
コンテンツ