Code Kata Erfahrungen
In den letzten Jahren habe ich kleine Programmieraufgaben, sog. “Code Katas” eingesetzt, um Bewerber damit zu testen. Ich glaube, das Verfahren hat sich bewährt: Wir haben nicht einen Menschen “falsch” eingestellt. Alle “new hires” sind noch bei uns, und haben sich als ganz tolle neue Kollegen erwiesen. Darauf bin ich ein wenig stolz. 😊
Es ist Sinn der Übung, mit Bewerbern für Entwickler-Positionen nicht nur über Code zu sprechen, sondern am praktischen Beispiel zu programmieren. Nebenbei erfährt man so auch viel dazu, wie kommunikativ jemand ist, ob ein Mensch gern sein Wissen teilt, ob jemand gelernt hat, effizient zu suchen und und und. Wir konnten in den Katas viel über gute Bewerber:innen lernen, was nicht aus der Papierform hervorging.
Fünf positive Eigenschaften, die wir anhand der Code Kata erkennen konnten
- Strukturierter Lösungsansatz
Erfahrene Entwickler:innen schreiben einen Lösungsansatz zunächst als Pseudo-Code, und setzen diesen dann Schritt für Schritt um. Standard-Rückgabewerte werden als erstes formuliert. Blöcke werden sofort richtig eingerückt und geschlossen. - Kenntnisse der Programmiersprache
Konstrukte wieif
oderwhile
sind verstanden, die Argumente vonfor
& Co am richtigen Platz. Konzepte wie anonyme Funktionen oder Callbacks werden richtig eingesetzt. - Textverständnis
Die Aufgabe wird erstmal komplett gelesen. Bewerber:in entwickelt dann ein korrektes Verständnis, was gefordert ist, und ist in der Lage, dies mit eigenen Worten wiederzugeben. - Medienkompetenz & effizientes Suchen
Im Umgang mit Google kann Bewerber:in wichtiges von unwichtigem trennen. Sie kennt gute Informationsquellen und nutzt diese angemessen. - Umgang mit konstruktiver Kritik
Der Bewerber ist in der Lage, über seinen gewählten Lösungsweg fachlich zu diskutieren und dessen Vor- und Nachteile sinnvoll zu benennen.
Hätten wir auf die Kata verzichtet und nach diesen Themen im Vorstellungsgespräch gefragt, hätte jeder Bewerber sicher von sich behauptet, über all diese Eigenschaften zu verfügen. Aber was davon würden wir selbst auch so bestätigen?
Wo Licht ist, ist auch Schatten. Also:
Fünf negative Eigenschaften, die wir immer wieder gesehen haben
- Fehlende Grundlagen der Programmierung
Bewerber scheitern am Design des Kontrollflusses. Wann schreibe ich eine Funktion, wie nutze ich ein lambda. Selbst die Unterschiede zwischen kopf- und fußgesteuerten Schleifen sind nicht allen bekannt. - Kein Verständnis für Typen und Datenstrukturen
Bewerber:in kennt eingebaute Datentypen und Strukturen wie das Array nur oberflächlich. Set, LinkedList oder Hashmap? Fehlanzeige. Erweiterte Konzepte wie Bäume oder Graphen sind unbekannt. - Mangelnde Kenntnis der Standard Bibliothek
Die Funktionen und Möglichkeiten der Standard Library einer Programmiersprache sind nicht so präsent, dass Bewerber darüber sinnvoll verfügen kann. - Stack-Overflow-Driven Development
Oft liefert die Google-Suche nach einem Programmierthema Antworten auf Stack Overflow. Nicht ale Antworten sind gleich gut, oder passen zur Frage. Bewerber kopiert ohne nachzufragen Codezeilen von SO zusammen, in der Hoffnung, das Problem somit zu erschlagen. - Keine Erfahrung im Debugging
Der Klassiker: Wie gewandt ist Bewerberin im Suchen von Fehlern? Konsolenausgabe, ggfs Breakpoints… und werden die Unit-Tests eventuell zum Debuggen mitbenutzt? Hier unterscheidet sich ein Junior von einem erfahrenen Entwickler.