Discussion :

[jmsei]

Il y a aussi ceux qui ne sont pas bon pour des examens, mais très bon en entreprise, avec beaucoup d'imagination et faisant des propositions efficaces pour sortir de certain cul-de-sac dans des projets complexes ou mal fagotés.
Ayant de très bonnes relations avec leurs collègues et les clients, et à l'esprit ouvert avec une grande capacité d'adaptation et d’apprentissage.
Par exemple, pratiquer les langages objets principaux, les design-patterns, les bases de données, UML ... etc .... les best-pratices et la sureté et sécurité du code, mais qui peut se planter sur des détails du C dans un test parce que sa pratique est un peu oubliée.
L'employeur peut alors passer à coté d'une très bonne recrue sur un test de 15 mn mal adapté.

[Doksuri]

Faire coder le candidat avant l'embauche est aussi quelque chose de coûteux puisqu'il faut lui allouer une machine le temps de l'examen et il faut aussi avoir du code ou un exercice en stock et autant que possible pas un exercice que d'autres auraient déjà vu, il faut donc quelqu'un qui crée ces exercices.

j'ai envis de dire que, comme les profs (ou autre) une fois que t'as fait 1 exercice, bah tu le donne a tout le monde xD
et faire tourner un lamp une machine pourrie qui prend la poussiere ca devrait passer...

[dissert]

Chef de projet et développeur sont deux métiers complètement et radicalement différents, qui nécessitent tous les deux des compétences pointues.

On ne peut être à la fois un bon chef de projet et un bon développeur
(on peut être un mauvais des deux à la fois par contre).

Le recruteur dans l'exemple cité n'en a pas conscience et est complètement à côté de la plaque.

C'est pas des exercices de programmation qu'il doit donner à la personne à recruter, mais faire par exemple une mise en situation de négociation avec le client ou d'établir un diagramme de Gantt.

Lui demander après le recrutement de déboguer du code est d'abord sûrement en dehors des missions prévues dans son contrat de travail.

Ensuite, juger qu'il est mauvais parce qu'il ne sait pas le faire est une stupidité.

Si c'est vraiment un développeur qu'il veut recruter, prévoir un entretien avec quelqu'un qui se présente comme "Chef de projet .NET" (ou chef de projet n'importe quoi) est une perte de temps pour lui et pour le candidat.

[yoyo88]

question un peu con, mais la periode d'essaye n'est elle justement pas la pour éviter les erreurs de recrutement ?

Je peux comprendre que la compréension d'un gros projet est difficile, mais c'est pas avec un test de 20 min qu'on va savoir comment notre crack en Java est capable de s'adapter à notre projet.

certains candidats peut-etre moins douer sont sans doute plus a même de s'adptés.

apres, bien sur, ça depend se que l'on cherche.

[Kidd32]

C'est le cas pour 99% des postes aux USA, un ami en a passé 4, tous ont demandé soit un code à faire à distance, soit sur place, dans tous les cas c'était compliqué et il fallait créer du code dans une situation proche de la réalité.

C'est une bonne idée selon moi, et sur les aspects techniques pour des postes techniques j'approuve, pour des postes plus complexes il faut moderer le test par une évaluation des capacités d'apprentissage rapide du candidat.

[ikarus]

Il y a deux chose qui me choque sur cet article.

Le recruteur recherchant un "développeur" embauche un "chef de projet"...
Deux tafs bien différent selon le marcher de l'emploi actuel.
Je connais des chef de projet dans des services info qui n'ont jamais fait une ligne de code de leur vie. Pourtant ils sont d'excellents analystes.

De plus un test de debug, pourquoi pas, mais dans quelles conditions ?
Je ne suis pas sur que ce test soit bien utile.
Surtout s'il est réaliser sur papier ou en un temps trop court.

Un recrutement plus sure prend du temps et non pas un test a la c...
D'autant plus qu'un test sans internet ou sans un EDI avec la complétion de code source permettra surtout de juger de la mémoire du développeur. Non pas de sa rapidité ou de son ingéniosité a résoudre un problème donné.

[delaveine7]

je pense pour ma part qu'un chef de projet doit savoir au moins coder.
Et même si les deux poste sont radicalement différents, il appartient aux recruteurs d'utiliser la "période d'essai" pour confirmer les dires du demandeur.

[captainKirk]

Je trouve que demander au candidat d'écrire du code n'est pas du tout un bon moyen pour déterminer ses compétences. En effet, ce genre de test implique de se focaliser sur un langage de programmation donné. Or, un bon développeur possède une bonne connaissance de l'algorithmique, des concepts objets et un bon esprit d'analyse et de synthèse. Ces compétences sont transposables sur n'importe quel langage, il faut juste un peu de temps pour s'adapter et apprendre la syntaxe.

