IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Idelways

28PARTAGES

10  2 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Nathanael Marchand
Rédacteur https://www.developpez.com
Le 20/04/2011 à 17:37
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...
13  0 
Avatar de bleporini
Membre régulier https://www.developpez.com
Le 20/04/2011 à 20:03
Bonjour,

Moi je suis fondamentalement contre les tests techniques! Je postule régulièrement pour décrocher des missions de dev sénior/archi/CP (en moyenne, une dizaine par an). Il m'est arrivé deux fois de passer des tests techniques et la première fois je me suis dit que c'était également un moyen de mesurer mes compétences autrement qu'en situation de mission. Or je me suis retrouvé à devoir détecter des "static" manquants jusqu'à la question fatidique : donner un algorithme de tri d'un tableau de n-entiers... et là je me suis dit que je n'en rajouterais pas, au bout de 15 ans de carrière à invoquer la méthode "sort", je ne me rappelle plus de l'algo du tri à bulles vu en 2è année de DEUG!

Je n'ai jamais décroché de mission suite à ces deux entretiens car j'ai été mauvais et en sortant, c'est mon estime de moi qui en a pris un coup alors que j'ai toujours été apprécié pour mes compétences techniques dans toutes mes missions (ou alors on m'a menti!).

Depuis je refuse systématiquement les tests techniques, par contre, je négocie un entretien technique dans lequel je peux m'exprimer face aux pointures de la boîte susceptible de m'accueillir, je ne sais pas forcément répondre à tout mais cela permet d'exposer ma démarche.

Je suis intervenu dans une société qui faisait passer des questionnaires aux candidats et cela ne permet pas forcément de filtrer correctement: au cours de ma mission d'encadrement, j'ai tellement rencontré de recrues (~2 ans d'expé) avec un niveau ultra faible que j'ai été obligé de sensibiliser la direction sur le problème de fiabilité de leur process de recrutement.

J'ai participé également à des phases de recrutement et j'ai été amené à mener des entrevues techniques et là je trouve que la plupart du temps les candidats on du mal à valoriser leur profil car la marchandise la plus difficile à vendre c'est soi-même et la mésaventure exposée me semble loin d'être le cas général, bien au contraire.

C'est mon expérience et mon avis...
12  0 
Avatar de Le_Bret
Membre régulier https://www.developpez.com
Le 27/04/2011 à 15:03
Totalement d’accord avec captainKirk.

Nous faisions passer ce genre de tests jusqu’il y a peu. Un candidat techniquement irréprochable s’est révélé être un gros fouteur de merde : il ne commettait jamais d’erreur, en cas de problème cela venait toujours de l’utilisateur trop bête pour comprendre (notre client !), ou de l’analyse de besoin mal faite, ou des autres développeurs qui avait mal codé les classes qu’il utilisait… Bref jamais de sa faute et surtout insultant vis-à-vis des collègues. On l’a viré au bout d’un mois.

Finalement on a pris un jeune diplômé (20 ans tout juste !) qui s’était complètement planté à ce test. Premier boulot, premiers entretiens, il stressait à mort. Au départ il était en CDD en attendant de trouver quelqu’un ayant plus d’expérience, mais on l’a gardé définitivement car dans le vrai boulot, il peut en remontrer à certains qui ont « ingénieur » marqué sur la carte de visite.
8  0 
Avatar de Virgil Scipion
Membre habitué https://www.developpez.com
Le 20/04/2011 à 18:00
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.
8  1 
Avatar de Jbx 2.0b
Membre chevronné https://www.developpez.com
Le 20/04/2011 à 21:17
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é.
7  0 
Avatar de Jean-Michel Ormes
Rédacteur https://www.developpez.com
Le 20/04/2011 à 16:59
Citation Envoyé par Soundscape Voir le message
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.
7  1 
Avatar de gbrout
Membre à l'essai https://www.developpez.com
Le 20/04/2011 à 17:39
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.
8  2 
Avatar de Lorantus
Membre éclairé https://www.developpez.com
Le 20/04/2011 à 17:40
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.
6  0 
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 20/04/2011 à 17:42
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 !
7  1 
Avatar de sinople
Membre chevronné https://www.developpez.com
Le 21/04/2011 à 9:22
Avis mitigé sur la question...

Pour la France je ne sais pas, mais en Suisse on a la période d'essai (ou on peut virer un type dans la semaine) de 3 mois pour vérifier sur le terrain ce que vaut la personne.

Sinon personnellement, je testerai plutot la logique de la personne, voir ces connaissances générales sur le sujet plutot que de lui demander de pondre un code sous le stress d'un entretien (pas le meilleur environnement pour briller) qui faudra analyser (faut penser niveau temps pour le recruteur aussi...).

Je met aussi une grande importance à l'expérience de la personne (sauf dans le cadre d'un poste junior, mais la on s'en fou on sait qu'on va avoir une "chèvre" à qui faudra expliquer qu'au boulot c'est pas comme à l'école)

Sans oublier les compétances sociales de la personne (3 pages et il y a pas un post qui les cites... Bravo les gars!) vu qu'une équipe qui s'entend bien a tendance à mieux travailler qu'une équipe de chiffonnier.
6  0