Discussion :

[Idelways]

Faut-il faire coder les candidats durant les entretiens d'embauche ?
Certains "développeurs" ne peuvent tout simplement pas développer



Décrocher un poste à la suite d'un entretien d'embauche n'est pas chose aisée pour tous les développeurs, mais réussir à ne pas commettre de recrutements ratés peut s'avérer encore plus problématique pour les développeurs et chefs de projets chargés de passer les entretiens d'embauche.

Tellement certains CV sont fantaisistes... et leurs porteurs savent mentir.

Le « Scrum Master » .NET Richard Banks, narre dans son blog sa propre expérience avec un « recrutement horrible » qui lui a fait prendre de nouvelles résolutions afin de ne plus se faire avoir par les candidats menteurs.
Surtout au vu des coûts non négligeables d'un mauvais recrutement.

Le candidat en question état « spécial » dans la mesure où il s'est présenté (très humblement !) en tant que chef de projet .NET. Il parlait avec confiance de ses compétences et références au point où il ne laissait aucun doute au malheureux recruteur quant à lui offrir le poste.

Après l'habituelle période de familiarisation avec la base du code du nouveau Boulot, Richard Banks met sa nouvelle recrue à l'épreuve des bogues, avant de le mettre sur des choses plus sérieuses.

Et là, surprise ! Le « chef de projet » autoproclamé a d'énormes difficultés, il embête ses collègues en sollicitant leur aide, prend un temps fou et n'arrive finalement pas à bout d'un bogue plutôt simple.

Pour comble de misère, il s'avère que ce « développeur » ne peut tout simplement pas coder, il est incapable d'écrire une boucle « For » (même avec l'IntelliSense de Visual Studio), c'est à peine qu'il sait faire correctement une instruction If élémentaire.

Explication affligeante ? Certains candidats n'hésitent pas seulement à gonfler leur CV, mais peuvent amener leurs amis à se passer pour leurs ex. employeurs et leur rédiger même des références flatteuses.
C’est dire que certains ne reculent devant rien.

La nouvelle résolution que Banks recommande est donc de mettre les candidats à l'épreuve durant l'entretien d'embauche. Sa méthode : leur faire passer des excercies de débogage sur de petits bouts de codes issus d’un petit programme ayant quelques bogues à corriger.

Le temps que passent les candidats à réussir ces exercices permet à Banks d'estimer par ailleurs leur niveau.

Les menteurs, quant à eux, devront pondre du code plutôt que d'en parler.


Et vous ?
Faut-il faire coder les candidats durant les entretiens d'embauche ?
Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?


Source : blog de Richard Banks

[Soundscape]

Et à l'inverse, il y a des gens avec des CVs pourris qui savent coder parfaitement... sauf que le recruteur ne les demande jamais en entretien. C'est vrai pour la programmation mais aussi dans tous les métiers!!!!!
Je ne comprends pas pourquoi les cabinets de recrutements, les agences pour l'emploi et consort ne font pas passer systèmatiquement des tests...ce serait utile aux employeurs et aux candidats !!!!

[Jean-Michel Ormes]

Et à l'inverse, il y a des gens avec des CVs pourris qui savent coder parfaitement... sauf que le recruteur ne les demande jamais en entretien.

Le premier but d'un CV est de décrocher un entretien. Un CV pourri donne pas envie à un recruteur de convoquer le candidat aussi bon soit-il.

[gangsoleil]

Bonjour,

Faire corriger du code n'est pas la meme chose que d'en faire ecrire. Mais la aussi, on peut tomber sur quelqu'un qui sait lire du code, mais qui ne sait pas en ecrire pour autant.

Apres, ca depend aussi du temps accorde pour les entretiens : si tu veux que ce soit fait en 20 minutes, alors faire developper du code permettra d'avoir une notion moyenne de ce que sait faire la personne, mais fera passer a cote de certains tres bon profils - tout en ecremant les plus mauvais.

Un bon entretien, ca demande du temps, et de l'investissement. Les meilleurs entretiens que j'ai vu, c'etait a un contre 3 ou 4 developpeurs a large spectre, ce qui leur permet de couvrir beaucoup de domaines. Le fait de poser des questions techniques permet de voir le niveau d'un candidat.
Ce type d'entretien n'a pas echoue. Par contre, il necessite 3 a 4 personnes pendant un peu plus d'une heure (une heure d'entretien, et 10 a 15 minutes de preparation).

