Anleitungen für Bewerbungsaufgaben vorab testen

Um die Anleitung einer Bewerbungsaufgabe für zu Hause zu testen, lassen Sie eine Person, die die Aufgabe noch nicht kennt, dieselben Schritte zur Einrichtung und Abgabe durchlaufen wie Ihre Kandidatinnen und Kandidaten. Beobachten Sie, wo Hilfe nötig ist, halten Sie unbeabsichtigte Hindernisse fest, überarbeiten Sie die Unterlagen und wiederholen Sie den Versuch mit einer anderen Person. Behalten Sie dabei stets im Blick, welche Fähigkeiten Sie mit der Aufgabe prüfen wollen.

Am 11. Oktober beschrieb Terence Eden, wie er Menschen dafür bezahlte, seiner README zu folgen. Er bot 25 € für eine Stunde, beobachtete die Teilnehmer beim Teilen ihres Bildschirms und ließ sie ihre Gedanken laut aussprechen. Zwischen den Sitzungen überarbeitete er das Dokument. Insgesamt gab er nach eigenen Angaben etwa 150 € aus. Dabei entdeckte er einen falschen Demo-Link, verwirrende Dateioperationen, unerklärte Begriffe und eine wenig hilfreiche Reihenfolge der Abschnitte.

Die Diskussion auf Hacker News handelt von Softwaredokumentation. Eden untersuchte keinen Bewerbungsprozess. Für ein Recruiting-Team lässt sich daraus ableiten: Erproben Sie Ihre eigenen Anleitungen, bevor Sie die Arbeit von Kandidaten als Bewertungsgrundlage nutzen. Auch sorgfältig formulierte Aufgabenbeschreibungen können fehlende Berechtigungen oder einen unklaren letzten Schritt verbergen.

Was prüfen Ihre Aufgabenanleitungen tatsächlich?

Halten Sie fest, welche Fähigkeit Sie prüfen wollen, bevor Sie den Probelauf organisieren. Dieser Bezugspunkt hilft Ihnen zu entscheiden, ob eine Schwierigkeit zur Prüfung gehört oder durch einen vermeidbaren Fehler bei der Durchführung entsteht.

Nehmen wir eine erfundene Backend-Aufgabe: Eine kleine API soll einen Filter erhalten; Tests sollen sicherstellen, dass das bisherige Verhalten erhalten bleibt. Sie könnten bewerten, wie die Bewerberin oder der Bewerber den Code versteht, eine Änderung auswählt, Randfälle behandelt und eine Entscheidung erklärt. Das sind plausible Ziele, sofern sie der Arbeit in der ausgeschriebenen Rolle entsprechen.

Das US Office of Personnel Management beschreibt Arbeitsproben und Simulationen als Aufgaben, die tatsächlichen beruflichen Tätigkeiten ähneln. Die Hinweise unterscheiden außerdem zwischen Kompetenzen, die beim Einstieg erforderlich sind, und solchen, die der Arbeitgeber vermitteln will. Daraus ergibt sich eine hilfreiche Frage für jede Voraussetzung: Gehört diese Anforderung bereits beim Einstieg zur Rolle?

Unbekannten Code zu lesen, kann dazugehören. Die unveröffentlichte Datenbankkonfiguration Ihres Unternehmens zu kennen, ergibt sich daraus nicht. Auch Fehlersuche kann dazugehören. Sie sollten aber bewusst entscheiden, ob eine defekte Startumgebung die eigentliche Aufgabe zur Fehlersuche ist. Ein versteckter Fehler verändert, was die Aufgabe von den Teilnehmern verlangt.

Schreiben Sie Ihre Antwort neben die Bewertungskriterien. Für die erfundene API-Aufgabe könnte das lauten: „Wir bewerten die Korrektheit, den Erhalt des bisherigen Verhaltens, relevante Tests und Ihre Erläuterung der Abwägungen.“ Wenn die Interpretation einer unvollständig beschriebenen Anforderung beabsichtigt ist, erklären Sie, wie Sie die Annahmen der Kandidaten bewerten werden.

