Design-Review im Interview: Vorlage für Senior Engineers

Bei einem Design-Review im Interview für Senior Engineers prüfen Kandidatinnen und Kandidaten einen vorgegebenen technischen Entwurf, priorisieren nötige Änderungen und erläutern ein umsetzbares Vorgehen. Geben Sie allen dieselben Anforderungen und bewerten Sie die Begründungen anhand offengelegter Kriterien. Aussagekräftig ist, wie jemand eine Entscheidung mit ihren Folgen verbindet.

Das Format passt zu einer bestimmten Aufgabe: den Entwurf eines anderen Engineers zu prüfen, bevor sich das Team darauf festlegt. Sie erhalten eine konkrete Gesprächsgrundlage, ohne Kandidaten ein ganzes System entwerfen oder vertrauliche Unterlagen eines früheren Arbeitgebers mitbringen zu lassen.

Michael Lynchs Leitfaden zum Verfassen wirksamer Software-Design-Dokumente wurde diese Woche erneut auf Hacker News diskutiert. In seinem Artikel vom Juni 2026 empfiehlt er, solche Dokumente auf folgenreiche Entscheidungen auszurichten und den Aufwand der Aufgabe anzupassen. Daraus ergibt sich eine hilfreiche Interviewfrage: Erkennt diese Person, welche Entscheidungen zuerst geprüft werden sollten?

Die folgende Aufgabe ist ein eigens entwickeltes, fiktives Beispiel zum Anpassen. Zeitangaben, Rahmenbedingungen und Bewertungsleitfaden sind redaktionelle Vorschläge, kein validierter Einstellungstest. Damit ist keine Aussage über Vorhersagegenauigkeit oder Einstellungsergebnisse verbunden.

Beginnen Sie mit der tatsächlichen Entwurfsverantwortung

Setzen Sie ein Design-Review ein, wenn die Prüfung von Entwürfen zur Stelle gehört. Der Titel „Senior“ allein sagt nicht, ob jemand Zugriffskontrollen, Datenverarbeitung, Interaktionen im Frontend oder Infrastrukturänderungen beurteilen muss.

Formulieren Sie mit den Personalverantwortlichen einen Satz: „Dieser Engineer wird vorgeschlagene Änderungen an unserem kundenbezogenen Backend prüfen und dem Team helfen zu entscheiden, was veröffentlicht werden kann.“ Klären Sie dann, welche Entscheidungen die Person von Beginn an beherrschen muss und welchen Kontext Sie vermitteln werden.

Die Hinweise zur Arbeitsplatzanalyse des US Office of Personnel Management verknüpfen Auswahlentscheidungen mit den tatsächlichen Aufgaben und den dafür nötigen Kompetenzen. Wenden Sie diesen Grundsatz gezielt an. Geht es in der Stelle hauptsächlich um Produktarbeit im Frontend, brauchen Sie eine andere Aufgabe als einen Backend-Export, selbst wenn Ihre Interviewer gern über Warteschlangen sprechen.

Auch die OPM-Hinweise zu Arbeitsproben beziehen sich auf Kompetenzen, die Bewerber schon beim Einstieg mitbringen sollen. Machen Sie die Kenntnis einer internen Konvention nicht zur versteckten Bestehensbedingung, wenn Sie diese erst nach der Einstellung vermitteln wollen.

Leiten Sie aus der Verantwortung beobachtbare Kriterien ab, bevor Sie jemanden einladen. Unser Leitfaden zum Erstellen idealer Kandidatenprofile hilft dabei. Grenzen Sie die Aufgabe so ein, dass Prüfer für jedes Kriterium erklären können, welchen Teil der ausgeschriebenen Stelle es betrifft.

Geben Sie Kandidaten vollständige Unterlagen

Liefern Sie den Kontext, der eine begründete Antwort ermöglicht. Die Unterlagen sollten das Ziel, die betrieblichen Grenzen, den Lösungsentwurf, die erwartete Antwort und die Arbeitsbedingungen enthalten.

Für einen ersten Probelauf können Sie 30 Minuten Vorbereitung und ein 30-minütiges Gespräch vorsehen. Das sind Ausgangswerte zum Erproben mit Kollegen, keine gemessenen Bearbeitungszeiten. Lassen sich die Unterlagen nicht im angekündigten Zeitrahmen prüfen, kürzen Sie sie vor dem Einsatz mit Kandidatinnen und Kandidaten.

