Chapitre 11 du livre de Sandro Mancuso sur le Software Craftsmanship

Comme chaque semaine, nous vous proposons un résumé d’un chapitre de l’excellent livre de Sandro Mancuso Software Craftsmanship – Professionalism Pragmatism Pride. Nous vous proposons cette semaine, le résumé du chapitre 11 décrivant ce que le recruteur doit éviter lors d’un entretien.

Si vous êtes intéressés par la vision d’un craftsman sur son logiciel vous pouvez retrouver Sandro dans le catalogue de formation de Xebia Training.

Déjà publié :

1. Software Development
2. Agile
3. Software Craftsmanship
4. The Software Craftsmanship Attitude
5. Heroes, Goodwill and Professionalism
6. Working Software
7. Technical Practices
8. The Long Road
9. Recruitment 
10. Interviewing Software Craftsmen

Interview Anti-patterns

Les développeurs expérimentés savent utiliser l’entretien pour juger du contexte de travail de leur futur poste. Certaines erreurs récurrentes commises par les recruteurs poussent les développeurs talentueux à refuser un poste :

• Le recruteur qui veut en mettre plein la vue. Un recruteur qui tente d’impressionner un candidat par ses titres ou compétences, ou pose des questions-pièges dans le but de corriger le candidat, sera immédiatement repéré par le développeur expérimenté. Il vaut mieux traiter les candidats avec respect, comme des gens qui peuvent apporter des arguments à un débat sur des problèmes techniques.

• Les casse-têtes. Éviter les questions qui n’ont rien à voir avec le poste (ex. « Combien de balles de golf peut-on faire rentrer dans un avion »). Ce genre de question ne reflète en rien la capacité du candidat à travailler en équipe ou à se comporter de manière professionnelle.
   
• Poser des questions auxquelles on ne connait pas la réponse. Chercher des questions-réponses sur Google avant l’entretien n’est jamais une bonne idée. Si le recruteur est compétent, il connait les questions et réponses importantes pour le poste.

• Pas d’Internet. De la même manière, interdire l’accès à Internet en entretien ne reflète pas la réalité du travail qui sera demandé au candidat. Être capable de chercher des solutions pour résoudre des problèmes fait partie des compétences requises.

• Coder sur papier. Cela ne correspond pas à la réalité du travail qu’effectuera le candidat. Il n’est pas possible d’écrire des tests, de réusiner (déplacer des morceaux de code, extraire des fonctions) son code au fur et à mesure que l’on affine sa compréhension du problème.

• Questions d’algorithmique. S’il est nécessaire de vérifier la capacité d’un candidat à résoudre des problèmes, il faut tout de même que les problèmes soient en rapport avec le poste. En entretien, très souvent les problèmes présentés aux candidats sont des problèmes d’algorithmique pur alors que de grandes connaissances en algorithmes ne sont requises que pour très peu de postes. Il vaut mieux des exercices permettant d’évaluer le candidat sur les problèmes fréquents dans les projets de développement : manque de (bons) tests, refactoring à l’introduction de nouvelles fonctionnalités, couplage, TDD.
• Entretiens téléphoniques. Les entretiens téléphoniques sont mécaniques et ne permettent pas de voir comment le candidat se débrouille en conditions réelles car il n’y a pas de lecture possible du langage du corps, pas d’utilisation possible de stylo et tableau pour exprimer ses idées.