GitHub in der Bewerbung: Wann der Link dir schadet

Du setzt einen GitHub-Link in deine Bewerbung. Ein Senior Developer öffnet ihn und erwartet Code, über den ihr sprechen könnt. Stattdessen findet er ein leeres Profil. Oder mehrere Tutorial-Repositories mit einem ersten Upload und keiner Erklärung.

Das kann abschreckend wirken. Der Link verspricht einen Beleg für deine Fähigkeiten, liefert aber zusätzliche Arbeit: herausfinden, was dieses Profil überhaupt über dich aussagt. Du hast es bewusst in die Bewerbung aufgenommen. Damit gehört seine Präsentation zum Eindruck, den du hinterlässt.

Verlinke GitHub im Lebenslauf, wenn dort relevante Arbeit liegt, die du erklären kannst. Lass einen freiwilligen Link weg, wenn das Profil nichts ergänzt. Du brauchst weder Sterne noch ein profitables Produkt oder täglich neue Commits. Du brauchst einen guten Grund für den Klick und etwas Interessantes dahinter.

Hier erfährst du, wie das aussieht und warum ein kleines Projekt, das dir Spaß macht, überzeugender sein kann als ein Portfolio, das nur beschäftigt wirkt.

Solltest du GitHub in deiner Bewerbung verlinken?🔗

Ein leerer Link weckt eine Erwartung, die du nicht erfüllst🔗

Stell dir zwei ansonsten ähnliche Bewerbungen vor. Eine beschreibt ein konkretes Projekt und verlinkt den Code. Die andere nennt GitHub neben den Kontaktdaten, zeigt dort aber keine relevante öffentliche Arbeit. Die erste liefert einen Gesprächseinstieg. Die zweite gibt der Person, die sie prüft, keinen zusätzlichen Grund für eine Einladung.

Das ist ein Beispiel, keine Behauptung über alle Hiring Engineers. Manche Teams öffnen externe Links gar nicht. Andere fordern ausdrücklich Codebeispiele an. Halte dich an die Vorgaben der Bewerbung und erkläre die Situation, wenn nach einem GitHub-Profil gefragt wird, dessen relevante Arbeit privat ist.

Ein leeres öffentliches Profil beweist nicht, dass dir Erfahrung fehlt. Vielleicht arbeitest du mit vertraulichem Code, auf einer anderen Plattform oder an Projekten, die du nicht veröffentlichen darfst. Dann soll dein Developer-Lebenslauf diese Erfahrung zeigen. Ein freiwilliger Link sollte die Bewerbung stärken und nicht nur aus Gewohnheit Platz belegen.

Null Sterne und ein Commit sind kein Qualitätsurteil🔗

Die Formulierung „null Sterne, ein Commit“ greift zu kurz. Entscheidend sind oberflächliche Belege, nicht die Zahlen selbst. GitHub beschreibt Sterne als Möglichkeit, interessante Repositories wiederzufinden und Wertschätzung auszudrücken. Daraus wird keine Bewertung der Codequalität.

Ein einzelner Commit kann ein gutes Projekt enthalten, das aus einer anderen Umgebung importiert wurde. Auch eine zusammengeführte Historie ist möglich. Umgekehrt können Hunderte kleiner Commits ein Projekt verdecken, das du nicht erklären kannst. Erzeuge keine künstliche Aktivität für eine grünere Beitragsgrafik.

Unüberzeugend wird ein Repository, wenn es wenig zu prüfen gibt: unveränderter Starter-Code, keine brauchbare Funktion, keine Erklärung deines Beitrags. Null Sterne bei einem durchdachten Projekt sind völlig in Ordnung. Null Erklärung bei einer Tutorial-Kopie ist das Problem.

Was ein Senior Developer aus deinem Projekt erkennen kann🔗

Mach deine Entscheidungen sichtbar🔗

