Ein Lebenslauf für eine Rolle als Datenanalyst oder Data Scientist unterscheidet sich von einem allgemeinen Software-Engineering-Lebenslauf vor allem darin, worauf der Schwerpunkt liegt, nicht in seiner grundlegenden Form. Der berufliche Werdegang in umgekehrt chronologischer Reihenfolge, eine kurze Zusammenfassung und auf Ergebnisse ausgerichtete Aufzählungspunkte gelten weiterhin, aber ein datenorientierter Lebenslauf beginnt mit der Frage, die eine Analyse beantwortet hat, und der Entscheidung, die sie verändert hat, und nennt Umfang und Quelle der Daten ehrlich, statt sich auf die Pipeline oder das Modell zu verlassen, das die Antwort erzeugt hat. Ein fertiges Dashboard, ein trainiertes Modell oder eine saubere Pipeline sind für sich genommen nicht das Ergebnis, das einen Lebenslauf-Eintrag verdient; die Entscheidung, die ein Team dadurch anders getroffen hat, ist es.
Warum sich der Schwerpunkt bei datenlastiger Arbeit verschiebt
Ein allgemeiner Lebenslauf für Softwareentwicklung erhält üblicherweise Anerkennung für das, was ausgeliefert wurde: ein Feature, ein Dienst, ein System, das jetzt produktiv läuft und auf das eine Nutzerin oder ein Nutzer zeigen kann. Datenlastige Arbeit bringt häufig eine andere Art von Nutzen. Ein Bericht, den ein Führungsteam genutzt hat, um sich zwischen zwei Plänen zu entscheiden, eine Segmentierung, die verändert hat, wie ein Marketingbudget aufgeteilt wurde, eine Prüfung, die ein echtes Problem in einem Datensatz erkannt hat, bevor es ein nachgelagertes System erreichte, nichts davon zeigt sich so wie ein ausgeliefertes Feature. Ein Lebenslauf für diese Art von Rolle muss die Entscheidung ausdrücklich benennen, statt vorauszusetzen, dass Leserinnen und Leser ein Diagramm oder ein Modell selbst mit dem verknüpfen, was danach geschah. Diese Ausrichtung ist besonders wichtig für Analysten- und Data-Scientist-Rollen, in denen das tägliche Ergebnis häufig eine Antwort auf eine Frage ist, die jemand tatsächlich gestellt hat, nicht ein Feature, mit dem Nutzerinnen und Nutzer direkt interagieren.
Die Frage benennen, die ein Projekt beantwortet hat, nicht nur das verwendete Werkzeug
Ein Aufzählungspunkt, der mit dem Werkzeug beginnt, "Ein Modell zur Vorhersage von Kundenabwanderung in Python mit scikit-learn erstellt", sagt Leserinnen und Lesern, welche Technologie beteiligt war, bevor er ihnen irgendetwas darüber sagt, warum die Arbeit wichtig war. Ein Aufzählungspunkt, der mit der beantworteten Frage beginnt, liefert den Nutzen zuerst: welcher von mehreren Onboarding-Schritten eine Kündigung innerhalb von zwei Monaten am besten vorhersagte, ob eine geplante Preisänderung plausibel die Anmeldungen in einer bestimmten Region senken würde, welche von zwei konkurrierenden Produktänderungen ein Team priorisieren sollte. Das Werkzeug gehört weiterhin in den Aufzählungspunkt, nur später, sobald Leserinnen und Leser bereits wissen, warum die Analyse überhaupt entstand. Diese Reihenfolge ist bei datenlastiger Arbeit wichtiger als bei vielen allgemeinen Engineering-Aufgaben, weil die Frage, die eine Analyse beantworten sollte, für Außenstehende oft das Verständlichste an ihr ist.
Daten ehrlich beschreiben: Umfang, Quellen und Rahmen
Die Größe und Form der Daten zu benennen, mit denen ein Projekt tatsächlich gearbeitet hat, vermittelt Leserinnen und Lesern ein Gefühl für den Maßstab, ohne eine erfundene, präzise Zahl zu brauchen. Eine ehrliche Beschreibung nennt Dinge, an die Sie sich tatsächlich erinnern oder die Sie nachprüfen können: ungefähr wie viele Datensätze oder Zeilen betroffen waren, wie viele einzelne Quellen zum Aufbau des Datensatzes zusammengeführt wurden, wie weit die Daten zurückreichten, und ob die Arbeit einmalig als Einzelanalyse oder wiederkehrend nach Zeitplan lief. Den Rahmen ehrlich zu benennen, etwa "Daten aus drei internen Systemen zusammengeführt, die rund zwei Jahre Aktivität abdecken", hält einer Nachfrage stand, wie es eine erfundene, nicht überprüfbare Statistik über die Wirkung der Analyse nicht könnte. Wo eine Analyse tatsächlich eine erfasste Kennzahl verändert hat und diese Zahl noch belegbar ist, gehört sie direkt so in den Lebenslauf; wo das nicht der Fall ist, tragen Umfang und die dadurch ausgelöste Entscheidung den Aufzählungspunkt ebenso gut allein.
Werkzeuge nach ihrer Stelle in der Pipeline gruppieren
Die Werkzeugliste einer Datenrolle reicht oft gleichzeitig über eine Abfragesprache, eine Modellierungsbibliothek, ein Visualisierungstool und ein Planungs- oder Orchestrierungssystem, und diese Liste danach zu gruppieren, an welcher Stelle der Pipeline jedes Werkzeug steht, Erfassung, Transformation, Analyse und Modellierung, dann Berichterstattung oder Visualisierung, gibt Leserinnen und Lesern ein schnelleres Bild von der Form der Erfahrung einer Kandidatin oder eines Kandidaten als eine lange, unsortierte Zeile. Wer nach jemandem sucht, der eine End-to-End-Pipeline souverän verantwortet, sieht diese Form sofort in vier kurzen Pipeline-Stufen-Gruppen, und wer gezielt nach Modellierungserfahrung sucht, kann direkt zu dieser einen Gruppe springen, statt an einem Planungstool und einem Visualisierungstool vorbeizulesen, um sie zu finden.
Illustratives Beispiel: ein Aufzählungspunkt rund um eine dadurch ausgelöste Entscheidung
Illustratives Vorher und Nachher. Vorher, werkzeuggeleitet: "SQL und Python genutzt, um Nutzungsdaten von Kundinnen und Kunden zu analysieren und ein Abwanderungsmodell zu erstellen." Nachher, frage- und entscheidungsgeleitet: "Rund achtzehn Monate Nutzungsdaten über zwei Produktlinien hinweg analysiert, um zu ermitteln, welcher Onboarding-Schritt eine Kündigung innerhalb von sechzig Tagen am besten vorhersagte; der Befund führte dazu, dass das Produktteam genau diesen Schritt statt des gesamten Onboarding-Ablaufs neu gestaltete." Nichts in der überarbeiteten Version erfindet eine Prozentzahl oder ein Ergebnis, das die Person tatsächlich nicht beschreiben könnte; sie nennt die Frage, den ungefähren Umfang der Daten und die Entscheidung, die der Befund veränderte, alles Dinge, die die Person tatsächlich selbst miterlebt hat.
Wo das Quantifizieren von Wirkung weiterhin gilt
Dieselbe Vorsicht vor erfundenen Zahlen gilt hier wie überall sonst im Lebenslauf: Eine echte, derzeit überprüfbare Zahl aus einem Dashboard oder einem Bericht ist es wert, direkt genannt zu werden, ein in Erinnerung gerundeter Eindruck als saubere Prozentzahl nicht. Technischen Impact im Lebenslauf quantifizieren, ohne Zahlen zu erfinden behandelt diese Unterscheidung ausführlicher, und derselbe Ansatz aus Umfang und Entscheidung passt ebenso gut auf einen datenlastigen Aufzählungspunkt wie auf einen allgemeinen Engineering-Punkt.
Erstellen Sie Ihren Lebenslauf
Das Developer-Template von CVBuilderKit ist rund um projekt- und ergebnisgeleitete Einträge aufgebaut, was sich für die Projektliste eines Datenanalysten oder einer Data Scientist genauso eignet wie für Anwendungscode. Starten Sie damit oder mit einem leeren Dokument im Editor und lassen Sie jeden Aufzählungspunkt mit der Frage beginnen, die ein Projekt beantwortet hat, bevor Sie das Werkzeug nennen, das die Antwort geliefert hat.