Volltreffer mit Kodierungstests in natürlicher Umgebung [Fallstudie]

Durch 26. August 2015 #!31Mo, 18. Mai 2020 05:15:13 +0200p1331#31Mo, 18. Mai 2020 05:15:13 +0200p-5Europa/Warschau3131Europa/Warschaux31 18am31am-31Mo, 18. Mai 2020 05:15:13 +0200p5Europa/Warschau3131Europa/Warschaux312020Mo, 18. Mai 2020 05:15:13 +0200155155amMontag=8#!31Mo, 18 Mai 2020 05:15:13 +0200pEuropa/Warschau5#Mai 18. Mai, 2020#!31Mo, 18 Mai 2020 05:15:13 +0200p1331#/31Mo, 18 Mai 2020 05:15:13 +0200p-5Europa/Warschau3131Europa/Warschaux31#!31Mo, 18 Mai 2020 05:15:13 +0200pEuropa/Warschau5# Kodierungstest, Technisches Interview

After publishing a post concerning most common don’ts of hiring programmers we received some questions regarding programming tasks and the way we should verify coding Fähigkeiten.

From my long-term work experience I’ve got a lot of consulting practice on Rekrutierung process of programmers in some of the biggest IT companies based mostly in central-eastern Europe.

Wir haben viel über technische Interviews geschrieben. Zur Übersicht Der ultimative Leitfaden für das technische Interview.

Herausforderungen bei der Befragung von Entwicklern

When I started interviewing developers there was no time for active programming and Kodierungstests. We had a lot of candidates, so we had to stick to one hour limit for every issue – soft and technical assessment as well as financial negotiations. Finally we were hiring around 5% of initial candidates. After trial period about 90% of them continued working. It was quite good conversion rate.

Ziemlich...

But after calculating costs that were caused by inappropriate hiring decisions we realized we were wasting a lot of money. Salary, HR, office, notebooks, Senior developers time for kick-start, etc. Expenses additional to salary were on average almost doubling final cost.

There were three major reasons for not hiring developers after trial period:

  1. Sie waren nicht in der Lage, im Team zu arbeiten,
  2. sie hatten nur theoretisches Wissen,
  3. sie arbeiteten viel langsamer als erwartet.

Der Grund, warum wir nicht in der Lage waren, all diese Nachteile herauszufinden, war das Überspringen aktiver Kodierungstests während des Interviews. Softwareentwickler einzustellen, ohne zu prüfen, ob sie wirklich schnell und intelligent programmieren können, ähnelt dem Kauf eines Autos, ohne zu prüfen, ob der Motor funktioniert.

Wie konnten wir also all diese Schwachstellen in nur 60 Minuten überprüfen?

Die Antwort lautet einfach – we couldn’t! We had to extend interviewing process by at least two hours. But prior to doing that we were forced to limit the number of candidates at first. We decided to make 15 minutes phone screening by asking 10-15 technical questions as well as getting to know their salary expectations. On that basis we’re inviting candidate again or not. Screening process allowed us to reduce number of next necessary meetings by almost 40%, which was worse result than we expected, but good enough for extending the time of every single interview.

Wir haben versucht, eine Lösung zu finden, um zu überprüfen, ob jeder Kandidat auf der gleichen Wellenlänge mit dem Team ist und ob er die Programmiersprachen verwenden kann, die wir normalerweise täglich benutzen. Unabhängig von den erforderlichen Programmierkenntnissen bei der Arbeit der Programmierer legen wir Wert auf die Art und Weise, wie sie denken, insbesondere da dies ihre Fähigkeit zur Kommunikation mit anderen beeinträchtigt.

Ist die Paarprogrammierung eine Lösung?

Die Idee war eine Paar-Programmierung! Cool - wir bekommen das Beste aus beiden Welten. Die Annahme war richtig für etwa 70% unserer Kandidaten. Infolgedessen reichte eine einstündige Codiersitzung aus, um zu sehen, wie sich jemand in unserer anspruchsvollen und spezifischen Umgebung verhalten wird - sowohl bei der praktischen Anwendung des vorhandenen Wissens als auch bei der Fähigkeit zur schnellen Information Verarbeitung, Flexibilität und auch als Teamarbeiter, der manchmal gezwungen ist, Kompromisse einzugehen, um die Unternehmensziele zu erreichen.

Simultaneously, it also allowed us to see how they use tools, but first of all – how they can use SOLID principles in practice etc. But what with the other 30%? In fact these were people who can’t program in pairs at all. It was totally unnatural for them. Is it a big problem? When you realize that in practice you spent 5-10% of the time on pair programming you have to think through if you  can live with such Mitarbeiter  at the position you are filling 🙂

Wie können wir ihre Kodierfähigkeiten überprüfen? Lassen Sie sie einfach die Aufgabe fortsetzen, die wir begonnen haben. Aber allein. Ohne Interviewer, die ihnen über die Schulter schauen und jede einzelne Zeile eines Codes kommentieren.

Wichtig ist auch, dass wir die natürlichen Bedingungen für jeden Entwickler wiederherstellen - installierte Lieblings-IDE, Zugang zu StackOverflow.com, Dokumentation usw. Wenn der Kandidat nach der Verwendung seines eigenen Notebooks fragt - die Antwort sollte immer lauten: "Fühlen Sie sich frei. Tun Sie alles, was Sie brauchen, um sich beim Programmieren wohl zu fühlen". Natürliche Umgebung ist ein absolutes Muss für alle Arten von Tests zur Überprüfung der Programmierfähigkeiten, sowohl bei der Paarprogrammierung als auch bei Einzelgesprächen.