Par exemple, un bon développeur JAVA peut très rapidement devenir un bon développeur C# ou VB.Net, mais échouerait peut-être à ce genre de test, ne maîtrisant pas suffisamment le framework .Net.

De plus, il y a un outil que tout développeur, bon ou mauvais, utilise massivement aujourd'hui : Internet. Faut-il autoriser la connexion durant le test au risque de voir le candidat tricher ? Faut-il la couper au risque de voir un bon candidat échouer car il ne se souvenait plus du nom de la fonction dont il avait besoin ?

Encore une chose : ce genre de test ne met en avant que les compétences techniques. Que dire des qualités humaines du candidat ? Un développeur peu être très compétent sur le plan technique mais incapable de communiquer, capable de rester bloquer pendant des semaines sur un problème plutôt que d'en faire part au reste de l'équipe. J'ai déjà vu des développeurs à qui s'est arrivé tellement ils étaient certains de tout savoir sur tout et mieux que les autres... Pour travailler en équipe, les qualités humaines et de communication sont tout aussi (voir plus) importantes que les compétences techniques. Ces dernières s'acquièrent avec l'expérience, ce genre de test élimine donc d'office les développeurs débutants...

N'oublions pas qu'avant d'être développeurs, nous sommes d'abord des êtres humains qui devons vivre et collaborer dans l'entreprise !

[Le_Bret]

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.

[el_slapper]

je pense pour ma part qu'un chef de projet doit savoir au moins coder.
Et même si les deux poste sont radicalement différents, il appartient aux recruteurs d'utiliser la "période d'essai" pour confirmer les dires du demandeur.

Je ne suis pas d'accord.

Savoir coder, c'est un gros plus, mais j'ai vu des chefs de projets compétents, soit mauvais programmeurs, soit carrément infoutus de comprendre la moindre ligne de code. L'important, dans ce cas-là, c'est d'assumer ses propres faiblesses et de connaitre ses troupes. "Bon, Glandu, je sais qu'il me faudrait 5-6 jours pour faire ça, mais toi, en 2 jours, tu dois pouvoir y arriver?" Et 2 jours plus tard, c'était fait.

Celà étant, ça ne peut marcher que si les programeurs sont expérimentés. J'ai moi-même une fois fait partie d'une équipe de débutants, et là, le Chef de projet "velu" avec 20 ans de vécu de programmation, a été un excellent choix. Même si, niveau conduite de projet, il n'était pas top(euphémisme), on s'en est sortis parcequ'il a su nous guider techniquement. Si on met la chef codant de traviole de l'exemple précédent, on va dans le décor. Avec une équipe de grognards qu'elle savait gérer, on a fait des choses formidables, qu'un mauvais chef de projet(technique ou non) n'aurai jamais pu atteindre.

Quand à la période d'éssai, elle est quand même très couteuse. On a passé un mois à former le gugusse, à investir en lui, et il s'avère que si il ne trouve pas la donnée dont il a besoin, il en renomme une autre(vécu). Autant ne pas se planter dès le départ.

[popo]

Selon moi, le test technique est indispensable au recrutement d'un développeur mais celui-ci ne doit se passer lors d'un second entretien.

Lors du premier entretien, on discute avec le candidat pour essayer de cerner sa personalité. Cet entretien ne doit pas durer très longtemps et permet de se faire une idée sur le candidat. Dans cet entretien on pose les questions les plus importante. L'une des plus importante selon moi est "Que faites-vous lorsque vous rencontrez un problème que vous ne savez pas résoudre ou auquel vous n'avez pas encore été confronté ?". Il doit également permettre de savoir quelle est la méthodolgie de travail du candidat.

Le deuxième entretien, plus long est la pour vérifier si ce que le candidat mets dans son CV est vrai ou non. C'est à ça que sert le test technique. Sans rentrer dans du spécifique, il doit quand même comporter toutes les structures de bases (faire un test, une itération, creer une procédure ou fonction avec des paramètres, ce genre de chose). Il doit faire appel à la logique du candidat. Il doit comporter des éléments auxquel le futur candidat sera confronté régulièrement. Dans cet entretien, on peux regarder si la méthodologie qu'il emploie correspond à ce qu'il a dit au premier entretien, on peut regarder comment le code est structuré. J'estime que pour un bout de code basique, le candidat peut faire l'effort de nommer correctement ses variables et ne pas se contenter de mettre St1 et St2 pour des variables "Chaine" par exemple. On peut demander d'améliorer une fonction simple ou encore de détecter des erreurs monstrueuses dans une procédure (vous serez étonné de constater combiende candidat ne voient pas qu'il manque le "then" à la fin d'un "if" !).

