Discussion :

[foetus]

Je m'explique, si je devais passer des tests le weekend a chaque entretien, j'en passerais pas beaucoup.

Les recruteurs comme Frédéric Latour aiment voir que le candidat se remue le derche, montre sa motivation et dévoile son futur investissement personnel[*].
Et en plus c'est bonnard, puisque nous sommes développeurs nous codons 7/ 7, 24/ 24, donc le week-end c'est cacahuète.

Tout ceci à défaut de savoir lire un C.V. technique

Ah je suis bête le rémunération c'est pour les séniors, ceux qui n'ont plus grand chose à prouver surtout niveau recommandation, piston et autres relations.

* -> Penser à porter en entretien un maillot "I Love Dart" ou "I Love Go", 1 des ces langages sans avenir mais tellement buzzword

[2tour]

Les recruteurs comme Frédéric Latour aiment voir que le candidat se remue le derche, montre sa motivation et dévoile son futur investissement personnel[*].

Ce que Mr Latour "grand recruteur" ne sais pas c'est que motivation# niveau.

Un mec nul peut etre motivé, inversement si un bon dev voit un type comme latour lui casser les burettes, il ne risque pas de le revoir de si tot. Sa s'appelle la fuite des cerveaux, et il ne doit pas y'en avoir beaucoup dans sa boite.

[Invité]

Ce que Mr Latour "grand recruteur" ne sais pas c'est que motivation# niveau.

Un mec nul peut etre motivé, inversement si un bon dev voit un type comme latour lui casser les burettes, il ne risque pas de le revoir de si tot. Sa s'appelle la fuite des cerveaux, et il ne doit pas y'en avoir beaucoup dans sa boite.

On se connaît? Si vous pouviez argumenter de manière un peu plus rigoureuse, ce serait avec plaisir que je vous répondrais. En l'espèce je ne vois pas vraiment à quoi vous vous référez pour me faire un procès d'intention.

C'est incroyables tous ces "Informaticiens/développeurs" super forts (sauf en Français) qui sont sur la défensive dès qu'il s'agit de réaliser des tests techniques dans le cadre d'une procédure d'embauche.

En plus vous répétez en boucle des contre-vérités démenties plusieurs fois:

• Il ne s'agit pas de travailler tout le week-end mais quelques heures pendant le week-end (pour au contraire donner plus de liberté d'organisation).
• Les heures sont payées et même très bien payées.

Il est de plus en plus fréquent que les procédures d'embauche donnent lieu à des tests techniques. Cette démarche propose de payer le temps passé. Cela va plutôt dans le bon sens. Non?

[Invité]

Les recruteurs comme Frédéric Latour aiment voir que le candidat se remue le derche, montre sa motivation et dévoile son futur investissement personnel[*].
Et en plus c'est bonnard, puisque nous sommes développeurs nous codons 7/ 7, 24/ 24, donc le week-end c'est cacahuète.

Tout ceci à défaut de savoir lire un C.V. technique

Ah je suis bête le rémunération c'est pour les séniors, ceux qui n'ont plus grand chose à prouver surtout niveau recommandation, piston et autres relations.

* -> Penser à porter en entretien un maillot "I Love Dart" ou "I Love Go", 1 des ces langages sans avenir mais tellement buzzword

Je ne suis pas recruteur mais il m'arrive de recruter. Une petite distinction qui a son importance.

Vous faites ce que vous voulez de votre vie. L'informatique ne vous intéresse pas particulièrement? C'est purement alimentaire? Cela vous regarde. Néanmoins, il y a très peu de chances que vous puissiez rester à niveau dans un monde de technologies qui évoluent très vite en y consacrant 7 heures par jour pendant lesquelles vous devez accésoirement produire la richesse nécessaire à payer vos charges (qui sont particulièrement élevées - compter 2 fois votre net entre les charges patronales, les frais de structure, les obligations réglementaires, etc...).

La contrepartie d'un métier passionnant est peut-être l'implication. Mais chacun est libre de conduire sa vie comme il l'entend et de ne postuler que si les conditions du recrutement correspondent à son idéal.

[el_slapper]

