Deutsch

Ein Tag im Leben eines Data Scientists

Es ist 8:07 Uhr. Ihr Handy hat um 6:42 Uhr mit einem Modellverfall-Alert aus MLflow vibriert. Der PM hat Sie per Slack-DM um 7:55 Uhr angeschrieben: „Kurze Frage: Warum wurde dieser User als Abwanderungsrisiko markiert?" Sie haben Ihren Laptop noch nicht geöffnet. Willkommen in dem Job, den auf LinkedIn niemand genau beschreibt.

Die Stellenbeschreibung, für die Sie sich angemeldet haben, versprach „ML-Modelle bauen, Insights generieren, mit Stakeholdern zusammenarbeiten." All das stimmt, technisch gesehen. Die Anteile stimmen nicht. An einem typischen Dienstag bei einem B2B-SaaS-Unternehmen macht das eigentliche Modellbauen vielleicht ein Viertel Ihres Tages aus. Feature Engineering und SQL-Klempnerarbeit fressen einen weiteren großen Teil. Der Rest ist Übersetzungsarbeit: einem VP erklären, warum Präzision nicht dasselbe ist wie Genauigkeit, ein Konfidenzintervall gegenüber einem Vertriebsleiter verteidigen, eine Loom aufnehmen, die niemand ansieht, und dem Platform-Team daran erinnern, dass ja, das dbt-Modell, das jeden Mittwoch bricht, immer noch bricht.

Das ist nicht die Senior-DS-auf-LinkedIn-Version des Jobs. Es ist die tatsächliche. Wenn Sie drei Monate dabei sind und Ihre Woche nichts wie die Rolle aussieht, für die Sie sich beworben haben, liegt das nicht an Ihnen. Das ist die Rolle.

Hier sieht ein echter Dienstag aus.

8:00 bis 8:30 Uhr: Die Modellleistungsprüfung

Kaffee in der Hand, Laptop geöffnet, der erste Tab ist immer MLflow oder Weights & Biases. Sie scannen die gestrigen Vorhersagen anhand der Labels, die über Nacht eingegangen sind. Der AUC des Abwanderungsmodells fiel über das Wochenende von 0,84 auf 0,79. Das ist keine Katastrophe, aber genug, um es vor dem Standup zu untersuchen.

Sie prüfen zuerst die offensichtlichen Dinge. Hat sich die Eingabeverteilung verschoben? Sie rufen das Feature-Drift-Dashboard auf. Zwei Features driften. Eines ist „Tage seit letztem Login", was Sinn macht, weil das Produkt-Team am Freitag einen neuen Onboarding-Flow veröffentlicht hat und eine Reihe alter Nutzer wieder hineingezogen wurden. Das andere ist „Support-Tickets in den letzten 30 Tagen", das keine offensichtliche Erklärung hat. Sie notieren, es nach dem Standup genauer zu untersuchen.

Diese dreißigminütige Prüfung ist einer der am meisten unterschätzten Teile des Jobs. Die Hälfte der Senior-Data-Scientists, die ich kenne, wurde aufgrund der Stärke befördert, hier etwas entdeckt zu haben, das sonst niemand entdeckt hätte. Das Modell ist nicht kaputt gegangen. Die Welt, für die das Modell trainiert wurde, hat sich leicht verändert, und Sie haben es bemerkt, bevor alle anderen es taten.

Sie prüfen auch die gestrigen Experiment-Runs in MLflow. Zwei Ihrer Teamkollegen haben um 23 Uhr Trainings-Jobs gestartet. Einer hat konvergiert. Einer ist abgestürzt, weil jemand eine Spalte in der Quelltabelle umbenannt hat, ohne es jemandem zu sagen. Willkommen in der Datenwelt.

9:30 bis 11:30 Uhr: Experiment-Design (90 Minuten Diskussion über die Metrik)

Der PM stellt in dem Standup eine Frage: „Konvertiert die neue Pricing-Seite besser?" Einfach, oder? Stichprobengröße, Zweistichproben-Test, los.

Es ist nie so einfach.

