Warum Pair-Programming das beste Format für React Interviews ist

Ein guter Interview-Prozess ist entscheidend, um die besten React-Entwickler für dein Unternehmen zu gewinnen. Schließlich kann eine einzige Fehleinstellung die Leistung eines gesamten Teams beeinträchtigen. Ich sehe auf dem deutschen Markt immer wieder das folgende Problem.

Das Problem mit Coding Challenges

Viele Unternehmen erhalten zahlreiche Bewerbungen, vor allem aus dem Ausland und setzen auf Coding Challenges, um Kandidaten zu filtern. Doch dieses Verfahren hat seine Tücken: Gute Kandidaten, die keine Zeit für unbezahlte Arbeit aufwenden möchten, reichen möglicherweise gar keine Lösung ein, während schlechte Kandidaten mit Hilfe von Freunden, Tutorials oder ChatGPT eine Lösung erarbeiten, die über ihre tatsächlichen Kompetenzen liegt. Damit werden letztendlich genau die falschen Bewerber eingestellt.

Auch der kommunikative Aspekt des Entwicklerdaseins bleibt bei Coding Challenges leider auf der Strecke.

Die Lösung: Pair-Programming Interviews

Anstatt auf Coding Challenges zu setzen, führe ich 1on1 Pair-Programming Sessions mit jedem Bewerber durch. Der Bewerber teilt seinen Bildschirm und entwickelt in einem leeren neuen Projekt. Ich stelle eine Aufgabe in Textform, die technisch dem entspricht, was der Bewerber hinterher im Job auch tun muss. Das heißt konkret: "Bau eine UI-Component nach Design XY", wenn es im Job um ein Design-System geht, oder eher "Binde diese API an", wenn der Entwickler sich on-the-job eher mit Business-Logik und Schnittstellen beschäftigen wird. Die Aufgabe sollte dabei eher einfach sein und Möglichkeiten zum "Ausbrechen" in tiefergehende Konzepte bieten.

Ein konkretes Beispiel

Die Einladung zum Meeting umfasst eine Stunde. Nach einem kurzen Kennenlernen gebe ich dem Bewerber folgende Aufgabe:

# React Challenge: Todo List

## Setup

- Download this JSON file with a few todos from [Github](https://github.com/breytex/interview-todo/blob/main/db.json)
- Start a little backend with `npx json-server --watch db.json --port 3001`
- You can access the API's documentation at `http://localhost:3001`
- Create an empty NextJS project with TypeScript

## Excercise

Keep the implementation of the following exercise simple: just use plain HTML and inline CSS, without libraries such as Axios or Redux :)

1. Render a list of todos to the screen
2. Make it possible to add new todo items
   - Don't forget to add headers: `{"Content-Type": "application/json"}` to the fetch() method
3. Clicking on a todo item should redirect the user to a new NextJS page: `/todo/[id]`
4. Server-side render the details of the given todo item with the `[id]`

• Ich betone, dass man die Aufgabe nicht in der gegebenen Zeit schaffen muss. Es geht nur darum, zusammen zu programmieren und Herausforderungen zu diskutieren.
• Ich versuche, eine entspannte Atmosphäre zu schaffen, indem ich proaktiv Tipps gebe und auftretende Fehler (wie ein vergessenes await oder eine falsche Klammer) direkt anspreche.
• Es soll der Vibe wie in einem Meeting unter Kollegen entstehen. Ob das klappt ist natürlich auch von der sozialen Kompatiblität zwischen dem Kandidaten und dem Interviewer abhängig. Im Optimalfall ist der Interviewer ein Senior aus dem Team, in das der Kandidat platziert werden würde. Damit wäre auch die Personal-Fit-Frage von diesem Interview direkt mit abgedeckt.

Die Aufgabe ansich ist verhältnismäßig einfach. Es geht darum, ins flüssige Coden zu kommen und von da aus weitere vertiefende Fragen zu den Konzepten zu stellen, die der Kandidat gerade anwendet. Hier sind ein paar Beispiele:

1. Angenommen, die Internetverbindung ist sehr schlecht und das Erstellen eines Todo-Elements dauert sehr lange. Wie können wir die Benutzererfahrung verbessern? ("Optimistic update")
2. Angenommen, du baust einen "Abhaken"-Button. Wie können wir verhindern, dass der Benutzer ihn aus Versehen zweimal klickt? ("Button disable" oder "Debounce")
3. Wie würdest du die Todos jetzt sortieren, dass die abgehakten Aufgaben unten sind?

Wenn die Zeit knapp wird, unterbreche ich das Coden nach Beendigung einer Teilaufgabe und stelle noch ein paar weitere vertiefende Fragen zur Aufgabe, die der Bewerber mündlich beantworten soll:

1. Angenommen, du müsstest einen Unittest für diese Komponente schreiben. Worauf musst du achten? (Zum Beispiel darauf, dass man fetch mocken muss)
2. Du hast die Daten jetzt mit getServerSideProps gefetcht. Was für Alternativen zum Data-Fetching kennst du noch? Eigenen die sich für diesen Anwendungsfall? (getStaticProps)
3. Falls der Bewerber für eine Fullstack-Rolle in Frage kommt: Wie würdest du dieses Backend selbst implementieren? Wie verhinderst du, dass User A nicht die Todos von User B sehen kann?

Die Spreu vom Weizen trennen

Woran erkennt man jetzt die guten Bewerber?

Schlechte und sehr gute Bewerber erkennt man meist in den ersten fünf Minuten. In beiden Fällen könnte man das Interview vorzeitig beenden, da sich aus meiner Erfahrung der erste Eindruck selten nochmals ändert.

• Schlechte Bewerber sind unvorbereitet, haben Ausreden, warum sie im Screenshare nicht coden können oder haben kein Node.js auf ihrem Gerät installiert. Sie müssen jeden Basis-Befehl googeln und sind nur mit speziellen Libraries vertraut, kennen aber die Grundlagen von React nicht aus dem Kopf. Sie sind schnell frustriert und wollen die Hilfe des Interviewers nicht annehmen. In diesen Problemsituationen zeigen sich häufig dann auch die Schwächen in der Kommunikation, die bei einer Coding Challenge unter den Tisch gefallen wären.
• Mittelmäßige Bewerber verfügen möglicherweise über fundierte Programmierkenntnisse im Allgemeinen, kommen jedoch aus einer anderen Framework-Richtung wie Angular oder Vue.js und haben möglicherweise noch nicht das tiefere, React-spezifische Wissen erworben. Bei diesen Bewerbern kommt man erst über die tiefergehenden Fragen zu einem Ergebnis. Ist ein Bewerber auf der Kippe, nehme ich lieber den mit den besseren Kommunikations-Skills.
• Sehr gute Bewerber zeichnen sich bereits in den ersten Minuten durch eine gut konfigurierte IDE, fundierte Kenntnisse der relevanten Tastaturkürzel und einen schnellen und motivierten Start in die Aufgabe aus. Sie haben meist mit der Aufgabe keine Probleme sondern präsentieren eher noch eigenmotiviert Verbesserungsvorschläge. Bei Problemen kommunizieren sie offen und ohne diese zu überspielen.

Mit diesem Interview-Format testet man nicht nur die technischen Fähigkeiten, sondern auch die Fähigkeiten in Kommunikation und einer "Hands-on"-Mentalität. Dinge wie Debugging-Kompetenzen oder die aktive Auseinandersetzung mit Entwickler-Tools und der IDE können bei der Einstufung eines Kandidaten eine entscheidende Rolle spielen - würden jedoch bei einer Coding Challenge nicht ans Tageslicht kommen. Dabei geht es nicht darum, die Vorlieben eines Entwicklers qualitativ zu bewerten, sondern darum, ob er oder sie sich in vorherigen Jobs mit der Optimierung des eigenen Workflows beschäftigt hat (gutes Zeichen!) oder nicht.

Am Ende des Interviews gebe ich direkt konkretes Feedback. Hat der Bewerber sich als Senior beworben, aber das Interview nicht überstanden, gebe ich Tipps wie und mit welchen Online-Ressourcen man sich weiter verbessern kann. Für viele ist das Bewerbungsverfahren eine emotionale Angelegenheit, mit der verantwortungsvoll umgegangen werden sollte. Ich setze mich dafür ein, dass jeder Bewerber, egal ob gut oder schlecht, zeitnahe nach dem Interview eine Entscheidung mitgeteilt bekommt.

Fazit

Pair-Programming Interviews mögen zunächst zeitaufwändiger erscheinen als Coding Challenges. Doch aus meiner Erfahrung sind sie bei richtiger Handhabung kaum zeitaufwändiger, da das Überprüfen der Coding Challenges ebenfalls mindestens 30 bis 60 Minuten dauert. Zudem sind die Ergebnisse von Pair-Programming Interviews belastbarer und führen zu weniger false-positive Bewerbern.

Bonus: Will der Bewerber denn auch mit euch arbeiten?

Häufig drehen sich Interviews nur um das "wollen wir mit dir zusammen arbeiten?". Aber mindestens genau so wichtig ist ein "willst du denn auch mit uns?". Sollte der Bewerber nach dem Interview wirklich für die Rolle in Frage kommen, nimm dir die Zeit und zeig ein bisshen was von der Codebase (compliance beachten!) oder dem UX-zu-Code-Prozess (z.B. Figma). Viele Firmen geben keine tieferen Einblicke und genau das macht dann den Unterschied, dass der (gute) Bewerber am Ende unter den zahlreichen Angeboten (die er definitiv bekommen wird wenn er schon durch dieses Interview durchgekommen ist 🤓) sich auch für euch entscheidet.

Ich helfe dir gerne

Mit meinen 5 Jahren Erfahrung und mehr als 150 geführten Interviews im React-Bereich stehe ich dir gerne bei der Ausgestaltung deines Interviewprozesses zur Seite. Meld dich gerne bei mir: