Die SQL-Metriken, die Interviewern wirklich wichtig sind (aus echten Vorstellungsgesprächen)

Nach einigen SQL-Interviews liegt die Vermutung nahe, dass jedes Unternehmen etwas anderes testet. Nach 11 Interviews konnte ich diese Vermutung jedoch widerlegen. Trotz der Unterschiede zwischen den Unternehmen und Formaten tauchten immer wieder die gleichen Metrikfragen auf. Dieser Artikel fasst zusammen, was mir am häufigsten aufgefallen ist und was diese Muster über die tatsächliche Funktionsweise von SQL-Interviews aussagen.

Zwischen November 2023 und April 2025 nahm ich an 11 Vorstellungsgesprächen für Datenanalysten teil, die technische SQL-Tests umfassten. Während die Unternehmen und Formate variierten, folgten die SQL-Fragen selbst klaren und wiederholbaren Mustern. Unabhängig von der Unternehmensgröße oder Branche tauchten immer wieder die gleichen Arten von Metriken auf.

In diesem Artikel analysiere ich SQL-Interviewfragen aus diesen Vorstellungsgesprächen und kategorisiere sie anhand der SQL-Metrikmuster , die in früheren Artikeln vorgestellt wurden, darunter die Reihe „Sales Growth Dataset Exploration ”. Anstatt Metriken innerhalb eines einzelnen Datensatzes zu untersuchen, konzentriert sich dieser Artikel darauf, wie sich SQL-Interviewfragen um bestimmte Metriktypen gruppieren.

Das Ziel dieses Artikels ist klar: Ich möchte zeigen, welche SQL-Metriken in realen Vorstellungsgesprächen am häufigsten vorkommen, damit Sie Ihre Vorbereitung effektiver priorisieren können. Anstatt zu versuchen, jedes mögliche SQL-Thema abzudecken, zeigt diese Aufschlüsselung, wo die Lernzeit tendenziell den höchsten Ertrag bringt. Das ist auch der Grund, warum strukturierte SQL-Übungen, die sich auf reale Berichtsprobleme konzentrieren – wie die Übungen in den Kursen „LearnSQL.de“ –, tendenziell besser auf das abgestimmt sind, was in Vorstellungsgesprächen tatsächlich abgefragt wird, als Ad-hoc- oder puzzleartige SQL-Vorbereitungen.

Dabei gehe ich auch darauf ein, wie SQL in Vorstellungsgesprächen getestet wird, wie Antworten bewertet werden und warum bestimmte Metrikmuster weitaus häufiger auftreten als andere. Dies ist kein Leitfaden für Vorstellungsgesprächsstrategien nach Unternehmen oder Branche und enthält keine genauen Fragen oder Firmennamen. Der Schwerpunkt liegt auf wiederkehrenden Mustern und darauf, was sie über die Kernkompetenzen in SQL verraten, die Interviewer immer wieder testen.

Wenn Sie sich auf SQL-lastige Vorstellungsgespräche für Datenanalysten vorbereiten und sich auf das konzentrieren möchten, was in der Praxis tatsächlich vorkommt, finden Sie in diesem Artikel eine Zusammenfassung der Muster, auf die ich immer wieder gestoßen bin, und der Lehren, die sich daraus ziehen lassen.

SQL-Testmethoden, die in Vorstellungsgesprächen vorkommen

In den 11 Vorstellungsgesprächen wurde SQL anhand von drei unterschiedlichen Testformaten bewertet. Die zugrunde liegenden SQL-Kenntnisse waren zwar ähnlich, aber das Format des Tests hatte einen erheblichen Einfluss darauf, wie die Antworten bewertet wurden und worauf die Interviewer offenbar besonderen Wert legten.

Zeitlich begrenzte Online-Portale

Das erste Format war ein zeitlich begrenztes Online-Portal, das in der Regel auf Plattformen wie HackerRank gehostet wurde. Diese Tests waren auf etwa 20 bis 50 Minuten begrenzt und bestanden in der Regel aus ein oder zwei SQL-Fragen. Da die Umgebung standardisiert ist und keine Unterstützung bietet, sind die Fragen in der Regel einfacher in ihrer Struktur, aber streng in ihrer Ausführung. Korrektheit und Geschwindigkeit sind am wichtigsten, und die Lösungen werden in der Regel mit „bestanden“ oder „nicht bestanden“ bewertet.

