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 !

Emploi : Faire écrire un code fonctionnel lors d'un recrutement se généralise

Le , par Gordon Fowler

0PARTAGES

0  0 
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

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 ?

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

Avatar de h472009
Membre habitué https://www.developpez.com
Le 02/11/2009 à 20:14
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...
0  0 
Avatar de mrjay42
Membre habitué https://www.developpez.com
Le 02/11/2009 à 20:49
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...
0  0 
Avatar de pmithrandir
Expert confirmé https://www.developpez.com
Le 02/11/2009 à 23:13
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.
0  0 
Avatar de cf1020
Membre du Club https://www.developpez.com
Le 03/11/2009 à 1:14
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.
0  0 
Avatar de GanYoshi
Membre chevronné https://www.developpez.com
Le 03/11/2009 à 3:12
Citation Envoyé par cf1020 Voir le message
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
0  0 
Avatar de Franck SORIANO
Expert confirmé https://www.developpez.com
Le 03/11/2009 à 7:05

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.

Citation Envoyé par h472009

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

Citation Envoyé par cf1020
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...
0  0 
Avatar de Fred3d
Nouveau membre du Club https://www.developpez.com
Le 03/11/2009 à 9:18
... 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 ...
0  0 
Avatar de turican2
Membre actif https://www.developpez.com
Le 03/11/2009 à 9:22
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)
0  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 03/11/2009 à 9:32
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 .
0  0 
Avatar de Louis Griffont
Inactif https://www.developpez.com
Le 03/11/2009 à 9:42
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 !
0  0