Portfolio Projects for Frontend Developer

Dein Frontend-Lebenslauf ist voll mit Zertifikaten, aber Einladungen zu Interviews bleiben aus. Das ist kein Zufall. Wer Bewerbungen sichtet, will sehen, wie du baust, nicht wie gut du Tests bestehst.

Zertifikate zeigen, dass du Material durchgearbeitet hast. Projekte zeigen, dass du Entscheidungen triffst. Für Frontend Developer ist der Unterschied im Screening oft der einzige, der zählt.

Was Reviewer in Projekten wirklich ansehen#

Niemand zählt deine Sterne auf GitHub. Reviewer öffnen dein Repo, scrollen durch den Code und die Demo, und nach zwei Minuten haben sie eine Meinung. Diese Meinung hängt an wenigen Dingen.

Erstens: Gibt es ein Problem, das du löst, oder nur eine Nachbau einer To-do-App? Zweitens: Steht im README, warum du dich für Router, State-Management oder ein CSS-Konzept entschieden hast? Drittens: Funktioniert die Demo, wenn ich den Link anklicke, ohne Setup?

Dazu kommen Basics, die viele vergessen. Tastaturbedienung, sichtbarer Fokus, Ladezustände, Fehlermeldungen, responsives Verhalten auf dem Handy. Das sind keine Bonuspunkte. Das ist Frontend-Arbeit.

Ein Reviewer sieht auch, wie sauber dein Commit-Verlauf ist, ob Komponenten lesbar sind und ob du harte Werte irgendwo versteckt hast. Wer das halbe Projekt in einer Komponente mit 800 Zeilen baut, hat nichts über Architektur gelernt.

Drei Projekte, die mehr erzählen als ein Kursabschluss#

Wähle Projekte, die unterschiedliche Fähigkeiten zeigen. Drei identische CRUD-Apps mit anderem Theme sind eine einzige App in schlecht.

Projekt 1: Ein datengetriebenes Dashboard mit echten Daten

Baue ein Dashboard, das öffentliche Daten lädt, filtert und visualisiert. Wetterdaten, ÖPNV-Verbindungen, Energiepreise, was dich interessiert. Der Punkt ist nicht das Thema, sondern die Komplexität der Zustände.

Du brauchst Ladezustand, Fehlerfall, leere Ergebnisse, Pagination oder Virtualisierung bei vielen Zeilen, und eine Filterlogik, die sich nicht bei jeder Eingabe zerlegt. Genau das wird im Job täglich gebaut. Wer zeigt, dass er mit asynchronen Daten umgehen kann, hat sofort einen Vorteil.

Nimm dazu eine Chart-Bibliothek, aber begründe die Wahl. Warum diese und nicht eine andere? Was war an der Performance bei 5000 Datenpunkten? Solche Sätze im README wiegen mehr als jede Zertifikatsnummer.

Projekt 2: Eine App mit echter Persistenz und Auth

Baue etwas, das Daten über Sessions hinaus behält. Ein Lesetracker, ein Reiseplaner, ein Tool für Vereinsmitglieder. Authentifizierung, Datenbank, Validierung auf dem Server.

Das zwingt dich zu Fragen, die Kurse oft auslassen: Was passiert bei einem abgelaufenen Token? Wie verhinderst du doppelte Einträge? Was sieht der Nutzer, wenn die Verbindung abbricht? Zeigst du das, glaubt dir ein Reviewer, dass du über den reinen Client hinausdenkst.

Nicht jedes Projekt braucht ein riesiges Backend. Aber eines deiner Projekte sollte zeigen, dass du Daten nicht nur in useState hältst und beim Neuladen verlierst.

Projekt 3: Ein Beitrag zu einem bestehenden Projekt oder ein Tool für echte Nutzer

Etwas reparieren oder verbessern, das andere benutzen, ist der stärkste Beweis in einem Portfolio. Ein Bugfix in einer Open-Source-Bibliothek, ein Plugin, ein internes Tool für einen Verein oder eine lokale Initiative.

Der Grund ist simpel: Du arbeitest an fremdem Code, musst Konventionen lesen, Pull Requests formulieren und Feedback aushalten. Genau das ist der Job. Ein Reviewer sieht, dass du nicht nur in deiner eigenen Struktur denkst.

Falls du keine Nutzer auftreibst, bau ein Werkzeug, das du selbst täglich benutzt und dokumentiere ehrlich, was daran noch fehlt. Ehrliche Restprobleme wirken glaubwürdiger als ein perfektes Showcase-Projekt ohne Ecken.

So präsentierst du Projekte auf GitHub#

Das Repository ist deine Visitenkarte. Ein leeres oder unstrukturiertes README ist der schnellste Weg, dass jemand wieder schließt.

• Ein erster Satz im README, der erklärt, was das Projekt macht und für wen
• Ein Link zur lauffähigen Demo direkt ganz oben, nicht versteckt in einem Absatz
• Screenshots oder eine kurze GIF-Sequenz, damit man nicht klonen muss
• Abschnitt zu Setup und Start mit den exakten Befehlen, getestet in einer frischen Umgebung
• Abschnitt zu technischen Entscheidungen mit Begründung, nicht nur Nennung
• Liste der bewusst weggelassenen Features oder bekannten Probleme
• Hinweis zu Lighthouse-Werten oder Accessibility-Checks, wenn du sie gemacht hast
• Klare Komponentenstruktur, keine generischen Dateinamen wie utils2.js oder test_final.tsx

