Portfolio Projects for Software Engineer

Du hast drei Zertifikate, einen Udemy-Kurs und trotzdem keine Einladung zum Gespräch. Das ist normal. Recruiter und Tech-Leads sehen Bewerbungen mit gleichem Muster jeden Tag, und ein weiteres Zertifikat ändert daran nichts. Was zählt, ist der Beweis, dass du Software baust, die außerhalb eines Tutorials funktioniert.

Warum Projekte mehr wiegen als Zertifikate#

Ein Zertifikat sagt, dass du eine Prüfung bestanden hast. Ein Projekt zeigt, wie du Probleme löst, wenn niemand dir die Aufgabe vordefiniert hat. Genau das ist der Job: Anforderungen verstehen, Entscheidungen treffen, Code schreiben, der auch in sechs Monaten noch lesbar ist.

Für Berufseinsteiger und Quereinsteiger ist das die einzige Währung, die überall anerkannt wird. Niemand muss deine Uni kennen oder deinen Kursanbieter. Eine lauffähige Anwendung mit sauberem Repo spricht in jeder Sprache.

Was Reviewer wirklich ansehen#

Reviewer schauen nicht auf die Anzahl der Sterne. Sie verbringen zwei bis fünf Minuten mit deinem Profil und suchen nach bestimmten Signalen.

• Gibt es eine README, die erklärt, was das Projekt macht und wie man es startet?
• Sind Commits nachvollziehbar, oder gibt es einen einzigen Commit mit 200 Dateien?
• Steht im Code, warum eine Entscheidung getroffen wurde, oder nur was?
• Gibt es Tests, auch wenn es nur ein paar sind?
• Sieht man einen echten Trade-off, zum Beispiel Performance gegen Lesbarkeit?

Der wichtigste Punkt: Sie wollen sehen, wie du denkst. Ein Projekt, das eine ungewöhnliche technische Entscheidung begründet, ist interessanter als ein Projekt mit modernem Tech-Stack aber ohne Begründung.

Drei Projekte, die funktionieren#

1. Ein Tool, das du selbst benutzt

Baue etwas, das ein Problem aus deinem Alltag löst. Ein CLI-Tool, das deine Notizen durchsuchbar macht. Eine kleine Web-App, die Ausgaben aus einem CSV-Export kategorisiert. Ein Telegram-Bot, der dich an Dinge erinnert, die du ständig vergisst.

Der Vorteil: Du kennst die Anforderungen aus eigener Erfahrung. Du kannst im Interview realistisch über Edge Cases sprechen, weil du sie selbst getroffen hast. Und die Wahrscheinlichkeit, dass ein anderer Bewerber exakt dasselbe Projekt hat, geht gegen null.

2. Eine API mit Authentifizierung und Datenhaltung

Baue ein Backend mit echter Persistenz, echter Authentifizierung und dokumentierten Endpunkten. Eine Buchungs-API für Räume. Ein Service, der Daten aus einer öffentlichen API cached und in einem eigenen Format ausliefert. Ein URL-Shortener mit Analytics.

Das zeigt Backend-Kenntnisse, die in vielen Stellenanzeigen stehen: Datenbankmodellierung, Token-basierte Auth, Fehlerbehandlung, Rate Limiting. Alles Dinge, die man in Kursen oft überspringt, im Job aber täglich braucht.

3. Ein Beitrag zu einem bestehenden Open-Source-Projekt

Such dir ein kleineres Projekt auf GitHub mit offenen Issues und lass ein Feature oder einen Bugfix reviewen. Nicht bei React oder Kubernetes anfangen. Kleinere Projekte mit aktivem Maintainer sind realistischer.

Ein gemergter Pull Request ist das stärkste Signal in der ganzen Liste. Er zeigt, dass du fremden Code liest, dich an Konventionen hältst und Feedback verarbeitest. Genau diese Fähigkeiten werden im Interview geprüft, und du hast dafür einen konkreten Beweis.

Projekte auf dem Resume präsentieren#

Die meisten Leute schreiben sowas: "Persönliches Projekt: Task Manager mit React". Das sagt nichts. Besser ist eine Zeile, die Problem, Umfang und Ergebnis zusammenfasst.

Schlecht:

Eigenes Projekt: To-Do-App mit React und Node.js

Besser:

Task-Board für Teams mit Rollenverwaltung und Echtzeit-Updates: React-Frontend, Node-API mit WebSocket, PostgreSQL. Deployed auf einem eigenen Server, 40 Commits, dokumentierte Architekturentscheidungen im Repo.

Der Unterschied ist nicht die Länge. Der Unterschied ist, dass die zweite Version dem Leser drei Fragen beantwortet: Was wurde gebaut, womit, und woran sieht man, dass es ernst gemeint war.

Wenn du Hilfe brauchst, die Stellenanzeige auf die relevanten Begriffe zu prüfen, hilft der kostenlose JD-Decoder, um die Anforderungen sauber zu zerlegen. Und bevor du abschickst, lass deinen Lebenslauf durch den kostenlosen ATS-Check laufen, um Formatierung auszuschließen, die Bewerbungen still aussortiert.