Der Probelauf prüft, ob die Unterlagen diese beabsichtigte Bewertung ermöglichen. Ein erfolgreicher Durchlauf belegt nicht, dass die Aufgabe die spätere Arbeitsleistung vorhersagt. Für die grundsätzliche Gestaltung von Aufgaben gibt es den separaten Leitfaden zur Strukturierung von Code-Aufgaben.

Geben Sie unbeteiligten Lesern die tatsächlichen Aufgabenunterlagen

Erproben Sie Einladung, Zugang, Anleitung und Abgabeweg gemeinsam. Wenn Sie einem Kollegen nur das Repository schicken, fehlen die Übergänge, an denen Kandidatinnen und Kandidaten den nächsten Schritt aus den Augen verlieren können.

Wählen Sie jemanden mit den erwarteten Einstiegskompetenzen, der die Aufgabe weder geschrieben noch geprüft hat. Ein Entwickler aus einem anderen Projekt kann dafür geeignet sein. Eine Person ohne Programmiererfahrung entdeckt möglicherweise ein sprachliches Problem. Schwierigkeiten bei der Installation der Laufzeitumgebung wären für eine erfahrene Entwicklungsrolle jedoch anders einzuordnen.

Erklären Sie vor Beginn den Zweck: Sie testen die Aufgabenunterlagen. Wenn Sie jemanden eigens für die Sitzung gewinnen, vereinbaren Sie den Arbeitsumfang und die Vergütung. Edens Budget beschreibt sein Experiment; es ist weder ein üblicher Preis noch eine Empfehlung zur Zahl der Teilnehmer. Machen Sie einen Bewerber nicht ohne dessen Wissen zum unbezahlten Teilnehmer eines Usability-Tests.

Geben Sie der Person dieselben Materialien und Berechtigungen, die Sie Kandidatinnen und Kandidaten zur Verfügung stellen wollen:

• Die Einladung und etwaige Hinweise zur Vorbereitung.
• Die Zusammenfassung der Aufgabe, die ausführliche Anleitung und die Bewertungskriterien.
• Den Repository-Zugang, bereitgestellte Daten und erforderliche Zugangsdaten.
• Den erwarteten Aufwand, die Abgabefrist und das Ereignis, mit dem die Bearbeitungszeit beginnt.
• Regeln zur Nutzung von Dokumentation, Suche, Zusammenarbeit und KI-Unterstützung.
• Den tatsächlichen Abgabeweg und eine Kontaktperson für Fragen.

Verwenden Sie ein Testkonto und für die Sitzung geeignete Daten. Wenn die Aufgabe eine bestimmte Umgebung voraussetzt, stellen Sie diese ausdrücklich bereit. Dürfen Bewerber ihre eigenen Rechner verwenden, probieren Sie den dokumentierten Ablauf in einer zulässigen Umgebung aus, in der die Abhängigkeiten Ihres Teams noch nicht installiert sind.

Bitten Sie die Person vor dem Weiterarbeiten zu beschreiben, welches Ergebnis sie ihrer Meinung nach liefern soll. Halten Sie diese Erklärung als Beobachtung fest. Eine abweichende Interpretation kann auf eine unklare Anforderung hinweisen. Sie kann aber auch eine vernünftige fachliche Entscheidung innerhalb des vorgesehenen Spielraums sein.

Bei einer Programmieraufgabe sollte die Person weit genug gehen, um die Ausgangsversion auszuführen, eine kleine zulässige Änderung vorzunehmen und die Abgabe abzuschließen. Vereinbaren Sie diesen Umfang vorab. Sie müssen den praktischen Ablauf beobachten, ohne dabei stillschweigend eine vollständige unbezahlte Lösung zu verlangen.

Beobachten Sie, wo die Anleitung nicht mehr weiterhilft

