Wenn eine Lösung alle Tests besteht, lassen Sie den Kandidaten eine klar definierte Änderung umsetzen, das neue Verhalten ebenso wie den bestehenden Vertrag testen und die Übergabe erläutern. Gute Anschlussfragen im Coding-Interview zeigen, wie jemand mit einer vorhandenen Implementierung arbeitet. Leiten Sie die Änderung aus den Aufgaben der Stelle ab und bewerten Sie alle anhand derselben Nachweise. Die [Hacker-News-Diskussion über das *Competitive Programmer's Handbook*](https://news.ycombinator.com/item?id=49944049) rückt das Üben von Algorithmen wieder in den Blick. Antti Laaksonens Buch liegt als Entwurf vom 3. Juli 2018 vor. Die [Einleitung](https://www.cses.fi/book/book.pdf#page=13) beschreibt Wettbewerbsprogrammierung als Entwurf und Implementierung von Algorithmen, deren Lösungen auf Korrektheit getestet werden. Sie erklärt außerdem, dass Wettbewerbsprogramme kurz sind und anschließend nicht gewartet werden müssen. Aus dieser letzten Unterscheidung ergibt sich eine nützliche Interviewfrage. Wenn Sie jemanden einstellen, der ein Produkt warten soll: Was passiert, wenn eine korrekte Lösung geändert werden muss? Prüfen Sie algorithmisches Denken dort, wo die Stelle es erfordert. Sammeln Sie anschließend Nachweise dafür, wie jemand arbeitet, sobald andere Entwickler auf den Code angewiesen sind. ## Was sagt Ihnen eine Lösung, die alle Tests besteht? Eine solche Lösung zeigt, dass eine Implementierung die getesteten Fälle erfüllt. Sie kann auch eine Grundlage sein, um über Korrektheit und Komplexität zu sprechen. Das sind belastbare Beobachtungen, doch einige Fragen zur Wartung bleiben offen. Sie haben noch nicht gesehen, wie Kandidatinnen und Kandidaten einen Vertrag lesen, den sie nicht selbst festgelegt haben. Vielleicht wissen Sie noch nicht, ob sie eine neue Anforderung von einer unbeabsichtigten Verhaltensänderung unterscheiden können. Eine fertige Lösung verrät außerdem wenig darüber, welche Notiz sie dem nächsten Entwickler hinterlassen würden. Das Handbuch beschreibt seinen eigenen Anwendungsbereich klar. Bei einer Wettbewerbsaufgabe zählt eine korrekte Implementierung unter den vorgegebenen Bedingungen. Ihre Auswahlaufgabe sollte die Tätigkeiten abbilden, die die neue Person übernehmen soll. Beide Ziele können nebeneinander bestehen. Bei einer Stelle in der Entwicklung eines Buchungsdienstes kann es sinnvoll sein, den Erhalt der bestehenden API-Semantik als eigenes Bewertungskriterium festzulegen. Bei einer Stelle mit Schwerpunkt Algorithmenentwicklung können die Herleitung und Analyse eines Algorithmus weiterhin im Mittelpunkt stehen. Legen Sie diese Ziele fest, bevor Sie die Aufgabe auswählen. Dieser Artikel verwendet ein fiktives Buchungsbeispiel. Er schlägt praktische Aufgabenunterlagen für ein Interview vor, kein validiertes Auswahlverfahren. Es gibt hier keine Belege dafür, dass diese konkrete Aufgabe Produktivität vorhersagt, Verzerrungen beseitigt oder zu besseren Einstellungen führt. Eine breitere Diskussion der Bewertungsformate finden Sie in unserem [Leitfaden zu Coding-Interviews im KI-Zeitalter](/blog/leetcode-obsolete-post-ai-interview). Hier geht es um einen kleineren Ausschnitt: eine vorhandene Funktion, eine gewünschte Änderung, einen Test und eine Übergabe. ## Wählen Sie Wartungsarbeit, die zur Stelle gehört Beginnen Sie mit einer Tätigkeit, die die neue Person bereits beim Einstieg beherrschen muss. Machen Sie daraus eine kleine, beobachtbare Aufgabe und entfernen Sie Einrichtungsarbeit, die damit nichts zu tun hat. Die [Hinweise zur Arbeitsplatzanalyse](https://www.opm.gov/policy-data-oversight/assessment-and-selection/job-analysis/) des US Office of Personnel Management verknüpfen berufliche Aufgaben mit den dafür erforderlichen Kompetenzen. Auf Software übertragen könnten Sie etwa den Erhalt eines API-Vertrags, die Erweiterung eines Datenmodells oder die Dokumentation der Folgen einer Codeänderung wählen. Diese Softwarebeispiele sind unsere Anwendung der Hinweise. Für diese Aufgabenunterlagen lautet das Ziel: **Verhalten ändern und dabei einen dokumentierten Vertrag erhalten**. Sie möchten sehen, ob Kandidatinnen und Kandidaten die betroffenen Datensätze erkennen, die Änderung umsetzen und das bisherige Verhalten mit Tests absichern können. Außerdem möchten Sie eine verständliche Beschreibung der Änderung. Dafür müssen Kandidaten weder Ihre Produktionsumgebung einrichten noch eine undokumentierte Geschäftsregel erraten. Stellen Sie einen funktionierenden Testbefehl, ein kleines Repository und die relevanten Regeln bereit. Falls die Installation scheitert, klären Sie das, bevor Sie die Codeänderung bewerten. Die [Hinweise des OPM zu Arbeitsproben](https://www.opm.gov/policy-data-oversight/assessment-and-selection/other-assessment-methods/work-samples-and-simulations/) beschreiben Aufgaben, die der tatsächlichen Arbeit ähneln. Sie warnen außerdem davor, Kompetenzen zu prüfen, die Sie erst nach der Einstellung vermitteln wollen. Wenn zur Stelle gehört, Ihr Framework nach dem Einstieg zu erlernen, dürfen Sie Framework-Kenntnisse nicht stillschweigend zum entscheidenden Kriterium machen. Machen Sie den Umfang für Kandidaten deutlich. Geben Sie an, welche Dateien relevant sind, was eingereicht werden soll und wie Sie es bewerten. Erläutern Sie, ob Dokumentation, Suche und KI-Unterstützung erlaubt sind. Unser [Leitfaden zur Gestaltung von Arbeitsproben](/blog/whiteboard-interview-dead-work-sample-design-2026) behandelt diese übergeordneten Formatentscheidungen. ## Geben Sie allen dieselbe funktionierende Implementierung Stellen Sie allen Kandidatinnen und Kandidaten die Implementierung samt Tests bereit. Die Wartungsaufgabe sollte von einer gemeinsamen Ausgangsbasis ausgehen. So hängen die gewonnenen Nachweise nicht davon ab, ob zuvor ein Algorithmusrätsel gelöst wurde. Die fiktiven Aufgabenunterlagen sehen so aus: Ein Buchungsdienst speichert Zeitintervalle als Ganzzahlen. Die Funktion gibt zurück, ob alle Buchungen in einem Raum möglich sind. Die folgende Ausgangsversion läuft mit der Python-Standardbibliothek; die Sprache dient als Beispiel und ist keine Vorgabe für das Auswahlverfahren. ### Bestehender Vertrag Schreiben Sie diese Regeln neben die Funktion in die README: - Jeder Datensatz enthält `start` und `end`, wobei `start < end` gilt. - Intervalle sind halboffen: Eine Buchung, die bei `20` endet, kann denselben Raum nutzen wie eine, die bei `20` beginnt. - Datensätze können in beliebiger Reihenfolge eintreffen. - Die Funktion gibt einen booleschen Wert zurück und belässt die Eingabeliste in ihrer ursprünglichen Reihenfolge. - Ungültige Intervalle sind nicht Teil dieser Aufgabe. Sie dürfen davon ausgehen, dass die genannte Vorbedingung erfüllt ist. Diese Regeln klären Fragen, deren Antworten Kandidaten sonst erraten müssten. Insbesondere sind unmittelbar aufeinanderfolgende Buchungen erlaubt, und das Sortieren darf die Liste des Aufrufers nicht verändern. ### Vorgegebene Lösung und Ausgangstests ```python # bookings.py def can_share_room(bookings): ordered = sorted(bookings, key=lambda booking: booking["start"]) return all( previous["end"] <= current["start"] for previous, current in zip(ordered, ordered[1:]) ) ``` ```python # test_bookings.py import unittest from bookings import can_share_room class BookingTests(unittest.TestCase): def test_empty_and_single_booking(self): self.assertTrue(can_share_room([])) self.assertTrue(can_share_room([{"start": 10, "end": 20}])) def test_adjacent_bookings_can_share(self): self.assertTrue(can_share_room([ {"start": 10, "end": 20}, {"start": 20, "end": 30}, ])) def test_overlapping_bookings_cannot_share(self): self.assertFalse(can_share_room([ {"start": 10, "end": 20}, {"start": 15, "end": 25}, ])) def test_unsorted_input_keeps_its_order(self): bookings = [ {"start": 20, "end": 30}, {"start": 10, "end": 20}, ] original = [booking.copy() for booking in bookings] self.assertTrue(can_share_room(bookings)) self.assertEqual(original, bookings) if __name__ == "__main__": unittest.main() ``` Die README nennt einen Befehl: `python -m unittest`. Führen Sie ihn selbst aus, bevor Sie das Repository übergeben. Kandidaten sollten eine Ausgangsversion vorfinden, bei der alle Tests bestehen und die weder das Herunterladen von Abhängigkeiten noch verborgene Zugangsdaten benötigt. Lassen Sie erklären, warum nach dem Sortieren ein Vergleich benachbarter Intervalle ausreicht, um Überschneidungen zu erkennen. Überschneidet sich ein späteres Intervall mit einem früheren, muss in der sortierten Folge auch eine Überschneidung zwischen Nachbarn auftreten. Sie können außerdem über den Aufwand des Sortierens und die zusätzliche Liste im Speicher sprechen, falls diese Konzepte für die Stelle relevant sind. Halten Sie das Gespräch über den Algorithmus getrennt von den Beobachtungen zur Wartung fest. Ein Kandidat kann den Algorithmus klar erklären und trotzdem die Kompatibilität übersehen. Ein anderer kann den Vertrag sorgfältig erhalten, aber bei der Erklärung der Komplexität Unterstützung brauchen. Getrennte Kriterien ermöglichen eine präzisere Bewertung. ## Verlangen Sie eine Änderung und Tests, die sie absichern Formulieren Sie einen präzisen Auftrag: Stornierte Buchungen sollen den Raum nicht mehr belegen, während ältere Datensätze ihre bisherige Bedeutung behalten. Bitten Sie um eine gezielte Codeänderung und Tests, die das geänderte Verhalten von dem unterscheiden, das erhalten bleiben muss. Verwenden Sie diesen Auftrag wörtlich in der fiktiven README: > Datensätze dürfen jetzt ein boolesches Feld `cancelled` enthalten. Ein Datensatz mit `cancelled: True` belegt den Raum nicht. Ein fehlendes Feld oder `cancelled: False` bedeutet, dass die Buchung ihn weiterhin belegt. Erhalten Sie die bestehenden Intervallregeln und die Eingabereihenfolge. Gehen Sie davon aus, dass die übergebenen Stornierungswerte boolesch sind. Ergänzen Sie Tests und eine kurze Übergabenotiz. Damit bleibt die Aufgabe auf eine Verhaltensänderung begrenzt. Kandidatinnen und Kandidaten müssen keine Stornierungsberechtigungen, Datumsverarbeitung, Speicherung oder ein neues Antwortformat entwerfen. Falls ihnen diese Fragen auffallen, können sie sie sinnvoll in der Übergabenotiz ansprechen. ### Eine gezielte Implementierung Eine mögliche Lösung filtert vor dem Sortieren: ```python def can_share_room(bookings): active = [ booking for booking in bookings if not booking.get("cancelled", False) ] ordered = sorted(active, key=lambda booking: booking["start"]) return all( previous["end"] <= current["start"] for previous, current in zip(ordered, ordered[1:]) ) ``` Der Standardwert für das fehlende Feld erhält das Verhalten älterer Datensätze. Das Filtern lässt die Liste des Aufrufers unverändert. Die Überschneidungsprüfung kann ihre ursprüngliche Bedeutung behalten, weil sie jetzt nur noch Datensätze erhält, die den Raum belegen. Dies ist eine Musterlösung zur Vorbereitung der Aufgabe. Geben Sie sie nicht mit den Aufgabenunterlagen an Kandidaten weiter. Akzeptieren Sie andere Implementierungen, die den Vertrag erfüllen; Vorlieben bei Benennung und Formatierung dürfen nicht stillschweigend zu neuen Anforderungen werden. ### Tests, die die Änderung nachweisen Ergänzen Sie die vorgegebene Testklasse um diese Methoden: ```python def test_cancelled_overlap_does_not_block_room(self): self.assertTrue(can_share_room([ {"start": 10, "end": 20}, {"start": 15, "end": 25, "cancelled": True}, ])) def test_explicit_false_still_blocks_room(self): self.assertFalse(can_share_room([ {"start": 10, "end": 20}, {"start": 15, "end": 25, "cancelled": False}, ])) def test_all_cancelled_bookings_leave_room_available(self): self.assertTrue(can_share_room([ {"start": 10, "end": 20, "cancelled": True}, {"start": 15, "end": 25, "cancelled": True}, ])) ``` Der erste neue Test schlägt mit der vorgegebenen Implementierung fehl. Das ist ein nützlicher Nachweis: Der Test prüft die gewünschte Änderung. Der zweite sichert explizit aktive Datensätze ab, während der ursprüngliche Überschneidungstest Datensätze ohne Stornierungsfeld schützt. Die ursprünglichen Tests für angrenzende Intervalle und die Reihenfolge bleiben wichtig. Sie decken Teile des Vertrags ab, die der Auftrag nicht verändert hat. Lassen Sie den Kandidaten zeigen, welche Zusicherungen die neue Regel nachweisen und welche die bisherigen Regeln absichern. Sie können besprechen, ob ein Test ergänzt werden sollte, der bestätigt, dass auch stornierte Datensätze in der Liste des Aufrufers bleiben. Damit wäre die Regel zum Erhalt der Eingabe auch für die neue Datenform ausdrücklich geprüft. Halten Sie einen fehlenden Test als konkrete Lücke in der Testabdeckung fest und prüfen Sie anschließend, ob die Implementierung die Regel tatsächlich verletzt. Belohnen Sie nicht allein die Zahl der Tests. Mehrere Tests für dasselbe Szenario können eine fehlende Prüfung eines Grenzfalls verdecken. Prüfen Sie den Zusammenhang zwischen jeder Zusicherung und dem dokumentierten Vertrag. ## Besprechen Sie die Übergabe anhand einheitlicher Fragen Bitten Sie alle Kandidatinnen und Kandidaten, die Änderung anhand derselben Kernfragen zu erklären. Prüfer sollten Nachweise aus Code und Tests festhalten, bevor sie die Gesamtentscheidung besprechen. Die [Hinweise des OPM zu strukturierten Interviews](https://www.opm.gov/policy-data-oversight/assessment-and-selection/structured-interviews/) beschreiben vorab festgelegte Fragen in einheitlicher Reihenfolge und gemeinsame Bewertungsmaßstäbe. Diese Prinzipien auf ein Codegespräch anzuwenden, ist eine praktische Empfehlung. Dadurch wird diese Aufgabe weder zu einem OPM-zertifizierten Auswahlverfahren, noch ist damit ihre Vorhersagekraft belegt. ### Eine brauchbare Übergabenotiz Eine Beispielnotiz könnte so lauten: > Stornierte Buchungen werden vor dem Sortieren ausgeschlossen. Fehlt das Stornierungsfeld, gilt die Buchung als aktiv, sodass ältere Datensätze ihr Verhalten behalten. Die bestehenden Tests für angrenzende Intervalle und die Eingabereihenfolge bestehen weiterhin. Der neue Test für eine Überschneidung mit einer stornierten Buchung schlägt bei der ursprünglichen Funktion fehl. Stornierungswerte in der Eingabe werden als boolesch vorausgesetzt; die Validierung importierter Daten ist nicht Teil dieser Codeänderung. Diese Notiz erklärt dem nächsten Entwickler, was sich geändert hat, was stabil geblieben ist und wo die Annahme endet. Sie braucht weder einen langen Aufsatz noch eine Nacherzählung jeder Bearbeitung. Stellen Sie dieselben drei Kernfragen: 1. Welches bestehende Verhalten haben Sie abgesichert, und wo ist der Nachweis? 2. Welcher Test würde ohne Ihre Änderung fehlschlagen? 3. Was sollte der nächste Entwickler wissen, bevor er diese Funktion erneut ändert? Prüfer können Rückfragen zur eingereichten Arbeit stellen. Halten Sie auch diese fest, insbesondere wenn sie Informationen geliefert haben, die ein anderer Kandidat bereits in den anfänglichen Anweisungen erhielt. Verbessern Sie die Unterlagen, wenn wiederkehrende Fragen eine Unklarheit aufdecken. ### Ein einheitlicher Bewertungsbogen Verwenden Sie einen Bogen mit konkreten Nachweisen, auf die Sie sich vor Beginn der Interviews verständigt haben: | Kriterium | Nachweis festhalten | Mögliche Schwachstelle prüfen | | --- | --- | --- | | Vertragsverständnis | Erkennt, dass fehlende und auf `False` gesetzte Stornierungswerte aktive Buchungen bedeuten | Lässt ältere Datensätze weg oder verändert die Regeln für angrenzende Intervalle | | Korrektheit der Änderung | Stornierte Datensätze beeinflussen die Verfügbarkeit nicht | Bezieht stornierte, sich überschneidende Buchungen weiter in den Vergleich ein | | Schutz vor Regressionen | Ordnet Zusicherungen dem neuen und dem bestehenden Verhalten zu | Zeigt bestandene Tests, ohne deren Abdeckung zu erklären | | Übergabe | Nennt die Änderung, das erhaltene Verhalten und die Annahme zur Eingabe | Überlässt es dem nächsten Entwickler, den Vertrag zu erschließen | Dies sind vorgeschlagene Bewertungshilfen für diese Aufgabe. Passen Sie sie an die ermittelten Tätigkeiten an und entscheiden Sie vor Sichtung der Einreichungen, wie sie die Einstellungsentscheidung beeinflussen. Beschreiben Sie sie nicht als wissenschaftlich belegte Bewertungsschwellen. Erproben Sie die Unterlagen mit Kollegen, die die Stelle kennen. Fragen Sie, wo Klärungsbedarf bestand und ob die verlangte Arbeit eine Voraussetzung für den Einstieg ist. Das OPM weist darauf hin, dass Entwicklung und Durchführung von Arbeitsproben Aufwand verursachen; planen Sie diese Vorbereitung und Bewertung ein. Für eine Senior-Stelle, deren zentrale Aufgabe die Bewertung eines Entwurfs ist, brauchen Sie eine andere Übung. Unser [Leitfaden zur Entwurfsbewertung im Interview mit Senior-Entwicklern](/blog/senior-engineer-design-review-interview) behandelt diese Tätigkeit. Diese kleine Codeänderung kann nicht jede Form technischen Urteilsvermögens abbilden. ## Organisieren Sie die Code-Aufgabe in Kit Bereiten Sie die Aufgabe und die Bewertungskriterien selbst vor und organisieren Sie die Code-Aufgabe anschließend mit Kit in der Recruiting-Pipeline. Implementierung, Tests und Codebewertung liegen in GitHub; die Prüfer beurteilen die Nachweise. Für Code-Aufgaben verwendet Kit private Repositories, die aus dem Vorlagen-Repository des Arbeitgebers erstellt werden. Kandidatinnen und Kandidaten verbinden GitHub für den Ablauf der Aufgabe. Nach der Abgabe können Prüfer mit verbundenem GitHub-Konto Einladungen zum Repository erhalten und dort Code und Versionsverlauf prüfen. Hinterlegen Sie README, Ausgangstests und geforderte Ergebnisse in Ihrer Vorlage. Falls Sie einen Pull Request erwarten, verlangen Sie ihn in diesen Anweisungen. Kit erstellt keinen Pull Request automatisch und bewertet die Implementierung nicht. Legen Sie ergänzend zur Aufgabe die Bewertungskriterien Ihres Teams fest. Setzen Sie eine Abgabefrist im Kalender, die zum Prozess passt, und erläutern Sie den erwarteten Arbeitsaufwand gesondert. Eine Frist misst nicht die tatsächlich aufgewendeten Programmierstunden. Werten Sie ihren Ablauf nicht als Beweis dafür, dass das Repository gegen Änderungen gesperrt ist. Unser [Leitfaden zur Einrichtung von Code-Aufgaben](/blog/how-to-structure-code-assignments) behandelt den gesamten Ablauf einschließlich Fristen und Bewertung. Eine korrekte Lösung ist ein sinnvoller Ausgangspunkt. Ergänzen Sie sie bei einer Stelle mit Wartungsaufgaben um eine klare Änderung, Tests zum Schutz des Vertrags und eine Übergabe, mit der ein anderer Entwickler arbeiten kann. Erproben Sie diese Unterlagen zunächst anhand einer tatsächlichen Aufgabe in Ihrem Team und überarbeiten Sie die Anweisungen, bevor Sie sie Kandidaten geben.