So bereitest du dich auf Interviews mit Take‑Home‑Aufgabe plus Live‑Review vor

Viele Vorstellungsgespräche kombinieren mittlerweile eine Take‑Home‑Aufgabe mit einer Live‑Review‑Session: du arbeitest alleine, dann erklärst du deine Entscheidungen und Ergebnisse vor dem Team. Das prüft sowohl dein eigenständiges Denken als auch deine Fähigkeit, Ergebnisse klar zu kommunizieren.

Diese Anleitung zeigt dir einen pragmatischen Ablauf: welche Fragen du vorab stellen solltest, wie du deine Abgabe strukturierst, wie du die Live‑Durchsicht aufbaust, wie du mit Kritik umgehst und wie du nach dem Termin am besten nachfasst.

Vor dem Start: Regeln und Erwartungen klären

Frag beim Recruiter kurz nach: Welche Abgaben erwarten sie genau (Code, Dokument, Slides, Demo) und wie lange ist die Live‑Review angesetzt? Das beeinflusst deine Reihenfolge und Prioritäten.

Klär auch, ob externe Bibliotheken erlaubt sind, ob Tests/CI grün sein sollen und ob sie die Dateien selbst ausführen. Manche Teams teilen eine Bewertungsskala — falls vorhanden, bitte darum.

• Frage: gewünschte Formate und Dateitypen (z. B. ausführbares Repo, PDF, Figma‑Link).
• Frage: Dauer der Live‑Review und Teilnehmer (Eng., PM, Design).
• Frage: erlaubte Hilfsmittel und ob Tests laufen müssen.
• Frage: wollen sie den Code ausführen oder nur Screenshots/Slides sehen?

Die Aufgabe so vorbereiten, dass die Live‑Review einfach wird

Mache es den Reviewern leicht: klare Datei‑Struktur, eine kurze Zusammenfassung oben und eine Demo‑Anleitung, damit sie Ergebnisse schnell sehen können. Ein schwer auffindbares Werk ist schon halb verloren.

Priorisiere Nachvollziehbarkeit über perfekte Optik. Eine funktionierende Minimalversion mit guten Erklärungen schlägt eine hübsche, aber undurchsichtige Abgabe. Überlege: welches Element willst du im Live‑Review als erstes zeigen? Mach das sofort verfügbar.

• Ganz oben: 2–3 Zeilen Problemzusammenfassung + 4–6 Bullet‑Punkte zu Ansatz und wichtigsten Ergebnissen.
• ‘How I tested this’‑Abschnitt: Befehle, Beispiel‑Inputs und erwartete Outputs.
• Markiere eine Datei/Slide als 'Walkthrough start here' für den schnellen Zugriff.
• Bei Repos: kleine, beschreibende Commits — Reviewer schauen gern in die Historie.

Die Live‑Vorstellung als klare Story planen

Vermeide lineares Durchklicken. Teile deine Präsentation in drei Akte: Kontext, Ergebnis, und die wichtigsten Entscheidungsgründe. So verstehen die Reviewer schnell, was du erreichen wolltest.

Plane außerdem Übergänge: nach einer kurzen Kontext‑Zusammenfassung zeigst du das Hauptergebnis, dann gehst du auf Architektur, Tests oder Nutzerfluss ein. Schließe mit 2–3 klaren nächsten Schritten, die du mit ihnen diskutieren möchtest.

• Kontext (1–2 Minuten): Prompt kurz wiederholen und Erfolgskriterien nennen.
• Showcase (2–5 Minuten): Demo oder Ergebnis zuerst zeigen.
• Deep dive (5–10 Minuten): Code‑Abschnitte, Wireframes oder Messmethoden erklären.
• Wrap (1 Minute): mögliche nächste Schritte und Einladung zu Fragen.

Kurze Sätze trainieren, die dir Zeit und Kontrolle geben

Unterbrechungen sind normal. Bereite kurze Formulierungen vor, mit denen du umformst, Zeit gewinnst oder den Fokus lenkst. Das hilft, gelassen zu bleiben und das Gespräch zu steuern.

Übe außerdem, wie du Trade‑offs kurz erklärst. Ein strukturierter, reflektierter Antwortaufbau wirkt besser als das Verteidigen einer einzigen 'richtigen' Lösung.

• Bei Unterbrechung: „Gute Frage — ich zeige kurz das Ergebnis und erkläre dann die Überlegungen.“
• Bei Gegenoptionen: „Das hatte ich auch im Blick. Mit mehr Zeit würde ich X testen, weil ich erwarte, dass…“
• Bei technischem Fehler: „Stimmt, das könnte passieren; ich würde zuerst A fixen und einen Test B ergänzen.“

Wenn sie dich bitten, live zu editieren oder zu laufen zu lassen

Manche Teams wollen, dass du live kleine Änderungen machst oder Code ausführst. Entscheide vorab, ob du das machen willst – und bereite eine saubere, reproduzierbare Umgebung vor (Anweisungen, Virtualenv, Docker).

Wenn du nicht live editieren möchtest, sage das offen und biete stattdessen eine vorbereitete Demo‑Branch oder eine klare Schritt‑für‑Schritt‑Änderung an, die du durchgehst.

• Leg eine Demo‑Branch oder Notebook an mit einer kleinen Änderung, die du vorführen kannst.
• Teste die nötigen Befehle auf einer sauberen Maschine, um Überraschungen zu vermeiden.
• Wenn du nicht live editierst: „Ich kann die Änderung gern durchgehen; hier sind die genauen Edit‑Schritte und Testbefehle.“

Kritik konstruktiv beantworten — eine kurze Struktur

Nimm Kritik mit einer einfachen vierstufigen Antwort: zustimmen/klären, das Problem zusammenfassen, deine Entscheidung erklären und einen konkreten nächsten Schritt vorschlagen. Das zeigt, dass du feedbackfähig und handlungsorientiert bist.

Diese Struktur hilft, das Gespräch produktiv zu halten und gibt dir einen Plan, wie du echte Unsicherheiten adressieren würdest.

• Zustimmen/klären: „Ich verstehe — Sie meinen also X, richtig?“
• Problem zusammenfassen: „Das Risiko wäre, dass Y unter Z‑Bedingungen passiert.“
• Erklärung: „Ich habe A gewählt wegen B‑Voraussetzungen und C‑Abwägungen.“
• Nächster Schritt: „Mit mehr Zeit würde ich Experiment D durchführen und Metrik E beobachten.“

Betrachte die Take‑Home‑Abgabe und die Live‑Review als eine zusammenhängende Präsentation: die Abgabe ist deine Forschung und Prototyp; das Live‑Review ist die Gelegenheit, dem Team zu zeigen, wie du denkst. Sorge dafür, dass beides leicht zu konsumieren ist.

Mach vor dem Einreichen einen Probedurchlauf unter Zeitdruck: öffne genau die Dateien, präsentiere in der gegebenen Zeit und beantworte ein paar Probe‑Fragen. Diese Übung spart dir peinliche Pausen und macht dich deutlich souveräner.