Einführung
Bei der Lösung von Datenproblemen, die häufig in Vorstellungsgesprächen gestellt werden, fällt auf, dass die „Form“ des Datensatzes stillschweigend den Programmierstil bestimmt. Eine Zeitreihe führt dazu, dass man Fensterfunktionen verwendet. Ein Sternschema zwingt zu JOIN-Ketten und GROUP BY. Eine Aufgabe in pandas mit zwei DataFrames verlangt förmlich nach .merge() und isin().
Dieser Artikel macht diese Intuition messbar. Anhand einer Reihe repräsentativer SQL- und pandas-Probleme werden grundlegende Merkmale der Code-Struktur identifiziert (Nutzung von Common Table Expressions (CTEs), Häufigkeit von Fensterfunktionen, gängige pandas-Techniken) und es wird veranschaulicht, welche Elemente vorherrschen und warum dies der Fall ist.
Warum die Datenstruktur Ihren Programmierstil verändert
Datenprobleme sind nicht nur logische Herausforderungen, sondern vielmehr Einschränkungen, die in Tabellen verpackt sind:
- Zeilen, die von anderen Zeilen abhängen (Zeit, Rang, „Vorheriger Wert“)
Wenn die Antwort jeder Zeile von benachbarten Zeilen abhängt (z. B. der Temperatur von gestern, der vorherigen Transaktion, laufende Summen), neigen die Lösungen dazu, Fensterfunktionen wie LAG(), LEAD(), ROW_NUMBER() und DENSE_RANK() zu verwenden.
Betrachten Sie beispielsweise die Tabellen dieser Interviewfrage:
Das Ergebnis jedes Kunden an einem bestimmten Tag kann nicht isoliert bestimmt werden. Nach der Aggregation der Bestellkosten auf der Ebene Kunde-Tag muss jede Zeile im Verhältnis zu anderen Kunden am gleichen Datum bewertet werden, um zu bestimmen, welcher Gesamtbetrag der höchste ist.
Da die Antwort für eine Zeile davon abhängt, wie sie im Vergleich zu ihren Mitbewerbern innerhalb einer Zeitpartition eingestuft wird, führt diese Datenstruktur natürlich zu Fensterfunktionen wie RANK() oder DENSE_RANK() anstelle einfacher Aggregationen.
- Mehrere Tabellen mit Rollen (Dimensionen vs. Fakten)
Wenn eine Tabelle Entitäten beschreibt und eine andere Ereignisse, tendieren die Lösungen zu JOIN + GROUP BY-Mustern (SQL) oder .merge() + .groupby()-Muster (pandas).
In diesem Beispiel sind die Datentabellen wie folgt:
Da die Entitätsattribute (Benutzer und Kontostatus) und die Ereignisdaten (Downloads) getrennt sind, muss die Logik zunächst mit JOINs kombiniert werden, bevor eine sinnvolle Aggregation (genau die Dimension) stattfinden kann. Dieses Faktormuster führt zu JOIN + GROUP BY-Lösungen.
- Kleine Ausgaben mit Ausschlusslogik (Anti-Join-Muster)
Probleme, die fragen „Wer hat nie X gemacht?“, werden oft zu LEFT JOIN … IS NULL / NOT EXISTS (SQL) oder ~df[‚col‘].isin(…) (pandas).
Was wir messen: Merkmale der Code-Struktur
Um den „Programmierstil“ über verschiedene Lösungen hinweg zu vergleichen, ist es nützlich, eine begrenzte Anzahl von beobachtbaren Merkmalen zu identifizieren, die aus SQL-Text und Python-Code extrahiert werden können.
Obwohl diese möglicherweise keine perfekten Indikatoren für die Qualität der Lösung (z. B. Richtigkeit oder Effizienz) sind, können sie als vertrauenswürdige Signale dafür dienen, wie Analysten mit einem Datensatz umgehen.
- SQL-Merkmale, die wir messen
- Pandas-Merkmale, die wir messen
Welche Konstrukte am häufigsten vorkommen
Um über anekdotische Beobachtungen hinauszugehen und diese Muster zu quantifizieren, ist eine einfachere und konsistentere Methode erforderlich, um strukturelle Signale direkt aus Lösungscode abzuleiten.
Als konkreter Anker für diesen Workflow haben wir alle Bildungsfragen auf der StrataScratch-Plattform verwendet.
Im unten gezeigten Ergebnis ist „Gesamtvorkommen“ die rohe Zählung der Häufigkeit, mit der ein Muster in allen Codes erscheint. Eine einzelne Frage könnte JOIN dreimal verwenden, sodass diese drei alle zusammengezählt werden. „Fragen, die verwenden“ bezieht sich darauf, wie viele unterschiedliche Fragen mindestens ein Vorkommen dieses Merkmals haben (d. h. ein binäres „verwendet / nicht verwendet“ pro Frage).
Diese Methode reduziert jede Lösung auf eine begrenzte Anzahl von beobachtbaren Merkmalen, die es uns ermöglichen, Programmierstile konsistent und reproduzierbar über Probleme hinweg zu vergleichen und die Datenstruktur direkt mit dominierenden Konstrukten zu verknüpfen.
- SQL-Merkmale
- Pandas-Merkmale (Python-Lösungen)
Häufigkeitsmerkmale in SQL
Fensterfunktionen steigen in „höchsten pro Tag“ und auf Rangfreundlichkeit ausgerichteten Aufgaben.
In dieser Interviewfrage werden wir beispielsweise gebeten, einen täglichen Gesamtbetrag pro Kunde zu berechnen und dann das höchste Ergebnis für jedes Datum auszuwählen, einschließlich der Bindungen. Dies ist eine Anforderung, die natürlich zu Fensterfunktionen wie RANK() oder DENSE_RANK() führt, segmentiert nach Tag.
Die Lösung sieht wie folgt aus:
WITH customer_daily_totals AS (
SELECT
o.cust_id,
o.order_date,
SUM(o.total_order_cost) AS total_daily_cost
FROM orders o
WHERE o.order_date BETWEEN ‚2019-02-01‘ AND ‚2019-05-01‘
GROUP BY o.cust_id, o.order_date
),
ranked_daily_totals AS (
SELECT
cust_id,
order_date,
total_daily_cost,
RANK() OVER (
PARTITION BY order_date
ORDER BY total_daily_cost DESC
) AS rnk
FROM customer_daily_totals
)
SELECT
c.first_name,
rdt.order_date,
rdt.total_daily_cost AS max_cost
FROM ranked_daily_totals rdt
JOIN customers c ON rdt.cust_id = c.id
WHERE rdt.rnk = 1
ORDER BY rdt.order_date;
Dieser zweistufige Ansatz – zuerst aggregieren, dann innerhalb jedes Datums rangieren – zeigt, warum Fensterfunktionen ideal für „höchste pro Gruppe“-Szenarien sind, in denen Bindungen aufrechterhalten werden müssen, und warum grundlegende GROUP BY-Logik unzureichend ist.
CTE-Nutzung steigt bei Fragen mit gestufter Berechnung
Eine Common Table Expression (CTE) (oder mehrere CTEs) hält jeden Schritt lesbar und erleichtert die Validierung von Zwischenergebnissen.
Diese Struktur spiegelt auch wider, wie Analysten denken: Sie trennt die Datenaufbereitung von der Geschäftlogik, sodass die Abfrage einfacher zu verstehen, zu beheben und anzupassen ist, wenn sich die Anforderungen ändern.
JOIN plus Aggregation wird zum Standard bei Multi-Table-Geschäftsmetriken
Wenn Maße in einer Tabelle und Dimensionen in einer anderen leben, können JOIN-Klauseln oft nicht vermieden werden. Nach dem JOIN sind GROUP BY und bedingte Summen (SUM(CASE WHEN … THEN … END)) in der Regel der kürzeste Weg.
Methoden-Highlights in Pandas
.merge() erscheint immer dann, wenn die Antwort von mehr als einer Tabelle abhängt.
Diese Interviewfrage ist ein gutes Beispiel für das pandas-Muster. Wenn Fahrten und Zahlungs- oder Rabattlogik über Spalten und Tabellen verteilt sind, kombiniert man typischerweise zuerst die Daten, um dann zu zählen oder zu vergleichen.
import pandas as pd
orders_payments = lyft_orders.merge(lyft_payments, on=’order_id‘)
orders_payments = orders_payments[(orders_payments[‚order_date‘].dt.to_period(‚M‘) == ‚2021-08‘) & (orders_payments[‚promo_code‘] == False)]
grouped_df = orders_payments.groupby(‚city‘).size().rename(’n_orders‘).reset_index()
result = grouped_df[grouped_df[’n_orders‘] == grouped_df[’n_orders‘].max()][‚city‘]
Nachdem die Tabellen zusammengeführt wurden, reduziert sich der Rest der Lösung auf einen vertrauten .groupby()- und Vergleichsschritt, was unterstreicht, wie die anfängliche Tabellenzusammenführung die nachgelagerte Logik in pandas vereinfachen kann.
Warum diese Muster immer wieder auftreten
- Zeitbasierte Tabellen erfordern oft Fensterlogik
Wenn ein Problem auf Summen „pro Tag“ verweist, Vergleiche zwischen Tagen oder die Auswahl des höchsten Wertes für jedes Datum erfordert, ist normalerweise eine geordnete Logik erforderlich. Aus diesem Grund sind Rangfunktionen mit OVER häufig, insbesondere wenn Bindungen aufrechterhalten werden müssen.
- Mehrstufige Geschäftsregeln profitieren von Staging
Einige Probleme mischen Filterregeln, Joins und berechnete Metriken. Es ist möglich, alles in einer einzigen Abfrage zu schreiben, aber dies erhöht die Schwierigkeit des Lesens und Debuggens. CTEs helfen dabei, dies zu trennen, indem sie Anreicherung von Aggregation auf eine Weise trennen, die einfacher zu validieren ist und mit dem Premium- vs. Freemium-Modell übereinstimmt.
- Multi-Table-Fragen erhöhen natürlich die JOIN-Dichte
Wenn eine Metrik von Attributen abhängt, die in einer anderen Tabelle gespeichert sind, ist ein JOIN erforderlich. Sobald die Tabellen kombiniert sind, sind gruppierte Zusammenfassungen der natürliche nächste Schritt. Diese Gesamtstruktur zeigt sich wiederholt in StrataScratch-Fragen, die Ereignisdaten mit Entitätsprofilen mischen.
Praktische Erkenntnisse für schnellere, sauberere Lösungen
- Wenn die Ausgabe von geordneten Zeilen abhängt, erwarten Sie Fensterfunktionen wie ROW_NUMBER() oder DENSE_RANK().
- Wenn die Frage wie „Berechne A, dann berechne B aus A“ klingt, verbessert ein WITH-Block normalerweise die Klarheit.
- Wenn der Datensatz über mehrere Entitäten verteilt ist, planen Sie frühzeitig JOINs und entscheiden Sie Ihre Gruppierungsschlüssel, bevor Sie die endgültige Auswahl schreiben.
- In pandas behandeln Sie .merge() als Standard, wenn die Logik mehrere DataFrames umfasst, und bauen Sie die Metrik dann mit .groupby() und sauberem Filtern auf.
Fazit
Der Programmierstil folgt der Struktur: Zeitbasierte und „höchste pro Gruppe“-Fragen neigen dazu, Fensterfunktionen zu produzieren. Mehrstufige Geschäftsregeln führen zu CTEs.
Multi-Table-Metriken erhöhen die JOIN-Dichte, und pandas spiegelt diese Bewegungen durch .merge() und .groupby() wider.
Wichtiger ist, dass das frühzeitige Erkennen dieser strukturellen Muster Ihren Ansatz für ein neues Problem erheblich verändern kann. Anstatt von Syntax oder auswendig gelernten Tricks auszugehen, können Sie vom Datensatz selbst aus argumentieren: Ist dies ein Maximum pro Gruppe? Eine gestufte Geschäftsregel? Eine Multi-Table-Metrik?
Dieser Perspektivwechsel ermöglicht es Ihnen, den Hauptrahmen vorherzusehen, bevor Sie irgendeinen Code schreiben. Letztendlich führt dies zu schnelleren Lösungsskizzen, einfacherer Validierung und mehr Konsistenz zwischen SQL und pandas, da Sie auf die Datenstruktur reagieren und nicht nur auf den Text der Frage.
Sobald Sie lernen, die Form des Datensatzes zu erkennen, können Sie das dominante Konstrukt frühzeitig vorhersagen. Das macht Lösungen schneller zu schreiben, einfacher zu debuggen und konsistenter über neue Probleme hinweg.
Nate Rosidi ist Datenwissenschaftler und in der Produktstrategie tätig. Er ist auch Dozent für Analytik und Gründer von StrataScratch, einer Plattform, die Datenwissenschaftlern hilft, sich mit echten Interviewfragen von Top-Unternehmen auf Vorstellungsgespräche vorzubereiten. Nate schreibt über die neuesten Trends auf dem Arbeitsmarkt, gibt Interviewtipps, teilt Projekte zur Datenwissenschaft und behandelt alles rund um SQL.
Erhalten Sie das KOSTENLOSE E-Book ‚KDnuggets Artificial Intelligence Pocket Dictionary‘ zusammen mit dem führenden Newsletter zu Data Science, Machine Learning, KI & Analytics direkt in Ihr Postfach.
„`
Bildquelle: ai-generated-gemini
