Discussion :

[batataw]

Y'a une constante que je déplore. Les entretiens sont souvent dans un mode compétition. Le candidat va-t-il réussir a franchir toutes les etapes, voir les pieges qui lui sont tendus. C'est évident que pour se faire une idée d'un candidat en une heure d'entretien, il vaut mieux mettre la barre haute. Cependant l'entreprise a autant besoin de moi que moi j'ai besoin d'elle.
Il serait plus judicieux de proposer un échange constructif. A la fin de l'entretien je devrais savoir si je suis fait ou non pour ce poste.

Le pire étant, quand certaines boites demandent au meilleur développeur de faire les entretiens. Le gars, il est de bonne volonté. On lui a demandé de vérifier si le candidat avait les compétences requises. Le probleme c'est que il ne sait pas conduire un entretien et qu'il va s'enfermer dans des questions techniques plus ou moins pertinentes. Mais il ne va jamais essayer de prendre de la hauteur.

[Franck SORIANO]

Dans l'analyse d'un candidat, quelle proportion prends toutes ces analyses ?

Je ne me risquerai pas à donner de règles générales. C'est plus une question de feeling au cas par cas.
Si tu as un doûte sur un candidat, c'est le genre de détails qui peut aider.

La dernière fois que je m'en suis servit pour exclure un candidat, j'avais déjà dit non après l'entretien. Mais il avait réussit à enfumer mon chef qui voulait à tout prix le recruter.
On a décidé de lui faire faire un test, et j'ai pu montrer que ce superman qui avait découvert les secrets de l'informatiques et qui allait nous les enseigner n'était qu'un beau parleur incapable de passer à la pratique.
Evidemment, il n'y a pas que son attitude face au clavier qui a compté, mais en le regardant écrire son code, je savais parfaitement ce que j'allais trouver (en fait non, son code était encore pire que ce que je m'attendais).

Mais bon, après, ca dépend de ton boulot, si on te demande de faire des requêtes SQL a la chaine, ou d'optimiser des requêtes existantes, ou la même chose pour des algorithme. En fonction, le niveau de réflexion requis n'est pas le même.

Comme tu dis, ça dépend du contexte et du poste.
Si c'est une SSII qui fait un recrutement, le niveau de compétence réel du candidat est très secondaire face à la moneillabilité de son profil. Un beau parleur en régit qui passe 15 jours sur un dev qui devrait en prendre 10 peut-être plus intéressant qu'un géni qui réalise en 5 jours le dev où il devait être facturé pendant 10j.
Si c'est un client qui recrute un prestataire, ça n'a pas beaucoup d'importance non plus. Tant que le mec tiens à peu près ce qui était prévu au budget. On a demandé un budget, on l'a obtenu, maintenant il faut le consommer...

En revanche, si tu es éditeur de logiciel, la startup moyenne qui cherche l'oiseau rare pour développer le nouveau projet à lancer. Tu as besoin d'un mec qui devras être sur tous les fronts à la fois, sinon il te faudra embaucher 50 personnes pour avoir toutes les compétences nécessaires au projet.
Bref tu cherches le futur chef de projet, responsable technique et directeur du Dev qui deviendra le pillier incontournable du projet (et souvent de l'entreprise).
Et surtout, si tu te plantes sur le recrutement, la boîte coule... (il suffit d'avoir recruter un mec ordinaire au lieu du superman, car tu ne peux pas le licencier et tu n'as pas les moyens de faire une autre embauche)
Ce genre de détails devient très important. Pour mon dernier employeur, j'ai échappé de peu à la graphologie...

[batataw]

La dernière fois que je m'en suis servit pour exclure un candidat, j'avais déjà dit non après l'entretien. Mais il avait réussit à enfumer mon chef qui voulait à tout prix le recruter.
On a décidé de lui faire faire un test, et j'ai pu montrer que ce superman qui avait découvert les secrets de l'informatiques et qui allait nous les enseigner n'était qu'un beau parleur incapable de passer à la pratique.
Evidemment, il n'y a pas que son attitude face au clavier qui a compté, mais en le regardant écrire son code, je savais parfaitement ce que j'allais trouver (en fait non, son code était encore pire que ce que je m'attendais).

C'est excatement ce que je déplore...je ne veux pas te jeter la pierre mais comme je le dit plus haut les recrutements ne se font pas avec le candidat mais contre lui.

[Franck SORIANO]

C'est excatement ce que je déplore...je ne veux pas te jeter la pierre mais comme je le dit plus haut les recrutements ne se font pas avec le candidat mais contre lui.

Désolé mais c'est la dure réalité économique.

Si tu as besoin d'un profil, soit le candidat correspond au profil cherché, soit il ne correspond pas et tu ne l'embauches pas. Le candidat fait tout pour montrer les points de concordance, le recruteur doit rechercher les points de discordances.

Dans l'exemple que j'ai cité, on avait besoin d'un développeur C# imédiatement opérationnel pour un projet d'un niveau technique assez élevé qui devait être livré en 3 mois. Le candidat ne maîtrisait pas les bases élémentaires du langage, et on ne pouvait pas se permettre de prendre un débutant.

Mais dans un autre contexte, il m'est aussi arrivé de faire embaucher un "BTS comptabilité" avec très peu d'expérience.
Durant son test, il avait réussi à me montrer qu'il avait un fort potentiel (et pourtant, il n'avait pas obtenu le résultat qu'on attendait), j'avais le temps de m'occuper de lui et on faisait un recrutement pour du long terme.

Il ne s'agit pas d'être "avec le candidat" ou "contre le candidat" mais seulement de vérifier s'il peut correspondre aux besoins de l'entreprise et gérer les risques liés à l'embauche.

[trucentete]

- Un test, pourquoi pas s'il est bien fait... mais je crois plus à une discussion technique sur des réalisations rapporté dans le CV et des études de cas par exemple... on peut décerner un pipoteur d'un vrais technicien lors de ces entretiens.
Ce qui compte le plus après c'est comment on va s'intégrer à une équipe... d'ou la discussion qui permet d'apprécier des compétences et de cerner un peu la personne
Par expérience, j'ai travaillé dans une équipe de développeur ou ça ne collait pas du tout avec un des développeurs et le reste de l'équipe, ça a été une catastrophe et ça a pesé sur les réalisations... le développeur qui posait problème était très bon techniquement, donc ça ne suffit pas.

De plus, les recruteurs et le recruté bénéficie d'une période d'essai, mieux vaut avoir fait le bon choix avant mais bon ça peut arriver...

[batataw]

Désolé mais c'est la dure réalité économique.

Si tu as besoin d'un profil, soit le candidat correspond au profil cherché, soit il ne correspond pas et tu ne l'embauches pas. Le candidat fait tout pour montrer les points de concordance, le recruteur doit rechercher les points de discordances.

Dans l'exemple que j'ai cité, on avait besoin d'un développeur C# imédiatement opérationnel pour un projet d'un niveau technique assez élevé qui devait être livré en 3 mois. Le candidat ne maîtrisait pas les bases élémentaires du langage, et on ne pouvait pas se permettre de prendre un débutant.

Mais dans un autre contexte, il m'est aussi arrivé de faire embaucher un "BTS comptabilité" avec très peu d'expérience.
Durant son test, il avait réussi à me montrer qu'il avait un fort potentiel (et pourtant, il n'avait pas obtenu le résultat qu'on attendait), j'avais le temps de m'occuper de lui et on faisait un recrutement pour du long terme.

Il ne s'agit pas d'être "avec le candidat" ou "contre le candidat" mais seulement de vérifier s'il peut correspondre aux besoins de l'entreprise et gérer les risques liés à l'embauche.

La dur réalité, c'est que nous sommes un pays de lettres ou le bagout, la culture générale et les diplomes font la différence. J'ai cotoyé des developpeurs moyens voir médiocres mais qui avaient un sens de l'a propos assez impressionant. De tres belles phrases qui ne savaient pas transformer en cas pratiques. Y'a moins de place pour les developpeurs bon techniquement mais qui ne savent pas se vendre.

Il faudrait passer a la culture du "portefolio" quand je vais a un entretien en plus de mon CV je dois apporter mes réalisations voir mes idées. Le recruteur doit voir dans quel mesure le profile du candidat colle avec les différents projets et la culture de l'entreprise. L'entretien serait alors plus un débat, un échange plutot que cette piece de théatre qui laisse beaucoup trop de place finalement a la chance.

[B.AF]

Je trouve marrant qu'il faille une crise pour que les vendeurs de viande commence à se préoccuper de sa qualité.

Probablement les stocks d'invendus, où les impayés ?

Les politiques de recrutement "vertueuses" des SSII me feront toujours rire !

Pour les autres industries, il ne faut pas aussi négliger qu'il s'agit de filtrer un peu aussi les commerciaux RH (qui eux ont une nette tendance à brader des profils inadéquats en les modifiants) des dites SSII.

J'adore toujours qu'on m'explique que si l'agneau se fait bouffer, c'est avant tout de sa faute et que le loup n'a fait que son devoir.

[Excellion]

Lorsque tu frappes avec une seule main ou avec deux tu es loin d'avoir la même vitesse de frappe. Si tu juges que tapper avec une seule main te permet d'avoir un rythme suffisant au point ne pas avoir voulu l'améliorer, c'est que tu considères que ta vitesse de frappe n'entrave pas ta réflexion.
Autrement dit, que tu ne réfléchis pas plus vite que ce que tu tappes sur ton clavier, ta vitesse de frappe révèle alors ta vitesse de réflexion c'est dailleurs ce que tu dis dans ton explication.

Mais il n'y a pas que le nombre de mains ou de doigts utilisés qui est révélateur. On peut aussi regarder l'attitude générale : Est-ce que le candidat as besoin de regarder le clavier lorsqu'il tappe, est-ce qu'il ne regarde que l'écran ou est-ce qu'il passe son temps à passer de l'écran au clavier.
Est-ce qu'il alterne les phases de réflexion et les phases de frappe, ou est-ce qu'il tappe en continu...

Comme je l'ai dit précédemment, le nombre d'années d'expériences ne fait pas la qualité de cette dernière. Si un candidat expérimenté ne sait pas tapper sans regarder le clavier, s'il tappe avec un seul doigt ou autre pratique contre-productive ça montre qu'il n'a pas cherché à s'améliorer.
Ce genre de détail est révélateur d'un certain nombre de traits de personnalité, et il est très difficile de mentir sur ce genre de détails.

Symptomatique du recruteur. La graphologie portée à l'ère du numérique. C'est d'ailleurs comme cela que certains développeurs sont devenus des accros du tabassage de clavier. En fait, ils ne reflechissent pas, ils ne cherchent pas à étudier un problème, ils alignent des lignes de codes en martyrisant leur clavier. Résultat, quand vous devez reprendre derrière eux, vous regrettez amèrement leur embauche...

[B.AF]

Symptomatique du recruteur. La graphologie portée à l'ère du numérique. C'est d'ailleurs comme cela que certains développeurs sont devenus des accros du tabassage de clavier. En fait, ils ne reflechissent pas, ils ne cherchent pas à étudier un problème, ils alignent des lignes de codes en martyrisant leur clavier. Résultat, quand vous devez reprendre derrière eux, vous regrettez amèrement leur embauche...

En fait il cherche des sténo...pendant que la MOA dicte le besoin.
Le problème des recruteurs aujourd'hui, c'est qu'ils pensent tous sans exception être les plus fins connaisseurs de la nature humaine et qu'ils jouent à la psycho comptoir.

[Kanithael]

Symptomatique du recruteur. La graphologie portée à l'ère du numérique. C'est d'ailleurs comme cela que certains développeurs sont devenus des accros du tabassage de clavier. En fait, ils ne reflechissent pas, ils ne cherchent pas à étudier un problème, ils alignent des lignes de codes en martyrisant leur clavier. Résultat, quand vous devez reprendre derrière eux, vous regrettez amèrement leur embauche...

Je ne suis pas d'accord. Si on demande au nouvel embauché d'être quelqu'un qui va passer la plupart de son temps à coder, son attitude avec un clavier est importante. Aller vite (en plus de le faire bien) c'est son boulot après tout. Et je pense aussi qu'avec l'expérience, on apprend à taper au clavier sans le regarder machinalement. Si la personne galère malgré l'expérience affichée sur son cv, pour moi il y a un truc louche !

[I_believe_in_code]

J'ai cotoyé des developpeurs moyens voir médiocres mais qui avaient un sens de l'a propos assez impressionant. De tres belles phrases qui ne savaient pas transformer en cas pratiques. Y'a moins de place pour les developpeurs bon techniquement mais qui ne savent pas se vendre.

D'où l'utilité de faire passer des tests sérieux. On ne recrute pas un informaticien comme on recrute un vendeur de lessive.

[Skyounet]

Symptomatique du recruteur. La graphologie portée à l'ère du numérique. C'est d'ailleurs comme cela que certains développeurs sont devenus des accros du tabassage de clavier. En fait, ils ne reflechissent pas, ils ne cherchent pas à étudier un problème, ils alignent des lignes de codes en martyrisant leur clavier. Résultat, quand vous devez reprendre derrière eux, vous regrettez amèrement leur embauche...

Vous ne comprenez pas sa phrase. Il parle pas de pisseur de code, il parle seulement de l'attitude d'une personne face à un clavier.

Un développeur qui tape à 2 doigts c'est quand même plus louche qu'un qui tape à 8 doigts.

Il ne recherche pas un mec qui tape sur son clavier sans réfléchir mais un mec qui sait utiliser ses doigts pour taper sur son clavier lorsque le moment de développer sera venu.

Je pisse pas du code à longueur de journée, et pourtant j'utilise 8 à 10 doigts sans regarder le clavier (en même temps je suis obligé j'ai un clavier canadien que j'ai réglé en clavier français ).

[Franck SORIANO]

Merci , il y en a au moins un qui a compris ce que j'essaie de dire.

Je vais vous rassurer, je ne suis pas un recruteur. Je suis seulement la personne à qui on demande de finir le travail lorsque la dead-line est là, celle à qui on demande de réparer les dégats lorsque tout a explosé et que l'auteur du code ne comprend plus rien à son propre travail...
A force, on finit par acquerrir un certain poid dans le choix de ses collaborateurs, et on supporte de moins en moins les boulets.

[Golgotha]

Je crois que si j'étais obligé de faire passer une test à un candidat, je lui demanderais ce qu'il ne sais pas faire... admettons qu'il me réponde java, je lui laisse alors un temps données pour débug une fonction en java avec internet sous la mains.

l'informatique ça évolue, le développeur est amener à changer sans cesse de "métier", donc la qualité principale pour moi c'est "savoir ce démerder"

[ishtan]

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

De mon coté, je trouve qu'un exercice pratique est une excellente manière de voir si le candidat convient au poste. Il permet essentiellement d'éliminer ceux qui n'ont que des connaissances théoriques et qui sont incapables de réaliser une application.
Je me suis parfois retrouvé avec des collègues qui avaient d'excellentes connaissances théoriques mais qui étaient incapable de corriger un bug tout simple. A mon avis, cet exercice seul ne permet pas de vérifier les connaissances d'un candidat mais c'est un bon complément.

En revanche je suis d'accord sur le fait que pisser du code sur un feuille est inutile.

[deadalnix]

Oui bien la je suis en train de travailler sur le code d'un personne n'ayant visiblement aucune connaissance ni en modélisation ni en sécurité, et je peux t'assurer que finalement, la théorie, ça sert

[Bruno PICART]

Au moins vous aurez montré que vous savez coder.

Ayez toujours en tête la bonne vieille boucle assembleur qui sait calculer une factorielle, ça peut être très utile, de nos jours

Maintenant, le genre de pratiques montrera à votre futur employeur (tant pis pour vous !) que vous avez une parfaite maîtrise de notions telles que l'analyse d'un cahier des charges, la définition de spécifications, la conception des systèmes de données d'essai, la détermination des paramètres limites mettant à l'épreuve la robustesse de ce que vous avez codé (parce qu'à l'évidence on ne demandera plus que ça en SSII), et peut-être aussi la vulnérablilité des applications face aux méthodes de cracking

Depuis ma décision de devenir free-lancer, je fais entre 12 et 16 heures par jour,mais chaque seconde qui passe est un moment de pur bonheur

[nicolofontana12]

Il est difficile de qualifier quelqu'un par un bout de code. Mais que faire?

[deadalnix]

Et bien, je penses que la meilleur chose à faire est de le confronter à un programmeur avec un gros niveau.

Ils faut ensuite qu'il parlent de choses et d'autres, à partir d'exemples hypothétiques.

Par exemple, j'ai passé un recrutement il y a quelques temps (je n'ai finalement pas pris le poste, mais pour d'autres raisons) dans le monde du web.

Dans un premier temps, j'ai un entretient avec une personne de l'entreprise afin de cerner un peu ma personnalité et mes motivations, jusque la, tout ce qu'il y a de plus standard. Bien sur, ce genre de phase dans un entretiens n'est jamais parfaite car on la façon dont le candidat gère le stress peu influer beaucoups, mais je ne vois pas comment faire mieux.

Mais par la suite, j'ai passé un petit quizz. Environs 1 question sur 2 était de difficulté moyenne et 1/2 plus difficile, afin de cerner une candidat qui sortirait du lot. mais le but du quizz rapide est principalement de détecter les charlots qui ne sauraient pas répondre aux question moyennes.

Bref, viens ensuite une troisième partie, (la partie 2 est courte, elle permet à mon avis au recruteur de gagner du temps en éliminant les incompétents) : un entretiens avec un routard du milieu.

On a parlé des projets que j'avais déjà effectué, tant d'un point de vue technique que ce qui tourne autour (le dev ce n'est pas que de la technique) et on est partit vite sur des idée du type : si je devais refaire un outils type google ou dailymotion, comment je m'y prendrais. Et ça parle technique, expérience utilisateur, gestion de projet, bref tout y passe.

A mon avis, cette boite à une bonne procédure de recrutement. Cela permet de se faire une idée bien mieux qu'un bout de code inutile, mais surtout très chronophage pour le recruté. C'est clair que pour ma part, si la boite veux du dev, il faut payer.

[longbeach]

1) des sources d'un blog d'un américain, c'est pas la référence en ce qui concerne le recrutement en France et à la Française mais intéressant quand même.

2) les tests lors des recrutements je suis contre, c'est ridicule. La période d'essai est là pour ça etc etc

Sujet déjà évoqué maintes fois.