SQL-Interviewfragen: zehn Fragen mit Abfragen und Ergebnissen

Klären Sie die Datenregeln, bevor Sie eine Abfrage schreiben

Eine richtige Abfrage beginnt mit einer klaren Frage. Was ist die Zeile der Tabelle: Bestellung, Zahlung oder Kunde? Welche Zeit gilt? Zählen stornierte Bestellungen mit? Darf ein Kunde mehrere Konten haben? Geben Sie ein kleines Schema und die Regeln vor. Bewerten Sie danach Ergebnis, Lesbarkeit und Umgang mit Randfällen.

Eine Arbeitsprobe mit synthetischen Tabellen ist fairer als produktive Daten. Geben Sie gleiche Zeit und Hilfsmittel vor. Fragen Sie, wie die Person das Ergebnis mit einer kleinen Kontrollrechnung überprüft. Ein korrekt aussehender Gesamtwert beweist wenig, wenn unklar bleibt, welche Zeilen einfließen.

Zehn Fragen und woran Sie eine gute Antwort erkennen

1. Worin unterscheiden sich WHERE und HAVING? Gute Antwort: WHERE filtert Eingabezeilen, HAVING Gruppen nach der Aggregation. Warnsignal: beide Bedingungen werden beliebig ausgetauscht.
2. Wann verwenden Sie LEFT JOIN statt INNER JOIN? Gute Antwort: wenn Zeilen der linken Tabelle ohne Treffer erhalten bleiben sollen. Sie fragt, ob NULL im Ergebnis erwartet wird.
3. Warum kann ein JOIN Summen vervielfachen? Gute Antwort: mehrere Treffer auf der rechten Seite vervielfachen linke Zeilen. Die Person prüft Kardinalität statt mit DISTINCT Symptome zu verdecken.
4. Wie finden Sie doppelte Datensätze? Gute Antwort: Sie klärt zuerst den fachlichen Schlüssel und gruppiert nach dessen Spalten. Warnsignal: jede wiederholte ID gilt automatisch als Datenfehler.
5. Wie behandeln Sie NULL? Gute Antwort: Sie berücksichtigt, dass NULL unbekannt oder fehlend bedeutet und Vergleiche mit IS NULL prüft. Warnsignal: NULL wird wie ein gewöhnlicher Wert verglichen.
6. Wie würden Sie die neueste Bestellung je Kunde finden? Gute Antwort: sie definiert Gleichstände und nutzt eine passende Rangfolge oder Aggregation. Warnsignal: MAX-Zeitstempel wird ohne Beachtung mehrfacher Treffer zurückverbunden.
7. Was bewirkt ein GROUP BY? Gute Antwort: Ergebniszeilen werden nach Gruppenschlüsseln zusammengefasst; alle nicht aggregierten Ausgaben müssen zur Gruppierung passen.
8. Wie untersuchen Sie eine langsame Abfrage? Gute Antwort: sie prüft Ausführungsplan, Datenmenge und Filter, bevor sie einen Index vorschlägt. Warnsignal: „Index auf alles“.
9. Wie schützen Sie eine Abfrage mit Nutzereingaben? Gute Antwort: Werte werden über gebundene Parameter übergeben, nicht in SQL-Text hineinkopiert. Sie erklärt, dass Platzhalter keine beliebigen Spaltennamen ersetzen.
10. Wie testen Sie eine Abfrage mit Randfällen? Gute Antwort: sie erstellt kleine Daten für leere Mengen, doppelte Treffer und fehlende Beziehungen und notiert erwartete Zeilen.

Diese Kriterien sind Gesprächshilfen. Fragen Sie nach einer Begründung zur konkreten Aufgabe, nicht nach dem Auswendiglernen einer Definition.

Drei Abfragen mit synthetischen Daten und erwarteten Ergebnissen

1. Neueste Bestellung pro Kunde

Eingabe: orders = (Kunde, Bestellung, Zeit): (7, 41, 2026-01-03), (7, 42, 2026-01-08), (9, 50, 2026-01-05). Bei gleichem Zeitstempel entscheidet die größere Bestellnummer. Die Abfrage vergibt eine Reihenfolge je Kunde:

WITH ranked AS (
  SELECT customer_id, order_id, created_at,
         ROW_NUMBER() OVER (
           PARTITION BY customer_id
           ORDER BY created_at DESC, order_id DESC
         ) AS rn
  FROM orders
)
SELECT customer_id, order_id, created_at
FROM ranked
WHERE rn = 1
ORDER BY customer_id;

Erwartete Ausgabe: (7, 42, 2026-01-08) und (9, 50, 2026-01-05). Fragen Sie, wie die Ausgabe aussähe, wenn Kunde 7 zwei Bestellungen am selben Tag hätte.

2. Kunden ohne Bestellung sichtbar halten

Eingabe: customers = (1, Ada), (2, Bo); orders = (10, customer 1). Ein INNER JOIN würde Bo auslassen. Mit LEFT JOIN bleibt Bo erhalten:

SELECT c.id, c.name, COUNT(o.id) AS order_count
FROM customers AS c
LEFT JOIN orders AS o ON o.customer_id = c.id
GROUP BY c.id, c.name
ORDER BY c.id;

Erwartete Ausgabe: (1, Ada, 1), (2, Bo, 0). COUNT(o.id) zählt nur passende Bestellungen; COUNT(*) würde auch die erhaltene Zeile für Bo zählen. Das ist ein guter Nachfragetest.

3. Bezahlte Bestellungen je Kunde

Eingabe: orders = (1, bezahlt, 10), (1, bezahlt, 15), (2, bezahlt, 9), (2, offen, 100), (3, bezahlt, 7). Gesucht sind Kunden mit mindestens zwei bezahlten Bestellungen:

SELECT customer_id, COUNT(*) AS order_count,
       SUM(amount) AS revenue
FROM orders
WHERE status = 'bezahlt'
GROUP BY customer_id
HAVING COUNT(*) >= 2
ORDER BY revenue DESC;

Erwartete Ausgabe: nur Kunde 1 mit Anzahl 2 und Umsatz 25. Erst WHERE wählt bezahlte Bestellungen, dann HAVING filtert Gruppen. Kunde 2 darf trotz hoher offener Bestellung nicht erscheinen.

Bitten Sie die Person, jede Abfrage in einem Test mit diesen Zeilen auszuführen und die Ausgabe zu vergleichen. SQL-Dialekte unterscheiden sich; für die drei Beispiele gilt die übliche Syntax von PostgreSQL und SQLite.

SQL-Kenntnis ersetzt keine fachliche Datenregel

Ein Interview zeigt begrenzte Aufgaben. Ihr Team legt Kennzahlendefinitionen, Datenzugriff und fachliche Entscheidungen fest. Division5 gleicht den Bedarf mit vorab geprüften Profilen ab. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Für alle Fachkräfte gilt eine 30-tägige Testphase; Umfang und Bedingungen halten Sie vor Beginn schriftlich fest. So läuft der Auswahlprozess ab.

Fachkräfte für Ihr Team ansehen.