Les recruteurs comme Frédéric Latour aiment voir que le candidat se remue le derche, montre sa motivation et dévoile son futur investissement personnel[*].
Et en plus c'est bonnard, puisque nous sommes développeurs nous codons 7/ 7, 24/ 24, donc le week-end c'est cacahuète.

En même temps, le candidat qui arrive et m'explique que mon job, il s'en bat les noix de coco, j'aurais du mal à sentir sa volonté d'être efficace. On parle quand même de postes de haut niveau d'exigence, pas de balayer chez McKing.

Tout ceci à défaut de savoir lire un C.V. technique

Vu que le CV technique n'est absolument pas un prédicteur. J'ai vu des gens :
_"4 ans d'expérience chez les plus grands comptes, dont 2 cornaqué par Accenture" qui n'arrive pas à pondre 10 lignes de code en un mois.
_"10 ans d'expérience sur tous les ETL présents sur le marché - même OWB" qui n'ose même pas sauvegarder un composant de test sur l'environnement de dev, et débrancher le PC par peur de faire une connerie.
_"indépendant depuis 6 ans dans le domaine" qui casse tout tout le temps, et nécessite une semaine de réparation par jour de boulot effectué - le gars devait changer l'alimentation d'une table, s'est gouré de table, n'a pas trouvé le champ, en a renommé un choisi au hasard, et l'a alimenté au hasard. Et livré en louvoyant pour éviter les tests.
_"11 ans d'expérience en JAVA", mais infoutu de faire en 40 heures ce que le petit jeune avec encore du lait au bout du nez faisait en une heure.
_"20 ans d'expérience en maintenance COBOL". N'avait jamais vu un incident de production de sa vie.
_"expert technique dans plein de domaines". Ne testait jamais un code avant de le livrer. Une fois, 4 ans après la livraison, ça m'a pété à la gueule. Un truc que personne n'utilisait jamais, jusqu'au jour ou un client, patron du CAC40, a demandé à son agent bancaire haut-de-gamme de faire des réglages fins sur l'usage de sa carte. Et demandé des têtes à l'informatique à son homologue de la banque quand il a vu de ses yeux vu l'agent faire la modif, et le système n'en avoir rien à battre. J'ai eu 7 heures(sans avoir le temps de manger) pour sauver mes fesses et celles de ma chef.
_"expert en tests MVS, spécialement en traitement de fichiers, 12 ans de métier". Incapable de lire le Binaire Codé Décimal, utilisé par 100% des clients, dans plus de 50% de leurs fichiers. C'est un format de nombres pour lequel les processeurs qui tournent sur les machines MVS sont spécialement optimisés...
_"spécialiste HTML, spécialisée dans la rédaction de fichiers d'aide"...fichiers d'aide inutilisables par quiconque d'un tant soi peu humain. A fini chef d'équipe, position ou elle faisait moins de dégats(mais quand même, elle a vraqué les specs).

Alors le CV technique, excuse-moi, mais bon, comment dire...

(tiens, je note dans ma série qu'il y a une seule femme incompétente, alors que j'ai croisé une proportion de femmes plus importante que 12,5% - pas sur que mon échantillon soit représentatif, toutefois)

Ah je suis bête le rémunération c'est pour les séniors, ceux qui n'ont plus grand chose à prouver surtout niveau recommandation, piston et autres relations.

Une recommandation, quand tu choisis les recommandateurs, c'est franchement pas un souci. Il suffit d'avoir 3 personnes qui t'ont apprécié personnellement, et hop! c'est dans la poche. J'ai triché, en plus, j'ai pris 3 dames assez âgées qui ne parlaient pas un mot d'anglais, car je savais que la RH anglophone serait obligée de sous-traiter à la RH française, beaucoup plus coulante...

* -> Penser à porter en entretien un maillot "I Love Dart" ou "I Love Go", 1 des ces langages sans avenir mais tellement buzzword

ça, ça dépend de l'interlocuteur. D'aucuns te flingueront juste pour ne pas avoir la cravate. D'autres pour en avoir une. C'est orthogonal au débat, je dirais. Mais c'est un problème réel.

[DonQuiche]

* -> Penser à porter en entretien un maillot "I Love Dart" ou "I Love Go", 1 des ces langages sans avenir mais tellement buzzword

Dart relevait du buzz, je n'y ai jamais cru et il va vers sa mort.