Sagen Sie Kandidaten, dass kurze Notizen genügen und weder Foliendesign noch sprachlicher Feinschliff oder die Anzahl der Kommentare bewertet werden. Bieten Sie eine barrierefreie Textfassung an. Erklären Sie, wie sich Anpassungen an Format oder Zeitrahmen anfragen lassen, und nennen Sie einen Kontakt für Rückfragen.

Legen Sie fest, welche Regeln für Dokumentation, Websuche, KI-Unterstützung und Zusammenarbeit gelten. Stellen Sie Zugang bereit, wenn ein bestimmtes Werkzeug vorgeschrieben ist. Ein Gespräch kann zusätzliche Überlegungen sichtbar machen. Es belegt weder die Urheberschaft noch schließt es fremde Hilfe aus.

Verwenden Sie synthetische Daten und einen fiktiven Entwurf. Verlangen Sie keine internen Pläne des bisherigen Arbeitgebers und nutzen Sie die Aufgabe nicht, um eine Lösung für anstehende Aufgaben in Ihrem Produkt zu erhalten. Fragen zu Aufwand, Vergütung und Kommunikation behandelt unser Leitfaden zum Gestalten von Code-Aufgaben.

Erproben Sie diesen fiktiven Entwurf für einen Kundendatenexport

Lassen Sie einen klar begrenzten Entwurf prüfen, statt eine Exportplattform von Grund auf entwerfen zu lassen. Alles in diesem Abschnitt gehört in die Unterlagen für Kandidatinnen und Kandidaten, auch die Rahmenbedingungen, unter denen verschiedene Antworten sinnvoll sind.

Der vorgegebene Kontext

Ihr fiktives Unternehmen betreibt eine Geschäftsanwendung. Jede Kundenorganisation hat eigene Datensätze. Berechtigte Administratoren auf Kundenseite möchten die Datensätze ihrer Organisation in eine CSV-Datei exportieren, ein Textformat, das sich in einer Tabellenkalkulation öffnen lässt.

Für die erste Version gelten folgende Anforderungen und Grenzen:

• Ein Administrator kann einen Export der Datensätze seiner Organisation anfordern.
• Die Datei enthält vertrauliche Kundeninformationen. Eine Anmeldung allein berechtigt nicht zum Zugriff auf die Daten sämtlicher Organisationen.
• Der derzeit größte Kunde hat 200.000 Datensätze. Die Dauer der Exporterstellung und der maximale Speicherbedarf wurden noch nicht gemessen.
• Kunden können bis zu zehn Minuten warten, bis die Datei bereitsteht. Zeitgesteuerte Exporte sind für die erste Version nicht nötig.
• Die Anwendung verfügt bereits über Hintergrund-Worker und einen privaten Dateispeicher.
• Zwei Engineers haben eine Woche für die erste Version. Sie können den anfänglichen Umfang reduzieren, wenn sie die Folgen für Kunden erklären.
• Das Team hat noch nicht festgelegt, wie lange Dateien aufbewahrt werden und was geschieht, wenn ein Administrator nach der Exportanforderung seine Zugriffsrechte verliert.

Diese Zahlen beschreiben das erfundene Szenario. Sie sind keine Empfehlungen für die Größe Ihrer Anwendung, Lieferzusagen oder Personalbesetzung.

Der zu prüfende Entwurf

Fügen Sie dem Kundendashboard eine Export-Schaltfläche hinzu. Der Browser sendet eine Organisations-ID an einen neuen Endpunkt. Dieser prüft, ob die anfragende Person angemeldet ist, lädt die Datensätze dieser Organisation, erstellt die CSV-Datei und lädt sie in den Dateispeicher hoch. Anschließend gibt er eine Download-URL zurück.

Speichern Sie die URL im Benutzerprofil, damit das Dashboard den jüngsten Export anzeigen kann. Die URL bleibt unbegrenzt gültig. Bei einer Zeitüberschreitung zeigen Sie einen Fehler an und bitten den Benutzer, erneut auf Export zu klicken.

Nehmen Sie alle verfügbaren Felder auf, um spätere Nachforderungen zu vermeiden. Ergänzen Sie einen Test, der zeigt, dass ein angemeldeter Benutzer einen Download-Link erhält. Fügen Sie nach der Veröffentlichung wiederkehrende Exporte und einen konfigurierbaren Exporteditor hinzu.