Gib der Person, die deinen Code liest, mehr als eine Liste von Technologien. Warum nutzt du eine lokale Datenbank? Was passiert ohne Netzwerk? Welcher Teil war schwieriger als erwartet? Auch ein kleines Projekt kann durch deine Antworten technisches Urteilsvermögen zeigen.

Dokumentiere einen sinnvollen Kompromiss. Zum Beispiel: „Ich nutze Polling, weil sich die Daten selten ändern und ich keine dauerhafte Verbindung betreiben möchte.“ Beschreibe einen Fehler und den Test, der ihn abfängt. Für ein Skript mit zwei Funktionen brauchst du kein aufwendiges Architekturdiagramm.

Wenn du mit einem Tutorial begonnen hast, benenne deine Änderungen. Hast du KI-Unterstützung verwendet, solltest du den entstandenen Code erklären und überprüfen können. Verantwortung für ein Projekt bedeutet, die präsentierte Arbeit einschließlich ihrer Grenzen zu verstehen.

Zeig ein funktionierendes Ergebnis, auch ohne Umsatz🔗

Umsatz beantwortet eine geschäftliche Frage. Dein Portfolio soll meist eine technische beantworten: Kannst du ein Problem verstehen, eine sinnvolle Lösung bauen und erklären, was du gelernt hast?

Ein Werkzeug, das nur du nutzt, kann das leisten. Zeig einen Screenshot, eine kurze Aufnahme oder ein reproduzierbares Beispiel. Erkläre, wie du die Funktion prüfst. Teste bei einem Parser fehlerhafte Eingaben und bei einem Planungstool überlappende Termine. Ein sinnvoller Fehlerfall ist aussagekräftiger als ein Badge ohne Kontext.

Wirtschaftliche Ergebnisse können für Rollen mit Produktverantwortung relevant sein. Sie sind keine Voraussetzung für ein gutes Codebeispiel. Ein Projekt darf interessant sein, ohne einen Euro zu verdienen.

Bau ein Portfolio-Projekt, das du selbst nutzen willst🔗

Starte mit einem Interesse und finde darin ein technisches Problem🔗

Wähle etwas, das dich genug interessiert, um nach der ersten Version weiterzumachen. Ein Klettertagebuch kann eine spannende Datenmodellierung erfordern. Eine Spiele-Mod kann Performance-Fragen aufwerfen. Ein Probenplaner kann zu einem nützlichen Werkzeug werden.

Nehmen wir diesen Probenplaner als fiktives Beispiel. Deine Band möchte Songs innerhalb eines festen Zeitfensters proben. Du baust eine einfache Liste und merkst dann, dass Instrumentenwechsel Zeit kosten. Plötzlich gibt es eine echte Einschränkung zu modellieren. Du ergänzt eine Prüfung der Gesamtdauer, speicherst Proben lokal und erklärst, warum du Benutzerkonten zunächst weglässt.

Das Projekt bleibt klein, aber du hast Entscheidungen zu besprechen. Es zeigt mehr Eigenständigkeit als die Kopie einer großen App, die du selbst nie benutzen wolltest. Spaß hilft dir, neugierig zu bleiben. Die Umsetzung muss diese Neugier sichtbar machen.

Beende eine nützliche Funktion, bevor du das nächste Repo startest🔗

Wähle den kleinsten vollständigen Ablauf: Setlist importieren, Dauer berechnen, speichern. Bring ihn zum Laufen, bevor du Social Features ergänzt oder den Stack wechselst. Ein verständliches, ausführbares Projekt lässt sich besser beurteilen als mehrere ehrgeizige Gerüste.

Nutze es selbst oder lass jemanden mit demselben Hobby ausprobieren. Halte fest, was unverständlich war und was du geändert hast. Erstelle echte Commits, während sich die Arbeit entwickelt. Ist das Projekt fertig, schreib das dazu. Es braucht keine künstlichen wöchentlichen Updates, um nützlich zu bleiben.