Go est quant à lui déjà utilisé par plusieurs entreprises pour des projets d'ampleur, à commencer chez Google. Il est là pour durer. Ce n'est pas un grand langage, ce n'est pas un langage très productif, ce n'est pas un langage innovant, mais c'est un langage solide pour des applications distribuées sur des milliers de machines dans le monde et nécessitant de faire travailler ensemble des dizaines de milliers d'ingénieurs aux compétences hétérogènes (y compris des mauvais) dont certains ne contribuent qu'occasionnellement.

[CoderInTheDark]

C'est toujours mieux, que certaines pratiques.

Mais bon, ça n'empêche pas de devoir passer devant un commercial ou un RH
Qui parfois t’affirme des énormités, quand ils parlent de techniques
Et là c’est dur de ne pas être déstabilisé.

[RyzenOC]

Mais bon, ça n'empêche pas de devoir passer devant un commercial ou un RH
Qui parfois t’affirme des énormités, quand ils parlent de techniques
Et là c’est dur de ne pas être déstabilisé.

C'est pour voir si tu est capable d'encaisser des inepties sans lui casser la tronche, pour tester ta motivation sont fort quand même !

Une pratique que j'adore c'est la question HS style "vous préférez le rouge ou le bleu ?" la bonne réponse c'est "j'aime toute les couleurs" (ou un truc dans ce style), une technique apparues dans les années 70, encore utilisée aujourd'hui pour "éliminer les mauvais développeurs". edit C'est du vécu.

Tous sa pour dire que y'a pas de technique efficace, y'a tous le temps un MAIS.

[tchize_]

Bien que je n'ai finalement rien contre l'idée, j'aurais quand même plusieurs questions / remarques par rapport à cette proposition.

1) D'un point de vue pratique, de mon coté (frites) de la frontière surtout: comment est géré le statut du candidat pour ce travail? Qui dit rémunération dit déclaration de ladite rémunération. Qui dit déclaration dit un statut derrière: employé, cadre ou indépendant. Et pour un travail de 2 jours, aucun de ces statuts ne semble intéressant. Après 4 ou 5 heures de travail sur le problème (notez que l'article ne dit pas de fournir des problème de 16 heures non plus, juste plus de deux heures), je n'ai pas envie de me taper 3 jours de bordel administratif pour déclarer tout ça en indépendant. De plus les lois interdissent que ce travail porte concurrence à votre employeur (problème si vous allez à la concurrence) et obligent d'informer votre employeur (voir sous certains status nécessitent l'accord de l'employeur). Vous n'avez pas nécessairement envie d'aller dire à votre employeur: ce we je fais une interview à la concurrence, ça te dérange pas?

2) Cette méthode a-t-elle fait l'objet de test comparatifs avec d'autres méthodes? Autrement dit as-t-on par exemple pris dans une grosse boite d'un coté le recrutement "classique" et de l'autre le recrutement "weekend" pour voir après 2 ans, combien sont partis et comment ils performent dans leurs évaluation de travail? On a une belle démonstration de l'idée derrière, mais sans évaluation scientifique derrière, ça a juste autant de valeur qu'un beau prospectus électoral sur papier glacé qui dit "votez pour moi, je suis le meilleur et je l'ai déjà prouvé croyez moi"

2bis) Quel équilibre dans ce système? On demande disons 5h de travail, payés, au candidat pour démontrer qu'il fait l'affaire. Mais la boite dépense-t-elle aussi 5h de temps, et sous quelle forme, pour démontrer au candidat qu'il faut venir chez elle? L'entretiens de recrutement, c'est à deux sens.

3) Combien de candidats voient-ils pour un poste? Parce qu'il faut bien mettre ça dans la balance. 5 candidats = être disponible semaine et we pendant un mois, c'est très très lourd au recruteur sur la vie de famille / vie sociale. Et pour peu qu'il y aie 5 ou 6 recrutements par an, ça deviens ingérable. Même problème coté candidat. Si on voit 5 candidats pour un poste, le candidat devra faire en moyenne 5 interviews pour trouver un poste. Ca veux dire bloquer 5 fois vendredi / we / lundi, ça fait la moitié des jours de congés annuel qui y passent. Bon lui on suppose qu'il change pas de poste 5 fois par an mais quand même

