Discussion :

[Reward]

Bonjour,

Pour répondre au sujet initial, étant moi-même développeur/archi, je suis complètement d'accord avec ce genre de pratique.
Mettez-vous à la place de l'embocheur, aimeriez-vous recruter une chèvre qui vous plombera une équipe ?
Mettez-vous à la place d'un dev, aimeriez-vous voir un nouveau collaborateur incapable de résoudre des bugs ou des devs de base ?

Il faut faire passer des tests pour le bien de tous, car il est très facile de jouer du pipeau.

L'expérience m'a appris qu'un mauvais dev était débusqué en 1, 2 voir 3 mois. Alors qu'un mauvais CP peut sévir entre 6 et 12 mois avant d'être découvert.

Donc autant prendre une heure pour voir les réactions face à des algos de bases, qui ont été mentionnés précédemment, c'est déjà très révélateur et ça épargne des semaines de souffrance, largement rentable.

Par contre, hors de question que je résolve un problème de l'entreprise pendant un entretien, à moins d'être facturé .

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

Mon expérience m'a montré le contraire. Un CP doit connaître les bases de code et de technique, pour une raison simple : éviter de se faire mener en bateau par le "responsable technique", ou tout simplement les développeurs.

J'ai vu ce que ça donnait un CP avec un mercenaire aux commandes du code, et bien c'était l'échec ultime.

[grunk]

Demander de produire du code pure pendant un entretien ca me gonfle royalement. Souvent on doit faire ça sur papier , parfois avec un recruteur qui vous regarde par dessus l'épaule ...

Par contre mettre en situation le candidat en lui demandant du pseudo code , un algo pour résoudre un problème ca me parait plus sensé.

Quand je vois certaines personnes tout à fait capable d'écrire un if et un for mais pas foutu de produire un code clair et réfléchi (genre je fait 200 lignes de c/c parce que c'est plus facile que de réfléchir à une solution plus optimisé) je me dis que tester la logique et la capacité de réfléxion d'un candidat plutôt que le coté purement technique, c'est pas plus mal

[isop80]

Des tests de recrutement avec des pièges, des cas tordus etc.., on en voit de plus en plus
Beaucoup de société passe à côté de bon recrutement parceque les candidats se sont plantés sur des QCMs machiavéliques

La meilleure façon pour recruter un bon CP, c'est d'exposer un problème et de trouver une solution en appliquant un design pattern par exemple (composite, factory, observateur etc ...)

Sinon, il y a tout simplement la période d'essai.

[Flaburgan]

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.

Quand on voit les coûts d'un mauvais recrutement, on se dit que quand même, on devrait pas être à 5 minutes près...

[cs_ntd]

La encore le test ne doit pas être un examen rigide et noté, mais juste un outil de décision qui doit être regardé a la lumière de la situation du candidat et du poste a pourvoir.