[SurferIX]

Faire corriger du code n'est pas la meme chose que d'en faire ecrire. Mais la aussi, on peut tomber sur quelqu'un qui sait lire du code, mais qui ne sait pas en ecrire pour autant.

Euh je ne pense pas que quelqu'un qui ne sait pas écrire proprement du code puisse facilement le lire et/ou le corriger. Peut-être que je me trompe.

[Ryu2000]

Personnellement les CV et les entretiens ce n'est pas mon truc.
Je serais très heureux que la chose à faire pour trouver un emploi de développeur c'est coder !

De cette manière l'employeur peut nous placer au poste que l'ont mérite et nous permettre d'évoluer correctement.

Moi je me sentirais trop mal à place du gars ayant obtenu un gros poste, alors qu'il est complétement nul.

[el_slapper]

Les plus nuls se sentent souvent très bons, car ils sont tellements nuls qu'ils ne voient même pas leurs propres limites. Il fut un temps ou je correspondait un peu à la description. Toujours? Je ne sais pas. J'ose prétendre avoir progressé.

Le meilleur entretien que j'ai passé, j'ai gratté pendant 90 minutes sur 3 exercices(sur papier, c'eut été encore mieux sur machine) :

1)une petite spec, faire un algo et un plan de test.
2)une gestion de configuration avec gestion de conflit.
3)un code existant à analyser et à améliorer.

Je me suis gauffré au point 2, n'ayant jamais géré de conflit avant(par contre, chez ce client, j'en ai géré une tétrachiée, et maintenant je sais faire). Mais j'ai été suffisemment convaincant aux points 1 et 3 pour passer. Et ça a été le meilleur projet de ma carrière.

A mon sens, il est important de faire des tests variés et assez profonds. Mon client actuel recrute sur un QCM de 12 questions(écrites par votre serviteur). Ca permet d'éviter les purs boulets(ou les profils mal positionnés) qui ne connaissent rien, mais c'est tout - un médiocre fera illusion. Sur le test en 3 points, il ya beaucoup plus de casse, et il faut quand même de la bouteille et du talent pour s'en sortir. Mais je ne sais pas si c'est pertinent pour un jeune diplomé.

Je voulais rajouter des petites choses au QCM, mais le client me dit "pas le temps, ça ne doit pas dépasser 15 minutes", alors bon.....faut pas s'étonner, après, si on ramasse des moyens.

[Flaburgan]

Je voulais rajouter des petites choses au QCM, mais le client me dit "pas le temps, ça ne doit pas dépasser 15 minutes", alors bon.....faut pas s'étonner, après, si on ramasse des moyens.

Quand on voit les coûts d'un mauvais recrutement, on se dit que quand même, on devrait pas être à 5 minutes près...

[bleporini]

Il ne faut pas oublier une chose, un process de sélection doit satisfaire deux axes: l'evaluation de compétences techniques et des façons d'agir. Évidemment un RRH ne va pas pouvoir s'occuper de la partie technique et inversement. Tout cela pour en arriver a la conclusion qu'un candidat qui a réussi a sur vendre ses compétences n'a pas été détecte comme un fumiste par le RRH, si par chance il en croise durant les entretiens. Certes ce n'est pas un détecteur de mensonges mais cela permet de se poser des questions sur le savoir être du candidat et sur sa faculté a s'intégrer dans l'équipe.

Tiens sur ce sujet, quoi de pire pour un projet qu'un développeur compétent qui est incapable de s'appuyer sur un code sans avoir a le remanier afin qu'il réponde a ses exigences personnelles, genre "c'est fait avec les pieds" ou "c'est mieux comme ça". Et pourtant celui ci il a souvent déchire le test technique et fait reGulierement reculer l'équipe. il ne faut pas non plus amalgamer maitrise d'une technologie et compétence technique.

L'expérience m'a appris qu'un mauvais dev était débusqué en 1, 2 voir 3 mois. Alors qu'un mauvais CP peut sévir entre 6 et 12 mois avant d'être découvert.