Live-SQL-Interviews mit einer gemeinsamen IDE

Das zweite Format war ein Live-SQL-Interview, das in einer gemeinsamen IDE während einer virtuellen Sitzung durchgeführt wurde. In diesen Interviews durfte ich oft SQL schreiben, ohne es auszuführen, wodurch die Bedeutung der exakten Syntax verringert und der Fokus auf logische Korrektheit und Argumentation verlagert wurde. Da Syntaxfehler weniger schwerwiegend waren, neigten die Interviewer dazu, mehr Fragen zu stellen oder Unklarheiten einzuführen, wobei sie manchmal auf eine erste Aufforderung noch weitere Fragen folgten. Die Bewertung in diesem Format war selten binär, sondern spiegelte stattdessen wider, wie klar die Argumentation kommuniziert wurde.

SQL-Aufgaben zum Mitnehmen

Das dritte Format war eine SQL-Aufgabe für zu Hause, die in der Regel als Dokument mit Schemata, Anweisungen zur Tabellenerstellung und mehreren Fragen geliefert wurde. Für diese Aufgaben wurden in der Regel ein bis zwei Tage Zeit zur Verfügung gestellt, und sie umfassten eine größere Anzahl von Fragen, oft fünf bis zehn. Die einzelnen Fragen waren zwar nicht immer konzeptionell schwieriger, aber sie waren detaillierter und zeitaufwändiger. Wie bei Live-IDE-Interviews wurden auch die Hausaufgaben subjektiv bewertet, wobei Struktur, Erklärung und Annahmen eine größere Rolle bei der abschließenden Bewertung spielten.

Bei allen drei Formaten prägte die Testmethode direkt, was unter „guter Leistung” zu verstehen war. Zeitlich begrenzte Portale belohnten schnelle und präzise Lösungen. Bei Live- und Hausaufgabenformaten wurde zusätzliches Gewicht darauf gelegt, wie die Antworten strukturiert, erklärt und an vage oder unvollständige Problemstellungen angepasst waren. Dieser Unterschied im Bewertungskontext wird wichtig, wenn es darum geht, zu interpretieren, welche SQL-Metrikmuster in Interviews am häufigsten vorkommen.

Wie SQL-Antworten bewertet wurden

Die Art und Weise, wie SQL-Antworten bewertet wurden, variierte je nach Testformat erheblich. Bei zeitlich begrenzten Portalbewertungen erfolgte die Benotung in der Regel binär. Die Abfragen lieferten entweder die erwartete Ausgabe innerhalb der Beschränkungen der Plattform oder nicht. Es gab wenig Spielraum für Teilpunkte, alternative Ansätze oder Erklärungen. In diesen Settings überwogen Korrektheit und Geschwindigkeit alle anderen Überlegungen.

Live-SQL-Vorstellungsgespräche und Hausaufgaben wurden anders bewertet. In beiden Fällen wurden die Antworten selten einfach als richtig oder falsch bewertet. Stattdessen erfolgte die Bewertung anhand eines Spektrums, das berücksichtigte, wie die Lösung aufgebaut war, wie mit Annahmen umgegangen wurde und wie klar die Argumentation kommuniziert wurde. Die Interviewer achteten oft auf Signale, die über die endgültige Abfrage hinausgingen, z. B. ob der Kandidat die Datengranularität verstanden hatte, mit Randfällen umgegangen war oder einen Ansatz gewählt hatte, der angemessen skalierbar war.

In mehreren Interviews stieß ich auf Bewertungsschemata, die eher einer informellen Benotung als einer strengen Bestehens- oder Nichtbestehensentscheidung ähnelten. Eine Lösung, die die grundlegenden Anforderungen erfüllte, konnte als akzeptabel angesehen werden, während für eine bessere Leistung ein alternativer Ansatz demonstriert, Kompromisse diskutiert oder potenzielle Probleme mit den Daten identifiziert werden mussten. In einigen Fällen konnten zwei Kandidaten zu korrekten Ergebnissen gelangen, wurden jedoch unterschiedlich bewertet, je nachdem, wie gut sie ihre Entscheidungen erklärten.

