A day in the life oder: If it fits, it sits

Softwareentwickler*innen sind rar – gute Softwareentwickler*innen sogar sehr rar. Und als wäre die technische Seite fürs Recruiting nicht schon Herausforderung genug – dann gibt es ja auch noch die zwischenmenschliche Chemie, die stimmen muss. Denn: Jemand, der gut zum Team passt, macht es für alle Seiten von Anfang an leichter, bspw. auch im Onboarding. Hier geben wir euch einen kleinen Einblick, wie wir uns dieser Aufgabe nähern.

Ein Auswahlprozess ist eben mehr als die Lösung einer Rechenaufgabe oder das Schreiben exzellenten Codes. Kommunikation, Kritikfähigkeit und ein geteiltes Bild zur agilen Arbeitsweise ist uns bei mindmatters sehr wichtig und wird deshalb auch schon im Vorwege von uns konkret mit abgeklopft – allerdings nicht nur in unserem Sinne, sondern auch im Sinne der Bewerber*innen um am Ende hoffentlich zu einer motivierten Verstärkung zu kommen, die Freunde an der Arbeit mit dem ganzen Team hat. Aber wie kann man so einen Kennenlern- und Auswahlprozess (für beide Seiten) bewusst und aktiv gestalten?

Die Herausforderung gewöhnlicher Test-Cases

Das klassische Whiteboard-Interview ist bei uns sofort durchgefallen. Dort stellt man sich vor einem Whiteboard auf, formuliert eine Aufgabe und ist gespannt, wie die Bewerber*innen diese denn wohl lösen werden. Natürlich kann man im Lauf eines solchen Vorgehens erkennen, ob die Bewerber*innen in der Lage sind, auch ohne Internet zu programmieren – aber Schlüsselworte auswendig zu lernen und fallen zu lassen ist eben auch kein Indiz, ob jemand Software entwickeln kann.

A Day in the life: Wie ein Kennenlernen mit Bewerber*innen bei mindmatters aussieht

Bei mindmatters werden vielversprechende Bewerber*innen zu einem Probetag eingeladen. Zwei Entwickler*innen von uns sind an diesem Tag für den Ablauf verantwortlich – und sie sind auch für die Auswertung nach dem gemeinsamen Kennenlerntag zuständig. Unsere Entwickler*innen teilen sich für den Tag auf. Einer ist Pairing-Partner, der andere ist quasi Product Owner (Abk. PO).

Die Rolle der/des PO ist es, sich im Vorfeld eine Aufgabe auszudenken, die Bewerber*in und Pairing-Dev dann gemeinsam zu lösen haben. Wichtig hierbei: Die/der Pairing-Dev von mindmatters kennt die Aufgaben vorher ebenfalls nicht! So erzeugen wir eine Situation, die der täglichen Arbeit nahe kommt und keiner hat einen Vorteil.

Meistens beginnt die gemeinsame Arbeit dann mit der Auswahl der Plattform und der Programmiersprache. Hier machen wir keine Vorgaben – beide sollen sich einigen und dann gemeinsam in einem Umfeld entwickeln, in dem sich beide wohl fühlen. Vormittags steht die/der andere Dev als PO Rede und Antwort. Hierbei kann die/der Product Owner auch mal Dinge offen lassen und sich von den beiden Devs beraten lassen – auch sowas soll im Projektalltag mal vorkommen – haben wir gehört. ;-)

Rein technisch ist es so, dass wir in solchen Situationen den gemeinsamen Rechner mit zwei Tastaturen und Mäusen ausstatten – so wird einfaches Wechseln zwischen den Rollen ‘Coder’ und ‘Navigator’ einfach möglich.

Abseits des Fachlichen: ein Kennenlernen beim Lunch

Wenn der Vormittag vorbei ist versuchen wir, mit möglichst vielen Kolleg*innen im Büro zu sein, damit wir gemeinsam mit den Bewerber*innen zu Mittag essen können. So lernen sich alle auch abseits des Fachlichen ein wenig näher kennen, und: Die Bewerber*innen bekommen ihrerseits ein Bild vom gesamten Team.

Nach dem Mittagessen und einer ausgelassenen Runde Dart oder Kicker* (*kein Einstellungskriterium ;) ) sind die beiden Devs wieder gefordert. In einem Review stellen die Devs der/dem PO ihre Ergebnisse vor und weisen auf Schwierigkeiten oder offene Punkte hin. Idealerweise ist die Aufgabe so formuliert, dass mehrere User Stories enthalten sind. Diese nicht abgearbeiteten User Stories können dann in einer Kombination aus Planning I und II priorisiert und in Tasks aufgeteilt werden. Ein danach stattfindendes Planning Poker gibt den Devs die Gelegenheit, eine erste Aussage zu machen, wie lange das Projekt dauern würde – würde man es in der Realität weiterführen.

Wie im echten Leben: eine gemeinsame Retrospektive

Wenn diese Phase beendet ist kommt es zu einer gemeinsamen Retrospektive. Hier wird meistens noch ein*e Coach von mindmatters hinzugezogen, die/der diese Retro moderiert und begleitet. Wir konzentrieren uns hier auf drei Kernfragen:

1. Format: Kam das Format bei den Bewerber*innen gut an? Was könnte man noch verbessern?
2. Aufgabe: War die Aufgabe so angemessen? Haben Dinge gefehlt? Hätte die Bewerberin/der Bewerber lieber andere Schwerpunkte gehabt?
3. Kollaboration: Wie lief das Pairing? Waren die Informationen der/des PO verständlich? Mit welchen Fragen kann man mehr aus dem Produkt herausholen? Und vor allem auch: Fühlte sich die Zusammenarbeit generell “gut” an?

Nach dem Ende der Retrospektive (die nicht länger als eine halbe Stunde dauern sollte) heißt es dann vorerst Abschied nehmen. Aber nicht für lange. Passt es zwischen uns, wirst du Teil des Teams. Wenn nicht, sagen wir ab. Oder du.