Sie verbringen 90 Minuten in Hex mit der Planung des Experiments. Die Mathematik ist der einfache Teil. Hier ist das, was tatsächlich die Zeit frisst:

„Gewinner" definieren. Der PM möchte Klicks auf den „Kostenlose Testversion starten"-Button messen. Sie weisen darauf hin, dass Klicks nicht dasselbe sind wie Starts, Starts nicht dasselbe wie Aktivierungen, und Aktivierungen nicht dasselbe wie bezahlte Conversions. Als Sie fertig sind, hat sich die Erfolgsmetrik dreimal geändert und Sie haben eine Leitplanken-Kennzahl für die Retention in der ersten Woche, weil der Funnel der alten Pricing-Seite nach der Aktivierung ein bekanntes Leck hatte.

Power-Calc-Realitätsprüfung. Bei Ihrem aktuellen wöchentlichen Traffic erfordert die Erkennung eines 3%igen relativen Lifts bei bezahlten Conversions, das Experiment sechs Wochen lang laufen zu lassen. Der PM möchte Ergebnisse in zwei Wochen. Sie einigen sich auf eine verrauschtere Proxy-Metrik (Testversions-Starts) für die frühe Einschätzung und die echte Metrik (bezahlte Conversions) für die endgültige Entscheidung.

Leitplanken-Kennzahlen. Was, wenn die neue Seite die Testversions-Starts erhöht, aber die Qualität dieser Testversionen senkt? Sie fügen eine Leitplanken-Kennzahl für die Aktivierungsrate hinzu. Was, wenn sie die Mischung der ausgewählten Plan-Stufen ändert? Sie fügen eine Leitplanken-Kennzahl für den durchschnittlichen Umsatz pro Neukunde hinzu. Jetzt gibt es drei Metriken, zwei Leitplanken und eine Stopp-Regel.

Vorab-Commit zur Segmentierung. Der PM fragt, ob Sie „danach einfach nach Unternehmensgröße aufschlüsseln" können. Sie sagen nein, und dann ja, aber nur mit einer Bonferroni-Korrektur und einer schriftlich festgehaltenen Liste der Segmente vor dem Start des Tests. Sie schreiben die Liste gemeinsam auf. Das wird später den Job von jemandem retten.

Sie veröffentlichen das Experiment-Design-Dokument im Hex-Workspace des Teams, verlinken es auf der Notion-Projektseite und taggen den PM und den Engineering Lead. Die Mathematik dauerte 15 Minuten. Das Gespräch dauerte 75 Minuten. Dieses Verhältnis ist für den Rest Ihrer Karriere ungefähr richtig.

12:30 bis 14:00 Uhr: Asynchron mit Engineering zum Produktions-Deployment

Sie essen das Mittagessen hastig am Schreibtisch. Der Nachmittagsblock ist der, der neue Data Scientists am meisten frustriert: Ihr Modell ist seit drei Wochen „bereit zum Versand", und der Blocker hat nichts mit dem Modell zu tun.

Das Modell selbst ist in Ordnung. Das Problem ist die Feature-Pipeline. Ihr Abwanderungsmodell benötigt ein Feature namens weighted_engagement_30d, eine gewichtete Summe aus Logins, gesendeten Nachrichten und Teilnahmen an Meetings über die letzten 30 Tage. Dieses Feature wird in einem dbt-Modell namens fct_user_engagement_daily berechnet. Das dbt-Modell bricht jeden Mittwochmorgen zwischen 6 und 7 Uhr Pacific, weil es von einem Salesforce-Sync abhängt, der inkonsistent abschließt.

Sie besitzen das dbt-Modell nicht. Das Analytics-Engineering-Team besitzt es. Sie wissen, dass es unzuverlässig ist. Sie haben ein Ticket dafür. Sie haben das Ticket seit zwei Monaten.

Also ist der Job heute, einen langen PR-Kommentar zum Staging-Deployment zu schreiben. Sie erklären:

  • Die Feature-Pipeline hat ein bekanntes wöchentliches Ausfallzeitfenster
  • Ihr Modell benötigt das Feature mit höchstens 24-stündiger Veraltung
  • Die aktuelle Überwachung des dbt-Modells feuert, nachdem das Feature bereits veraltet ist
  • Sie möchten, dass das Platform-Team entweder das vorgelagerte dbt-Modell repariert oder einen Fallback einrichtet, der den letzten guten Snapshot des Features mit einem Frische-Flag verwendet

Sie taggen den Platform-Team-Lead, verlinken das dbt-Überwachungs-Alert vom letzten Mittwoch als Beleg und verlinken das Frische-Anforderungsdokument Ihres Modells. Sie eskalieren nicht. Sie beklagen sich nicht. Sie hinterlassen einen ruhigen, spezifischen PR-Kommentar mit drei nach Ihrer Präferenz geordneten Optionen und einer Standardempfehlung. Dann schließen Sie den Tab.

Das ist der Teil des Jobs, den die Stellenbeschreibung „funktionsübergreifende Zusammenarbeit" nennt. Er besteht hauptsächlich aus Warten, mit gelegentlicher ruhiger Interessenvertretung, auf eine Sache, die Sie nicht reparieren können, um von jemand anderem repariert zu werden. Machen Sie früh Frieden damit.

14:00 bis 15:00 Uhr: Das „Diese Vorhersage ist falsch"-Meeting

Ein Vertriebsleiter hat dreißig Minuten in Ihrem Kalender gebucht. Der Betreff: „Kurzes Gespräch über das Abwanderungsmodell: Einer meiner Kunden, den es markiert hat, hat gerade für drei Jahre verlängert."

Sie wissen, wie das laufen wird. Sie hatten dieses Meeting ungefähr vierzehnmal seit Sie angefangen haben. Sie haben ein Skript. Hier ist die ungefähre Form:

Mit Neugier öffnen, nicht mit Verteidigung. „Erzählen Sie mir von dem Kunden. Was ist seine Geschichte?" Sie lassen den Vertriebsleiter fünf Minuten lang darüber reden, wie das Modell das Team in Verlegenheit bringen wird, wie der Kunde beleidigt wäre, wenn er es wüsste, und wie er sowieso immer das Gefühl hatte, dass das Modell unzuverlässig ist.

Die Metrik neu formulieren, ohne sie dumm fühlen zu lassen. „Das Modell prognostiziert mit 87% Präzision in der Kohorte mit hohem Abwanderungsrisiko. Das bedeutet, dass von jedem 100 Accounts, die das Modell markiert, etwa 87 tatsächlich innerhalb von 90 Tagen abwandern. Die anderen 13 nicht. Dieser Account gehört zu diesen 13. Das ist kein Modellversagen. Das ist das Modell, das genau wie geplant funktioniert."

Ein Looker-Dashboard mitbringen, keinen defensiven Ton. Sie teilen Ihren Bildschirm und öffnen das Looker-Dashboard für die Abwanderungsmodellleistung. Sie zeigen die Precision-Recall-Kurve. Sie zeigen, dass das Senken des Schwellenwerts, um mehr Abwandernde zu erfassen, noch mehr False Positives bedeuten würde, und das Erhöhen würde echte Abwanderung verpassen. Sie zeigen den Dollarbetrag der im letzten Quartal aufgehaltenen Abwanderung (2,4 Mio. $) gegenüber dem Dollarbetrag der False Positives, wenn jeder markierte Account abwandern würde (viel höher als das, aber das sagen sie nicht).

Mit dem Schließen, wofür das Modell in ihrer Sprache ist. „Dieses Modell ist ein Triage-Tool. Es ist kein Urteil. Es sagt Ihrem Team, wo es die erste Stunde der Woche verbringen soll. Die Tatsache, dass ein markierter Account verlängert hat, bedeutet, dass Ihr Team seinen Job gemacht hat. Sie haben eingegriffen. Das ist die Erfolgsbedingung."

