Was ein Recruiter zuerst tatsächlich überfliegt
Ein Recruiter verbringt nur wenige Sekunden mit dem oberen Drittel eines Software-Entwickler-Lebenslaufs, bevor er entscheidet, ob er weiterliest: Ihren aktuellsten Titel, die Sprachen und Frameworks in Ihrer Skill-Zeile und den ersten Punkt unter Ihrer letzten Stelle. Alles darunter bestätigt entweder den Eindruck, den der obere Teil der Seite bereits gemacht hat, oder verliert die Aufmerksamkeit des Lesers vollständig.
Das bedeutet, dass der Kopfbereich und der erste Eintrag zur Berufserfahrung mehr Gewicht tragen als jeder andere Teil der Seite. Setzen Sie Ihre stärkste, konkreteste Zeile zuerst unter jede Rolle, statt sie als dritten oder vierten Punkt zu verstecken, und halten Sie die Skill-Zeile weit oben, damit ein überfliegendes Auge sie erreicht, bevor es zum nächsten Lebenslauf im Stapel weiterzieht.
Ein Junior-Beispiel: Projekte als Ersatz für Erfahrung
Ein Junior-Entwickler mit einem Praktikum und ein paar Nebenprojekten kann trotzdem einen vollständigen, konkreten Lebenslauf schreiben, indem er jedes Projekt wie einen Berufseintrag behandelt. Unter einem Projekt namens "Order Tracker" könnte ein Junior-Kandidat schreiben: "React- und Node-Anwendung zur Bestellverfolgung für ein lokales Café gebaut; einen Suchfilter hinzugefügt, der die durchschnittliche Suchzeit von 12 Sekunden auf unter 2 Sekunden senkte." Das ist eine konkrete, zitierte Illustration des Musters, keine Aussage über ein typisches Ergebnis.
Der Praktikums-Eintrag folgt derselben Regel: benennen Sie, was sich geändert hat, nicht nur, was Ihnen zugewiesen wurde. Eine Zeile wie "14 gemeldete Fehler im Checkout-Prozess während eines zehnwöchigen Praktikums behoben, drei davon release-blockierend" sagt einem Leser mehr als "Das Entwicklungsteam bei Fehlerbehebungen unterstützt." Halten Sie diesen Abschnitt auf zwei oder drei Projekte mit jeweils ein bis zwei Punkten, statt jedes jemals veröffentlichte Repository aufzulisten.
Ein Mid-Level-Beispiel: Wirkungs-Punkte mit Vorher und Nachher
Ein Mid-Level-Entwickler mit drei bis sechs Jahren Erfahrung sollte pflichtenbasierte Punkte überall dort durch eine Vorher-Nachher-Zahl ersetzen, wo eine echt existiert. Für eine Backend-Rolle könnte das lauten: "Die p95-Latenz beim Checkout von 1,8 s auf 620 ms gesenkt, indem drei sequenzielle Abfragen zu einer gebündelt wurden, bei einem Dienst mit rund 40.000 Anfragen täglich." Die Zahl überzeugt; der Satz drumherum liefert nur den Kontext.
Ein zweites Beispiel für eine andere Art von Beitrag: "Die Migration des Authentifizierungsmoduls eines Monolithen in einen eigenen Dienst geleitet, über sechs Wochen mit zwei anderen Teams koordiniert, ohne Ausfallzeit während der Umstellung." Nicht jeder Punkt braucht einen Prozentsatz - eine Umfangsangabe wie "mit zwei anderen Teams koordiniert" ist immer noch konkret, weil sie nennt, wer beteiligt war und wie lange es dauerte, statt die Arbeit nur "teamübergreifende Zusammenarbeit" zu nennen.
Wann ein eigener Projektabschnitt sinnvoll ist
Ein eigener Projektabschnitt lohnt sich, wenn Sie Nebenarbeit haben, die etwas zeigt, das Ihre Berufserfahrung nicht zeigt: eine Sprache, die Sie außerhalb der Arbeit nutzen, ein Open-Source-Beitrag oder ein persönliches Tool, das Sie gebaut haben und weiter pflegen. Für Junior-Kandidaten leistet er oft mehr als der Erfahrungsabschnitt selbst; für Senior-Kandidaten ist er meist optional, außer das Projekt ist ungewöhnlich relevant für die angestrebte Stelle.
Halten Sie jeden Projekteintrag auf eine Kontextzeile und ein oder zwei Aufzählungspunkte, dieselbe Dichte wie ein Berufseintrag, und verlinken Sie das Repository oder eine Live-Demo, falls vorhanden. Ein Projektabschnitt mit zehn Einträgen ohne Details wirkt wie Füllmaterial; drei Einträge mit je einem konkreten Punkt wirken wie Belege.
Skills und Werkzeuge: konkret, nicht erschöpfend
Listen Sie die Sprachen, Frameworks und Werkzeuge auf, zu denen Sie im Vorstellungsgespräch tatsächlich sicher befragt werden könnten, gruppiert auf eine für die Rolle sinnvolle Weise - Sprachen, Frameworks, Infrastruktur und so weiter. Eine Technologie wegzulassen, die Sie nur eine Woche lang genutzt haben, ist in Ordnung; die Liste sollte widerspiegeln, worüber Sie sprechen können, nicht alles, was jemals Ihren Lebenslauf berührt hat.
Passen Sie die Formulierung an die Stellenanzeige an, wo es ehrlich zutrifft: Wenn die Anzeige "PostgreSQL" sagt und Sie es genutzt haben, schreiben Sie "PostgreSQL" statt nur "SQL-Datenbanken", da sowohl ein automatisches Bewerbermanagementsystem als auch ein menschlicher Leser oft nach dem genauen Begriff suchen. Fügen Sie keine Technologie hinzu, die Sie nicht genutzt haben, nur weil eine Anzeige sie erwähnt - diese Lücke fällt im ersten technischen Gespräch auf.
Häufig gestellte Fragen
- Sollte ein Junior-Lebenslauf für Software-Entwickler Projekte oder Erfahrung zuerst listen?
- Projekte zuerst, wenn Sie wenig bezahlte Erfahrung haben, denn dort liegt Ihr stärkster, konkretester Beleg; verschieben Sie Erfahrung über Projekte, sobald Sie ein echtes Praktikum oder eine Stelle vorweisen können, und halten Sie den stärkeren Abschnitt weiter oben.
- Wie viele Aufzählungspunkte sollte jedes Projekt oder jede Rolle haben?
- Zwei bis vier Punkte pro Eintrag reichen meist, um zu zeigen, was Sie gebaut haben und was sich dadurch geändert hat. Mehr verwässert die Seite, und ein Leser erinnert sich an die ersten ein bis zwei Zeilen unter jedem Eintrag deutlich besser als an die vierte oder fünfte.
- Ist es in Ordnung, denselben Lebenslauf für jede Software-Entwickler-Stelle wiederzuverwenden?
- Die Struktur kann gleich bleiben, aber die Skill-Zeile und die Reihenfolge Ihrer Aufzählungspunkte sollten sich an die Anforderungen jeder Anzeige anpassen, da sowohl ein menschlicher Leser als auch ein automatischer Filter oft nach den spezifischen Begriffen dieser Stellenanzeige suchen.
- Was sollte ein Mid-Level-Entwickler streichen, wenn der Lebenslauf über zwei Seiten hinausgeht?
- Streichen Sie Rollen, die älter als etwa zehn Jahre sind, außer sie sind direkt relevant, kürzen Sie jeden Punkt, der nur eine Zuständigkeit statt eines Ergebnisses beschreibt, und behalten Sie den Projektabschnitt nur, wenn er etwas zeigt, das Ihre Berufserfahrung noch nicht abdeckt.