Deploy die Demo auf einer stabilen URL. Wenn der Link nach vier Wochen tot ist, war die halbe Arbeit umsonst. Nutze Environment-Variablen für Secrets und zeig im README, welche Werte gesetzt werden müssen.

So kommen Projekte in den Lebenslauf#

Ein Projekt im Lebenslauf ist kein Link allein. Es braucht eine Zeile, die Ergebnis und Umfang benennt, und eine zweite, die Technik nennt.

Schlecht: "Dashboard-Projekt mit React gebaut". Gut: "Dashboard für öffentliche Energiepreise mit Filterung, CSV-Export und Chart-Ansicht, gebaut mit React, TypeScript und TanStack Query, deployt auf Vercel, Lighthouse Performance 94".

Der Unterschied ist konkret. Der zweite Satz nennt Umfang, Technik und ein überprüfbares Ergebnis. Ein Reviewer kann in zehn Sekunden einschätzen, ob das stimmt.

Packe die drei Projekte unter eine Überschrift wie "Ausgewählte Projekte" direkt unter die Berufserfahrung oder, bei Berufseinsteigern, über die Ausbildung. Jedes Projekt bekommt Name, eine Zeile Ergebnis, Tech-Stack und zwei Links: Demo und Repository. Mehr braucht es nicht.

Wenn du Hilfe beim Formulieren brauchst, wirf einen Blick auf unsere Tipps für den Lebenslauf und lass deine Bewerbung gegen die Stellenanzeigen laufen, die dich interessieren. Für eine erste technische Einschätzung deiner Unterlagen gibt es bei uns auch einen kostenlosen ATS-Check.

Fehler, die Projekte nach Tutorial aussehen lassen#

Der häufigste Fehler: Das Projekt ist eine 1:1-Umsetzung aus einem YouTube-Kurs, inklusive gleicher Farben und gleichem Beispielnamen. Reviewer erkennen das sofort, weil sie dieselben Tutorials gesehen haben.

Andere Klassiker: Keine README-Erklärung, warum du etwas so gebaut hast. Kein Error-Handling, weil in der Demo ja immer alles funktioniert. Hardcodierte Daten, die aussehen wie echte, aber es nicht sind. Ein Deployment, das nur lokal läuft.

Auch gefährlich: Feature-Sammeln ohne Fokus. Ein Projekt mit Login, Chat, Echtzeit-Updates, Dark Mode und PWA, bei dem nichts davon sauber funktioniert, wirkt unruhiger als ein kleines Projekt, das eine Sache richtig macht.

Zuletzt: Generische Namen. "Weather App" oder "Task Manager" sagen nichts. Nenne das Projekt nach dem Problem, das es löst, oder gib ihm einen kurzen, eindeutigen Namen und beschreibe den Zweck in einem Satz.

Wie du über Projekte im Interview sprichst#

Bereite für jedes Projekt eine kurze Erzählung vor. Was war das Problem, was war deine Rolle, was war die schwierigste Entscheidung, was würdest du heute anders machen. Halte das auf zwei Minuten pro Projekt.

Rechne damit, dass jemand nach Details fragt: Warum diese State-Lösung, warum diese Bibliothek, was passiert bei 10 000 Einträgen, wie hast du Accessibility geprüft. Wenn du eine Antwort nicht weißt, sag das. "Habe ich nicht getestet, würde ich aber so rangehen" ist besser als eine erfundene Begründung.

Übe das laut. Nicht im Kopf. Nimm dir ein Job-Angebot aus unserer Datenbank, lies die Anforderungen durch und formuliere für jede relevante Anforderung einen Satz zu deinem Projekt. Wenn in der Anzeige "Erfahrung mit asynchronen Daten" steht, solltest du sofort ein Beispiel aus deinem Dashboard parat haben.

Wenn dir die Formulierungen für die Projekte im Lebenslauf schwerfallen, hilft ein Blick in unsere Ressourcen für Bewerbungen. Dort findest du Vorlagen für Projektsätze, die konkret bleiben und nicht ins Marketing abrutschen.

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 ein Frontend-Portfolio haben?

Drei saubere Projekte reichen in den meisten Fällen. Lieber drei Projekte mit klarem Fokus und guter Doku als zehn halbfertige Repositories, die den Leser nur verwirren.

Brauche ich ein eigenes Portfolio-Website oder reicht GitHub?

Eine schlichte eigene Seite hilft, weil sie zeigt, dass du auch Layout, Typografie und Responsivität beherrschst. Sie muss nicht aufwendig sein, eine Seite mit Kurzprofil, drei Projekten und Kontakt reicht völlig.

Müssen die Projekte originell sein?

Nein, aber sie sollten einen eigenen Winkel haben. Ein Klon einer bekannten App ist in Ordnung, wenn du eine eigene Erweiterung baust oder eine Entscheidung anders triffst als im Tutorial und das begründest.

Was mache ich, wenn meine Projekte nur aus der Ausbildung oder Weiterbildung stammen?

Das ist kein Ausschlusskriterium, solange du den Code aufräumst, dokumentierst und einen eigenen Beitrag benennen kannst. Beschreibe ehrlich, was vom Kurs kam und was du selbst entschieden hast.

Wie aktuell muss der Tech-Stack in meinen Projekten sein?

Er muss nicht jedes neue Framework widerspiegeln, aber er sollte zeigen, dass du mit einer modernen Version arbeitest und die Gründe für deine Wahl kennst. Prüfe die aktuellen Anforderungen in Stellenanzeigen, bevor du dich auf ein veraltetes Setup festlegst.