Discussion :

[Gordon Fowler]

Faire écrire un code fonctionnel lors d'un recrutement se généralise
Est-ce une bonne méthode d'évaluation ou une aberration ?


De plus en plus de recruteurs exigent des candidats qu'ils écrivent, pour prouver leurs savoir-faire, des bouts de codes ; mais pas n'importe quels bouts : il faut que ceux-ci soient entièrement fonctionnels.

La différence est de taille.

Joel Spolsky, célèbre programmeur américain - il a notamment été le chef de projet d'Excel entre 1991 et 1994 -, explique qu'il impose toujours cet exercice aux candidats.
Mais lui, précise-t-il, ne demande qu'une bribe de code, pas un produit fini "qui tourne". Pour Spolsky, il s'agit d'évaluer in vivo la capacité à penser, à réagir aux critiques, à s'adapter. Ce type d'exercice, précise-t-il, ne sert en fait pas à évaluer un savoir-faire technologique.

Il utilise une métaphore intéressante. Un test fondé sur l'écriture de code revient à évaluer les capacités d'un électricien ou d'un plombier. Il ne viendrait à l'esprit de personne de demander à l'une de ces deux professions de faire toute l'électricité ou toute la tuyauterie d'un studio avant l'embauche.

C'est pourtant, pour continuer la métaphore, ce que font les recruteurs qui demandent une application clef en main à un programmeur.

Certains vont jusqu'à dire que ces exigences sont irrespectueuses et, pour parler cruement, complètement à "coté de la plaque".
Un candidat n'a en effet pas le temps matériel de produire un code focntionnel pour chaque entreprise à laquel il postule. Un recruteur peut néanmoins évaluer la motivation de cette manière. Mais la manière reste bizarre.

Irrespectueux également pour les programmeurs seniors. Un simple examen du CV ou une conversation sur quelques subtilités devraient suffire à évaluer la maîtrise de tel ou tel langage.

Enfin, pour d'autres, écrire un code fonctionnel passe surtout à coté de l'essentiel.
Or l'essentiel c'est ce que cherche Joel Spolsky ou n'importe quel bon recruteur : mettre à jour les facultés d'apprentissage et d'adaptation dans le temps (avec la syntaxe d'un langage donné).
Un test fondé sur la production d'un code fonctionnel est une photo figée. Pas une mise en perspective du profil du candidat.

Pour toutes ces raisons, la question de la pertinence de ce genre de tests se pose de plus en plus, surtout en période économiquement tendue où les rapports de force employeurs-employés sont modifiés au profit des premiers. Et où il est difficile de refuser.

Y compris les pratiques les plus inadéquates ?

Source : Les billet de Spolsky ici et là

Lire aussi :

La rubrique Emploi
80% des jeunes diplômés de 2008 en IT ont trouvé un emploi, selon l'Apec

Et vous ? :

Avez-vous eu à faire ce genre d'exercices lors d'un entretien d'embauche ? Qu'en avez-vous pensé ?
Au contraire vous défendez les tests d'écriture de code fonctionnel : dîtes nous pourquoi ?

[h472009]

Pour moi, sans une periode d'essais, on pourra jamais juger un developpeur.

Savoir implementer un algorithme ou une fonctionalités ne veux rien dire, c'est le cadre d'un projet réel, avec son travail de groupe, et son stress ettouffant qui pourrant distinguer un bon developpeur d'un autre moin bon...

[mrjay42]

A la rigueur un débug d'un code sur une machine déjà configurée pourquoi pas...

Pour avoir cherché du boulot de mars à septembre 2009 je peux vous dire que ce à quoi on a droit est bien :
Des QCM (sur papier ou par interface web) sur de la prog...Qui se résument en fait à du "par cœur" et de la pure syntaxe !
Totalement stupide.
Surtout qu'au final les recruteurs ont tendance à se servir de ce genre de QCM comme une condition binaire à l'embauche :
Si le QCM est bien rempli alors embauche
Sinon on rappelle le candidat en disant que c'est pas la peine...

[pmithrandir]

Je ne trouve pas obligatoirement les tests à l'embauche stupide. Mais comme tout, ils doivent être bien fait et juste une part du processus de recrutement.

J'avais eu quelque question de base(genre syntaxe php) des question bete de POO ou un petit algorithme à faire dans un temps donné une fois.

Une autre fois, ils avaient poussé le vis jusqu'à me demander par cœur les fonctions sur les tableaux en PHP, dans les différentes versions... l'enfer

La première méthode me parait bonne pour vérifier que le candidat n'a pas raconté de bobard trop énorme, et ne dure que 15 minutes.

La seconde m'a paru stupide. Je n'utilise pas tous les jours les fonction sur les tableau en PHP, donc, quand j'en ai besoin, je vais voir sur le site la liste et je prend la meilleure.

[cf1020]

Toutes les combines sont bonnes pour certains employeurs pour ne pas embaucher certains candidats. Et eux, est-ce qu'ils sont compétents dans leur tâche ?!.

Jamais de la vie ont peut juger le travail d'un programmeur par un bout de code qui tourne, pour cela, il faut au minimum 1 mois de travail, comme aussi, on ne peut JAMAIS juger le travail d'un programmeur par sa manière d'écrire du code. Chacun à son style, et avec ou sans cette chose inutile appellée "UML", chacun aura toujours sa façon de faire pour arriver au même résultat.

[GanYoshi]

Chacun à son style, et avec ou sans cette chose inutile appellée "UML", chacun aura toujours sa façon de faire pour arriver au même résultat.

Troll velu spoted

[Franck SORIANO]

De plus en plus de recruteurs exigent des candidats qu'ils écrivent, pour prouver leurs savoir-faire, des bouts de codes ; mais pas n'importe quels bouts : il faut que ceux-ci soient entièrement fonctionnels.

Du code qui ne fonctionne pas, ça ne sert pas à grand chose.

Demander d'écrire du code fonctionnel ça me semble être un minmum. C'est la seule façon de mettre le candidat en situation réelle et d'avoir un aperçu de ses compétences.
Il y a un tas de petites choses qui peuvent se faire en 1 heure. On peut très bien soumettre un candidat à un problème, et voir comment il l'analyse et s'il parvient à le résoudre.

Tout le monde sait très bien que les CV sont trafiqués et exagérément embellis.
De même en entretien, j'ai déjà vu des beaux parleur qui récitent par coeur des connaissances théoriques, mais qui une fois face à leur clavier sont totalement incappable de les mettre en pratique... (un truc tout bête d'ailleurs, regarder avec combien de doigts il tappe sur le clavier en dit déjà long sur le candidat)

Le test à l'embauche ne permettra pas d'évaluer complètement les compétences d'un candidat, mais bien souvent il permet qu'en même d'éliminer bon nombre de boulet...

Irrespectueux également pour les programmeurs seniors. Un simple examen du CV ou une conversation sur quelques subtilités devraient suffire à évaluer la maîtrise de tel ou tel langage.

Le nombre d'années d'expérience ne fait pas la qualité de cette dernière. Si le candidat a passé 15 ans à faire les mêmes erreurs, ça ne se voit pas sur le CV, et le candidat aura en plus de grandes chances d'être irrécupérable.
De plus, ce n'est pas la maîtrise d'un langage qui est importante (ça ça s'apprend vite et facilement). C'est la faculté d'analyse, de compréhension d'un problème et la capacité à trouver une façon de le résoudre.

Savoir implementer un algorithme ou une fonctionalités ne veux rien dire, c'est le cadre d'un projet réel, avec son travail de groupe, et son stress ettouffant qui pourrant distinguer un bon developpeur d'un autre moin bon...

Savoir implémenter un algorithme ne veut peut-être rien dire. Mais lorsque le candidat n'y arrive pas, ça en dit très long...
Lorsque le candidat regarde l'énnoncé et te dis rapidement que ce n'est pas la peine qu'il essaie, il n'y arrivera pas, ça en dit aussi long.
Et je ne parle même pas de celui qui au bout d'une heure te dit qu'il n'a rien à te montrer parce que l'IDE vient juste de planté et qu'il n'avait pas enregistré son travail...

Toutes les combines sont bonnes pour certains employeurs pour ne pas embaucher certains candidats.

Tu n'as pas besoin de combines. Si le candidat ne te convient pas, tu dis non.

Pour finir, je dirais que le test à l'embauche est un critère bien plus sérieux et pertinent que d'exclure un profil parce que son CV dit BAC+4 et qu'on cherche un BAC+5. Ou parce que le candidat dit "expert SQL Server" et pas "expert Oracle", pour faire un développement avec un ORM...

[Fred3d]

... a mon avis le meilleur moyen de se faire une idée de quelqu'un est la période d'essai pour la voir évoluer dans des conditions réélles ... maintenant si un recruteur hésite entre plusieurs personnes faut bien qu'il se base sur certains critères pour les départager donc écrire un petit morceau de code pourquoi pas ...

[turican2]

Ouep mais avez vous fait un entretien où le code a développer se faisait sur une vieille bouse de bécane sans internet ni msdn d'installé? moi perso j'ai souvent besoin de la doc donc démontrer ok, mais donnons quelques moyens au candidat .

Les entreprises sérieuses (je pense aux grosses ssii d'informatique) devraient créer un standard pour ce type d'entretien et prévenir le candidat sur le temps nécessaire à la réalisation de la séance. Car 45 min de RH, 30 minutes de chef de projet, 1h (plus 1h30) de test, attente entre les protagonistes, ça fait quasiment 3h d'entretien et ça casse le planning du candidat.

Au final, je ne suis clairement pas opposé à la mise en application du candidat. Les gens qui nous disent pouvoir produire la lune en 1 mois j'en rencontre beaucoup mais il faudrait cadrer (légalement) l'entretien. Et oui, si le code produit est bien penser et que le candidat au final ne vient pas dans la dite société... la propriété intellectuel de ce code appartient à qui? c'est pas factice ce que je raconte, je l'ai entendu)

[el_slapper]

En SSII, j'ai passé un entretien chez un client ou j'avais une heure et demie pour résoudre - sur papier - 3 problèmes :

_une analyse de specs, avec algorithme et plan de test à pondre
_une gestion de config avec gestion de conflit
_une analyse de code

très intéressant pour écarter ceux qui n'y pannent rien. Réussir ne signifie pas être bon, mais échouer est clairement significatif .

[Louis Griffont]

Pour ma part, j'ai les deux expériences...

1) En tant que candidat, j'ai parfois été soumis a des petits tests, parfois pas !
2) En tant que recruteur, j'ai toujours soumis les candidats à un test, pas de programmation mais plutôt d'analyse. Tous les candidats avaient le même test et le même temps. Ensuite je comparais ! Entre, le test et l'entretien, on arrive à se faire une idée. Mais une idée seulement, et rien ne vaut une période d'essais, d'au moins 3 mois renouvelables pour se rendre vraiment compte de la valeur d'une personne !