Je suis d'accord que dit comme ça, ça parait presque bien. Le problème c'est que, même si le recruteur à l'intention de le faire, le fera-t-il ?
Imaginez un recrutement à 100 candidats (c'est pas énorme non plus), le recruteur prendra-t-il le temps d'aller chercher derriere chaque candidat la petite subtilité le petit truc en plus ? (ou en moins )
Et en sachant qu'il a des tests tout prêt qui lui disent {en théorie} le niveau de la personne ?
Hmm...

Anyway, je suis d'accord avec toi, ça peut être une condition indispensable quand même pour recruter quelqu'un pour une mission de quelques mois, ou une tâche immédiate. Mais pour peux qu'on s'engage plus d'un an avec un employé... je pense qu'il faut regarder derrière le simple "Moi je connais bien la javadoc ", et meme ne pas se concentrer là dessus...

Nan mais de toute façon, j'aime pas les tests

[sinople]

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.

[Benav]

Quelle est selon-vous la meilleure méthode pour ne pas rater le recrutement d'un développeur ?

Utiliser la période d'essai comme une période pendant laquelle on fait... des essais.

Trop souvent ce que fait le nouvel arrivant durant sa période d'essai correspond à la nécessité du moment, alors qu'à mon sens ce devrait être une période durant laquelle des jalons et des tests ont été préalablement planifiés. Ce n'est que trop rarement le cas.

[Uther]

Je suis d'accord que dit comme ça, ça parait presque bien. Le problème c'est que, même si le recruteur à l'intention de le faire, le fera-t-il ?
Imaginez un recrutement à 100 candidats (c'est pas énorme non plus), le recruteur prendra-t-il le temps d'aller chercher derriere chaque candidat la petite subtilité le petit truc en plus ? (ou en moins )
Et en sachant qu'il a des tests tout prêt qui lui disent {en théorie} le niveau de la personne ?

C'est au recruteur de voir, mais s'il fait passer des tests, il a quand même intérêt à ce que ce soit significatif.
L'informatique n'est pas comme la fonction publique. En tout cas chez nous, on est très très très loin de pouvoir sélectionner un poste parmi une centaine de candidats, et je pense qu'on est pas les seul.

[bleporini]

Il ne faut pas oublier une chose, un process de sélection doit satisfaire deux axes: l'evaluation de compétences techniques et des façons d'agir. Évidemment un RRH ne va pas pouvoir s'occuper de la partie technique et inversement. Tout cela pour en arriver a la conclusion qu'un candidat qui a réussi a sur vendre ses compétences n'a pas été détecte comme un fumiste par le RRH, si par chance il en croise durant les entretiens. Certes ce n'est pas un détecteur de mensonges mais cela permet de se poser des questions sur le savoir être du candidat et sur sa faculté a s'intégrer dans l'équipe.

Tiens sur ce sujet, quoi de pire pour un projet qu'un développeur compétent qui est incapable de s'appuyer sur un code sans avoir a le remanier afin qu'il réponde a ses exigences personnelles, genre "c'est fait avec les pieds" ou "c'est mieux comme ça". Et pourtant celui ci il a souvent déchire le test technique et fait reGulierement reculer l'équipe. il ne faut pas non plus amalgamer maitrise d'une technologie et compétence technique.

L'expérience m'a appris qu'un mauvais dev était débusqué en 1, 2 voir 3 mois. Alors qu'un mauvais CP peut sévir entre 6 et 12 mois avant d'être découvert.

-1: en tant que senior, une de nos taches est de procéder a l'intégration des nouvelles recrues: ce qui implique "marquage a la culotte" lors des premiers commits dans le SCM. Le max pour débusquer un mauvais dev est un mois, au delà cela devient notre responsabilité.

Mettez-vous à la place de l'embocheur, aimeriez-vous recruter une chèvre qui vous plombera une équipe ?

L'intégration dans l'équipe est loin de se résumer a la maitrise d'une techno.

[cs_ntd]

...

A mais on est d'accord, il y a des recruteurs très bon, qui "fonctionnent" dans un bon système.
Et puis il y a les autres, qui sont incompétents/qui font ce qu'ils peuvent avec un patron pas forcément compétent, avec des recrutements à la sauvette ou à la dernière minute..

Et là oui la solution de facilité c'est de faire un QCM en choisissant des trucs tordus sur Internet. Et si le recruteur fait ça, je pense pas qu'il a l'intention d'analyser en profondeur le profil de chaque candidat, il va chercher à recruter au plus vite.

Moi ce qui me chagrine, c'est qu'on soit enclin à "généraliser" ça, c'est à dire tendre la perche aux recruteurs pour bacler les entretiens, et qu'on soit enclin à nous considérer comme des braves bêtes dociles qui résolvent les problèmes, un gros étalage de connaissance, sans une once de créativité

[Christophe P.]

Le candidat s'est présenté en tant que "chef de projet .NET" et a probablement été embauché en tant que tel pour ce boulot. A ma connaissance, le boulot de chef de projet n'a rien à voir avec de la correction de bug. Un chef de projet n'est pas forcément un développeur (même si beaucoup le sont aussi). Donc le fait qu'il ai du mal à corriger un bug ne me choque pas. Si sur le CV il y avait aussi écrit "Expert .NET" c'est effectivement un menteur.

[Higgins]

Par le passé, je me suis fais "bananer" par un beau parleur avec un CV en or.
Il a réussi à faire illusion pendant la période d'essai mais par la suite il s'est avéré que c'était un incapable. Alors maintenant, les tests lors de l'entretien, c'est systématique:
- faire corriger un problème
- écrire un bout de code
- quelques questions théoriques.

Lors du dernier recrutement, nous avions précisé "Maîtrise du SQL impérative", il a fallu près de 3 mois et recevoir plus de 20 candidats (soi-disant tous "experts") pour trouver quelqu'un capable d'écrire une requête simple avec une jointure entre 2 tables. La quasi totalité d'entre eux s'est liquéfiée à l'annonce du test (je savais pas, j'ai pas révisé,ça fait longtemps que j'en ai pas fait mais ça va revenir, etc......)
L'avantage, c'est que cette fois, on a quelqu'un qui est capable de faire son boulot.

[Benav]

Il a réussi à faire illusion pendant la période d'essai

Du coup, la solution de l'entretien technique n'aurait pas été efficace non ? Je veux dire, si il a pu faire illusion pendant 1 ou 3 mois, il aurait fait illusion pendant une demi journée. Ou alors la période d'essai n'a pas été bien faite, mais là c'est un autre problème.

[UNi[FR]]

J'ai fait passé pas mal d'entertien pour recruter des prestataires et à chaque fois je faisais passer un test avec quelques questions.

Ex : Comment fait-on un constructeur ne PHP5 ?
ou encore comment optimiser une requête SQL dont la jointure est faite dans le WHERE ?

des questions simples pour un développeur PHP/SQL.

Le résultat est déconcertant car plus de 2/3 des personnes interrogées ont eu du mal à répondre à ce questionnaire. Et quand nous avons enfin trouvé un développeur qui répondait correctement, nous somme tombé sur le développeur insociable qui ne savait pas travailler en équipe !

Donc en effet ce n'est pas évident de recruter des développeurs !

[bizet]

Bonjour,

oui aux tests, mais pas à n'importe quoi. Trop souvent les questions sont trop spécifiques et n'apportent aucune valeur ou ne permettent pas de juger.

Je me souviens d'un entretien avec le responsable et un "technicien là pour juger de mes compétences".
Après une première question très pointue à laquelle je n'ai pu répondre, arrive la deuxième : "Quelle est l'exception levée dans le cas suivant : ......" avec un cas ultra spécifique.
Ma réponse a été "Google est mon ami". Réponse qui a fait beaucoup rire le responsable et beaucoup moins le techos.
Nous sommes partis dans un débat sur l'utilité de connaitre toutes les spécificités d'un langage.
Pour le techos je me devais de connaitre l'ensemble des méthodes du langage, ce qui pour moi ne sert à rien avec IntelliSense et les docs sur le net.
Par contre il est selon moi plus utile de connaitre les design patterns ou la différence entre String et StringBuilder.

Au final, le responsable voulait me recruter mais j'ai refusé, je pense que l'ambiance avec le techos allait être trop compliqué.

[noOneIsInnocent]

Salut

je suis d'accord pour faire passer les tests mais à condition de mettre le candidat dans les bonnes conditions
si on recrute un candidat pour faire du développement Java, on doit lui mettre à disposition un IDE qu'il a indiqué pratiqué dans son CV, la Javadoc .
mais sur le principe je suis d'accord mais là encore on devrait faire passer plusieurs entretiens avec le RH, le futur responsable + si nécessaire un entretien technique.
Il y a aussi quelque chose que j'ai remarqué c'est que l'on admet de plus en plus que un chef de projet soit mauvais techniquement. Ce que je conçois parfaitement à partir du moment où il sait gérer son équipe, le client et s'appuyer sur un expert technique.

Autre problème en France du moins, c'est que une fois le mec recruté et que sa période d'essai est passée, il est difficile de le renvoyer pour incompétence.

[s4mk1ng]

Franchementje trouves que c'est la meilleure solution pour savoir si la personne correspond vraiment à la mission .
Après il faut aussi faire attention à ne pas effectuer des tests ultra-techniques alors qu'on ne recherche pas une personne ultra-qualifié mais juste un développeur junior

[Traroth2]

Au-delà du simple aspect compétence, il y a aussi une vérification de la l’honnêteté de la personne. Quelqu'un qui me dit qu'il est expert en Java et qui arrive pas à aligner deux lignes de code, je ne lui paie pas une formation, je lui dit de s'en aller !

[gangsoleil]

Bonjour,

Pour en revenir sur le probleme du chef de projet, ca depend de ce qu'on lui demande : s'il doit faire des chiffrages, il doit connaitre un minimum la technique. En revanche, s'il ne sert a rien de plus qu'aller a des reunions et suivre l'evolution des projets, en se basant aveuglement sur les chiffrages des developpeurs, alors effectivement, il peut etre un peu moins technique, mais doit tout de meme avoir de solides bases.

Quant aux tests pour les developpeurs, je maintiens que c'est moins efficace qu'un entretien technique. Mais moins cher aussi. Et donc moins fiable.

[Reward]

L'intégration dans l'équipe est loin de se résumer a la maitrise d'une techno.

Je fais la distinction entre celui qui pipeaute son CV en prétendant maitriser et celui dont ce n'est pas le cas, mais que l'on pourra mener à niveau.

On peut toujours faire monter une personne techniquement, à partir du moment où l'humain est viable, l'inverse est quasi impossible. C'est pour cela que je privilège toujours l'humain chez un candidat.

Mes propos portaient sur les candidats mythos.