Les débordements de mémoire tampon sont-ils acceptables pour un développeur diplômé? Est-ce qu'on met la barre trop haut? Quelles sont les capacités attendues des ingénieurs diplômés / juniors?
Le contexte:
Nous recrutons actuellement pour un poste de développeur débutant travaillant principalement en C sous Linux.
Dans le cadre de ce processus, nous demandons aux candidats de passer un test de code à loisir en C.
Jusqu'à présent, nous avons rejeté deux candidats au motif que leur code, bien que lisible et dans un cas plutôt idiomatique, souffrait d'erreurs de débordement de la mémoire tampon en raison d'écritures de mémoire tampon sans limites.
[Modifier]:
- Nous demandons explicitement un code de qualité de production vérifié et vérifié.
- Nous fournissons un cadre de test et de construction aux candidats
[Mise à jour]:
Grâce à ce fil et aux conversations que nous avons eues en personne avec d'autres développeurs, nous modifions la manière dont nous effectuons les tests de code et ciblons notre recrutement.
Nous avons décidé que si un candidat était incapable de réparer ou de comprendre un débordement de mémoire tampon, il serait inutilisable pour le travail que nous effectuons. Il prendrait en particulier plus de mentorat que ce qui nous convient. Nous rejetterons donc toujours les candidats qui ne peuvent finalement pas soumettre un échantillon de code robuste.
Cependant, nous avons mis en place des mesures pour rendre le processus de recrutement plus productif pour nous et les candidats.
En particulier:
- Nous rendons nos attentes plus explicites, avec une explication claire de ce que nous entendons par qualité de la production et un avertissement selon lequel le code devrait être robuste en ce qui concerne les entrées et les erreurs.
- Nous relions maintenant les candidats aux ressources sur la programmation défensive et à la bibliothèque standard C dans la description du test de code.
- Nous avons changé notre public cible de développeurs et diplômés débutants pour cibler des personnes possédant une expérience pertinente.
- Au cas où le code soumis échouerait d'une manière ou d'une autre mais serait autrement accepté, nous fournissons maintenant un scénario de test minimum qui provoque la condition d'erreur et donne aux candidats une chance de corriger leurs erreurs (à moins que le code ne soit rejeté pour une autre raison). Nous indiquerons également les lignes / fonctions problématiques, le cas échéant.
- L’objectif des tests lui-même a maintenant légèrement changé, passant d’un filtre frontal à une chance de donner une meilleure image du candidat, en particulier il éclairera notre discussion téléphonique. Cela dit, nous sommes toujours disposés à refuser en nous basant uniquement sur du code.
[Mise à jour du 15/07/2015]: Andy Davis de Nujob a écrit un article intéressant et pertinent sur l'utilisation d'un test de code du point de vue du candidat. Cet article mérite d'être examiné. Trouvez le ici .