-1: en tant que senior, une de nos taches est de procéder a l'intégration des nouvelles recrues: ce qui implique "marquage a la culotte" lors des premiers commits dans le SCM. Le max pour débusquer un mauvais dev est un mois, au delà cela devient notre responsabilité.

Mettez-vous à la place de l'embocheur, aimeriez-vous recruter une chèvre qui vous plombera une équipe ?

L'intégration dans l'équipe est loin de se résumer a la maitrise d'une techno.

[Reward]

L'intégration dans l'équipe est loin de se résumer a la maitrise d'une techno.

Je fais la distinction entre celui qui pipeaute son CV en prétendant maitriser et celui dont ce n'est pas le cas, mais que l'on pourra mener à niveau.

On peut toujours faire monter une personne techniquement, à partir du moment où l'humain est viable, l'inverse est quasi impossible. C'est pour cela que je privilège toujours l'humain chez un candidat.

Mes propos portaient sur les candidats mythos.

[freddyboy]

Je pense effectivement qu'un petit test de développement de 45 minutes à 1h est essentiel lors du recrutement d'un développeur.

Des petites applications, comme la division par zéro, la calculette, l'insertion d'un objet type 'Personne' en base de données sont des tests qui peuvent se montrer révélateur.

Ou encore une méthode qui détermine si une chaine commence par une lettre majuscule comme l'explique Joel Spolsky ici http://www.joelonsoftware.com/articl...rviewing3.html.

L'organisation du code (en couche ou non), les commentaires, les règles de programmation, la gestion des exceptions peuvent être évalués.

Pour ma part, j'ai fait 5 sociétés et j'ai eu 2 fois des tests de développement en entretien et je trouve cette pratique normale et seine.

[Faiche]

C'est marrant, aux états unis, il y a quelques compagnies qu'on ne peut contacter que lorsqu'on a résolu un algo. Cad : la réponse est un nombre, et l'email du rectruteur c'est nombre@entreprise.com

Et dans l'email, il faut envoyer le cv, la lettre de motiv, et le code qui a permi de trouver la réponse.

[Nyark]

C'est marrant, aux états unis, il y a quelques compagnies qu'on ne peut contacter que lorsqu'on a résolu un algo. Cad : la réponse est un nombre, et l'email du rectruteur c'est nombre@entreprise.com

Et dans l'email, il faut envoyer le cv, la lettre de motiv, et le code qui a permi de trouver la réponse.

Personnellement, je trouve que c'est très intéressant pour poser une candidature.
Le CV et la lettre de motivation reste quand même de l'esbroufe dans les premières années d'une carrière, car comme vous avez pu l'indiquer précédemment, "les menteurs" passeront parfois cette étape au détriment des autres.

L'intérêt d'un tel procédé, c'est que la compétence sert de première barrière. Savoir se vendre est une bonne chose, mais il est tout de même navrant de laisser sur le carreau de bons éléments au profit de charlatans uniquement bons à se faire recruter et à rien d'autre.

[kedare]

A mon boulot on a des QCM à l'entretient d'embauche, bon pas en tant que développeur mais en tant qu'administrateur par contre

[atha2]

Coder lors d'un entretien pourquoi pas. Le test de Traroth2 me semble à la porté de n'importe quel vrai développeur sans faire perdre de temps (ça doit prendre 10 lignes et 2 minutes grand max). Ça permet d'éliminer les "menteurs".

Pour ma part mon pire entretien : le recruteur, après avoir discuté un peu, m'a fait répondre à un dizaine de questions sur le langage Java :
-Java est un langage :

1) compilé 2) interprété ?

-> Bon évidemment il est compilé en Bytecode mais ensuite c'est moins clair (JIT, tout ça). Et puis généralement quand on parle de compilation c'est en langage machine. Donc que répondre quand c'est un QCM ? J'ai mit les 2 me disant que je pourrai expliquer ma démarche lors de la correction, il attendait compilé et m'a sortie "ba oui javac c'est pour compilateur Java donc c'est compilé et puis c'est tout"
-Comment transformer un int a en String ?

