Data Scientist Interviewfragen & Antworten

Beispielantwort

Unser Marketing-Team gab monatlich 200.000 Dollar für die Nutzergewinnung über 5 Kanäle aus, hatte aber kein klares Bild vom ROI pro Kanal. Ich entwickelte ein Multi-Touch-Attributionsmodell auf Basis von Markov-Ketten und analysierte Nutzerdaten aus 6 Monaten. Die Analyse zeigte, dass ein Kanal, auf den 30 % des Budgets entfielen, nur 8 % der Conversions lieferte, während organische Suche um den Faktor 3 unterbewertet wurde. Ich präsentierte die Ergebnisse dem CMO mit klaren Visualisierungen. Daraufhin wurden monatlich 60.000 Dollar vom schwachen Kanal umgeleitet, was die Gesamt-Conversion-Rate im Folgequartal um 22 % steigerte.

Beispielantwort

Ich entwickelte ein Kundensegmentierungsmodell, das empfahl, eine Treueprogramm-Stufe einzustellen. Der VP of Customer Success widersprach energisch: Diese Stufe enthielt die lautstärksten Fürsprecher des Unternehmens. Statt das Modell abstrakt zu verteidigen, tauchte ich tiefer in die Daten ein und stellte fest, dass der VP teilweise Recht hatte. Diese Kunden hatten hohe NPS-Werte, aber einen geringen Umsatzbeitrag. Ich überarbeitete die Analyse und bezog Lifetime-Value-Projektionen sowie empfehlungsgetriebene Referral-Umsätze ein. Das aktualisierte Modell zeigte, dass die Stufe erhaltenswert war, aber umstrukturiert werden musste. Wir senkten die Programmkosten um 40 %, während wir das Segment mit hoher Fürsprache behielten. Die wichtigste Erkenntnis: Modelle erfassen, was man misst, und manchmal weiß der Stakeholder, was man nicht misst.

Beispielantwort

Ich setzte ein Nachfrageprognosemodell für ein E-Commerce-Unternehmen ein, das beim Backtesting gut abschnitt, aber innerhalb von 3 Wochen nach dem Launch erheblich an Qualität verlor. Die Ursache war Data Drift: Die Trainingsdaten stammten aus stabilen Zeiträumen, doch wir gingen kurz vor einer großen Preisänderung eines Wettbewerbers live, die das Kaufverhalten verschob. Ich implementierte eine Monitoring-Pipeline, die Input-Feature-Verteilungen und Modellvorhersage-Verteilungen in Echtzeit verfolgte. Sobald der Drift einen Schwellenwert überschreitet, trainiert das Modell automatisch auf aktuellen Daten neu. Ich ergänzte außerdem einen Fallback auf einfache Heuristiken, wenn die Konfidenz unter einen Schwellenwert fällt. Die Erfahrung lehrte mich: Die Modellbereitstellung ist nur die halbe Arbeit. Monitoring und ein kontrolliertes Degradationsverhalten sind die andere Hälfte.

Beispielantwort

Das Führungsteam wollte verstehen, warum unsere Empfehlungsmaschine manchmal scheinbar zufällige Produkte vorschlug. Ich hatte 15 Minuten in der Vorstandssitzung. Statt kollaboratives Filtern mathematisch zu erklären, nutzte ich eine Analogie: 'Stellen Sie sich einen Buchhändler vor, der sich erinnert, was jeder Kunde gekauft hat. Wenn Sie hereinkommen, denkt er an Kunden, die Ihnen ähneln, und empfiehlt, was diese Personen mochten.' Dann zeigte ich 3 echte Nutzerbeispiele, bei denen die Empfehlungen sofort Sinn ergaben, sobald man die Ähnlichkeitslogik verstand. Ich zeigte auch 2 Fehlerfälle und erläuterte, wie wir sie mit inhaltsbasiertem Filtern beheben wollten. Der Vorstand genehmigte auf Basis dieser Präsentation ein zusätzliches Budget für das Empfehlungsteam.

Beispielantwort

Das hängt vom Problemkontext und der Kostenasymmetrie der Fehler ab. Bei einem Betrugserkennungsmodell, bei dem positive Fälle 0,1 % der Daten ausmachen, wähle ich zuerst die richtige Evaluierungsmetrik. Accuracy ist hier bedeutungslos, daher nutze ich Precision-Recall-AUC, F1 oder eine benutzerdefinierte Kostenfunktion, die falsch negative Ergebnisse nach ihrem Geschäftswert gewichtet. Datenseitig probiere ich SMOTE für synthetisches Oversampling, zufälliges Undersampling mit Ensemble-Methoden (wie EasyEnsemble) oder stratifiziertes Sampling. Modellseitig verwende ich Klassengewichte, um Fehlklassifikationen der Minderheitsklasse stärker zu bestrafen. Algorithmen wie XGBoost handhaben Ungleichgewichte gut mit scale_pos_weight. Ich ziehe auch Anomalieerkennung in Betracht: Wenn die Minderheitsklasse selten genug ist, kann die Problemstellung als Anomalieerkennung statt als Klassifikation besser funktionieren. Entscheidend ist die Evaluierung auf einem Hold-out-Set, das die reale Klassenverteilung widerspiegelt.