4) Quelle liberté d'arrangement de l'horaire ça laisse pour un candidat? Personnellement, le we étant mon seul temps libre, l'agenda est blindé parfois 2 mois à l'avance. Si demain on me propose un poste 2 fois mieux payé dans un environnement de rêve, mais faut être dispo un w-e complet, je dois répondre "on se voit en décembre pour l'interview alors".

5) Quelle est la réactivité de ce système? Combien de candidats on peut tester par semaine? Quand j'ai décidé de changer de poste récemment, en 4 semaines tout était plié, depuis la première lettre envoyée à la proposition de contrat. Dans un domaine concurrentiel, le candidat qui est toujours disponible au bout de deux mois, c'est soit que les autres n'en ont pas voulu, soit qu'il veux vraiment bosser juste pour vous. J'ai bossé dans un endroit ou le délai d'engagement était de 6 mois, je vous laisse imaginer comment on galérait pour trouver


6) Un peu orthogonal au sujet. Je vois régulièrement passer la question de comment tester un candidat informaticien. Mais en quoi ce problème est-il spécifique aux informaticiens? Les autres, il font quoi pour recruter des experts comptables, des vendeurs seniors, un soudeur plongeur expert, un spécialiste en restauration de tableaux? Dans tous les cas, le problème est le même: on ne peux pas juger sur le CV, sur les recommandations, il est difficile de tester le candidat en seulement quelques heures et si il n'est pas à la hauteur, ça va être cher de rattraper ses merdes. J'ai parfois l'impression qu'on veux donner l'image que le métier d'informaticien est tellement spécifique qu'il lui faut des procédures spécifiques. Ben non, on est comme tous les autres: on utilise des outils, de l'expérience et un cerveau pour atteindre des objectifs qui nous sont fixés, dans les règles de l'art. On a juste la chance d'exercer dans un domaine où la demande est telle que ca paye bien.

[kiprok]

6) Un peu orthogonal au sujet. Je vois régulièrement passer la question de comment tester un candidat informaticien. Mais en quoi ce problème est-il spécifique aux informaticiens? Les autres, il font quoi pour recruter des experts comptables, des vendeurs seniors, un soudeur plongeur expert, un spécialiste en restauration de tableaux? Dans tous les cas, le problème est le même: on ne peux pas juger sur le CV, sur les recommandations, il est difficile de tester le candidat en seulement quelques heures et si il n'est pas à la hauteur, ça va être cher de rattraper ses merdes. J'ai parfois l'impression qu'on veux donner l'image que le métier d'informaticien est tellement spécifique qu'il lui faut des procédures spécifiques. Ben non, on est comme tous les autres: on utilise des outils, de l'expérience et un cerveau pour atteindre des objectifs qui nous sont fixés, dans les règles de l'art. On a juste la chance d'exercer dans un domaine où la demande est telle que ca paye bien.

Tout à fait d'accord avec ce point (et d'autres aussi mais celui ci me parait bien important)...

Je suis d'ailleurs étonné par la généralité évoquée dans l'article :

En effet, quand on arrive à la question d’embaucher le candidat que l’on recherche, le domaine spécifique de la technologie défit toutes les techniques qui ont été prouvées comme efficaces dans les autres domaines.

[el_slapper]

snip

J'aime bien ton approche scientifique du sujet.

J'ajouterais juste que pour moi, avant même de tester, il faut aller dans les bonnes zones de pêche, et Joel Spolsky explique ça bien mieux que moi. On ne recherche pas de pivot de basket à une conférence de nains. On trouvera de meilleurs plongeurs si on cible à la COMEX que chez AIR FRANCE, par exemple.

[mrqs2crbs]

voila, voila,

je l'ai retrouvé,
on a de la chance que certains des entretiens d'embauche (à "l'américaine") soient filmés.
ça permet de mieux ce rendre compte:

https://youtu.be/riP6qZ5us5k

[Cheshire_Cat]

Personnellement je ne suis pas d'accord.

Appeler un ami pour discuter d'un problème, c'est challenger ses idées.
Et quand bien même le candidat irait repomper la solution sur Google, dans la mesure où il répond parfaitement à la demande, je ne vois pas où il peut y avoir un problème.

