Bewerber programmieren lassen

Warum man Bewerber programmieren lassen sollte

Phil Calçado beschreibt in diesem Artikel die Evolution des Einstellungsprozesses, die er bei mehreren Unternehmen – u.a. ThoughtWorks und SoundCloud – mitgemacht hat: On asking job candidates to code.

Er beginnt mit der Auswahl von Kandidaten für Entwicklerpositionen anhand der Bücher, die sie gelesen haben. Das trennt bereits die Spreu vom Weizen, da „schlechte“ Programmierer häufig keine technischen Bücher lesen.

Danach geht es weiter mit dem obligatorischen „Live Coding“. Das machen wir tatsächlich auch so: Bewerber müssen zunächst im Pair Programming zeigen, ob sie wirklich programmieren können, und wenn ja, wie sie Probleme lösen. Ganz nebenbei lernen sich die beiden Entwickler auch persönlich kennen und man kann danach besser einschätzen, ob der Bewerber ins Team passt.

Die letzte Stufe der Evolution ist eine vorgefertigte Test Suite, die den Kandidaten zugesendet wird. Erst wenn alle Tests grün sind, ist die Aufgabe gelöst. Das erspart den Einstellenden das mühsame Auswerten des Codes der Kandidaten. Das ist aber wohl nur sinnvoll, wenn man regelmäßig viele Bewerber hat.

Ich fand den Artikel sehr interessant, da sich ein ähnliches Ergebnis bei uns gezeigt hat. Viele Bewerber können leider einfach nicht richtig programmieren! Und das geht schon bei Kleinigkeiten wie einer for-Schleife los. Diese „Entwickler“ werden durch ein Verfahren wie das obige schnell aussortiert und belasten den Einstellenden nicht unnötig.


Wie läuft der Einstellungsprozess in deinem Unternehmen ab? Stellt ihr seltsame Fragen im Vorstellungsgespräch oder lasst die Kandidaten programmieren?

2 thoughts on “Warum man Bewerber programmieren lassen sollte

  1. Hi,

    die Frage ist, was wird dann da an Code verlangt? Ich wurde auch mal gefragt wie ich ein „Bubblesort“ programmieren würde und sollte das dann aufmalen. Aber was war denn überhaupt ein „Bubblesort“? Kannte ich bis dato nicht. Und nun?
    Schlussendlich hatte mir das Unternehmen sowieso nicht gefallen, insofern war es nicht tragisch dort nicht genommen worden zu sein.

    Andererseits (auch dort war es nicht tragisch), hatte ich mal eine Aufgabe mit Datenbanken, wenn dann auch noch zwei Leute über die Schulter gucken und du da im Anzug sitzt und die Schweißperlen runterlaufen… Jo, muss irgendwie nicht sein.
    Danach kam dann noch eine Aufgabe nach Hause. Ein Programm mit Datenbank und entsprechender Datenbankabfrage. Einen Datenbankhelper hatte ich als static deklariert, da lässt sich drüber streiten, ob das nun gut oder schlecht ist. Aber wozu daraus ein Objekt machen? Ende vom Lied war, das sei ja nicht Objektorientiert und schlecht und bla bla bla. Komische Firma -> wollte ich eh nicht hin.

    Also von mir aus lasst den Bewerber eine Aufgabe zuhause machen – in Ruhe! Und nicht wenn da zig Leute über die Schulter schauen.

    Achso und 1 Tag Probearbeiten musste ich auch schon, wo ich mich dann frage, wie soll man das als Berufstätiger machen. Da wird man dann genötigt 1 kostbaren Tag Urlaub zu nehmen, nur für die Firma. Um später eine Absage zu erhalten? Das kann doch nicht deren Ernst sein.

    Also es gibt ja nun genügend andere Auswahlverfahren und die Firmen die Interesse hatten, hatten so einen Spielkram auch nicht gemacht.

    Viele Grüße!

  2. Hallo Pascal,

    danke für dein Feedback. Du siehst das Ganze natürlich hauptsächlich aus Sicht des Bewerbers. Aber wenn du auf der anderen Seite sitzt, denkst du vielleicht etwas anders. Wenn du jemanden einstellst, der sich im Nachhinein als schlechter Programmierer herausstellt, war der ganze Aufwand für den Bewerbungsprozess umsonst und du hast einen Haufen Kosten verursacht. Und die Kosten wachsen noch an, wenn du den Entwickler weiter beschäftigen musst. Ich halte es daher für unerlässlich, Bewerber auf Entwicklerstellen programmieren zu lassen. Wohlgemerkt rede ich hier nicht von Azubis, sondern von fertigen Entwicklern.

    Das Programmieren an der Tafel oder vor einem großen „Publikum“ finde ich auch unsinnig. Bei uns gibt es ein Pair Programming mit einer anderen Person und das war’s. Wer so einer Situation – die im Alltag ganz normal ist – nicht gewachsen ist, ist dann meiner Meinung nach halt eben nicht der richtige Kandidat.

    Ich würde auch keinen Bewerber ablehnen, weil er mal eine Methode static macht. Sofern er die Vor- und Nachteile und vor allem seine Entscheidung sauber begründen kann, ist das doch völlig in Ordnung.

    Und zum „wertvollen“ Urlaubstag: Na klar ist das kostbare Freizeit des Bewerbers. Aber er bewirbt sich ja nicht umsonst. Vielfach ist doch z.B. ein Gehaltsanstieg zu erwarten oder überhaupt ein besserer Job. Ich denke, dass man da durchaus auch von einem Bewerber etwas Einsatz erwarten darf. Und bei uns werden auch nicht wahllos 20 Leute zum Probearbeiten eingeladen (denn das geht ja auch von unserer eigenen Zeit ab!), sondern z.B. nur die letzten 3. Daher ist die Chance, den Job dann letztlich zu bekommen, also nicht so schlecht.

    Viele Grüße!
    Stefan

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax