Wie du Nebenprojekte und Open‑Source‑Beiträge im Vorstellungsgespräch präsentierst

Nebenprojekte und Beiträge zu Open‑Source sind oft der beste Beweis dafür, dass du etwas wirklich kannst — vorausgesetzt, du präsentierst sie richtig. Recruiter und Hiring Manager wollen sehen, was du tatsächlich gemacht hast, welche Entscheidung du getroffen hast und was dabei herauskam.

Dieser Leitfaden zeigt, wie du die passenden Projekte auswählst, kurze, klare Erklärungen baust und welche Artefakte (Demo, Code, Diagramm) du bereit haben solltest, damit deine Arbeit im Gespräch überzeugt.

Wähle die richtigen Projekte aus

Nicht jedes Projekt ist gleich wertvoll im Interview. Wähle 2–3 Arbeiten, die direkt zu den Hauptaufgaben der Stelle passen. Für Backend‑Rollen etwa Projekte zu Architektur, Datenmodell oder Performance; für Produktrollen Projekte mit Nutzerforschung und Iteration.

Bevorzuge Arbeiten, bei denen deine Rolle klar ist und die greifbare Ergebnisse liefern. Ein kleines, komplettes Projekt, das du alleine verantwortet hast, ist oft stärker als ein unfertiges Großprojekt mit unklaren Beiträgen.

Bei Open‑Source‑Beiträge nimm solche mit nachvollziehbarem Kontext: ein Bugfix, eine neue Funktion oder Verbesserungen in der Dokumentation, die den Einstieg für andere erleichtern.

• Relevanz: passt zur ausgeschriebenen Rolle
• Verantwortung: du kannst Entscheidungen erklären
• Auswirkung: möglichst messbar (Nutzer, Performance, Bug‑Reduktion)
• Aktualität: idealerweise innerhalb der letzten 1–2 Jahre

Erstelle eine 60‑Sekunden‑Story pro Projekt

Interviewende haben wenig Zeit. Bereite für jedes Projekt eine prägnante 60‑Sekunden‑Story vor: Kontext, deine Rolle, die zentrale Herausforderung und das Ergebnis. Kurz wie eine Mini‑Fallstudie.

Aufbau: 1) Ein-Satz‑Kontext, 2) konkrete Maßnahmen, 3) konkretes Ergebnis oder Lernpunkt. Vermeide vage Aussagen wie „Ich habe Performance verbessert“ ohne Zahlen oder Relevanz.

Beispiel: „Ich habe ein Hintergrundjob‑System gebaut (Kontext). Ich habe Retry‑Logik und Sharding eingeführt, um Duplikate zu vermeiden und Fehler zu isolieren (Maßnahmen). Das reduzierte fehlgeschlagene Jobs um 70% und sparte dem Team wöchentlich Zeit beim Debuggen (Ergebnis).“

• Nenne Zahlen oder konkrete Beispiele, wenn möglich
• Sprich in klarer, einfacher Sprache – setz keine Kenntnisse voraus
• Schließe mit einer kurzen Erkenntnis oder einem Trade‑off ab

Wähle die richtige Form der Darstellung: Demo, Code oder Diagramm

Je nach Interviewphase passt eine andere Form besser. Im Telefon‑Screen reicht die Story. In technischen Interviews oder Onsite‑Runden funktionieren Demos, Architekturdiagramme oder Code‑Walkthroughs besser.

Bereite 1–2 Screenshots oder ein kurzes Screen‑Recording vor, das in Sekunden zeigt, worum es geht. Für Code wähle bewusst einen kleinen Ausschnitt (20–40 Zeilen), der eine nicht triviale Entscheidung zeigt — z. B. Fehlerbehandlung oder einen Algorithmus.

Für Architektur: zeichne ein einfaches Diagramm mit Komponenten und Datenfluss. Markiere, wo die Herausforderung lag, welche Kompromisse du eingegangen bist und wo du Monitoring/Tests platziert hast.

• Demo: maximal 60–90 Sekunden, Fokus auf Nutzerfluss oder Ergebnis
• Code: kleiner, kommentierter Ausschnitt; erkläre die Entscheidungsgründe
• Diagramm: klare Boxen/Pfeile, Beschriftungen zu Problemzonen und Messpunkten

Der Walkthrough: Erzählung plus technische Details

Wenn dich jemand durch dein Projekt führen lässt, beginne mit der 60‑Sekunden‑Story und biete dann an, in Architektur, Tests, Deployment oder in einen besonders kniffligen Bug zu gehen — je nachdem, was der Gesprächspartner möchte.

Erkläre deine Entscheidungen: Warum dieses Framework? Wie hast du Randfälle behandelt? Welche Tests hast du geschrieben? Nenne Einschränkungen wie Deadline oder kleine Teamgröße, damit deine Trade‑offs nachvollziehbar werden.

Bei Open‑Source‑Arbeit beschreibe den Kollaborationskontext: wie das Issue entstanden ist, wie Maintainer reagiert haben und was du über Kommunikation im Shared‑Code‑Umfeld gelernt hast.

• Kurz anfangen, dann fragen: „Soll ich Code, Diagramm oder die Demo zeigen?“
• Erkläre Trade‑offs explizit: Performance vs. Einfachheit, Zeit vs. Vollständigkeit
• Nenne Tests, Monitoring und Fehlerbehandlung, um Produktionsbewusstsein zu zeigen

Bereite Antworten auf typische Nachfragen vor

Interviewer fragen oft nach Skalierung, Randfällen und Wartbarkeit. Formuliere kurze Antworten auf Fragen wie: Was passiert bei Traffic‑Spitzen? Wie würdest du Multi‑Region unterstützen? Wie hast du Rennen und Nebenläufigkeit getestet?

Überlege dir zudem, was du mit mehr Zeit oder einem größeren Team anders gemacht hättest. Das zeigt strategisches Denken und wie du Lösungen hochskalierst.

Wenn du dich bei einer Zahl oder einem Commit nicht erinnerst: sag das offen. Schätzungen sind ok und du kannst anbieten, den Link nach dem Gespräch zu schicken.

• Habe einen kurzen Plan für Skalierung und Observability parat
• Nenne ein oder zwei Testfälle und warum du sie gewählt hast
• Erkläre, wie du Dokumentation oder Onboarding für andere angelegt hast

Mach deine Artefakte interviewfreundlich

Rechne damit, dass Interviewende wenig Zeit haben. Oben in der README sollte stehen: Ein‑Satz‑Zusammenfassung, Demo/GIF, wie man lokal startet (falls nötig) und wo die relevanten Dateien liegen.

Für Code‑Snippets füge inline‑Kommentare oder eine kurze Notiz hinzu, die den Zweck der Funktion und die kritischen Zeilen markiert. Bei Open‑Source‑Contributions verlinke Issue und Diskussion.

Achte darauf, dass deine persönliche Website mobil nutzbar ist und das relevante Projekt ohne langes Suchen erreichbar ist.

• README oben: TL;DR, Demo, Startanleitung, Pfad zu Schlüsselfiles
• Markiere spezifische Commits oder Dateien, damit Interviewer nicht suchen müssen
• Screenshots oder GIFs machen einen schnellen, guten Eindruck

Nebenprojekte und Open‑Source sind starke Beweise dafür, dass du liefern kannst. Entscheidend ist nicht nur, was du gemacht hast, sondern wie du es präsentierst.

Wähle relevante Arbeiten, bereite kurze Storys und schnelle Demos oder Codeausschnitte vor und übe Antworten auf Nachfragen. So wird deine persönliche Arbeit zum überzeugenden Argument im Vorstellungsgespräch.