Outre les compétences techniques, un développeur doit être capable de s'exprimer avec des termes non technique, ou bien savoir transcrire ces termes technique en termes simple qu'un client pourrait comprendre (rien que pour le cas où il devrait écrire une notice d'utilisation même si souvent le client ne la lira jamais )

Certains d'entre vous préconise l'utilisation de la période d'essai pour détecter les menteurs ou les incompétents. Il n'empêche que le test technique permet de faire un premier tri. Cela coute moins cher de monopoliser une personne de l'entreprise pendant une heure que rémunérer quelqu'un pendant 1 mois (au minimum) pour s'appercevoir que c'est un gros arnaqueur. Et puis n'oublions pas le cas où l'entreprise doit également former le candidat à l'outil qu'elle utilise pour développer. Légalement, la durée d'une période d'essaie ne doit pas dépasser un certain laps de temps (dont je ne me souviens pas désolé) mais si on doit passer tout ce temps à former le candidat à l'outil, on se retrouve à devoir licencier le candidat (et donc à payer encore plus).

[dsy]

Pour ceux qui s'inquiètent de la technicité, du contexte ou du coût des tests :

J'ai horreur moi aussi des tests de technique pure à faire sans ordinateur. Et depuis peu, je suis aussi un adepte des tests avec connection Internet.

Pour ma part, je propose donc un test trés simple que les candidats réalisent chez eux : réaliser un petit programme (console) de lecture d'un fichier texte avec un composant fourni à l'avance.
Lorsque j'ai fait passer le test à nos dev, ils ont rigolés tellement le test est simple. Pas d'interface à réaliser et les outils sont fournis à l'avance pour se familiariser avec.

Je laisse aux candidats le choix de la date et l'heure du test. Ils le recoivent par e-mail avec accusé de réception. Ils peuvent donc se préparer avec tout le temps nécessaire car ils connaissent le sujet général du test et le composant utilisé.

Pas besoin de coder à la main. Ils doivent utiliser Visual Studio pour le test car il s'agit d'un test en C#. Je leur propose un lien vers la version Express (gratuite) si besoin.

Ils peuvent donc choisir le contexte : au calme chez eux, avec ou sans Internet, avec de la documentation, etc. Mais comme le test est assez court, cela n'a pas forcément d'intérêt pour eux de passer leur temps sur Internet. C'est le même principe que certains examens avec documentation autorisée. Je test ainsi la gestion du temps.

Certains candidats ne lisent pas les indications jusqu'au bout et sont donc mal préparés au test. Cela me permet de tester aussi : l'aptitude à lire et comprendre un document technique (même court), l'esprit de synthèse, l'organisation et la réaction fasse à un problème car ils peuvent me contacter.

Au final et malgré la simplicité du test et le choix des conditions, je reçois des résultats assez mauvais alors que les candidats se disent développeurs de niveau bac+4 ou 5.

Bien sûr le candidat peut demander à un tiers de réaliser le test à sa place mais il me suffit d'interroger le candidat sur sa méthode de travail pour résoudre le problème.

[lequebecois79]

je crois que c'est essentiel afin d'avoir un candidat compétent, les cv sont trop souvent boosté en france

le mec a fait 2 page en php et n'hésite pas à se qualifier expert en la matière

[captainKirk]

- S'assurer des compétences techniques d'un développeur qui sort de l'école : ca n'a pas de sens, il n'a pas encore assez d'expérience. Le métier de développeur s'apprend essentiellement sur le tas. C'est en forgeant qu'on devient forgeron, idem pour le dév.

- S'assurer des compétences techniques d'un développeur qui a 10 ans d'expérience : mais lol, il aurait réussit à faire semblant de coder pendant tout ce temps ???!

[dsy]

- S'assurer des compétences techniques d'un développeur qui sort de l'école : ca n'a pas de sens, il n'a pas encore assez d'expérience. Le métier de développeur s'apprend essentiellement sur le tas. C'est en forgeant qu'on devient forgeron, idem pour le dév.

L'expérience des projets scolaires suffit largement pour passer un petit test technique comme le mien.

- S'assurer des compétences techniques d'un développeur qui a 10 ans d'expérience : mais lol, il aurait réussit à faire semblant de coder pendant tout ce temps ???!

Un développeur qui a fait 10 ans de PHP n'a pas forcément la capacité à s'adapter à du C#. S'il indique qu'il est capable de faire du C# alors il faut le tester ou bien le former mais l'entreprise doit le savoir avant de le faire signer.

[gangsoleil]

- S'assurer des compétences techniques d'un développeur qui sort de l'école : ca n'a pas de sens, il n'a pas encore assez d'expérience. Le métier de développeur s'apprend essentiellement sur le tas. C'est en forgeant qu'on devient forgeron, idem pour le dév.

Une personne peut essayer de se survendre, et peut aussi pretendre connaitre des technos qu'il ne connait pas.
Le but de l'entretien technique est justement different du test d'ecriture de code, et permet de s'adapter aux reponses du candidat, pour trouver ses forces et ses faiblesses.

- S'assurer des compétences techniques d'un développeur qui a 10 ans d'expérience : mais lol, il aurait réussit à faire semblant de coder pendant tout ce temps ???!

10 ans d'experience ne t'assurent pas du tout que la personne a du recul sur ce qu'elle fait, et un entretien te permet donc de savoir si la personne colle au profil que tu recherches ou non.

[ZnhaarX]

Personnellement je suis partisan des tests en entretiens.
Bon okay je suis en stage de fin d'étude, donc mon expérience professionnel est surement négligeable par rapport à la votre.
Mais j'essaye de me mettre à la place d'un recruteur et je verrais un entretien plus basé sur la "logique" et le "raisonnement" que sur les aspects techniques. Pourquoi?

Parce que le bon développeur est celui, selon moi, qui sait s'adapter à n'importe quelle situation; donc la connaissance des technologies ne me semblent pas être quelque chose d'essentiel (entendons nous bien, en entretien ^^ Loin de moi l'idée de dire que l'expérience dans certaines technologies n'est pas une plus-value)
Je pense que des tests de réflexion sur des alternatives algorithmiques serait quelque chose de plutôt sympathique, mais évidemment de plus compliquer à évaluer. Mais dans ce cas là, on évaluerait concrètement le raisonnement du candidat (ce qui me semble plus important que d'évaluer ses connaissances techniques).
Après ça dépend aussi des besoins de l'entreprise/employeur. Si l'entreprise est dans le besoin de ressources humaines pour un projet qui nécessite, dans l’immédiat, une connaissance "experte" d'une certaine technologie, ce genre de tests restent inappropriés.

Donc par exemple, poser des questions à un candidat sur la finalité de la complexité algorithmique, l'utilité selon lui de l'UML ou ce genre de choses. Ce sont pas des questions pièges, mais ça permet de rendre l'entretien moins impersonnel (contrairement à faire coder quelqu'un sur un morceau de papier pour juger uniquement ses compétences dans un certain domaine techniques).
Une des possibilités mettant en valeur le raisonnement du candidat serait aussi de lui demander des alternatives algorithmiques, par exemple "Faire une swap-function sans utiliser de variables temporaires".
C'est bête, ça fait creuser les méninges et ça montre à la personne qui fait passer l'entretien comment raisonne le candidat.
(Pour la réponse d'ailleurs, on peut passer par une simple suite d'opérations arithmétiques ou par l'utilisation de l'opérateur XOR).