Der Entwurf ist absichtlich unvollständig. Sagen Sie das ausdrücklich. Kandidaten sollen ihn verbessern und nicht erraten, ob der Interviewer ihn insgeheim bereits für korrekt hält.

Die erwartete Antwort

Bitten Sie um vier Dinge:

1. Nennen Sie die drei Änderungen, die Sie vor der ersten Veröffentlichung priorisieren würden. Erläutern Sie, welche Folge jede davon verhindern oder abmildern soll.
2. Empfehlen Sie ein Vorgehen für die Veröffentlichung, das zu den vorgegebenen Grenzen passt. Sagen Sie, was Sie weglassen würden.
3. Nennen Sie eine offene Frage, deren Antwort Ihre Empfehlung ändern könnte.
4. Beschreiben Sie, welche Nachweise Sie vor einer Freigabe erwarten würden, etwa Tests oder Messungen.

Eine Implementierung ist nicht verlangt. Kandidaten können eine Skizze, Stichpunkte oder ein kurzes Dokument verwenden. Annahmen dürfen sie ausdrücklich benennen, aber keine vorgegebene Anforderung stillschweigend ändern, damit die bevorzugte Architektur passt.

Achten Sie auf Prioritäten mit Bezug zum Entwurf

Ein hilfreiches Review unterscheidet zwischen Hindernissen für die Veröffentlichung, offenen Fragen, Verbesserungen und späterer Arbeit. Zwölf Bedenken zu finden ist nicht automatisch besser, als drei folgenreiche Punkte zu erkennen und einen schlüssigen Umgang damit vorzuschlagen.

In dieser Aufgabe ist der Zugriff ein konkretes Problem. Der Entwurf vertraut einer vom Browser gelieferten Organisations-ID und beschreibt lediglich eine Anmeldeprüfung. Kandidatinnen und Kandidaten sollten diese Lücke mit der Anforderung verbinden, dass Administratoren nur auf Datensätze ihrer eigenen Organisation zugreifen dürfen. „Sicherheit ergänzen“ sagt weniger aus als eine Erklärung, wo Berechtigungen geprüft werden müssen.

Auch die Erstellung innerhalb der Webanfrage verdient eine Prüfung. Die genannte Datensatzanzahl und die fehlenden Messungen beweisen nicht, dass eine synchrone Erstellung scheitern wird. Sie zeigen aber, dass der Entwurf noch nicht belegt, ob sie innerhalb der Anfragegrenzen zuverlässig abgeschlossen werden kann. Achten Sie darauf, ob Kandidaten ein beobachtetes Problem von einem noch zu untersuchenden Risiko unterscheiden.

Der unbegrenzt gültige Link und das ungeklärte Verhalten bei Rechteentzug machen eine fehlende Produktentscheidung sichtbar. Ein gutes Review fragt, wer eine fertige Datei wie lange herunterladen dürfen soll. Es sollte keine Aufbewahrungsregel erfinden und diese Vorliebe als bereits vorgegebene Anforderung darstellen.

Googles Leitfaden für Code-Reviews nennt Entwurf, Funktionalität, Grenzfälle und Komplexität als Prüfpunkte. Dazu zählt unnötige Arbeit für nur vermutete künftige Bedürfnisse. Diese Aspekte sind auch hier hilfreich. Der Leitfaden behandelt technische Reviews, nicht die Validität dieser Einstellungsaufgabe.

Ein konfigurierbarer Exporteditor kann in diesem Fall warten: Die erste Version verlangt ihn nicht. Wer im Review vor allem diesen Editor entwirft, sollte erklären, warum er vor den genannten Zugriffs- und Bereitstellungsfragen Zeit verdient.

Lassen Sie mehrere begründbare Veröffentlichungspläne zu

Bewerten Sie, ob der Plan zu den Grenzen passt, nicht ob er Ihrer bevorzugten Implementierung entspricht. Halten Sie vor den Interviews plausible Alternativen fest, damit Prüfer aus einer unausgesprochenen Vorliebe keine Anforderung machen.

Eine Kandidatin oder ein Kandidat könnte vorschlagen, die vorhandenen Worker zur Erstellung im Hintergrund zu nutzen, jede Exportanforderung zu speichern, Dateien privat abzulegen und Downloads über eine Route mit Berechtigungsprüfung anzubieten. Dazu gehören Erklärungen zum Umgang mit wiederholten Anforderungen, zur Anzeige von Fertigstellung oder Fehlern und zu Messungen, die das Zehn-Minuten-Ziel belegen.

