La révision du code dans le recrutement informatique - pourquoi et comment l'utiliser ?

Par 21 avril 2016 #!30jeu, 16 Avr 2020 11:14:41 +0200p4130#30jeu, 16 Avr 2020 11:14:41 +0200p-11Europe/Warsaw3030Europe/Warsawx30 16 30 -30jeu, 16 Avr 2020 11:14:41 +0200p11Europe/Warsaw3030Europe/Warsawx302020jeu, 16 Avr 2020 11:14:41 +02001411144 jeudi=254#!30jeu, 16 Avr 2020 11:14:41 +0200pEurope/Warsaw4#avril 16th, 2020#!30jeu, 16 Avr 2020 11:14:41 +0200p4130#/30jeu, 16 Avr 2020 11:14:41 +0200p-11Europe/Warsaw3030Europe/Warsawx30#!30jeu, 16 Avr 2020 11:14:41 +0200pEurope/Warsaw4# Test de codage, Recrutement informatique, Entretien technique

One of the most important but still ignored aspects of hiring a développeur de logiciels is verifying how candidate is dealing with the code and whether is able to express their thoughts with particular programming language. Usually in IT recrutement we do it by asking candidate to write some code solving particular problem. Candidate can do it alone or as a pair programming with the recruiter (Hit the bull’s eye with tests de codage in natural environment [case study]). We do it because writing code is one of the most important things developers do on a daily basis. However we should also remember that developers much more often read than write the source code. So we should not forget about verifying if candidate is able to quickly analyse and understand some code snippets. We can simply show some code printouts or (even better) give IDE with some project and ask questions related to what is happening here. That’s where code review challenge is really helpful.

Comment vérifier les compétences en programmation des candidats lors de l'entretien technique ?

Regarding what is said above we see that most of the time during technical interview/ assessment we spend on verifying if the candidate is able to solve some programming challenges or problems. Candidate is focusing on understanding and analyzing the problem and then finding a proper solution. However, we can realize that candidate is forced to think more about “what to do” than “how to do”. When we ask candidate to write a code which will be able to reserve a seat for a flight in some conditions, the goal is to ship the correct functionality, and mostly due to stress and time limitation it’s all the candidate is able to do. Is there any option to reverse this situation and let the candidate focus on “how”? Yes! For the many years when I was actively involved in IT sourcing and hiring developers or architects I was using code reviews.

Qu'est-ce que la révision des codes ?

Révision du code is a process when programmeurs verify each other code to find any potential problems, errors or deviations from best practices (if you want to learn more go to Wikipedia). Depuis quelques années, la révision du code est un élément essentiel du processus de livraison des logiciels. Elle nous donne une grande vérifiabilité et une meilleure qualité de code, mais elle permet aussi un partage des connaissances impressionnant - les gens peuvent maintenant enseigner et apprendre en même temps, en partageant leurs expériences. Mais je ne veux pas vous convaincre d'appliquer les révisions de code dans votre processus de développement (ce que vous devriez d'ailleurs repenser si vous ne l'utilisez pas encore), mais vous montrer pourquoi et comment utiliser les révisions de code lors d'un entretien technique.

Comment utiliser la révision de code dans le processus de recrutement informatique ?

En montrant le code candidat qui est déjà écrit et qui fonctionne (la plupart du temps) comme prévu, nous leur permettons de se concentrer sur la qualité de la solution. En demandant simple question “So, what do you think about this code” we change candidate into read-only mode. What is important to mention is that some developers are used to such tasks which they take during exam certifications, etc. and they are looking up for some silly, intentional errors like missing semicolons, incorrect parameters, wrong classes, etc. In my opinion we should use different approach. I always used working code that compiles correctly. I emphasize at the beginning that there are no “certification-like” errors and candidate should focus on best practices, some common problems that are hard to be noticed by automatic tools and can cause serious problems of production.

Exemple de défi de révision de code

For example in Java that could be invoking thread.run() instead of thread.start() which compiles correctly, tests are passing but we’re not starting new thread which can degradate final performance. We can also check if candidate will notice that some transactional method is invoked outside of the transactional aspect, which can cause serious consistency problems in a base de données.

Comment évaluer les compétences de programmation sur la base de l'examen des codes ?

Sur la base de la première impression du candidat, nous pouvons évaluer son approche de la qualité. Si, pour nous, le code est vraiment laid et plein de problèmes et que le candidat dit quelque chose comme "ça me semble bien", nous pouvons supposer qu'il n'aidera pas à améliorer la qualité du code dans notre entreprise et même qu'il la dégradera. Il est également assez facile d'évaluer l'expérience du candidat. Par exemple, dans un code source d'environ 60 lignes junior les développeurs ont pu trouver environ 4-5 numéros. Les développeurs ayant plus de 8 ans d'expérience ont pu en trouver 10. Et les meilleurs candidats ont pu trouver entre 15 et 20 sujets. Le meilleur candidat m'a indiqué deux problèmes dont je n'étais pas au courant, et lorsque j'ai écrit le code, plus de 30 problèmes ont été inclus.

Que devons-nous attendre des candidats ? Les points les plus importants sont les questions mentionnées ci-dessus - des problèmes qui sont courants pour une technologie particulière et qui ne sont pas visibles au premier abord. Ensuite, il y a la question de la lisibilité. Le code doit être propre, bien structuré et bien nommé afin que tout autre développeur (et pas seulement l'auteur) puisse le comprendre et le modifier. Ainsi, les noms des méthodes ou des variables - sont-ils significatifs, pas trop longs, etc. sont des méthodes qui ne sont pas trop grandes et qui ne contiennent pas trop de logique. Les technologies utilisées dans l'extrait sont-elles un bon choix pour résoudre un problème particulier (par exemple, si notre code utilise des opérations de chaîne de caractères pour construire un XML, nous pouvons nous attendre à ce que le candidat souligne qu'il existe de nombreuses bibliothèques qui ont été créées pour le faire de manière plus efficace).

Révision du code dans les campagnes d'évaluation DevSkiller

À l'adresse suivante : DevSkiller nous pensons que la révision du code devrait être incluse dans l'évaluation de la programmation compétences. C'est pourquoi la plupart de nos campagnes d'évaluation contiennent ce genre de problème à résoudre. Nous encourageons également les entreprises à élaborer leurs propres tests de codage qui comprendront un défi d'examen du code. C'est assez pratique pour la plupart des entreprises car vous pouvez utiliser votre ancienne base de code pour préparer une telle tâche. Il vous suffit d'en parler à votre service informatique et de l'inclure dans votre processus de recrutement.