Portfolio Projects for Backend Developer

Dein GitHub voller Tutorial-Forks, aber kein Projekt, das dich von der Masse abhebt. Genau das ist das Problem. Zertifikate und abgeschlossene Kurse sind für viele Hiring Manager austauschbar geworden. Was zählt, ist Code, den jemand ansehen und verstehen kann.

Drei Projekte reichen. Nicht zehn. Drei, die zeigen, dass du Systeme baust, nicht nur Beispiele abarbeitest.

Was Reviewer wirklich anschauen#

Wer deine Bewerbung öffnet, hat selten mehr als fünf Minuten für den ersten Eindruck. In dieser Zeit passiert Folgendes: Der README wird überflogen, dann ein Blick in die Projektstruktur, dann vielleicht zwei, drei Dateien. Niemand liest deinen kompletten Code.

Reviewer suchen nach drei Dingen. Erstens: Trifft das Projekt ein reales Problem? Zweitens: Versteht der Bewerber, warum er Architekturentscheidungen getroffen hat? Drittens: Läuft das Projekt ohne Doktorarbeit zum Starten?

Wenn dein README allein schon die Hälfte dieser Fragen beantwortet, bist du weiter als die meisten Mitbewerber. Ein hilfreiches Werkzeug, um zu verstehen, was ein konkretes Stellenprofil wirklich verlangt, ist der kostenfreie Stellenanzeigen-Decoder. Er zeigt dir, welche Fähigkeiten im Text wirklich gemeint sind.

Projekt eins: Eine API mit echten Grenzfällen#

Baue eine REST- oder GraphQL-API, die ein Geschäftsproblem löst. Buchungsverwaltung, Bestandsführung, Rechnungsstellung. Etwas, das jeder nachvollziehen kann.

Der Unterschied zum Tutorial: Bau die langweiligen Teile ein. Validierung. Fehlerbehandlung. Pagination. Rate Limiting. Eine sinnvolle Datenbank-Schema mit echten Relationen. Dazu Tests, die nicht nur den Happy Path abdecken.

Nimm dir ein Problem aus deinem Alltag oder Beruf. Eine API zur Verwaltung von Werkstattterminen ist glaubwürdiger als der zehnte To-do-Clone. Zeige im README, warum du dieses Problem gewählt hast.

Projekt zwei: Ein System, das unter Last steht#

Das zweite Projekt zeigt, dass du über die einzelne Anwendung hinausdenkst. Eine Message Queue, ein Background Worker, Caching, ein einfacher Load Balancer. Nicht alles auf einmal, sondern zwei, drei Bausteine, die zusammenarbeiten.

Beispiel: Ein Bildverarbeitungsdienst. Der Upload geht per API rein, die eigentliche Arbeit läuft in einem Worker, das Ergebnis landet im Storage, der Client pollt oder bekommt ein Event. Das sind vielleicht 300 Zeilen Code, aber es zeigt Verteilung, Fehlerfälle und asynchrone Verarbeitung.

Dokumentiere, was passiert, wenn ein Worker mitten in der Arbeit stirbt. Diese Frage kommt im Interview, und du solltest die Antwort aus deinem eigenen Projekt kennen.

Projekt drei: Etwas, das du betreibst#

Das dritte Projekt ist das stärkste, weil es selten ist. Ein kleiner Dienst, der wirklich läuft. Monitoring, Logging, ein Deployment, das nicht nur localhost kennt. Das kann eine kleine App auf einem billigen VPS sein oder eine Serverless-Funktion mit sauberem CI/CD.

Du musst nichts Teures bezahlen. Viele Cloud-Anbieter haben ein Free Tier, das für kleine Dienste reicht. Prüfe aber die aktuellen Konditionen auf der offiziellen Anbieterseite, die ändern sich häufig.

Was zählt: Du kannst sagen, wie oft dein Service in den letzten Wochen ausgefallen ist, wie du es gemerkt hast und was du daraus gemacht hast. Das ist Betriebserfahrung, und die ist selten bei Junior-Bewerbern.

Wie du die Projekte im Lebenslauf zeigst#

Ein Projekt im Lebenslauf ist kein Platzhalter. Es braucht eine Zeile, die Problem, Ansatz und Ergebnis nennt. Keine Aufzählung von Technologien am Ende, das sieht aus wie Keyword-Stuffing.

Schwach: Backend-Projekt: Booking API mit Node.js, PostgreSQL, Docker

Stärker: Booking API für Werkstatttermine: Entworfen und gebaut, um Doppelbuchungen zu verhindern. Validierung und Transaktionen in PostgreSQL, 40 Integrationstests, tägliches Deployment über GitHub Actions.

Der zweite Satz nennt ein Problem, eine konkrete Entscheidung und ein Ergebnis. Wenn du wissen willst, ob dein Lebenslauf die richtigen Begriffe für ATS enthält, wirf einen Blick in den kostenfreien ATS-Checker. Er zeigt dir, wo dein Dokument an Filtern scheitert.

Maximal zwei bis drei Projekte im Lebenslauf. Alles andere liegt auf GitHub und wird verlinkt.

GitHub richtig aufsetzen#

Der README ist deine Visitenkarte. Er sollte in dieser Reihenfolge Antworten geben: Was macht das Projekt? Warum existiert es? Wie starte ich es lokal? Wo sind die Tests? Welche Entscheidungen hast du getroffen und warum?

Ein paar Details, die den Unterschied machen:

• Ein Makefile oder ein Startskript, damit make run wirklich läuft
• Eine .env.example mit allen erwarteten Variablen
• Konkrete Anforderungen, etwa "Python 3.12 oder neuer", nicht "moderne Umgebung"
• Ein Abschnitt "Designentscheidungen" mit zwei, drei Absätzen zu Trade-offs
• Screenshots oder eine kurze GIF-Sequenz, wenn es eine Oberfläche gibt
• Eine Lizenz, damit klar ist, was andere damit machen dürfen
• Keine generischen README-Templates mit Aufzählung von Features, die niemand geprüft hat

Pinne die drei Projekte oben auf dein Profil. Alles andere nach unten. Ein Profil mit 40 Repos, von denen 35 halb fertig sind, wirkt unordentlich.

Fehler, die Projekte nach Tutorial aussehen lassen#

Der häufigste Fehler: Der Code ist zu glatt. Wenn es keine einzige Stelle gibt, an der du eine Alternative verworfen hast, sieht das Projekt nach Anleitung aus. Schreib im README, welche Variante du zuerst gebaut hast und warum du sie verworfen hast.

Der zweite Fehler: Zu viele Technologien, zu wenig Substanz. Wenn dein kleines Projekt Docker, Kubernetes, Redis, Kafka und eine Microservice-Architektur nutzt, glaubt dir niemand, dass du das alles verstehst. Nimm die Technologien, die das Problem lösen, und nicht mehr.

Der dritte Fehler: Keine Tests. Auch nur fünf Tests, die echte Fehlerfälle abdecken, sind besser als fünfzig, die nur expect(200) prüfen.

Und der vierte Fehler: Ein README, der nur installieren erklärt. Wenn niemand versteht, warum du das gebaut hast, bleibt ein Haufen Code ohne Kontext.

So redest du im Interview darüber#

Bereite für jedes Projekt eine zweiminütige Version vor. Was das Problem war, was du gebaut hast, welche Entscheidung die schwierigste war. Danach kommen die Nachfragen, und hier trennt sich Spreu vom Weizen.

Übliche Fragen und wie du antwortest:

"Warum hast du X gewählt?" Nenne die Alternative, die du verworfen hast. "Ich habe zuerst ein ORM genommen, aber die Queries für die Paginierung wurden zu langsam. Dann habe ich die zwei kritischen Queries von Hand geschrieben."

"Was würdest du heute anders machen?" Eine echte Antwort. "Das Caching wäre sauberer als separate Schicht statt im Service versteckt. Das hat die Tests unnötig kompliziert gemacht."

"Was passiert bei 100 gleichzeitigen Nutzern?" Wenn du es gemessen hast, sag die Zahl. Wenn nicht, sag ehrlich, wo der Flaschenhals wäre und wie du es testen würdest.

Nie sagen: "Das ist nur ein Hobbyprojekt." Damit entwertest du deine eigene Arbeit. Sag stattdessen, was du gelernt hast, das du im Job einsetzen würdest.

Zum Schluss ein Tipp zum Finden passender Stellen: Nutze die kostenfreie Jobsuche, um nach Rollen zu filtern, die genau die Fähigkeiten suchen, die deine Projekte zeigen. So passt dein Portfolio zur Bewerbung und nicht umgekehrt. Mehr Tipps zu Bewerbung und Gehalt findest du im Jobrise Blog.

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 Portfolio-Projekte brauche ich als Backend Developer?

Drei durchdachte Projekte schlagen zehn oberflächliche. Entscheidend ist, dass ein Reviewer in wenigen Minuten versteht, was das Projekt macht und welche Entscheidungen du getroffen hast.

Sollte ich Zertifikate komplett weglassen?

Nein, aber sie sind Einstiegsticket, kein Argument. Nenne sie kurz im Lebenslauf, wenn sie relevant sind, und verlass dich bei der Überzeugung auf Projekte, die man sich ansehen kann.

Was, wenn ich noch keine Berufserfahrung habe?

Dann sind die Projekte deine Erfahrung. Wähle ein Problem aus einem Job, einem Nebenjob oder dem Alltag und beschreibe es so, als wäre es eine echte Anforderung. Kontext macht den Code verständlich.

Brauche ich für die Projekte Cloud-Kenntnisse?

Für das dritte Projekt ja, aber das reicht ein kleiner Dienst auf einem günstigen Server. Wichtiger als die Cloud-Zertifizierung ist, dass du erklären kannst, wie dein Service deployed und überwacht wird.

Wie aktuell muss der Code in den Projekten sein?

Er muss laufen und mit aktuellen Versionen der Sprache starten. Wenn dein letztes Projekt vor zwei Jahren gepusht wurde, aktualisiere zumindest die Abhängigkeiten und den README. Verwaiste Projekte wirken schnell so, als hättest du das Interesse verloren.