Halten Sie fest, was passiert ist, bevor Sie Ihre Absicht erklären. Ein Hinweis kann nötig sein. Dass er nötig war, gehört jedoch zu den Erkenntnissen, die Sie sammeln wollen.

Bitten Sie die Person, während der Arbeit laut zu beschreiben, welcher Anweisung sie folgt, was sie von einem Befehl erwartet und wo sie nach dem nächsten Schritt sucht. Erklären Sie ihr die Seite nicht fortlaufend. Wenn sie innehält, lassen Sie sie den Grund erläutern, bevor Sie die Pause als Problem werten.

Eine Pause beim Nachdenken über die Bedeutung eines Filters kann wertvolle Überlegungen sichtbar machen. Eine Pause, weil der Link „Ausgangs-Repository“ heißt, aber eine Seite ohne Zugangsberechtigung öffnet, deutet auf ein Problem bei der Durchführung hin. Unterscheiden Sie diese Beobachtungen in Ihren Notizen, statt sie in einer einzigen Bearbeitungsdauer zusammenzufassen.

Führen Sie ein kurzes Protokoll der Hindernisse. Die folgenden Einträge sind erfundene Beispiele für die API-Aufgabe und keine Ergebnisse einer tatsächlichen Recruiting-Studie:

Ergänzen Sie den Befehl, die Fehlermeldung oder die Formulierung, mit der sich das Problem nachvollziehen lässt. „Die Einrichtung war verwirrend“ bietet wenig Ansatzpunkte. „Der Einrichtungsbefehl erwartet einen Datenbanknamen, der in der Beispieldatei für die Umgebungskonfiguration fehlt“ zeigt der zuständigen Person, wo sie ansetzen kann.

Wenn Sie eingreifen, notieren Sie die geleistete Hilfe. Andernfalls kann das Endergebnis den Eindruck erwecken, die Unterlagen seien verständlich, obwohl Ihre Erklärung den Durchlauf erst ermöglicht hat. Betrachten Sie das laute Denken als Mittel zur Fehlersuche: Beobachtet zu werden und Gedanken auszusprechen, kann die Arbeitsweise verändern. Daraus lässt sich die gewöhnliche Leistung von Kandidaten nicht abschätzen.

Überarbeiten Sie die Aufgabenbeschreibung und testen Sie die Änderungen

Beheben Sie die kleinste erkennbare Ursache und lassen Sie den überarbeiteten Ablauf von jemandem testen, der Ihre Behelfslösung noch nicht kennt. Die erste Person kennt inzwischen Details, die die nächste Kandidatin oder der nächste Kandidat nicht kennen wird.

Bei der erfundenen API-Aufgabe lautet die ursprüngliche Anleitung: „Starten Sie die Anwendung, fügen Sie Filter hinzu und senden Sie Ihre Lösung.“ Die überarbeiteten Unterlagen könnten eine unterstützte Laufzeitumgebung, genaue Installationsbefehle, einen Testbefehl für den Ausgangszustand, Beispieldaten und das gewünschte Filterverhalten enthalten. Hinzu kämen der Abgabeort und die Bewertungskriterien.

Richten Sie diese Korrekturen an den Beobachtungen aus. Wenn die Person die Abhängigkeiten nicht installieren kann, hilft ein zusätzlicher Absatz über die Unternehmenskultur nicht weiter. Wenn die Tests erfolgreich sind, die Person aber die Abgabeaktion nicht findet, gehört die Korrektur an diesen Übergang.

Prüfen Sie die Befehle selbst, bevor Sie eine weitere Sitzung beobachten. Gehen Sie die Schritte mit einem frischen Checkout in der dokumentierten Umgebung durch. Beseitigen Sie unbeabsichtigte Abhängigkeiten von Ihren lokalen Zugangsdaten, zwischengespeicherten Daten oder unveröffentlichten Einstellungen. Automatisierte Prüfungen können defekte Links und Befehle erkennen. Sie zeigen aber nicht, wie jemand „Senden Sie Ihre Lösung“ versteht.