1) a.toString() 2) a.asString() 3) a.string() 4) new String(a)

-> WTF ??? J'ai répondu, en écrivant à coté "" + a et String.valueOf(a). Le recruteur attendait a.toString(), comme quoi Java était un langage objet, donc tout était objet et comme Object avait une méthode toString(), il fallait s'en servir et surtout ne pas ajouter de réponse à un QCM.
Le recruteur (surement un développeur C# qui s'était que Java était pareil) n'avait jamais entendu parler de type primitif...


Tout ça pour dire que la technique dans un entretien (code ou autre), je ne suis pas contre mais à condition que le recruteur maitrise réellement son sujet. Sinon on se retrouve avec des questions aberrantes et une "correction" encore pire


EDIT : @lequebecois79 : Je viens de faire le test en version beta (pas besoin de s'enregistrer). J'espère juste que le vrai test est meilleur. La plupart des questions sont très ambiguëes (on ne sait pas toujours ce qui est demandé). Bon c'est peut-être pas pour rien que ce test est en version beta
Mais j'ai surtout l'impression que le test est plus là pour piéger les candidats que pour tester ses réelles connaissances/compétences. Du genre utiliser un print alors que 95% du temps on utilise println. Bon j'ai passé 24minutes sur les 42 autorisées mais je suis tombé dans pas mal de piège de ce genre... Résultat 15/28 dont 7, 8 questions où soit je suis tombé dans un piège, soit je ne toujours pas convaincu par la réponse

[Jbx 2.0b]

Dans ma boîte, aucun des chefs de projet ne sait réellement coder.

Il y a ceux qui ont su, en fortran dans les années 80 quand ils sortaient des études. Ceux qui n'ont jamais été vraiment disposé à cette tâche et qui ont vite trouvé la porte de sortie pour devenir CP. Et ceux qui n'ont jamais su, et qui ont été catapulté là et se retrouvent à gérer des développeurs tout aussi bien que des cueilleurs de fruits rouges.

Chez nous, un CP c'est quelqu'un qui maîtrise excel, et qui partage son temps entre le téléphone et les réunions. Le CP te demande si tu es en retard, produit un fichier excel calculant ton retard, organise des réunions ou il montre des jolis diagrammes qui montrent clairement les différents retards qu'a prit le projet, et qui contribuent en grande partie à ce retard et donc à sa légitimité, et ainsi à son salaire bien plus élevé que le développeur lambda.

En cours, on m'avait expliqué qu'un CP en France, était très souvent issu du technique, à contrario des pays anglo-saxons.

Du coup, en vue de mon expérience ( en vue des précédents commentaires, tout le monde ne semble pas avoir ma "malchance" ) j'ai un peu de mal à comprendre l'étonnement de Richard Banks.

Pour ce qui est des tests, je suis pour si ceux-ci sont cohérents.
Je me suis vu répondre à un questionnaire C pour une mission estampillé C++.
Me planter littéralement sur un autre questionnaire C++ bourré de MFC, dont je n'ai aucune connaissance (sans aucun regret).
J'ai aussi effectué un C++ de deux heures plutôt corsé, et lutter avec les conteneurs STL vu que je sortais de 6 mois de full Qt (les différences sont faibles, mais difficiles à justifier ). Ce dernier m'a d'ailleurs un peu dégouté, avec un simple accès internet je me serrais bien débrouillé.

[Bluespear]

Faut-il faire coder les candidats durant les entretiens d'embauche ?

Non. Je pense qu'après avoir eu le blablabla de la RH sur l'entreprise pendant 15 minutes, avoir raconté sa vie pour montrer qu'il saura s'intégrer dans une team et résisté à des questions de "mise en pression cass-pied" pour voir comment réagit le candidat à des provocations, le faire jouer avec du code C sur un tableau blanc et plein de pointeurs supervisé par 1-2 développeurs qui le font tous les jours c'est un peu jouer au lotto pour avoir 5% de chance de recruter le bon candidat.

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?
1/ Ne pas faire aveuglément confiance au candidat. Si il a pas mal d'expérience, il est malgré tout devenu habituel de "bullshiter" dans les CV. En Suisse, profiter des 3 mois d'essais pour lui infliger les plus grosses épreuves qu'il pourrait avoir à affronter, surtout si la place que le candidat vise est du genre "Scrum Master" / "Senior Architect"... il y a surement de belles grosses "story" trainant en backlog qui pourraient passer en en implémentation, ça aurait de quoi montrer que le sujet sait y faire face

2/ Si la roadmap est déjà planifiée sur du long terme, la meilleure façon de s'assurer des capacités du canditat sont à mon avis:

a/ De lui demander des exemples de projets comparable à ce qu'il devra faire
b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

[gokudomatic]

Faut-il faire coder les candidats durant les entretiens d'embauche ?

Non. Je pense qu'après avoir eu le blablabla de la RH sur l'entreprise pendant 15 minutes, avoir raconté sa vie pour montrer qu'il saura s'intégrer dans une team et résisté à des questions de "mise en pression cass-pied" pour voir comment réagit le candidat à des provocations, le faire jouer avec du code C sur un tableau blanc et plein de pointeurs supervisé par 1-2 développeurs qui le font tous les jours c'est un peu jouer au lotto pour avoir 5% de chance de recruter le bon candidat.

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?
1/ Ne pas faire aveuglément confiance au candidat. Si il a pas mal d'expérience, il est malgré tout devenu habituel de "bullshiter" dans les CV. En Suisse, profiter des 3 mois d'essais pour lui infliger les plus grosses épreuves qu'il pourrait avoir à affronter, surtout si la place que le candidat vise est du genre "Scrum Master" / "Senior Architect"... il y a surement de belles grosses "story" trainant en backlog qui pourraient passer en en implémentation, ça aurait de quoi montrer que le sujet sait y faire face

2/ Si la roadmap est déjà planifiée sur du long terme, la meilleure façon de s'assurer des capacités du canditat sont à mon avis:

a/ De lui demander des exemples de projets comparable à ce qu'il devra faire
b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

Donner un projet à réaliser dans un temps imparti? En théorie, l'idée est bonne. Mais en pratique, aucun chercheur d'emploi n'aura le temps de faire ça. A moins que ce soit vraiment un micro-projet qui tient plus du devoir scolaire de la semaine qu'autre chose.

[Flaburgan]

Rajoute de plus que rien ne te prouve que ce sera lui qui l'aura fait.
Si les gens sont prêt à tricher sur leur CV, alors ils seront aussi prêt à faire passer les tests à d'autres.

Et puis quoi, on bosse pas pour des prunes non plus, coder un projet pour une entreprise qui ne nous a pas encore (et peut être jamais) embauché...

[gangsoleil]

b/ Lui donner un projet à réaliser dans un temps imparti, par exemple 1 à 2 semaines sur son temps libre suivant sa condition et qu'il devra présenter / défendre durant l'entretient. Je trouve ça plus utile que de lui faire pondre 30 lignes de code après 40 minutes d'entretient avec la RH

"Mon bon monsieur, je vous remercie de l'exercice que vous me proposez. Quelle est la remuneration que vous proposez pour que je me fasse chier pendant 2 semaines sur mon temps libre a vous prouver que quelqu'un (moi ou un autre) est capable de resoudre votre probleme ?"

Serieusement, si un recruteur me sort ca lors d'un entretien, je lui explique qu'il est bien gentil, mais que j'ai autre chose a foutre que de bosser le soir pour rentrer dans sa boite. Je pense d'ailleurs que je mets fin a l'entretien.

Et vu que (d'après les offres d'emploi actuel), tout le monde veut quelqu'un avec 5 ans d'expérience dans le domaine, connaissance de .Net avec 5 ans d'exp, maitrise de l'anglais du français et de l'allemand, certif SQL,...: candidat introuvable pour le salaire de misère que certains proposent, ça prouvera qu'il saura s'adapter pour se débrouiller dans son job.

Ca veut juste dire que ton candidat a suffisamment besoin de ce poste pour accepter de travailler au noir pour ta societe sur ses heures de temps libre, et de te rendre un projet que tu revendras tres cher a tes clients, pour peu que le candidat soit bon.

Oui, beaucoup d'offres sont delirantes, mais tes propos le sont egalement.