Le but de l'exercice est-il de savoir si le candidat a une tête bien pleine, ou une tête bien faite ?

[AmericainDad]

En effet j'estime qu'il y a pas de bons ni mauvais mais plutôt des candidats qui correspondent ou pas au poste. on est tous différents et chacun sa sensibilité. Mais sinon c'est un excellent mode de recrutement.
je me demande cependant est ce qu'il est adapté aux débutants?

[Gort'h]

En effet j'estime qu'il y a pas de bons ni mauvais mais plutôt des candidats qui correspondent ou pas au poste. on est tous différents et chacun sa sensibilité. Mais sinon c'est un excellent mode de recrutement.
je me demande cependant est ce qu'il est adapté aux débutants?

Why not?

[Saverok]

En effet j'estime qu'il y a pas de bons ni mauvais mais plutôt des candidats qui correspondent ou pas au poste. on est tous différents et chacun sa sensibilité.

Sur la technique,il y a tout un tas d'indicateurs objectifs qui permettent d'évaluer le niveau.
Donc oui, il y a des mauvais et des bons développeurs.
A noter que cela est vrai pour toutes les professions, rien de spécifique aux métiers de l'info.

je me demande cependant est ce qu'il est adapté aux débutants?

Comme indiqué dans l'article et dans pas mal de posts, ce type de recrutement est réservé aux seniors.
Sur un profil débutant, il n'y absolument pas de besoin d'aller si loin dans les tests et on n'attend pas les mêmes choses.
Là, plus encore que la solution, ce qui est évalué c'est sa présentation et le débat qu'elle peut susciter et comment le candidats sait y répondre.

[el_slapper]

Sur la technique,il y a tout un tas d'indicateurs objectifs qui permettent d'évaluer le niveau.
Donc oui, il y a des mauvais et des bons développeurs.
A noter que cela est vrai pour toutes les professions, rien de spécifique aux métiers de l'info.

Je pense que vous avez tous les deux raison : on a tous des points forts... et tout le monde n'a pas forcément les points forts pour être développeur, quelle que soit la branche.

Comme indiqué dans l'article et dans pas mal de posts, ce type de recrutement est réservé aux seniors.
Sur un profil débutant, il n'y absolument pas de besoin d'aller si loin dans les tests et on n'attend pas les mêmes choses.
Là, plus encore que la solution, ce qui est évalué c'est sa présentation et le débat qu'elle peut susciter et comment le candidats sait y répondre.

Je ne sais pas. franchement, pour avoir vu des séniors incapables et des débutants superforts(meilleurs que moi et mes 10 ans de bouteille et ma fierté, et mes réussites soulignées appréciées par mes clients successifs), je me dis que la principale différente entre un débutant et un sénior est que le sénior a plus bourlingué, ce qui lui donne plus d'aplomb pour gérer les situations difficiles. Mais le gain en terme de productivité est infime, surtout comparé avec le gain de productivité entre 2 seniors - ou entre deux débutants.

Donc recruter différemment, je ne sais pas. Si j'attends d'un vieux con de mon âge d'être capable de faire un élément complet en un week-end, j'attends la même chose d'un débutant, je serais juste plus tolérant sur les bizarreries du code. Par contre, le vieux con, il a intérêt à poser des questions en cas de doute. On peut pardonner ça à un débutant timide. A un vétéran de 1000 guerres, non.

[Saverok]

Je ne sais pas. franchement, pour avoir vu des séniors incapables et des débutants superforts(meilleurs que moi et mes 10 ans de bouteille et ma fierté, et mes réussites soulignées appréciées par mes clients successifs), je me dis que la principale différente entre un débutant et un sénior est que le sénior a plus bourlingué, ce qui lui donne plus d'aplomb pour gérer les situations difficiles. Mais le gain en terme de productivité est infime, surtout comparé avec le gain de productivité entre 2 seniors - ou entre deux débutants.

Donc recruter différemment, je ne sais pas. Si j'attends d'un vieux con de mon âge d'être capable de faire un élément complet en un week-end, j'attends la même chose d'un débutant, je serais juste plus tolérant sur les bizarreries du code. Par contre, le vieux con, il a intérêt à poser des questions en cas de doute. On peut pardonner ça à un débutant timide. A un vétéran de 1000 guerres, non.

En effet, côté productivité, la différence entre senior et junior n'est pas l'élément déterminant.
Voici les qualités que je recherche chez un développeur :
* structuration du code
* maintenabilité du code
* clarté du code
* présenter clairement et synthétiquement son projet
* avoir un regard critique sur sa réa (qualité et défaut, justifier ses choix, etc.)
* poser des questions pertinentes et précises
* adapter son discours en fonction de son interlocuteur
* anticiper

Il s'avère que ces qualités viennent souvent avec l'expérience.
Il a fallu que je me prenne pas mal de claques professionnelles pour apprendre à poser des questions pertinentes en fonction de mon interlocuteur, adapter mon discours, synthétiser, etc.

En tant que junior (j'ai l'impression d'être un vieux croûton en écrivant çà alors que je n'ai que 10 ans d'expérience ), on a souvent tendance à se perdre dans les détails et vouloir être très précis dans les termes, etc.

Il faut une certaine expérience pour intervenir de manière pertinente celons les situations.

J'en en horreur lorsqu'un développeur vient me voir et me dire "j'ai un problème" sans rien ajouté de plus.
On n'annonce jamais ça de cette façon.
On vient avec un plan d'action, une analyse, des pistes, des demandes d'arbitrage, des demandes d'assistance précises et argumentées, les impacts (planning, chiffrage, etc), etc.
Autant avec un junior, je vais prendre du temps pour lui expliquer la méthodo d'analyse face à une situation de blocage.
Alors que face à un senior, il va se faire accueillir comme il se doit.

[el_slapper]

En effet, côté productivité, la différence entre senior et junior n'est pas l'élément déterminant.
Voici les qualités que je recherche chez un développeur :
* structuration du code
* maintenabilité du code
* clarté du code
* présenter clairement et synthétiquement son projet
* avoir un regard critique sur sa réa (qualité et défaut, justifier ses choix, etc.)
* poser des questions pertinentes et précises
* adapter son discours en fonction de son interlocuteur
* anticiper

Il s'avère que ces qualités viennent souvent avec l'expérience.
Il a fallu que je me prenne pas mal de claques professionnelles pour apprendre à poser des questions pertinentes en fonction de mon interlocuteur, adapter mon discours, synthétiser, etc.(.../...)

C'est bien gentil, mais si le mec il ne sait pas faire un fizbuzz, même avec toutes ces qualités, j'en veux pas. Et j'en ai connu, des comme ça.

Après, c'est clairement un plus, pour quelqu'un qui sait déjà coder. Et souvent, ça s'améliore avec l'expérience. Je dis s'améliore, parce que généralement, c'est latent. D'aucuns n'apprennent jamais, et font encore du code spaghetti après 50 ans. Mais c'est difficile à détecter quand c'est juste latent.

J'en en horreur lorsqu'un développeur vient me voir et me dire "j'ai un problème" sans rien ajouté de plus.
On n'annonce jamais ça de cette façon.
On vient avec un plan d'action, une analyse, des pistes, des demandes d'arbitrage, des demandes d'assistance précises et argumentées, les impacts (planning, chiffrage, etc), etc.
Autant avec un junior, je vais prendre du temps pour lui expliquer la méthodo d'analyse face à une situation de blocage.
Alors que face à un senior, il va se faire accueillir comme il se doit.

Dis-toi bien que quand je mets ma casquette de testeur, si je me contente de dire "ton programme y marche pas", je vais me faire accueillir comme il se doit. Et c'est normal. Pour aller dans ton sens, mon expérience personnelle, c'est que si je n'ai pas passé 15 minutes sur la seule rédaction du rapport de bug, sans compter le temps d'analyse et de détermination du périmètre, alors le bug ne sera pas corrigé dans son intégralité. J'ai appris ça à la dure. J'ai aussi appris que si on met deux bugs dans un rapport de bug, un seul bug sera corrigé. Et quand je suis de l'autre coté de la barrière, je sais tout de suite pourquoi...

Au final, tout ce que tu dis est vrai, mais ne nous rapproche pas du mythique Graal : ne garder que les bons candidats.

[mijdrol]

Ne plus faire de PHP :o