Formulieren Sie für den nächsten Durchlauf eine konkrete Frage. Zum Beispiel: Kann die Person allein mit den Unterlagen die Ausgangsversion ausführen? Kann sie erklären, wann die Arbeit offiziell abgegeben ist? Halten Sie die Beobachtung im selben Protokoll fest, statt die gesamte Aufgabe als „validiert“ zu kennzeichnen.

Testen Sie nach der Behebung eines Hindernisses, das spätere Schritte blockiert hat, erneut den vollständigen Ablauf. Eine korrigierte Repository-Einladung kann ein Einrichtungsproblem sichtbar machen, das die erste Person gar nicht erreicht hat. Beenden Sie die Probeläufe, wenn Sie ausreichend Erkenntnisse haben, um die konkreten entdeckten Hindernisse zu beheben. Benennen Sie dabei, welche Umgebungen und Personen Sie beobachtet haben und wo die Grenzen Ihrer Erkenntnisse liegen.

Sorgen Sie für einheitliche Bedingungen und Klarstellungen

Stellen Sie die Unterlagen fertig, bevor Sie eine Gruppe einladen, und teilen Sie wesentliche Korrekturen allen Betroffenen gleichermaßen mit. Werden Anforderungen stillschweigend geändert, vergleichen Prüferinnen und Prüfer möglicherweise Arbeiten, die unter unterschiedlichen Bedingungen entstanden sind.

Speichern Sie Einladung, Anleitung, Ausgangsversion des Codes und Bewertungsraster zusammen in dem Dokument oder Repository, das Ihr Team bereits nutzt. Halten Sie fest, welche Version jede Kandidatin und jeder Kandidat erhalten hat. Das ist ein Vorschlag für die Durchführung; allein die Versionierung macht eine Prüfung noch nicht fair.

Die Hinweise der US EEOC zu Einstellungstests und Auswahlverfahren behandeln den angemessenen Zweck, die Durchführung, Bewertung und Validierung. Ein Probelauf mit einer unbeteiligten Person ist eine einzelne praktische Prüfung. Er erfüllt nicht sämtliche dieser Pflichten und belegt keine Rechtskonformität.

Angenommen, ein Kandidat meldet, dass sich die bereitgestellten Daten nicht laden lassen. Bestätigen Sie das Problem, informieren Sie andere betroffene Kandidatinnen und Kandidaten über die Änderung und prüfen Sie, ob deren Abgabefristen angepasst werden sollten. Hat der Fehler jemanden daran gehindert, bewertbare Arbeit vorzulegen, untersuchen Sie seine Auswirkungen, bevor Sie das fehlende Ergebnis als mangelnde Fähigkeit werten.

Trennen Sie organisatorische Klarstellungen von Hilfestellungen zur Lösung. „Die Datei laden Sie auf dieser Seite hoch“ lässt sich allen mitteilen. Ein Gespräch, das einen Lösungsansatz für das Kernproblem liefert, verändert die erhaltene Unterstützung und sollte für die Prüfer dokumentiert werden.

Bewahren Sie nach der Abgabe den Zusammenhang zwischen den jeweiligen Unterlagen und der Bewertung. Ein Prüfer sollte die kommunizierten Kriterien kennen, einschließlich jeder beabsichtigten Mehrdeutigkeit. Spätere Interviewfragen zu einer erfolgreichen Lösung gehören zu einem anderen Schritt; siehe das Interview nach der erfolgreichen Lösung.

Machen Sie die Anleitung für die Leser zugänglich

Prüfen Sie im Probelauf auch, wie Menschen die Unterlagen lesen und darin navigieren. Selbst ein korrekter Befehl ist schwer zu nutzen, wenn er nur in einem Screenshot oder unter einer unpassenden Überschrift steht.

Das W3C-WAI-Tutorial zu Überschriften erläutert, wie aussagekräftige, strukturierte Überschriften die Navigation und das Verständnis erleichtern. In einer Aufgabe helfen Überschriften wie „Einrichtung“, „Erforderliches Verhalten“ und „Abgabe“, die richtige Stelle zu finden. Prüfen Sie das tatsächlich angezeigte Dokument, einschließlich der PDF-Datei oder Repository-Seite, die Sie verteilen.

Stellen Sie Befehle als markierbaren und kopierbaren Text bereit. Benennen Sie Links so, dass ihr Ziel erkennbar ist. Prüfen Sie, ob wichtige Hinweise auf den unterstützten Geräten und in den verwendeten Dokumentformaten lesbar bleiben. Enthält die Abgabeseite Bedienelemente, nehmen Sie deren Tastaturbedienung in den Probelauf auf. Das Lesen der Aufgabenbeschreibung deckt nicht automatisch den gesamten Ablauf ab.

Bieten Sie schon vor Beginn eine Kontaktmöglichkeit an. In ihren US-Hinweisen zu Bewerberinnen und Bewerbern und dem ADA erläutert die EEOC, dass Arbeitgeber den Bewerbungsprozess beschreiben und fragen können, ob Bewerberinnen und Bewerber dafür eine Anpassung benötigen. Bearbeiten Sie solche Anfragen über einen geeigneten vertraulichen Kanal. Medizinische Diagnoseangaben gehören nicht in gemeinsam genutzte Bewertungsnotizen.

Ein Durchlauf mit einer Person erfasst deren Erfahrung. Er belegt weder die Barrierefreiheit für alle Nutzer noch eine vollständige WCAG-Konformität. Was die Formulierung betrifft, behandelt der frühere Leitfaden für klare Kandidatenanweisungen die Erwartungen an die Aufgabe, Fristen und Eingangsbestätigungen. Der Probelauf liefert zusätzlich Erkenntnisse darüber, ob eine Person den eingerichteten Ablauf tatsächlich durchlaufen kann.

Hinterlegen Sie die getestete Anleitung bei Ihrer Kit-Aufgabe

Nutzen Sie für den abschließenden Probelauf den tatsächlichen Ablauf aus Kandidatensicht. Felder und Vorschauen helfen bei der Vorbereitung. Erst das Durchlaufen aller Schritte zeigt, was die Einstellungen praktisch bedeuten.

In Kit Hiring kann eine Code-Aufgabe ein privates GitHub-Repository nutzen, das aus Ihrer Vorlage erstellt wird. Zu den Einstellungen gehören die Anleitung, der geschätzte Aufwand und die Zeitvorgaben. Die Kandidatin oder der Kandidat verbindet GitHub und erhält eine Repository-Einladung. Mit der Annahme dieser Einladung beginnt die Bearbeitungszeit. Die Kandidatenseite zeigt anschließend die Anleitung und die Abgabeaktion; eine spätere verbindliche Frist beendet das Zeitfenster durch automatische Abgabe.

Bei einer Arbeitsprobe beginnt die Bearbeitungszeit durch ein anderes Ereignis. Kandidatinnen und Kandidaten können zunächst die Zusammenfassung lesen und dann auf Aufgabe starten klicken. Dadurch wird die private Aufgabenbeschreibung sichtbar und die Bearbeitungszeit beginnt. Sie laden ihr Ergebnis hoch und erhalten eine Eingangsbestätigung. Machen Sie diese Unterschiede beim Probelauf Ihrer eigenen Aufgabe ausdrücklich deutlich. Die Dokumentation zum Bewerbererlebnis beschreibt beide Abläufe.

Kit stellt den Aufgabenablauf bereit. Ihr Team organisiert die Sitzung mit einer unbeteiligten Person, protokolliert Hindernisse und entscheidet, welche Korrekturen das Prüfziel erhalten. Geben Sie dieser Person die vorgesehene Einladung, beobachten Sie die Schritte von der Einrichtung bis zur Abgabe. Beheben Sie anschließend die reproduzierbaren Hindernisse und testen Sie den Ablauf erneut. Tun Sie das, bevor der erste Kandidat sie für Sie entdecken muss.