Ein weiterer Faktor war, dass die SQL-Leistung nicht immer isoliert bewertet wurde. Einige Interviewprozesse umfassten mehrere technische Runden, und die endgültigen Entscheidungen wurden über alle Runden hinweg getroffen. Ein starkes SQL-Interview konnte durch eine schwächere Leistung in anderen Bereichen ausgeglichen werden, und umgekehrt. Aus diesem Grund war es oft schwierig zu bestimmen, ob eine Ablehnung speziell die SQL-Leistung oder das Gesamtergebnis des Interviews widerspiegelte.

Zusammengenommen erklären diese Bewertungsunterschiede, warum das Bestehen oder Nichtbestehen allein kein zuverlässiges Kriterium für die Beurteilung der SQL-Interviewleistung ist. Sie helfen auch zu verdeutlichen, warum wiederkehrende SQL-Metrikmuster für die Untersuchung nützlicher sind als einzelne Fragen. Im nächsten Abschnitt wird das Metrikmuster-Framework vorgestellt, das zur Kategorisierung der Interviewfragen in dieser Analyse verwendet wurde.

Kurze Zusammenfassung des SQL-Metrikmuster-Frameworks

In dieser Analyse habe ich die SQL-Interviewfragen anhand des SQL-Metrikmuster-Frameworks kategorisiert, das in einem früheren Artikel über metrikgesteuerte SQL-Problemlösung vorgestellt wurde. Dieses Framework gruppiert SQL-Fragen nach der Art der berechneten Metrik und nicht nach bestimmten SQL-Funktionen oder -Features.

Die in diesem Artikel verwendeten Muster sind:

• KPI – Einwertige Metriken, die die Gesamtleistung zusammenfassen
• Aufschlüsselung – Metriken, die nach einer oder mehreren Dimensionen segmentiert sind
• Verhältnis – Metriken, die durch Division zweier verwandter Aggregate gebildet werden
• Rang – geordnete Metriken innerhalb einer Gruppe
• Kumulativ/Laufende Summe – Metriken, die sich im Laufe der Zeit ansammeln
• Gleitender Durchschnitt – über ein rollierendes Fenster geglättete Kennzahlen
• Prozentuale Veränderung/Wachstum – Metriken, die Werte über verschiedene Zeiträume hinweg vergleichen

Durch die Gruppierung der Fragen nach Metrikmustern lässt sich leichter erkennen, was in Interviews durchgängig geprüft wird: nicht Syntax oder isolierte SQL-Tricks, sondern die Fähigkeit, Geschäftsmetriken zu definieren, zu berechnen und zu interpretieren.

Eine vollständige Erläuterung des Frameworks, einschließlich Beispielen und häufigen Fallstricken, finden Sie im Originalartikel: Umsatzdaten analysieren mit dem Spickzettel für Datenanalysten.

Mit diesem Rahmenwerk wird im nächsten Abschnitt berichtet, wie oft jedes Metrikmuster in den Interviews aufgetreten ist.

Ergebnisse: Stichprobe der Interviews und Verteilung der Fragen

Diese Analyse basiert auf 11 Datenanalysten-Interviews, die zwischen November 2023 und April 2025 durchgeführt wurden und technische SQL-Fragen enthielten. Es wurden nur Interviews mit expliziter SQL-Bewertung berücksichtigt. In diesen Interviews wurden mehrere SQL-Fragen gestellt, sodass insgesamt ein Pool entstand, der groß genug war, um klare Wiederholungen bei den Metriktypen zu beobachten.

Verteilung der Interviews nach Unternehmensgruppen

Die Interviews umfassten eine Mischung aus Unternehmen unterschiedlicher Größe und aus verschiedenen Bereichen. Um eine Übergewichtung einzelner Unternehmen zu vermeiden, wurden die Interviews nach Kategorien gruppiert.

Gesamtzahl der Interviews – 11

Obwohl die Stichprobe begrenzt und geografisch konzentriert ist, deutet die Wiederholung von SQL-Fragetypen in verschiedenen Unternehmensgruppen darauf hin, dass die beobachteten Muster nicht auf eine einzelne Kategorie beschränkt sind.

SQL-Interviewfragen nach Metrikmuster

