Bewerbungsgespräch mit einem Programmierer - Methoden und Tests

Eines der Themen, über die ich mich mit befreundeten Gründern am häufigsten unterhalte, sind die technischen Mitarbeiter. Keiner scheint je genug Entwickler zu haben. Klar, bei einem Internet Startup sind Entwickler mehr oder weniger direkt korreliert mit der Entwicklungsgeschwindigkeit (mit moderierenden Faktoren, wie z.B. planlosen Chefs).

Woher man verlässlich die besten Entwickler bekommt, kann ich nicht sagen (und würde es wahrscheinlich auch nicht, wenn es grosse Geheimtipps gäbe). Aber ich würde mal gerne darüber schreiben, wie wir aus den Bewerbern die Guten ermitteln, nachdem wir einen Kandidaten zum Gespräch eingeladen haben (Lebenslaufanalyse kommt ein anderes Mal).

Das typische Bewerbungsgespräch läuft bei mir wie folgt ab:
- Begrüßung
- Vorstellung Hitflip
- Vorstellung Bewerber
- Hitflip Test
- Fragen, fertig
Meist bin ich in 50-60 Minuten durch.

Zu den einzelnen Punkten:

- Begrüßung, Getränke anbieten, ein paar dumme Witze machen. Hier versuche ich dem Bewerber die Nervosität zu nehmen sowie mir einen ersten Eindruck zu verschaffen. Hier sollte der Bewerber auch mal lachen können und sich entspannen und mich neugierig machen.

- Als nächstes werden die Interviewer vorgestellt. Ich mache das immer mit einem Kollegen zusammen. Ich erzähle auch etwas zur Firmengeschichte und -struktur sowie zur zukünftigen Aufgabe. Dauer: etwa 5 Minuten. Der für mich langweiligste Teil, den ich schon nachts betrunken blind runtererzählen kann.

- Dann bitte ich den Bewerber sich vorzustellen. Am meisten Zeit verbringe ich damit über die letzten 1-2 Projekte zu sprechen. Technologie, Aufgaben, Rolle, was hat derjenige gelernt, wie war die Zusammenarbeit im Team, was würde er anders machen. Hier lerne ich viel über den Bewerber und wie er sich einschätzt. Übertriebene Negativität ist ein KO-Kriterium. Übertreibungen aber genauso. Ich frage vor allem viel über die Rolle des einzelnen nach. Hat er wirklich den Build Prozess gebaut, hat er da Input gegeben oder war er nur Nutzniesser? Schreibt er Oracle, mySQL und SQL Server weil er ANSI SQL gelernt hat, oder kann er sagen warum es bei mySQL schwierig ist Backups zu machen? Also der Unterschied zwischen kennen und können. Dieser Teil des Gesprächs dauert etwa 20 Minuten.

- Als nächstes kommt der selbstentwickelte Hitflip-Entwicklertest. Da muss jeder durch, ob Einsteiger oder Guru. Der Test besteht aus 10 Fragen, die einfach anfangen und immer schwieriger werden. Ich versuche hier ein breites Wissen abzufragen und dort nachzubohren, wo es weh tut. Zum Test gehört das tägliche Brot eines Web Entwicklers: Stringvergleiche, reguläre Ausdrucke, effizientes SQL, XSS und dann noch ein paar Fragen zur objektorientierten Programmierung. Wenn ein Entwickler eher im Backend aktiv sein wird, geht es dann noch Richtung Optimierung, Caching und Skalierung. Wenn ein Entwickler eher im Frontend aktiv sein wird, lege ich öfter mal einen Screenshot auf den Tisch und fange an über CSS und XHTML zu sprechen. Manche Fragen sind durch Pseudocode oder reine Mathematik lösbar (damit die nicht-PHPler punkten können). Der Test dauert etwa eine halbe Stunde.

Bezüglich des Tests kam schon mehrmals die Frage, ob sich “Gurus” nicht zu schade für so etwas sind. Meiner Meinung nach nicht. Entwickler lösen gerne Probleme und stürzen sich meistens auf jedes, was man ihnen vorwirft. Ausserdem gibt es für die Aufgaben teilweise unterschiedliche Lösungswege, die unterschiedlich “elegant” sind. Auf eine Frage gibt es sogar 7 Lösungswege, wobei erst einer auf die 7. gekommen ist. Amaze me!

Nachdem der Entwickler das geschafft hat kommt auch schon die Zeit für Fragen. Ich versuche wenig in die Fragen des Bewerbers rein zu interpretieren. Es gibt natürlich welche, die positiver rüber kommen (Ausbildungsmöglichkeiten, Perspektive, Technik usw.), welche die Verständlich sind (Arbeitszeiten) und welche die eher negativ sind. Aber das hängt stark davon ab, wie sie gefragt werden.

Dann ist es auch schon wieder vorbei. Ich spreche dann mit dem Kollegen und versuche dem Bewerber innerhalb von 3-4 Tagen ein Angebot zu machen, oder eben abzusagen.

Ob das nun revolutionär ist? Ich denke nicht. Aber gerade Personalauswahl ist ein Thema, was man m.E. viel zu wenig an der Uni lernt. Mit dem oben beschriebenen System bin ich bisher ganz gut gefahren. Aber vielleicht hat ja jemand andere Ergänzungen / Anregungen / ganz eigene Methoden? Ich bin gespannt…

This entry was posted on Montag, Oktober 29th, 2007 at 2:23 pm and is filed under Managing Teams. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.