Ein PHP-Test für Bewerberinnen und Bewerber ist dann sinnvoll, wenn er hilft, eine konkrete Frage zur Arbeit zu beantworten: Kann die Person eine API warten, einen Fehler untersuchen oder an einer bestehenden Anwendung mitarbeiten? Er sollte nicht messen, wer am meisten freie Zeit hat, ein bestimmtes Tool kennt oder die persönlichen Vorlieben der prüfenden Person errät.
Damit das Ergebnis aussagekräftig ist, sollte das Team zunächst die relevanten Kompetenzen festlegen, ein angemessenes Format wählen und anhand beobachtbarer Kriterien bewerten. Der Test ist ein Teil des Auswahlverfahrens und kein Ersatz für das Gespräch über Erfahrung, Zusammenarbeit und Kontext.
Beginnen Sie mit den tatsächlichen Aufgaben der Stelle
Klären Sie vor dem Verfassen der Aufgabenstellung, was die Person in den ersten Monaten tun wird. Für eine Stelle mit Schwerpunkt Wartung einer Legacy-Anwendung sind andere Kompetenzen erforderlich als für eine Stelle, in der neue Dienste entwickelt werden. Im ersten Fall können das Lesen von Code, die Untersuchung von Fehlern und die sichere Umsetzung kleiner Änderungen wichtig sein; im zweiten Fall möglicherweise der Entwurf einer API oder die Definition von Grenzen zwischen Komponenten.
Wählen Sie zwei oder drei vorrangige Kompetenzen aus und verknüpfen Sie jede mit einer beobachtbaren Aufgabe. Erfordert die Stelle beispielsweise die Wartung einer PHP-API, lässt sich bewerten, wie Eingaben validiert und das Verhalten bei ungültigen Daten erklärt wird. Es ist nicht nötig, die gesamte Sprache, das Framework und die Architektur in einem einzigen Test abzudecken.
Es ist außerdem sinnvoll, zwischen unverzichtbaren Anforderungen und Kenntnissen zu unterscheiden, die sich erlernen lassen. Kann das Team ein Tool nach dem Einstieg vermitteln, kann es fähige Profile ausschließen, wenn dessen Beherrschung zur Zugangsvoraussetzung gemacht wird – ohne dadurch die Vorhersage der späteren Leistung zu verbessern.
Wählen Sie das Format passend zu dem, was Sie beobachten möchten
Eine Code-Review eignet sich, wenn die Arbeit darin besteht, eine bestehende Codebasis zu warten. Sie können einen kurzen Ausschnitt mit einem Fehler oder einer fragwürdigen Entscheidung bereitstellen und die Person bitten, Risiken zu identifizieren, Änderungen vorzuschlagen und zu benennen, was sie testen würde. So lassen sich Leseverständnis und Urteilsvermögen beobachten, ohne dass die Person eine Anwendung von Grund auf neu entwickeln muss.
Ein technisches Gespräch eignet sich, um Entscheidungen, Erfahrung und Kommunikation zu erkunden. Am besten funktioniert es mit Fragen zu konkreten Situationen und ausreichend Zeit, damit die Person Annahmen, Alternativen und Folgen darlegen kann. Es sollte nicht zu einer Gedächtnisprüfung über Syntax oder irrelevante Details werden.
Eine klar begrenzte praktische Aufgabe kann Aufschluss über die Implementierungsfähigkeit geben, wenn diese im Mittelpunkt steht. Beschränken Sie sie auf eine kleine Aufgabe, etwa eine Validierung zu ergänzen oder einen Fehlerfall in einem in sich geschlossenen Beispiel zu beheben. Ist eine umfangreiche Lösung erforderlich, ist es möglicherweise sinnvoller, die Bewertung in eine begleitete Code-Review und ein Gespräch aufzuteilen, statt stundenlange Arbeit zu Hause zu verlangen.
Das Format sollte es ermöglichen, die bewertete Kompetenz unter Beweis zu stellen, und nicht die Beherrschung einer bestimmten Umgebung belohnen. Ist ein bestimmtes Framework für die Stelle maßgeblich, geben Sie an, welches und warum. Andernfalls sollten gleichwertige Lösungen akzeptiert und das Denkvermögen bewertet werden.
Definieren Sie eine Aufgabe mit klarem Kontext und eindeutigen Grenzen
Eine gute Aufgabenstellung erläutert das Ziel, den erforderlichen Mindestkontext, die Einschränkungen und die Form der Abgabe. Geben Sie an, welches Verhalten erwartet wird, welche Teile des Codes geändert werden dürfen, ob Abhängigkeiten verfügbar sind und wie viel Zeit die Aufgabe in Anspruch nehmen sollte. Klären Sie auch, ob die Dokumentation konsultiert werden darf und welche Tools verwendet werden können.
Die Aufgabe sollte repräsentativ sein, aber keine Funktionalität liefern, die direkt in das Produkt übernommen werden kann. Vermeiden Sie die Forderung nach einer vollständigen Integration, einer umfangreichen Migration oder einer Funktion, die das Unternehmen veröffentlichen muss. Ähnelt der Fall einer tatsächlichen Aufgabe, verwenden Sie ein verkleinertes, fiktives Szenario ohne vertrauliche Daten oder vertraulichen Code. Das Ergebnis des Auswahlverfahrens darf nicht zu kostenloser Produktionsarbeit werden.
Die geschätzte Zeit ist eine Gestaltungsgrenze und kein Geschwindigkeitstest. Teilen Sie mit, was zu tun ist, wenn nicht alles fertig wird, und ermutigen Sie dazu, Prioritäten zu setzen. Es ist besser, eine teilweise Lösung zu sehen, die gut erläutert wird, als Personen zu bevorzugen, die außerhalb des Verfahrens viele Stunden investieren konnten.
Bewerten Sie anhand einer beobachtbaren Bewertungsmatrix
Legen Sie die Bewertungsmatrix fest, bevor Sie Bewerbungen prüfen. Eine kurze Skala – zum Beispiel unzureichend, angemessen und überzeugend – kann ausreichen, wenn jede Stufe konkrete Belege beschreibt. Vermeiden Sie vage Bezeichnungen wie „passt gut“ oder „eleganter Code“, hinter denen sich persönliche Vorlieben verbergen können.
- Problemlösung: Identifiziert Annahmen, erläutert Entscheidungen und erkennt Grenzen oder Alternativen.
- Korrektheit und Lesbarkeit: Löst die gestellte Aufgabe mit verständlichem Code und angemessenen Änderungen.
- Sicherheit: Behandelt Eingaben, Fehler und sensible Daten entsprechend dem Kontext der Aufgabe.
- Tests: Wählt relevante Fälle aus und erläutert, welches Verhalten sie abdecken – auch wenn keine vollständige Testsuite geschrieben wird.
- Zusammenarbeit: Stellt relevante Fragen, kommuniziert Unsicherheiten und reagiert auf Rückmeldungen, ohne Meinungsverschiedenheiten zu verschweigen.
Nicht alle Kriterien sind für jede Stelle gleich wichtig. Bei einer Wartungsstelle können Verständnis und Vorsicht im Vordergrund stehen, bei einer anderen der Entwurf von Schnittstellen. Machen Sie diese Prioritäten deutlich und unterscheiden Sie kritische Fehler – etwa eine offensichtliche Offenlegung von Daten – von stilistischen Details, die das Ergebnis nicht verändern.
Prüfen Sie die Arbeit und fragen Sie nach den Entscheidungen
Die Bewertung sollte einem einheitlichen Ablauf folgen. Die Prüfenden können zunächst unabhängig voneinander bewerten und anschließend die Belege vergleichen. So lässt sich der Einfluss des ersten Eindrucks verringern und erkennen, ob Kriterien mehrdeutig sind. Bei Abweichungen sollte sich das Gespräch auf konkrete Codeausschnitte und die Bewertungsmatrix beziehen, nicht auf intuitive Einschätzungen der Persönlichkeit.
Fragen Sie im Nachgespräch nach einer konkreten Entscheidung: Was würde die Person mit mehr Zeit ändern, welchen Testfall würde sie ergänzen oder welches Risiko hat sie als vorrangig betrachtet? Die Fragen sollten dazu dienen, die Überlegungen zu klären, und nicht plötzlich Anforderungen einführen, die in der Aufgabenstellung nicht vorkamen. Geben Sie Raum, Entscheidungen zu erläutern, die von denen des Teams abweichen.
Bewerten Sie die Reaktion auf einen Hinweis als Beleg für Zusammenarbeit, nicht für Gehorsam. Eine Person kann eine andere Alternative nachvollziehbar verteidigen. Die Fähigkeit, Abwägungen zu erläutern und eine Lösung angesichts neuer Informationen zu überarbeiten, ist oft aussagekräftiger, als einer Vorliebe der interviewenden Person zu entsprechen.
Verringern Sie Verzerrungen und bieten Sie sinnvolle Alternativen
Verwenden Sie für alle Personen, die sich auf dieselbe Stelle bewerben, dieselben Anweisungen, Kriterien und Zeitvorgaben. Blenden Sie, wenn möglich, nicht relevante Angaben bei der ersten Prüfung aus und begrenzen Sie unstrukturierte Kommentare. Akzeptieren Sie gleichwertige Formate, wenn sie dieselbe Kompetenz messen: Ein moderiertes Gespräch kann eine Aufgabe für zu Hause ersetzen, wenn es darum geht, die Denkweise zu verstehen.
Fragen Sie rechtzeitig, ob eine Anpassung des Formats oder Unterstützung bei der Barrierefreiheit erforderlich ist, und vereinbaren Sie ohne Nachteile eine Alternative. Gehen Sie nicht davon aus, dass Pausen, Sprechtempo oder ein informeller Kommunikationsstil das technische Niveau anzeigen. Auch die Nutzung von Dokumentation sollte einheitlich gehandhabt werden: Im Arbeitsalltag kann es normal sein, Referenzmaterial heranzuziehen.
Erkennen Sie eine unverhältnismäßige Aufgabe vor der Veröffentlichung
Prüfen Sie die Aufgabe aus der Perspektive einer bewerbenden Person. Lässt sich der Umfang innerhalb der angegebenen Zeit bewältigen? Sind genügend Informationen vorhanden, um ohne Rätselraten über Anforderungen zu beginnen? Werden Kompetenzen bewertet, die für die Stelle wichtig sind, oder die Vertrautheit mit einer nicht erläuterten internen Konvention? Könnte das Team das Ergebnis direkt geschäftlich nutzen? Eine bedenkliche Antwort auf die letzte Frage macht es erforderlich, die Aufgabe zu verkleinern oder zu ersetzen.
Weitere Warnsignale sind eine umfangreiche Anforderungsliste, eine Bewertung nach persönlichem Geschmack, widersprüchliche Anweisungen oder die indirekte Erwartung, dass nur eine perfekte Lösung genügt. Benötigt das Team selbst mehrere Stunden zur Lösung der Aufgabe, ist sie für eine erste Auswahl wahrscheinlich nicht klar genug begrenzt.
Checkliste zur Verbesserung des Auswahlverfahrens
- Jedes Kriterium mit einer tatsächlichen Verantwortung der Stelle verknüpfen.
- Das kürzeste Format wählen, mit dem sich die gesuchte Kompetenz beobachten lässt.
- Kontext, Tools, Zeitgrenzen und Abgabebedingungen kommunizieren.
- Bewertungsstufen mit Beispielen für konkrete Belege festlegen, bevor Ergebnisse eingehen.
- Vergleichbare Nachfragen stellen und die Erläuterung alternativer Lösungen ermöglichen.
- Rückmeldungen von Bewerberinnen und Bewerbern sowie Prüfenden einholen, um Unklarheiten oder unnötigen Aufwand zu erkennen.
Ein PHP-Test für Bewerberinnen und Bewerber muss nicht komplex sein, um aussagekräftig zu sein. Seine Qualität hängt davon ab, ob er etwas Relevantes mit vertretbarem Aufwand und einer konsistenten Bewertung misst. Wenn die Ergebnisse nach mehreren Auswahlrunden nicht dabei helfen, die für die Stelle erforderlichen Kompetenzen zu unterscheiden, sollten Sie das Design überarbeiten, bevor Sie den Schwierigkeitsgrad erhöhen.