[theMonz31]

Bonjour à Tous

Personnellement, j'ai 37 ans, je développe depuis l'age de 12 ans. J'ai commencé à coder en hexadécimal sur un Apple //e... le cadre étant posé,
je vais maintenant parler de mon expérience.

J'ai passé quelques entretiens dans des entreprises ou on demandait d'écrire du code...

Une m'a demandé d'écrire une calculatrice en C#... Ca m'a gonflé de devoir faire de la production écrite... J'ai été voir le recruteur, je lui ai expliqué que pisser du code me faisait royalement chier en entretien (quasiment de cette façon là pour l'explication), par contre, je lui ai dit comment je ferais, lui est parlé de CodeDom pour l'aspect calcul (plutot que de pondre un analyseur lexical). Le gars m'a dit que j'étais le premier a pensé à CodeDOM... J'ai pas eu le poste finalement parce que le salaire demandé ne pouvait être donner par la boite.

Exemple 2: Une autre boite (Toujours à Toulouse) m'a demandé de remplir plusieurs pages ou des questions s'enchainaient. Les questions s'étaient du genre (en C++), écrire la surcharge d'un opérateur, etc... trouver ce qui ne marche pas dans le code, etc...
La aussi, ça m'a profondément gonflé et je l'ai dit. Le gars a quand même insisté sur son questionnaire, alors je lui ai fait rapidement à l'oral...

Dans les deux cas, j'avais déja autour de 10 ans d'expérience professionnel.

Bilan : Faire écrire du code sur du papier, je trouve celà complètement CRETIN... et je le dis en face de n'importe quel recruteur ou autre. Demander à reflechir à un algorithme, je trouve celà aussi cretin sauf si on le fait par oral et qu'on voit comment la personne répond. Pour moi, un recrutement, ce n'est pas comme un "examen" scolaire. Pourquoi donner 15 minutes pour faire un exercice si des personnes mettent 2 minutes pour trouver la solution. Pourquoi tester la capacité à écrire du code.. Si on est capable de juger en 5 minutes qu'un développeur est bon ou mauvais par son code et qu'on n'est pas capable de le voir en discutant avec lui ou en lisant son CV, c'est peut-etre qu'on n'a pas les compétences pour recruter ce type de profil.

Perso, mon CV (11 boites en 13 ans) est touffu (2 pages), mais il n'est pas bidonné. Et quand je discute avec quelqu'un de technique, je vois vite si il a un bon niveau. Je pense qu'un recruteur c'est pareil.. SAuf si on passe par des cabinets de recrutement non spécialisé. De développeur à développeur, on voit bien si le candidat a le niveau... Par contre, face à quelqu'un des RH non techniques, il suffit d'aligner les mots techniques et les belles histoires d'expériences et cela passe...