Eine andere Antwort könnte zunächst eine kleinere Version für Kunden unter einer ausdrücklich benannten Größenbegrenzung vorsehen. Messungen würden dann klären, wie viel Arbeit ein Hintergrundjob übernehmen muss. Die Einschränkung muss klar sein: Der größte Kunde wird damit noch nicht bedient. Kandidaten müssen Zustimmung zum reduzierten Umfang einholen, statt die ursprüngliche Anforderung als erfüllt darzustellen.

Beide Pläne brauchen weiterhin die passenden Berechtigungsprüfungen und eine ausdrückliche Entscheidung über den Dateizugriff im Zeitverlauf. Eine einfachere Implementierung entschuldigt keine fehlenden Anforderungen. Eine aufwendigere erhält nicht allein deshalb zusätzliche Punkte, weil sie mehr Komponenten umfasst.

Vergleichen Sie die Begründungen. Erklärt die Person, was schiefgehen kann, wer es bemerken würde und welche Erkenntnisse die Entscheidung ändern? Benennt sie die Kosten der eigenen Empfehlung? Das ist hilfreicher als das Zählen von Architekturbegriffen.

Auch begründeten Widerspruch können Sie festhalten. Stellt jemand das Zehn-Minuten-Ziel oder die einwöchige Frist infrage, fragen Sie nach der Botschaft an die Produktverantwortlichen und einer Alternative. Eine Vorgabe zu hinterfragen ist etwas anderes, als sie zu übersehen.

Stellen Sie dieselben zentralen Vertiefungsfragen

Planen Sie das Gespräch, bevor Sie die Antwort sehen. Halten Sie die Kernfragen einheitlich und nutzen Sie Verständnisfragen, um die tatsächlich vorgetragenen Überlegungen nachzuvollziehen.

Die OPM-Hinweise zu strukturierten Interviews beschreiben vorab festgelegte Fragen und gemeinsame Bewertungsmaßstäbe. Für diese Aufgabe können Sie den Grundsatz mit einem kurzen Gesprächsleitfaden umsetzen:

• Welchen Punkt würden Sie zuerst lösen, und warum hat er Vorrang?
• Was würde Sie zu einem anderen Vorgehen für die Veröffentlichung bewegen?
• Wo hängt Ihr Plan von Informationen ab, die wir nicht geliefert haben?
• Was würden Sie von einem anderen Spezialisten prüfen lassen?

Geben Sie anschließend allen Kandidatinnen und Kandidaten dieselbe zusätzliche Information: „Die Produktverantwortlichen bestätigen: Administratoren, die ihre Zugriffsrechte verlieren, dürfen auch zuvor erstellte Exporte nicht mehr herunterladen.“ Fragen Sie, was sich dadurch am Plan ändert und was getestet werden muss.

Kündigen Sie vorher an, dass im Gespräch eine weitere Anforderung hinzukommt. Die zusätzliche Anforderung soll Gelegenheit geben, eine Entscheidung zu überarbeiten, statt Kandidaten überraschend auf die Probe zu stellen. Halten Sie fest, ob jemand eine Änderung erklärt, eine bereits vorhandene Absicherung benennt oder weitere Informationen benötigt.

Erfinden Sie für Kandidaten, die Sie beeindrucken, keine zunehmend schwierigeren Szenarien. Wenn eine Person einen regionalen Ausfall und eine andere eine Textänderung behandeln muss, beziehen sich die Bewertungen auf unterschiedliche Aufgaben.

Stützen Sie Bewertungen auf Beobachtungen

Legen Sie vor der Nachbesprechung fest, was jeder Punktwert bedeutet. Zu einem Kriterium sollte eine nachvollziehbare Notiz entstehen, keine Zuschreibung wie „tritt wie ein Senior auf“.

Die folgende Tabelle ist ein Vorschlag für den Einstieg. Passen Sie die Dimensionen an die Stelle an und erproben Sie die Beschreibungen. „Unzureichende Grundlage“ muss als Antwort möglich bleiben, wenn Aufgabe oder Gespräch nicht genug für eine Beurteilung gezeigt haben.

Eine Beobachtung könnte lauten: „Hat erkannt, dass die Organisations-ID eine Berechtigungsprüfung erfordert; verlangt einen Test mit einem Administrator einer anderen Organisation.“ Eine andere: „Hat eine Warteschlange empfohlen, aber keinen Bezug zur Anfragedauer hergestellt und die Fehlerbehandlung nicht erklärt.“