Jede SQL-Frage wurde anhand des zuvor beschriebenen SQL-Metrikmuster-Frameworks kategorisiert. Die folgende Tabelle zeigt, wie häufig jedes Muster in den Interviews vorkam.

Die Verteilung zeigt eine starke Konzentration auf eine kleine Anzahl von Metrikmustern, wobei Fragen zu Aufschlüsselungen und Verhältnissen weitaus häufiger auftraten als alle anderen. Fortgeschrittenere zeitbasierte und fensterbasierte Metriken kamen in dieser Interviewreihe selten vor.

Im nächsten Abschnitt werden diese Ergebnisse interpretiert und erklärt, warum bestimmte Metrikmuster in SQL-Interviews dominieren.

Interpretation: Warum bestimmte Metrikmuster in SQL-Interviews dominieren

Die Verteilung der SQL-Metrikmuster in diesen Interviews zeigt eine klare Konzentration auf Fragen zu Aufschlüsselungen und Verhältnissen. Dies ist kein Zufall. Diese beiden Muster bilden die Grundlage dafür, wie Unternehmen analytische Fragen stellen und wie Datenanalysten über die Leistung argumentieren sollen.

Aufschlüsselungsfragen kommen am häufigsten vor, da sie testen, ob ein Kandidat von einer übergeordneten Metrik zu einer segmentierten Ansicht übergehen kann. In der Praxis bedeutet dies, dass man verstehen muss, wie man die richtige Datengranularität definiert, Verknüpfungen ohne Aufblähung der Ergebnisse anwendet und Metriken nach relevanten Dimensionen wie Zeit, Region, Produkt oder Benutzertyp gruppiert. Eine korrekte Aufschlüsselungsabfrage zeigt, dass der Kandidat nicht nur die SQL-Syntax versteht, sondern auch weiß, wie sich Metriken verhalten, wenn sie über Dimensionen hinweg aufgeschlüsselt werden.

Verhältnisfragen tauchen aus ähnlichen Gründen häufig auf. Verhältnisse erfordern eine sorgfältige Abstimmung zwischen Zähler und Nenner, konsistente Filterung und das Bewusstsein für Randfälle wie Division durch Null oder fehlende Daten. Aus Sicht des Vorstellungsgesprächs zeigen Verhältnismetriken schnell, ob ein Kandidat versteht, was eine Metrik darstellt, oder ob er lediglich Spalten mechanisch aggregiert. Selbst wenn die SQL relativ kurz ist, ist die dahinterstehende Argumentation oft nicht einfach.

KPI- und Rangfragen kommen seltener vor, aber dennoch regelmäßig. Einwertige KPIs testen, ob ein Kandidat eine Metrik klar definieren und korrekt aggregieren kann, während Rangfragen Konzepte der Reihenfolge und Partitionierung einführen, die im Berichtswesen üblich, aber für die Konstruktion von Kernmetriken zweitrangig sind.

Fortgeschrittenere Muster wie kumulative Summen, gleitende Durchschnitte und prozentuale Veränderungen kommen in dieser Interviewreihe weitaus seltener vor. Diese Muster basieren in der Regel auf Fensterfunktionen und Zeitreihenlogik, die zwar wichtige Fähigkeiten sind, aber für die meisten täglichen Berichterstattungsaufgaben von Datenanalysten nicht von zentraler Bedeutung sind. Ihre geringere Häufigkeit deutet darauf hin, dass in Interviews die Korrektheit und Klarheit der grundlegenden Metriklogik gegenüber fortgeschrittenen SQL-Funktionen priorisiert wird.

Insgesamt zeigt die Verteilung der Muster, dass SQL-Interviews den Schwerpunkt eher auf die Definition, Segmentierung und den Vergleich von Metriken legen als auf syntaktische Komplexität. Die Interviewer scheinen SQL als Mittel zu nutzen, um zu beurteilen, wie die Kandidaten über Daten und geschäftliche Fragen denken, und nicht, wie viele fortgeschrittene SQL-Techniken sie isoliert anwenden können.

Schlussfolgerungen

Diese Analyse basiert auf einer begrenzten Stichprobe von 11 Vorstellungsgesprächen mit Datenanalysten aus der Bay Area, aber die Konzentration der Fragetypen war konsistent genug, um klare Prioritäten aufzuzeigen.

