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).

[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.

[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.

[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.

[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.

[gagaches]

Ne pas s'étonner du recrutement de personnes ayant participer à des projets open source :
le recruteur peut voir leur technique et leur compétence facilement, en plus de se dire que la personne est motivée.

vous voulez vous faire voir ? participez activement à l'open source

[Zeo34]

Salut,
Je rejoins l'avis des autres à savoir faire passer des tests est important car après on passe souvent plus de temps à expliquer, à déboguer (à la place de la recrue), ...
Mais il faut savoir être juste lors des tests, ne pas pousser le candidat à bout, lui faire passer des tests à la hauteur des compétences demandées ...

J'ai passé un entretien une fois avec comme test d'expliquer un bout de code .NET alors que je ne connaissais pas, ... Ca n'a pas empêché d'avoir le poste et d'apprendre .NET !

[Nathanael Marchand]

Je déteste les QCM... Je suis plutôt pour poser des questions assez pointues et/ou tordues. Cependant, ce qui prévaut n'est pas la réponse (si elle est juste tant mieux) mais le raisonnement et la démarche. C'est pourquoi j'estime qu'un entretien est absolument nécessaire avec une discussion réelle face à un techos.
Pas un vulgaire questionnaire papier ni un programme sur PC: ce genre de choses, ca démontre le non investissement dans le process de recrutement...

[gbrout]

Suite à l'exemple cité dans l'article et au délà du sujet bon/mauvais CV/candidat, je lancerai plutôt un sujet du genre : Un CP doit-il forcément savoir coder ?

Un CP peut être complétement détaché de l'aspect purement technique à fond du moment qu'il sait gérer une équipe, rédiger des spécifications, bonne gestion relation client...

Des CP qui ont débutés en tant que développeur sur des langages qui ne sont plus les mêmes aujourd'hui ? Est-ce que cela l'empêche d'être un bon CP ? Au dire de l'article oui !

Est-il primordial dans tous les cas de faire passer un test technique pour un poste de CP ? Pour un poste de développeurs je le conçois tout à fait et l'encourage fortement pour le pratiquer moi même lors des tests de recrutement.

[Lorantus]

Le premier entretient d'embauche que j'ai eu était de décoder un algorithme sous VB (6.0 -dire si ça date).

Il y avait des milliers de lignes et une fonction à décrire :
- trouver la fonction dans le code,
- décoder la fonction,
- décoder les 3 fonctions appelées par celle-ci.

Rien de tel pour savoir si je sais coder, avec un esprit d'analyse et de recule (pourquoi telle implémentation) et d'organisation (faut trouver les 3 misérables fonctions de 2 lignes dans tout le code !!! sans parler des sauts et rappels de fonction à fonction).

Du moment qu'il n'y a pas de production de code commercialisable par le recruteur...

C'est un pas de plus vers un recrutement par compétence que vers un recrutement au "bac +100 ans"; qui est le défaut des français.

N'oublions pas que c'est un outil, et pas une solution de recutement. Il y a d'autres choses à regarder avant de valider une embauche.

[Traroth2]

Quand je faisais passer des entretiens il y a quelques semaines, je faisais passer un test tout simple, sur papier :

Ecrire une classe java avec une méthode main qui contienne une boucle de 1 à 100 qui affiche "multiple de 5", "multiple de 7" ou "multiple de 5 et de 7" quand les cas se présentent.

Trop facile, non ?

Vous seriez surpris du taux d'échec. La moitié des candidats est complètement infoutu d'écrire un truc aussi simple !

[MisterS]

Bonjour ,

Je suis complètement d'accord avec du déboggage et de la compréhension de code. Éventuellement du Code basic ou du "Code a troue" (que je pense un bon compromis entre la compréhension et le codage en situation sans le stresse de la page blanche) !!

Ça éviterais les faux-coder / leader de projet fictif..

On observera que la plupart cherche à ce planquer dans un statut et une entreprise du style "Orange Business" .. et ne postule jamais la ou ont demande vraiment de hard coder (tel les prestataire de service 8i / SS²I .. ) ou ils savent qu'il se feront largement remarquer pour leurs incapacités en 1jours .. ^^

Cordialement ,

[Traroth2]

Je déteste les QCM... Je suis plutôt pour poser des questions assez pointues et/ou tordues. Cependant, ce qui prévaut n'est pas la réponse (si elle est juste tant mieux) mais le raisonnement et la démarche. C'est pourquoi j'estime qu'un entretien est absolument nécessaire avec une discussion réelle face à un techos.
Pas un vulgaire questionnaire papier ni un programme sur PC: ce genre de choses, ca démontre le non investissement dans le process de recrutement...

Oui, si c'est le seul test. Le but de ce genre de test, c'est juste de dégrossir. Ça permet de virer 90% des candidats, ce qui permet de se consacrer beaucoup plus aux 10% restants, qui eux en valent peut-être la peine.

En entretien, je demande parfois à des candidats de m'expliquer des trucs tout simples, genre "en Java, qu'est-ce qu'une interface", et je suis prêt à accepter plusieurs réponses comme correctes, et pourtant, le nombre de candidats qui ne savent visiblement pas ce que c'est, c'est stupéfiant !

[Uther]

Personnellement, on m'a demandé de produire du code et/ou de répondre à des questionnaires techniques lors de mes entretiens d'embauche et je ne n'envisagerais pas de recruter sans faire de même.

Même si on est le candidat n'est pas expert dans les technologies concernées, on voit vite s'il a un minimum de logique ou pas.

[Priato]

Au risque de passer pour un extra-terrestre, je suis plutôt contre le fait de donner du code pour un entretient, surtout quand celui-ci se présente comme un Chef de projet. J'ai connu des chefs de projets qui ne savaient pas coder une ligne de code mais qui faisaient parfaitement leur boulot: Savoir diriger une équipe et faire le relais entre l'équipe de dev et le client.

Petite parenthèse sur les société de services, il m'est arrivé de présenter mon CV à l'une d'entre elle, et celle-ci s'est tout de même permis d'en modifier le contenu pour gagner un contrat auprès d'un client... Que faire quand toi, nouvel embauché tu arrives devant le client et qu'on te propose quelque chose que tu ne sais pas faire... Tu es dé-crédibilisé auprès des 2 boites, alors que tu n'es pas en tord... Certes la première boite le savait, du moins le commercial qui lui va juste rapporter au manager que tu es une quiche...

A part ça j'ai passé plus d'une dizaine d'entretiens et on m'a jamais proposé de pondre le moindre algo. Par contre on m'a sorti tout un tas de questions plutot bien tordues...

Après il existe les périodes d'essai...

[Virgil Scipion]

Je refuse de coder durant les entretiens d'embauche, car cela est une véritable torture, vu qu'on doti écrire à la main, ce que je n'arrive pas à faire pendant plus de trente secondes.
A chaque fois je bâcle totalement l'exercice, utilisant plus de phrases en français que de lignes de code, me contenant d'expliquer mon idée plutôt que de perdre du temps à écrire un programme et indiquant souvent que plutôt d'inventer quelque chose je préfère d'abord vérifier si ça existe.
Apparemment ça ne plait pas... et tant mieux car ça présente une entreprise qui ne me plait pas non plus

Par contre, c'est une bonne idée de mettre le candidat face à un problème, non pas pour chronométrer le temps qu'il met pour résoudre le problème (surtout si le problème n'a pas de solution définie), mais pour voir comment il le résout, comment il réfléchit.
Par exemple, une trace d'erreur dans un langage générique, où la bonne réponse n'est pas seulement de dire "cette instruction est fausse", mais où l'on accepte aussi que le mec explique qu'il met des traces à tel et tel endroit pour cerner l'origine du problème.

Dans cette catégorie, le plus con, et du coup le plus vicieux, était un exercice pour fusionner et trier deux listes déjà triées.
Clairement simple, mais peu importe le résultat, tout ce que voulait le recruteur c'était voir comment on réagissait, comment on lui expliquait, il évaluait bien plus notre capacité à communiquer, à agir de façon réfléchie et calme que nos compétences de programmation.

[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.