Enfin voilà, personnellement je trouve ce genre d'entretien plus "vivant", intéressant et probant que ce soit pour le recruteur ou le recruté.

[lequebecois79]

- S'assurer des compétences techniques d'un développeur qui sort de l'école : ca n'a pas de sens, il n'a pas encore assez d'expérience. Le métier de développeur s'apprend essentiellement sur le tas. C'est en forgeant qu'on devient forgeron, idem pour le dév.

je sais pas ce que tu as fait à l'école, mais j'ai fait l'équivalent d'un bts et ensuite école d'ingénieur

et dès le bts, les travaux étaient orienté application d'entreprise...
par exemple faire une librairie en ligne en plus d'une application lourde en plusieurs langue... le tout en collaboration directement avec un propriétaire d'une librairie

donc analyse des besoins, création diagramme et cie, gestion de projet, création bd, page web.... le tout avec un délai assez serrer...

[friedamichelle]

Même si je ne suis pas à 100% pour les tests car en entretien, il peut avoir aussi du stress qui fait que les gens se ratent complétement sans oublier les tests avec des questions ambiguës.
Par contre, ce que je trouve moins sympa dans les processus de recrutement c'est des tests psychotechniques.

[CrashAngel]

Afin de savoir si vous avez vraiment un vrai développeur .NET en face de vous rien de plus facile que de l'interroger sur les frameworks ou les évenements sur les composants. En quelques secondes c'est fini pour lui.