cvharbor editorial

Lebenslauf für Softwareentwickler: Was wirklich zählt

Ein tabellarischer Lebenslauf für Softwareentwickler wird nicht durch Vollständigkeit besser, sondern dadurch, dass er zeigt, was durch die eigene Arbeit tatsächlich anders geworden ist — und das in einer Sprache, die auch ein Recruiter ohne technischen Hintergrund in wenigen Sekunden einordnen kann.

Ein Recruiter oder Teamlead sieht sich einen Lebenslauf im ersten Durchgang meist nur kurz an. In dieser Zeit zählt, ob erkennbar wird, was jemand tatsächlich bewirkt hat — nicht, welche Aufgaben formal zum Job gehörten. Bei Softwareentwicklern zeigt sich das am deutlichsten daran, ob eine Position als Tätigkeitsbeschreibung oder als Ergebnis formuliert ist.

Der tabellarische Lebenslauf: Aufbau, der in Deutschland erwartet wird

Der tabellarische Lebenslauf ist im deutschsprachigen Raum weiterhin der Standard: Berufserfahrung in umgekehrt chronologischer Reihenfolge, klare Datumsangaben (Monat/Jahr), knappe Stichpunkte statt Fließtext. Ein US-amerikanisches One-Page-Resume oder ein britischer CV mit langen Prosa-Absätzen wirkt in einer deutschen Bewerbung eher unpassend als originell.

• Persönliche Daten oben: Name, Kontaktdaten, optional Wohnort (die vollständige Adresse ist heute nicht mehr zwingend nötig).
• Berufserfahrung in umgekehrt chronologischer Reihenfolge, mit Firma, Position, Zeitraum und drei bis fünf Stichpunkten pro Station.
• Ausbildung und Studium knapp, mit Abschluss und Zeitraum — Details zur Bachelorarbeit gehören nur hinein, wenn sie fachlich relevant sind.
• Technische Fähigkeiten als eigener, gut sichtbarer Abschnitt, nicht in Fließtext versteckt.

Aufgaben beschreiben ist nicht dasselbe wie Wirkung zeigen

"Zuständig für die Wartung des Checkout-Systems" beschreibt einen Bereich, aber keine Handlung und kein Ergebnis. Stärker ist ein Satz, der benennt, was sich durch die eigene Arbeit verändert hat — mit einer Zahl, wenn eine echte, nachvollziehbare Zahl vorliegt.

Die Zahl im guten Beispiel stammt aus einer Quelle, die man im Gespräch auch belegen kann: der Ticket-Historie. Wenn eine Zahl nicht mehr nachvollziehbar ist, sollte sie nicht erfunden werden. Ein präzise formulierter Satz ohne Zahl ("die Ticketzahl sank so deutlich, dass der Support das Thema nicht mehr eskalierte") wirkt glaubwürdiger als eine Prozentangabe, die im Gespräch nicht standhält.

Tech-Stack: sinnvoll gruppiert statt aufgezählt

Eine lange, unsortierte Liste von Technologien liest sich wie eine Stichwortsammlung für die Bewerber-Datenbank, nicht wie ein Kompetenznachweis. Der Abschnitt lohnt sich trotzdem, weil intern oft nach genau diesen Begriffen gefiltert wird — nur profitiert er stark von Struktur.

• Nach Kategorien ordnen: Programmiersprachen, Frameworks, Infrastruktur, Datenbanken. Wer nach "Kubernetes" sucht, findet es unter "Infrastruktur" schneller als in einer einzigen langen Zeile.
• Nur aufnehmen, worüber man im Gespräch tatsächlich Auskunft geben kann. Eine Technologie aus einem alten Projekt, die man heute kaum noch erklären könnte, wird schnell zum Risiko.
• Die für die angestrebte Stelle relevantesten Technologien nach oben stellen — das kostet nichts und lenkt den Blick dorthin, wo er zuerst hinfällt.
• Selbstverständliches weglassen: "Git" oder "Kommandozeile" sind in der Softwareentwicklung keine Unterscheidungsmerkmale mehr.

Aussagekräftiger als die reine Liste sind ohnehin die Stichpunkte in der Berufserfahrung. "Ingestion-Pipeline in Go neu aufgebaut, nachdem der bisherige Python-Dienst der Last nicht mehr standhielt" sagt mehr über die tatsächliche Erfahrung mit Go aus als das bloße Wort in einer Aufzählung.

GitHub-Profil und private Projekte

Ein GitHub-Link lohnt sich, wenn das Profil selbst etwas zeigt: nachvollziehbare Commit-Historie, lauffähige Projekte, Code, den man auch gelesen sehen möchte. Ein Link auf ein Profil mit drei geforkten Tutorial-Repos ohne eigene Commits schadet eher, als dass er nützt — denn ein interessierter Leser klickt darauf.

• Zwei bis drei Repositories anpinnen, die die eigene Arbeit am besten repräsentieren, nicht alles, was je hochgeladen wurde.
• Eine kurze README, die erklärt, was das Projekt macht und warum es entstanden ist, macht aus einem Code-Ordner etwas, das auch fachfremde Leser einordnen können.
• Ein privates Projekt, das ein reales eigenes Problem löst, ist ein stärkeres Signal als eine sauber umgesetzte Tutorial-Kopie.
• Wenn die eigentlich relevante Arbeit aus Vertraulichkeitsgründen nicht öffentlich zugänglich ist, lohnt sich ein kurzer Hinweis in der Projektbeschreibung statt einer stillen Lücke.

Für Berufseinsteiger ohne umfangreiche Praxiserfahrung bringt dieser Abschnitt oft den größten Effekt, weil er häufig der einzige Ort ist, an dem selbstständige Arbeit sichtbar wird. Bei erfahrenen Entwicklern verschiebt sich das Gewicht zurück auf die Berufserfahrung — das Portfolio ist dann eine sinnvolle Ergänzung, aber nicht mehr tragend.

Unser Editor trennt das Tech-Stack-Feld bewusst von den Stichpunkten zur Berufserfahrung, damit der Stack nicht im Fließtext verschwindet — und lässt Stichpunkte ohne erkennbares Ergebnis nicht unkommentiert durchgehen. Lebenslauf erstellen

Anschreiben: notwendig oder nicht?

In der deutschen Bewerbungstradition gehört das Anschreiben klassisch fest zur Bewerbungsmappe. In der Softwareentwicklung ist die Praxis inzwischen uneinheitlicher: Viele Unternehmen, besonders internationale Tech-Firmen und Startups, verzichten explizit darauf oder werten es kaum. Wenn eine Stellenanzeige ein Anschreiben verlangt, sollte es geliefert werden — knapp, konkret auf die Stelle bezogen, ohne die Stichpunkte des Lebenslaufs zu wiederholen. Wenn es nicht verlangt wird, lohnt sich die Zeit meist mehr im Lebenslauf selbst.

Vor dem Absenden prüfen

• Benennt jeder Stichpunkt eine Veränderung, nicht nur eine Zuständigkeit?
• Lässt sich jede genannte Zahl im Gespräch auch erklären, wenn nach der Herkunft gefragt wird?
• Ist der Tech-Stack nach Kategorie geordnet und auf die konkrete Stelle zugeschnitten?
• Würden die angepinnten GitHub-Repositories einem tatsächlichen Blick standhalten?
• Ist der tabellarische Aufbau eingehalten — chronologisch, mit klaren Datumsangaben, ohne Fließtext-Absätze?