Der Vertriebsleiter verlässt das Gespräch ruhiger als er hineingekommen ist. Sie fügen das Gespräch dem Experiment-Log hinzu. Sie fügen eine Folie zur nächsten monatlichen DS-zu-Vertrieb-Sync hinzu mit dem Titel „Präzision ist nicht Genauigkeit", denn wenn Sie dieses Gespräch 14-mal hatten, hat der Rest der Vertriebsorganisation es öfter als sie zugeben.

16:00 bis 17:30 Uhr: Notebook-Bereinigung und das Experiment-Log

Der letzte Block des Tages ist zurück in Jupyter. Sie öffnen das Analyse-Notebook von der heutigen Pricing-Seiten-Experiment-Planung. Es ist ein Durcheinander. Die Hälfte davon ist Skizzencode. Es gibt eine Zelle, die nur df.head() sagt, ohne Kommentar. Es gibt ein Diagramm ohne Achsenbeschriftungen. Es gibt eine SQL-Abfrage gegen das falsche Schema.

Sie bereinigen es. Die Disziplin hier ist wichtiger als die Ästhetik. Sie machen es nicht für sich selbst hübsch. Sie machen es für die Version von Ihnen in drei Monaten lesbar, die sich erinnern muss, warum Sie eine Stichprobengröße von 4.200 und nicht 5.000 gewählt haben. Die Konvention in Ihrem Team:

  • Markdown-Zelle oben im Notebook mit der Frage, dem Datum und dem Ergebnis
  • Jeder Abschnitt hat eine einzeilige Markdown-Überschrift über dem Code
  • Diagramme haben Titel, Achsenbeschriftungen und eine einzeilige Interpretation darunter
  • Die letzte Zelle ist eine Markdown-Zelle mit der Empfehlung und dem nächsten Schritt

Sie committen das Notebook in das Team-Repository. Sie schreiben eine 200-Wörter-Zusammenfassung im Experiment-Log des Teams, das auf einer gemeinsamen Notion-Seite lebt. Sie pushen auch die dbt-Modell-Änderung, die Sie heute Morgen geschrieben haben. Sie ist in einem separaten Branch und für das Review am nächsten Tag markiert.

Letztes vor dem Schließen des Laptops: Sie prüfen die Notizen des Vertriebsleiter-Meetings von 14 Uhr und fügen ein TODO zum Team-Backlog hinzu. „Ein Looker-Dashboard für Vertrieb bauen, das die Präzision und Recall des Abwanderungsmodells in einfachen Worten zeigt, wöchentlich aktualisiert." Das ist das dritte Mal, dass Sie daran gedacht haben, es zu bauen. Vielleicht diese Woche wirklich.

Was die Stellenbeschreibung Ihnen nicht sagt

Einige Dinge, über die die Stellenbeschreibung hinweggehen wird und die es wert sind, ab Tag eins zu wissen.

Sie werden mehr SQL als Python schreiben. Snowflake oder BigQuery wird Ihre zweite Sprache sein. Je sauberer Ihr SQL, desto schneller Ihre Iterationsschleife. Die meisten Engpässe in Ihrer Woche sind kein Modellieren. Sie sind „die Daten sind noch nicht in der richtigen Form."

Feature Engineering frisst 40% Ihrer Modellierungszeit. Das XGBoost-Modell braucht 20 Minuten zum Trainieren. Die Features, die hineinfließen, brauchten zwei Wochen zum Aufbauen, Validieren und Einbinden in eine Pipeline. Neue Data Scientists unterschätzen das jedes Mal.

Das härteste „ML-Problem" ist meist ein Stakeholder, der dem Output nicht vertraut. Sie können ein wunderschön kalibriertes Modell mit einem publikationswürdigen AUC und null Auswirkungen haben, weil niemand darauf reagieren wird. Vertrauen wird durch wiederholbare Erklärungen, Dashboards in der Sprache der Stakeholder und ruhiges Erscheinen beim „Diese Vorhersage ist falsch"-Meeting aufgebaut.

„Diese Vorhersage ist falsch"-Panik ist ein wöchentliches Ereignis. Haben Sie ein Skript bereit. Bringen Sie ein Dashboard. Werden Sie nicht defensiv. Das Gespräch ist der Job, keine Ablenkung vom Job.

