Frontend-Entwickler auswählen: Aufgaben, Arbeitsprobe und Bewertung

Beschreiben Sie den Auftrag vor dem Technologie-Stack

„React-Erfahrung gesucht“ sagt wenig darüber aus, welche Arbeit die Person übernehmen soll. Beginnen Sie mit einer konkreten Produktaufgabe: Welche Oberfläche soll entstehen oder verbessert werden? Wer nutzt sie? Welche Daten und Fehlerfälle treten auf? Wer entscheidet über Gestaltung und fachliches Verhalten?

Verantwortung zuerst, Seniorität danach

Ein Titel sagt nicht, wer Entscheidungen trifft. Beschreiben Sie deshalb, ob die Person eine klar umrissene Oberfläche umsetzt, technische Teilentscheidungen selbst vorbereitet oder Frontend-Arbeit über mehrere Bereiche hinweg verantwortet.

Erwarten Sie keine Führung allein wegen einer Senioritätsbezeichnung. Prüfen Sie die konkrete Reichweite der Entscheidungen, für die Sie Verantwortung übertragen wollen.

Halten Sie Muss-Kriterien und Lernbares auseinander. Ein vorhandenes React-Produkt kann Erfahrung mit Komponenten, Zuständen und Tests erfordern. Eine eng abgegrenzte Landingpage braucht vielleicht vor allem solides HTML, CSS, JavaScript und ein gutes Gespür für responsive Darstellung. Eine lange Werkzeugliste macht den Auftrag schwerer lesbar, ohne zu zeigen, wie gute Arbeit aussieht.

React beschreibt den Aufbau einer Oberfläche als Komponenten, Zustände und Datenfluss. Die offizielle Anleitung eignet sich als gemeinsamer Bezugspunkt, nicht als starre Prüfungsvorlage. Fragen Sie nach dem Grund einer Lösung und danach, wie sie sich in Ihrem vorhandenen Produkt einfügt. React: Thinking in React

Eine kurze Arbeitsprobe prüft mehr als ein Gespräch allein

Wählen Sie eine kleine, repräsentative Aufgabe, die in einem Gespräch oder einem klar begrenzten Arbeitsfenster lösbar ist. Nutzen Sie synthetische Daten und ein neutrales Beispiel statt produktiven Quellcodes, Kundendaten oder unbezahlter Arbeit an einem echten Backlog. Geben Sie dieselbe Ausgangslage, dieselben erlaubten Hilfsmittel und dieselben Bewertungskriterien an alle Personen.

Eine mögliche Aufgabe: „Ergänzen Sie in einer Produktliste eine Suche, einen Statusfilter und einen Zustand für leere Ergebnisse. Erklären Sie, welche Annahmen Sie treffen und was Sie vor einem Merge noch prüfen würden.“ Lassen Sie die Person selbst entscheiden, wie sie den Auftrag zerlegt. Die Arbeit verrät, ob sie Unklarheiten anspricht, passende Zustände erkennt und Änderungen überprüfbar macht.

Vergeben Sie pro Kriterium eine nachvollziehbare Einstufung: „gezeigt“, „teilweise gezeigt“ oder „noch nicht gezeigt“. Notieren Sie dazu, was die Person konkret getan oder erklärt hat. Die Bewertung hilft beim Vergleich. Wie die Zusammenarbeit gelingt, zeigt sich erst im Alltag.

Fiktives Beispiel: Die Person vereinfacht den Zustand der Suche

Fiktives Beispiel, kein realer Kundenfall: In einer Arbeitsprobe speichert eine Person sowohl den Suchtext als auch eine separat gepflegte Liste der gefilterten Ergebnisse. Beim Löschen des Suchtexts bleibt die Ergebnisliste gelegentlich veraltet. Eine andere Person speichert nur Suchtext und Filter und berechnet die Treffer daraus.

Die zweite Entscheidung ist in diesem Beispiel besser begründet: Sie vermeidet zwei Datenquellen, die auseinanderlaufen können. Das passt zu Reacts Empfehlung, den Zustand auf die kleinste veränderliche Datenmenge zu begrenzen und abgeleitete Werte zu berechnen. Das ist kein pauschales Verbot, berechnete Werte zwischenzuspeichern. Bei großen Datenmengen können Messungen eine andere Lösung rechtfertigen. Fragen Sie, welche Leistung tatsächlich gemessen wurde und wie die Person die Korrektheit absichert. React: Choosing the State Structure

Bewerten Sie also die Begründung zusammen mit dem Ergebnis. Ein sauberer Codeausschnitt allein belegt weder gute Abstimmung noch sichere Änderungen im bestehenden System.

Checkliste für Ihr Auswahlgespräch

• Beschreiben Sie eine Aufgabe aus dem Produkt und erklären Sie, warum sie jetzt ansteht.
• Fragen Sie nach einer ähnlichen Oberfläche, an der die Person gearbeitet hat. Was war ihr eigener Anteil?
• Bitten Sie um eine konkrete Entscheidung zu Komponenten, Datenfluss oder Fehlerzuständen.
• Prüfen Sie Tastaturbedienung, Beschriftungen und Fokusführung an einem passenden Beispiel. WCAG 2.2 fasst dafür testbare Erfolgskriterien zusammen; ein Gespräch ersetzt keine Prüfung des fertigen Produkts. W3C WCAG 2.2
• Vereinbaren Sie vorab, welche Dokumentation, Suchmaschinen oder KI-Werkzeuge erlaubt sind. Lassen Sie die Person relevante Vorschläge prüfen und Änderungen erklären.
• Notieren Sie für jedes Kriterium ein beobachtbares Beispiel und eine offene Frage für das nächste Gespräch.

Was die Auswahl nicht klärt

Eine Arbeitsprobe bildet nur einen Ausschnitt der späteren Zusammenarbeit ab. Sie belegt keine langfristige Zuverlässigkeit, Produktivität oder Teamwirkung. Ein einzelnes Gespräch zeigt außerdem nicht, wie jemand mit Ihrem Codebestand, Ihren Entscheidungen und Rückmeldungen arbeitet. Treffen Sie die finale Entscheidung nach fachlichem Gespräch, Prüfung der bisherigen Arbeit und Klärung der konkreten Bedingungen.

Division5 gleicht Ihre Aufgaben mit vorab geprüften Profilen ab. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Für alle Fachkräfte gilt eine 30-tägige Testphase; Umfang und Bedingungen halten Sie vor Beginn schriftlich fest. Sie führen Ihr fachliches Gespräch und entscheiden selbst. Verfügbarkeit wird für die Anfrage geprüft. So läuft der Auswahlprozess ab.

Die fachliche Führung und Produktverantwortung bleiben bei Ihnen. Sie bestimmen Aufgaben, Prioritäten, Zugänge und Abnahme. Eine passende Besetzung ersetzt weder Ihre technische Leitung noch klare Zuständigkeiten im Team.

Fachkräfte für Ihr Team ansehen oder den Auswahlprozess im Detail lesen.