Beispielantwort

Bias ist der Fehler durch zu vereinfachende Annahmen: Ein lineares Modell, das eine quadratische Beziehung abbilden soll, wird unabhängig von den Trainingsdaten immer falsch liegen. Varianz ist der Fehler durch Empfindlichkeit gegenüber Schwankungen in den Trainingsdaten. Ein Polynom hohen Grades passt perfekt auf die Trainingsdaten, versagt aber bei neuen Daten. Der Kompromiss: Weniger Bias bedeutet typischerweise mehr Varianz und umgekehrt. In der Praxis beginne ich mit einem einfachen Modell (hoher Bias, niedrige Varianz) und erhöhe die Komplexität nur, wenn Validierungsmetriken es rechtfertigen. Regularisierungsmethoden (L1, L2, Dropout, Early Stopping) ermöglichen höhere Modellkapazität bei kontrollierter Varianz. Cross-Validation ist unverzichtbar, um einzuschätzen, wo man auf dem Bias-Varianz-Spektrum steht. Bei Ensembles: Bagging reduziert Varianz (Random Forest), Boosting reduziert Bias (XGBoost). Die Wahl treffe ich danach, ob mein Basismodell unter- oder überangepasst ist.

Beispielantwort

Zuerst definiere ich die Hypothese und die primäre Metrik. Für einen neuen Checkout-Flow könnte die Hypothese lauten: 'Der neue Ablauf steigert die Kaufabschlussrate.' Die primäre Metrik ist die Conversion-Rate, mit Leitplanken-Metriken wie Umsatz pro Sitzung und Seitenladezeit. Dann berechne ich die Stichprobengröße mit einer Power-Analyse. Für einen absoluten Lift von 2 % bei einer Baseline von 10 %, 80 % Power und 95 % Konfidenz benötige ich ungefähr 15.000 Nutzer pro Gruppe. Die Randomisierung erfolgt auf Nutzerebene, nicht auf Sitzungsebene, um inkonsistente Erfahrungen zu vermeiden. Der Test läuft mindestens einen vollständigen Geschäftszyklus, um Wochentags-Effekte zu erfassen. Für die Analyse nutze ich einen Zwei-Proportionen-Z-Test für die primäre Metrik und prüfe auf Neuheitseffekte, indem ich den Metrikverlauf über die Zeit betrachte. Ich segmentiere die Ergebnisse auch nach wichtigen Nutzerkohorten: Der neue Ablauf könnte Neukunden helfen, aber erfahrene Nutzer beeinträchtigen. Abschließend berücksichtige ich Korrekturen für mehrfache Vergleiche, wenn mehrere Metriken gleichzeitig getestet werden.

Beispielantwort

L1 (Lasso) addiert den Absolutwert der Gewichte zur Verlustfunktion, L2 (Ridge) addiert die quadrierten Gewichte. Der entscheidende praktische Unterschied: L1 treibt Gewichte auf genau null und führt damit automatische Feature-Selektion durch. L2 schrumpft Gewichte gegen null, ohne diesen Wert zu erreichen, und behält alle Features mit reduziertem Einfluss. L1 verwende ich, wenn ich vermute, dass viele Features irrelevant sind und ich ein spärliches, interpretierbares Modell möchte. Das ist typisch für hochdimensionale Datensätze wie Genomik oder Text. L2 setze ich ein, wenn die meisten Features ein gewisses Signal liefern und ich verhindern will, dass ein einzelnes Feature dominiert. Das ist üblich bei gut kuratierten Feature-Sets. Elastic Net kombiniert beide Ansätze und ist mein Standard, wenn ich unsicher bin: Es vereint die Spärlichkeit von L1 mit der Stabilität von L2 bei korrelierten Features. Die Regularisierungsstärke (Lambda) wird stets per Cross-Validation abgestimmt.

Beispielantwort