Aufschlüsselungs- und Verhältnisfragen dominierten die Interviewreihe. Die Vorbereitungszeit sollte am besten darauf verwendet werden, diese richtig zu beantworten: Metriken in der richtigen Granularität definieren, Tabellen ohne Aufblähung der Ergebnisse verknüpfen und Daten so gruppieren, dass sie der geschäftlichen Fragestellung entsprechen. Diese Fähigkeiten werden in grundlegenden, auf Berichterstellung ausgerichteten Kursen wie „SQL für Anfänger”, „Standard-SQL-Funktionen” und „SQL Basic Reporting” auf LearnSQL.de vertieft, in denen Abfragen eher auf realen Metriken als auf isolierter Syntax basieren.

Fortgeschrittene Metrikmuster – wie laufende Summen, gleitende Durchschnitte oder Wachstumsberechnungen – kamen weitaus seltener vor. Sie sind nützliche Ergänzungen, insbesondere für berichtslastige Aufgaben, ersetzen jedoch keine soliden Grundlagen. Kurse zu Themen wie „Fensterfunktionen“, „Rekursive Abfragen“ und „SQL GROUP BY Extensions“ auf LearnSQL.de sind am sinnvollsten, wenn die Muster „Breakdown“ und „Ratio“ bereits fest verankert sind.

Insgesamt deuten die Ergebnisse darauf hin, dass SQL-Vorstellungsgespräche eher die Klarheit der metrischen Argumentation als die Breite der SQL-Funktionen belohnen. Eine Vorbereitung, die den Schwerpunkt auf die Erstellung von Kernmetriken und die korrekte Verwendung von Joins legt, entspricht am ehesten dem, was in realen Vorstellungsgesprächen abgefragt wird.

Zusammenfassung

In diesem Artikel wurden SQL-Interviewfragen aus 11 echten Datenanalysten-Interviews analysiert, um herauszufinden, welche Metrikmuster in der Praxis am häufigsten vorkommen. Anstatt sich auf einzelne SQL-Techniken zu konzentrieren, wurden die Fragen nach der Art der berechneten Metrik gruppiert, wodurch sich eine klare Konzentration auf Aufschlüsselungs- und Verhältnis-Muster über Unternehmen und Interviewformate hinweg zeigte.

Die Ergebnisse deuten darauf hin, dass in SQL-Vorstellungsgesprächen durchweg mehr Wert auf die Erstellung von Metriken und die Berichtslogik gelegt wird als auf fortgeschrittene SQL-Funktionen. Die Interviewer scheinen diese Fragen zu nutzen, um zu beurteilen, ob die Kandidaten Metriken korrekt definieren, sinnvoll segmentieren und Vergleiche auf eine Weise begründen können, die die tatsächliche analytische Arbeit widerspiegelt.

Das SQL-Metrikmuster-Framework und das Data Analyst Cheat Sheet bieten eine strukturierte Herangehensweise an diese Probleme, indem sie SQL-Techniken, Metrikdefinitionen und den geschäftlichen Kontext miteinander kombinieren. Für Kandidaten, die diese Fähigkeiten wiederholt mit verschiedenen Datensätzen und Schwierigkeitsgraden üben möchten, ist der Zugang zu einem breiten, strukturierten Kursangebot wichtiger als das Springen zwischen unzusammenhängenden Ressourcen. Hier passt eine Option wie der Alle für immer SQL Plan natürlich gut, da er das langfristige Üben sowohl grundlegender als auch fortgeschrittener Metrikmuster ermöglicht, ohne dass eine Optimierung für die Auswahl einzelner Kurse erforderlich ist.

Dieser Artikel konzentriert sich bewusst auf Kernmuster und nicht auf Interviewstrategien. Eine tiefergehende Analyse könnte die Fragen nach Testformat weiter aufschlüsseln oder gemeinsame Untermuster innerhalb jedes Metriktyps untersuchen, aber die hier vorgestellten Ergebnisse lassen bereits eine klare Schlussfolgerung zu: Die Beherrschung der grundlegenden Metriklogik bietet den größten Nutzen für die Vorbereitung auf SQL-Interviews.