Bitte vor dem Verlinken einen anderen Developer, das Repository ohne deine mündliche Erklärung zu öffnen. Erkennt die Person, was es tut, und findet sie eine interessante Entscheidung? Wo sie hängen bleibt, solltest du nachbessern.

Mach deinen GitHub-Link leicht bewertbar🔗

Gib deinem README einen klaren Aufbau🔗

Beginne mit dem Problem und dem funktionierenden Ergebnis. Hilf anschließend beim Ausführen und beim Verstehen deiner Entscheidungen. GitHubs Leitfaden für Bewerbungen empfiehlt, relevante Projekte hervorzuheben und Dokumentation, Beispiele und Tests zu verbessern. Wende das gezielt an: Wenige überzeugende Projekte sind sinnvoller als das Auffüllen aller Plätze.

Dieser Aufbau funktioniert auch bei kleinen Projekten. Die Länge der Abschnitte sollte zum Umfang passen:

# Probenplaner
Welches Problem er löst und warum ich ihn gebaut habe.

## Demo
Screenshot oder kurze Aufnahme und ein Beispielablauf.

## Lokal starten
Voraussetzungen, Befehle und Beispieldaten.

## Entscheidungen
Ein wichtiger Kompromiss und was ich überdenken würde.

## Tests
Ausführung und abgedeckte Fehlerfälle.

## Grenzen und mein Beitrag
Was fehlt; was aus Bibliotheken oder Tutorials stammt.

Gib dem Projekt auch im Lebenslauf Kontext. Für unser fiktives Beispiel: „Probenplaner entwickelt, der Lieddauer validiert und Proben lokal speichert; Persistenzentscheidungen dokumentiert und ungültige Eingaben getestet.“ Verwende nur Aussagen, die dein tatsächliches Projekt belegt. Unser annotiertes Lebenslauf-Beispiel zeigt, wie du konkrete Erfahrung in die Bewerbung einordnest.

Prüfe diese Punkte vor deiner nächsten Bewerbung🔗

1. Öffne den Link ohne Anmeldung und prüfe, ob die gemeinte Arbeit zugänglich ist.
2. Platziere dein stärkstes relevantes Projekt gut sichtbar.
3. Prüfe die Startanleitung oder zeig eine hilfreiche Demo, wenn Deployment nicht sinnvoll ist.
4. Erkläre deinen Beitrag, eine Entscheidung und eine bekannte Einschränkung.
5. Entferne Zugangsdaten oder sensible Informationen, bevor du Arbeit veröffentlichst.
6. Gleiche die Projektbeschreibung im Lebenslauf mit dem Repository ab.

Die folgende Entscheidungshilfe enthält redaktionelle Empfehlungen, keine gemessenen Einstellungsergebnisse.

Wie CodingCareer dir hilft, die richtigen Belege zu zeigen🔗

Verbinde dein GitHub-Projekt mit deiner Jobsuche in Deutschland🔗

CodingCareer bietet Interview-Coaching durch Developer und Unterstützung entlang der Jobsuche im deutschen Tech-Markt. Der Online Presence Review umfasst angeheftete Repositories, README-Qualität und Profilstruktur mit konkreten Änderungsvorschlägen. Damit beantwortest du eine praktische Frage: Welche Teile deiner Arbeit sollte ein Unternehmen zuerst sehen?

Das Projekt muss auch zur übrigen Bewerbung passen. Dein Lebenslauf erklärt seine Relevanz, dein Online-Profil unterstützt dieselbe Positionierung und im Interview kannst du über den Code sprechen. Coaching kann diese Teile verbinden, ohne aus deinem Hobby eine Geschäftsidee machen zu müssen.

Bau etwas, das dir Spaß macht, zeig deine Entscheidungen und verlinke es, wenn es die Bewerbung stärkt. Schreib CodingCareer, um nach Review-Verfügbarkeit zu fragen und deine Arbeit passend für deine nächste Developer-Rolle in Deutschland zu präsentieren.