Produktions-Deployments dauern länger als Sie denken. Nicht weil der Code schwierig ist. Weil die Datenabhängigkeiten unzuverlässig sind, die Staging-Umgebung ein Spiegel des letzten Quartals der Produktion ist und das Platform-Team auch sein Bestes tut.

Tools, die Sie tatsächlich verwenden werden

Der Stack variiert je nach Unternehmen, aber die Form ist konsistent. Bei den meisten B2B-SaaS-Unternehmen mit einer echten DS-Funktion im Jahr 2026:

  • Python und Jupyter für Analyse und Modellierung. Einige Teams haben schwerere Arbeit in VS Code mit Notebooks-as-Percent-Files verlagert, aber Jupyter ist immer noch der Standard für die Erkundung.
  • SQL auf Snowflake oder BigQuery für alles, was Produktionsdaten berührt. Wenn Sie von einem Ort kamen, der direkt Postgres verwendete, ist das Warehouse-Denkmodell anders, und Sie werden zum ersten Mal über Kosten pro Abfrage nachdenken.
  • dbt für Transformationen. Sie werden mehr dbt-Modelle lesen als schreiben, aber einige werden Sie schreiben.
  • MLflow oder Weights & Biases für Experiment-Tracking. Die meisten Teams haben eines oder das andere; es spielt fast keine Rolle, welches.
  • Hex für kollaborative Notebooks, die PMs und Analysten lesen können. Hex tut für Analytics, was Figma für Design getan hat.
  • Looker für Stakeholder-Dashboards. Die Dashboards, die Sie hier bauen, sind das, woran Stakeholder Sie messen, auch wenn das Modell dahinter die eigentliche Arbeit ist.
  • Optional, aber üblich: Airflow, Prefect oder Dagster für Orchestrierung. Sie besitzen diese möglicherweise oder auch nicht.

Sie werden nicht alle davon in jedem Team verwenden. Sie werden wahrscheinlich in Ihren ersten 90 Tagen ein neues lernen.

Wie „gut" nach 90 Tagen aussieht

Wenn Sie neu in der Rolle sind, hier eine nützliche Erfolgsdefinition am Dreimonats-Marker. Vergessen Sie die Modellanzahl. Suchen Sie nach diesen:

  1. Sie können die echten Fragen Ihrer drei wichtigsten Stakeholder in ihrer Sprache benennen, ohne ein Dokument vor sich zu haben.
  2. Sie haben ein Modell in der Produktion. Auch ein kleines. Auch eine logistische Regression auf einem einzelnen Feature. Produktion schlägt Notebook.
  3. Sie hören nicht mehr auf zu zucken, wenn ein Stakeholder Sie mit „Diese Vorhersage ist falsch" anschreibt. Sie haben ein Skript. Sie bringen ein Dashboard.
  4. Sie wissen, welche dbt-Modelle wöchentlich brechen und welche Features unzuverlässig sind. Sie werden nicht mehr vom mittwöchlichen Ausfall überrascht.
  5. Sie haben mindestens ein Dokument geschrieben, das ein anderer Data Scientist in Ihrem Team verlinkt hat. Wissen, das sich zusammensetzt, schlägt Analyse, die vergessen wird.

Das ist die Messlatte. Nicht „fünf Modelle ausgeliefert" oder „Team-Velocity verdoppelt." Diese Metriken überleben den Kontakt mit der Realität nicht. Die obige Liste tut das.

Die 50/50-Aufteilung zwischen technischer Arbeit und Übersetzungsarbeit ist kein Fehler in der Rolle. Sie ist die Rolle. Übersetzung ist nicht unter dem Modellieren. Es ist, wie das Modellieren tatsächlich etwas verändert. Die Data Scientists, die sich früher als ihre Kollegen darauf einlassen, sind diejenigen, die in 18 Monaten statt in 30 zu Senior befördert werden.

Der Modellverfall-Alert um 6:42 Uhr wird morgen wieder vibrieren. Frühstücken Sie zuerst.

Mehr erfahren