GitHub so aufbereiten, dass es jemand versteht#

Dein Profil ist deine Visitenkarte. Drei Dinge reichen oft aus, um den Unterschied zu machen.

• Eine Profil-README, die in zwei Sätzen sagt, wer du bist und woran du gerade arbeitest.
• Pinned Repositories mit aussagekräftigen Namen, keine "test123" oder "learning-react".
• Pro Repo ein README mit: Was macht es, wie starte ich es lokal, welche Entscheidungen sind bewusst getroffen worden.

Ein Detail, das viele vergessen: Schreib rein, was du bewusst weggelassen hast. "Keine Tests für das Frontend, weil der Fokus auf der API lag und die Zeit begrenzt war" wirkt professioneller als ein Repo, das vorgibt, fertig zu sein.

Fehler, die Projekte nach Tutorial aussehen lassen#

Das klassische Problem: Man erkennt das Tutorial sofort wieder. Der Code ist zu gleichmäßig, die Struktur exakt wie im Video, und es gibt keine Abweichung, die zeigt, dass jemand selbst nachgedacht hat.

Konkret wirkt ein Projekt wie ein Tutorial, wenn es nur CRUD kann und sonst nichts. Wenn die README nur die Befehle zum Starten enthält. Wenn es keine einzige Stelle gibt, an der du einen Fehler behandelt hast, weil im Tutorial keine auftrat. Wenn der Name des Repos exakt dem Kurstitel entspricht.

Der Fix ist simpel: Bau eine Funktion ein, die im Tutorial nicht vorkam. Behandle einen echten Fehlerfall. Dokumentiere eine Alternative, die du verworfen hast. Das reicht, um das Profil aus der Masse zu heben.

Wie du im Interview darüber sprichst#

Bereite für jedes Projekt eine kurze Erzählung vor. Die Struktur ist immer gleich: Ausgangslage, Entscheidung, Problem, Lösung. Vier Sätze reichen.

Ein Beispiel für ein Backend-Projekt:

Ich brauchte eine API, die Buchungsanfragen schnell beantwortet, selbst wenn viele gleichzeitig reinkommen. Ich habe mich für PostgreSQL mit einem einfachen Connection Pooling entschieden, statt einen ORM zu nutzen, weil die Queries überschaubar waren und ich die Performance im Blick behalten wollte. Das Problem war, dass Doppelbuchungen durch Race Conditions entstanden sind. Ich habe das mit einem Unique Constraint auf Zeitfenster plus Transaktion gelöst.

Das klingt nach einem echten Engineer. Nicht nach jemandem, der eine Checkliste abarbeitet.

Wenn du aktuelle Stellen suchst, bei denen genau solche Projekte gefragt sind, lohnt ein Blick in die Jobangebote für Softwareentwickler. Und für weiteres Material zu Bewerbung und Technik findest du mehr Artikel im Karrierebereich.

Kostenlose Tools#

• jobrise.io/de/free-ats-checker/
• jobrise.io/de/free-jd-decoder/
• jobrise.io/de/jobs/
• jobrise.io/de/blog/

Häufige Fragen#

Wie viele Projekte sollte ich im Portfolio haben?

Drei gute sind besser als zehn mittelmäßige. Ein Reviewer schaut sich selten mehr als zwei Repos im Detail an. Konzentriere dich auf Projekte, die unterschiedliche Fähigkeiten zeigen, zum Beispiel eines mit Frontend-Fokus, eines mit Backend und Auth, und einen Open-Source-Beitrag.

Muss ich ein Live-Demo bereitstellen?

Nicht zwingend, aber es hilft. Ein Deployed-Demo mit öffentlicher URL macht es Reviewern leichter, das Projekt in zwei Minuten zu verstehen. Wenn Deployment zu aufwendig ist, reicht ein GIF oder Screenshot im README zusammen mit klaren Startbefehlen.

Was mache ich, wenn mein Projekt eine bestehende Lösung dupliziert?

Das ist unkritisch, solange du eine eigene Begründung hast. Ein eigener Kalender oder ein eigener Chat ist kein Problem, wenn du im README erklärst, warum du ihn gebaut hast und welche technische Entscheidung du dabei getroffen hast. Originalität entsteht durch die Begründung, nicht durch die Idee.

Sollte ich alte Projekte aus dem Portfolio entfernen?

Ja, wenn sie nicht mehr deinen aktuellen Stand zeigen. Ein Repo aus dem ersten Lernjahr mit unstrukturiertem Code kann mehr schaden als nutzen. Entweder überarbeitest du es, oder du nimmst es aus den Pinned Repositories.

Wie gehe ich mit fehlender Berufserfahrung um?

Lass die Projekte die Erfahrung ersetzen und beschreibe sie mit der gleichen Sprache, die auch für Berufserfahrung verwendet wird. "Entwickelt", "entworfen", "deployed", "getestet" sind keine geschützten Begriffe. Wer eine lauffähige Anwendung mit dokumentierten Entscheidungen vorweist, hat einen Nachweis, den viele Bewerber mit Berufserfahrung nicht liefern.