Alors au final, je dirais que pour moi, les tests de code ou d'algorithme ne sont là que, comme la graphologie, pour faire croire au recruteur que son incompétence à lire une personne est sauvé par une "preuve" qu'il peut qualifier de tangible.

A+

[antony810]

Les entreprises ont des périodes d'essai pour contrôler réellement le potentiel d'un candidat. L'entretien peut être un moment déstabilisant pour un candidat et qu'il ne permet pas de jauger de façon objective un candidat.

Que le CV soit trafiqué, ca se remarque assez facilement dans la mesure ou les questions du recruteurs soient pertinentes (j'en doute parfois).

Un développeur doit pouvoir se fondre dans un collectif aussi. Le coté geek ours des cavernes ou le soit disant dieu du code qui croit tout connaitre ca ne marche plus trop à mon sens. J'en ai croisé dans des équipes et ce fut dur dur à gérer.

Pour résumer le coté test technique oui mais pas obligatoire selon le poste.

[Aurelien.Regat-Barrel]

Les entreprises ont des périodes d'essai pour contrôler réellement le potentiel d'un candidat.

Yes. Mais les tests sont un bon moyen d'éliminer les plus mauvais / ceux qui bluff le plus : on ne peut pas faire passer une période d'essai à chaque candidat n'est-ce pas. Et aussi... et surtout... ça permet d'avoir des billes pour négocier le salaire : le mec se dit expert en Java et BD. Effectivement, les tests ont montré un très bon niveau en Java, mais en BD, c'est bien mais pas autant qu'il le laisse entendre...

J'ai cherché du taff y'a 2 mois et ai passé un certain nombre de tests :
- le test le plus débile est le QCM automatisé sur un site web avec un score à la fin. Et c'est ce que les recruteurs préfèrent le plus car ils ont une "note", un moyen simple de dire qui est bon et qui est mauvais... c'est leur fantasme et ça se comprend. J'y ai eu droit une seule fois, et ça m'a donné une mauvaise image de la boite, car de nombreux points du test auraient mérité débat.
- le test le + intelligent que j'ai subi est celui de ma boite actuelle : un test de connaissance générale en informatique. Très efficace pour savoir si le mec s'intéresse un minimum à son domaine : c'est quoi un MBR, ça veut dire quoi FPU, c'est quoi un thread. Ca m'a donné une très bonne image de la boite. Niveau code, il y avait juste quelques questions simples mais éliminatoires sur l'arithmétique des pointeurs : 2 personnes sur 3 ont pourtant échoué...

La plupart des tests, c'était entre les deux. Le DRH appelle le meilleur codeur de la boite qu'on ne bluff pas comme ça, et il arrive avec des exemples de code sur papier qu'il faut commenter. Et puis on discute de leurs projets, etc. J'ai eu des discussions très intéressantes.

D'après mes souvenirs, c'est ce que préconise Spolsky. Il s'agit de bosser en binome avec le mec, histoire de voir comment ça se passe : comment il s'y prend, quel cheminement il fait, son niveau d'exigence, et aussi, et surtout : comment réagit-il à la critique, surtout la critique non fondée ?

Les tests portent sur des problèmes simples : inverser la position des éléments d'un tableau ou d'une matrice... On pardonnera une virgule oubliée, mais pas un algo boggué...

[gmotw]

Je suis plutôt de l'avis de theMonz31. Je ne me vois pas pisser du code pour un entretien (surtout si c'est en face d'un gars qui pige que dalle).
Je ne suis pas franchement certaine que ça permette d'évaluer une personne qui n'a pas vocation à être un code monkey puisque ça exclut une bonne partie des compétences nécessaires (genre analyser, s'adapter aux technos, savoir rechercher les informations, pouvoir subir ses collègues sans les engueuler,...).

[Aurelien.Regat-Barrel]

Je suis plutôt de l'avis de theMonz31. Je ne me vois pas pisser du code pour un entretien (surtout si c'est en face d'un gars qui pige que dalle).
Je ne suis pas franchement certaine que ça permette d'évaluer une personne qui n'a pas vocation à être un code monkey puisque ça exclut une bonne partie des compétences nécessaires (genre analyser, s'adapter aux technos, savoir rechercher les informations, pouvoir subir ses collègues sans les engueuler,...).

La métaphore de Spolsky dont je me souviens, c'est que tu ne vas pas employer un magicien pour un anniversaire sans lui demander de te montrer 1 ou 2 tours.

Tout dépend du profil recherché. Te demander de coder lors d'un entretien pour un poste où tu ne devras pratiquement jamais coder, c'est effectivement stupide. Mais si c'est un poste de développeur, ça a du sens non ? Si être un code monkey c'est pas pour toi, te faire passer un tel test est un bon moyen d'éliminer ton profil si c'est le poste qu'on propose

Ce qu'on a oublié de dire et que je n'ai pas bien fait ressortir de mon message précédent, c'est qu'un test/entretien permet aussi au candidat d'évaluer l'entreprise. Ca donne une bonne idée de la mentalité de la boite et de comment on s'y prend pour se faire une opinion de toi etc... En fait, une boite subit autant son test qu'elle le fait passer. C'est je pense quelque chose d'essentiel à avoir en tête. Je me suis pas gêné pour dire à la boite en question que leur test était bidon et que ça me donnait pas une super image d'eux.

[martopioche]

Il utilise une métaphore intéressante. Un test fondé sur l'écriture de code revient à évaluer les capacités d'un électricien ou d'un plombier. Il ne viendrait à l'esprit de personne de demander à l'une de ces deux professions de faire toute l'électricité ou toute la tuyauterie d'un studio avant l'embauche.

Et il viendrait à l'esprit de quelqu'un d'interviewer un électricien/plombier avec du cuivre, un poste à souder, du plâtre ?

Certains vont jusqu'à dire que ces exigences sont irrespectueuses et, pour parler cruement, complètement à "coté de la plaque".

Ce n'est pas "à coté de la plaque", évaluer sur un cas pratique, ok, mais en fonction de la complexité, ça reviens presque à de la prestation non rémunérée... enfin, moi dans un cas similaire, ma réponse serait "ok, mais je serai obligé de vous facturer l'entretien"...

[Excellion]

Tiens, j'ai eu à faire ça aussi lors d'un de mes entretiens d'embauche. Sauf que le test devant durer une heure et faisait 10 pages. Dont des schémas UML, Merise, du code en java, en dot net... (a se demander ce qu'ils faisaient vraiment...)

A un moment je me suis même demandé si le gars se foutait pas de moi. A l'époque j'étais jeune diplomé, il est quasiment certain que je n'aurai pas pu venir à bout de l'examen (n'essayons pas de trouver des euphémismes, c'est bien un examen fait par les entreprises, parce qu'elles n'ont confiance ni dans notre système scolaire, ni dans les CV). De plus en parlant avec la personne, elle avait posé des questions dont elle n'était même pas sure de la réponse...

Personnellement je ne leur en veux pas de m'avoir fait passer ce truc (toutes les entreprises le font). Par contre, mon cv (et l'annonce...) ne mentionnait pas la moitié des éléments du test et j'avais quand même parcouru plus de 1000 km pour cet entretien.

[martopioche]

Ce qu'on a oublié de dire et que je n'ai pas bien fait ressortir de mon message précédent, c'est qu'un test/entretien permet aussi au candidat d'évaluer l'entreprise. Ca donne une bonne idée de la mentalité de la boite et de comment on s'y prend pour se faire une opinion de toi etc... En fait, une boite subit autant son test qu'elle le fait passer. C'est je pense quelque chose d'essentiel à avoir en tête. Je me suis pas gêné pour dire à la boite en question que leur test était bidon et que ça me donnait pas une super image d'eux.

Moi j'ai toujours dit que les questions des tests permettaient d'évaluer le niveau de la boite

[hugo123]

pour avoir passé plusieurs fois des tests sous diverses formes je commence a me faire une bonne idée.
Les QCM ou tests de codage écrits n'ont jamais été significatifs pour ma part :
- soit je venais juste de faire la même chose ou bien c'était un sujet très frais et dans ce cas je passais pour un dieu vivant alors que bon, c'était juste en plein dans mon actualité
- soit j'y avais pas touché depuis qq temps et j'avais l'impression de passer pour un débutant, on me parlait après comme un type qui a voulu enfumer l'entretien précédent. Ben oui sauf que dans la vie réelle j'aurais eu des outils et de la doc qui m'aurait permis de m'en sortir en 100 fois moins de temps qu'un débutant... Après 7 ans d'expérience je sais ou chercher et j'ai des notions générales mais je m'amuse pas a potasser chaque soir tout les éléments du langage...

Pour moi, rien ne vaut un entretien avec une personne technique.