Trennen Sie diese Beobachtungen von der endgültigen Einstellungsentscheidung. Eine Aufgabe bildet einen Teil der Stelle ab. Sie klärt weder Programmierfähigkeit noch sämtliche Fähigkeiten zur Zusammenarbeit oder die Eignung für jede Senior-Verantwortung. Unser Leitfaden zu strukturierten Scorecards zeigt, wie Sie Kriterien im gesamten Prozess ordnen können.

Stimmen Sie die Prüfer vor dem Einsatz aufeinander ab

Prüfen Sie, ob die Prüferinnen und Prüfer die Unterlagen verstehen und die Bewertungsbeschreibungen einheitlich anwenden. Lassen Sie Kollegen die Aufgabe bearbeiten, den tatsächlichen Aufwand notieren und die Antworten unabhängig bewerten, bevor sie darüber sprechen.

Gehen Bewertungen auseinander, untersuchen Sie den Grund. Hat jemand die Nennung eines bestimmten Dienstes belohnt? Hat ein anderer eine nicht genannte Anforderung vorausgesetzt? War die Antwort mehrdeutig oder die Bewertungsbeschreibung zu weit gefasst? Verbessern Sie Aufgabe oder Leitfaden, bevor Kandidaten dasselbe Problem erleben.

Bewahren Sie bei jeder Bewertung die zugehörige Version der Unterlagen und des Gesprächsleitfadens auf. Ändern Sie Anforderungen zwischen Interviews, dokumentieren Sie das und prüfen Sie, ob frühere Bewertungen vergleichbar bleiben. Verbessern Sie Anweisungen nicht stillschweigend mitten in einer Einstellungsrunde.

Fragen Sie die Teilnehmer des Probelaufs, wo Kontext fehlte und welche Anweisungen unnötig Zeit kosteten. Entfernen Sie Arbeit, die zu keinem offengelegten Kriterium beiträgt. Der Probelauf verbessert die Durchführung. Er beweist weder Vorhersagekraft noch die Abwesenheit von Verzerrungen.

Setzen Sie Prüfer ein, die mit den zu bewertenden Entscheidungen vertraut sind. Wird aus der Aufgabe eine spezialisierte Sicherheitsprüfung, beziehen Sie einen qualifizierten Prüfer ein und machen Sie die Anforderung ausdrücklich. Alternativ grenzen Sie die Aufgabe ein. Die Personalverantwortlichen müssen sicherstellen, dass Stelle, Aufgabe und Prüfungsteam zusammenpassen.

Organisieren Sie die Design-Review-Phase in Kit

Ordnen Sie Aufgabenbeschreibung, Kriterien und Beobachtungen der jeweiligen Kandidatenphase zu. Das Einstellungsteam muss weiterhin eine passende Aufgabe verfassen und entscheiden, welche Schlüsse die Beobachtungen tragen.

In Kit hinterlegen Sie das vorgegebene Dokument in der privaten Aufgabenbeschreibung einer Arbeitsprobe und sammeln die schriftliche Kritik als Upload oder Antwortlink. Weisen Sie Prüfer und Bewertungskriterien zu und planen Sie das Gespräch als Live-Interview. Kriterien unterstützen Beschreibungen, Gewichtungen und Skalen; den Bewertungsleitfaden erstellt Ihr Team.

Während einer laufenden Bewertungsrunde geben Prüfer ihre eigene Bewertung ab, bevor sie die abgeschlossenen Bewertungen der anderen sehen. Das unterstützt den vorgesehenen Ablauf, belegt aber weder Fairness noch Richtigkeit. Kit stellt keinen validierten Design-Review-Test bereit und beurteilt Architektur nicht automatisch.

Schließen Sie Aufgabenbeschreibung und Bewertungsleitfaden der Arbeitsprobe vor den Einladungen ab: Die Bewertungsbedingungen werden gesperrt, sobald der erste Kandidat die Phase erreicht. Wenn Sie eine Vergütung konfigurieren, erfasst Kit die Auszahlungsanforderung; Ihr Team überweist das Geld.

Beginnen Sie mit einer Verantwortung, einem vorgegebenen Entwurf und einer kurzen Liste von Entscheidungen, die Kandidaten erklären können sollten. Erproben Sie die Aufgabe mit den Prüfern, beseitigen Sie Unklarheiten und sagen Sie Kandidaten genau, welche Arbeit Sie erwarten.