Zunächst würde ich dem Drang widerstehen, sofort mit der Modellierung zu beginnen. Die ersten 2-3 Tage verbringe ich mit explorativer Datenanalyse: Ich erstelle Profile für jede Spalte hinsichtlich fehlender Werte, Verteilungen, Ausreißern und Inkonsistenzen. Die Befunde dokumentiere ich und präsentiere sie dem Dateneigentümer, der oft Anomalien erklären kann, deren Untersuchung sonst wochenlang dauern würde. Bei fehlenden Werten hängt mein Vorgehen vom Mechanismus ab: Bei völlig zufälligem Fehlen funktioniert Imputation (Median für numerische, Modus für kategorische Werte oder modellbasierte Imputation). Bei nicht-zufälligem Fehlen ist das Fehlen selbst informativ und ich kodiere es als Feature. Ich richte Datenvalidierungsprüfungen ein (mit Great Expectations oder Ähnlichem), um künftige Qualitätsprobleme bereits bei der Datenerfassung zu erkennen. Erst nach der Etablierung eines sauberen, verstandenen Datensatzes beginne ich mit der Modellierung, und das erste Modell halte ich einfach, um eine Baseline zu etablieren, bevor ich Komplexität hinzufüge.

Beispielantwort

Ich würde weder einfach 'Nein' sagen noch still die Qualität kompromittieren. Stattdessen gliedere ich die Arbeit in Wertschichten. Bis Freitag könnte ich ein einfaches kollaboratives Filtermodell auf Basis von Nutzer-Item-Interaktionen bereitstellen. Es wird nicht perfekt sein, aber besser als die aktuellen zufälligen Vorschläge. Das präsentiere ich als Phase 1 mit klar dokumentierten Einschränkungen. Phase 2 (Woche 2-3) würde inhaltsbasierte Features hinzufügen und das Cold-Start-Problem für neue Nutzer lösen. Für jede Phase lege ich dar, welche Leistungsverbesserung mit geschätzten Metriken zu erwarten ist. Dieser Ansatz liefert sofort echten Mehrwert und setzt gleichzeitig realistische Erwartungen für die vollständige Lösung. Ich würde auch darauf hinweisen, dass ein hastiges Deployment des vollständigen Modells bis zum Freitagstermin bedeuten würde, Offline-Evaluierung und A/B-Testing zu überspringen. Das hieße, etwas auszuliefern, ohne zu wissen, ob es den Nutzern tatsächlich hilft.

Beispielantwort

Das würde ich sofort melden: nicht nach dem Deployment, nicht in einer Retrospektive. Ich dokumentiere die Bedenken mit Belegen für die Proxy-Korrelation (z. B. Postleitzahl-zu-Demografie-Zuordnung) und präsentiere sie sowohl dem technischen Lead als auch einem Geschäftsstakeholder. Dann teste ich die Modellleistung mit und ohne dieses Feature. Oft hat das Entfernen des Proxy-Features minimale Auswirkungen auf die Gesamtgenauigkeit, reduziert aber die diskriminierende Wirkung erheblich. Wenn das Feature wirklich für die Leistung notwendig ist, erkunde ich fairnessgerechte Modellierungstechniken: Equalized-Odds-Post-Processing, adversariales Debiasing oder Kalibrierung über geschützte Gruppen hinweg. Ich empfehle außerdem, Fairness-Metriken als Teil der Modellevaluierungspipeline einzuführen: nicht nur Genauigkeit, sondern demografische Parität und gleichmäßige Chancengleichheit. Das Geschäftsrisiko eines diskriminierenden Modells (rechtlich, reputational, ethisch) überwiegt den marginalen Genauigkeitsgewinn bei weitem.

Beispielantwort

'Fühlt sich nicht richtig an' nehme ich ernst: Domain-Experten entdecken oft Probleme, die Metriken übersehen. Zuerst frage ich nach konkreten Beispielen für Vorhersagen, die sich falsch anfühlten, und suche nach Mustern. Häufige Ursachen: Das Modell optimiert auf die falsche Metrik (hohe Genauigkeit, aber schlechte Kalibrierung), das Testset spiegelt die reale Verteilung nicht wider, oder das Modell erfasst statistische Muster, die die Geschäftslogik verletzen. Ich untersuche die Modellvorhersagen für die spezifischen Beispiele mit SHAP oder LIME, um einzelne Vorhersagen zu erklären. Wenn das Modell technisch korrekt ist, aber Domain-Erwartungen verletzt, müssen möglicherweise Geschäftsregeleinschränkungen hinzugefügt oder die Verlustfunktion angepasst werden, um bestimmte Fehlertypen stärker zu bestrafen. Ich prüfe auch auf Data Leakage: Ein verdächtig hoher Testscore in Kombination mit geschäftlicher Skepsis ist ein klassisches Leakage-Signal.