Discussion :

[tomlev]

La période d'essai est déjà bien assez longue pour couvrir le risque que le candidat se révèle incompétent, en général quelques jours suffisent pour s'en rendre compte.

La période d'essai n'est absolument pas une façon viable de tester un candidat... un petit scénario pour illustrer le problème :

Le 1er janvier, tu décides d'embaucher un nouveau développeur. Tu publies une annonce, tu passes par des cabinets de recrutement, tu fais passer des entretiens, etc. Ça prend déjà du temps. Si tu te débrouilles bien, au bout de 2 mois, tu as trouvé un candidat qui fait l'affaire et accepte l'offre d'embauche. On est le 1er mars. Mais comme bien souvent, le candidat est déjà en poste et a une période de préavis de 3 mois. Il n'arrive donc que le 1er juin. Au bout de 2 semaines, il est clair que ta nouvelle recrue n'a pas les compétences requises : tu mets fin à la période d'essai. Résultat des courses, il s'est écoulé presque 6 mois, et tu n'as toujours pas ton nouveau développeur. Tout est à recommencer : 6 mois de perdus !

Si tu lui avais fait passé un entretien technique, tu aurais vu tout de suite qu'il n'avait pas le profil. Tu aurais peut-être passé un peu plus de temps à chercher, mais au final tu aurais eu un candidat valable, et tu n'aurais pas perdu 6 mois.

Pour moi, quelqu'un qui a les compétences requises n'a pas à craindre l'entretien technique. Je ne vois aucune raison de s'y opposer, à moins de vouloir cacher qu'on n'a pas les compétences.

[theMonz31]

Mais pour le 1/ pas de miracle. On peut pas embaucher un mec qui ne peut pas calculer la complexite d'une methode, ne sais pas ce qu'est un quicksort ou n'a pas les bases des datastructures.
Et pour ca, il faut un entretien technique sur tableau blanc.

Bah ça, désolé, mais c'est de la "pipe"....

par contre, tout à fait d'accord avec :

Pour moi c'est indispensable. J'ai vu tellement de super candidats avec de super principes, des experiences a faire palir n'importe qui, mais incapable d'imaginer une solution scalable... Trop souvent enferme sur des langages et des technologies specifiques: when you have a hammer, everything is a nail !

La connaissance (d'une méthode, algo, etc...), on s'en fout relativement... Si le mec a du potentiel.

En Grande Bretagne, les entreprises embauchent de gens qui ont un diplome Bac+4/5 parce que ce niveau, normalement, procure une certaine capacité cognitive...
La capacité d'apprendre est plus importante que de lister une collection de chose à savoir...

Parfois, j'ai eu des entretiens où le recruteur parlait de "design patterns" parce que ça fait bien... Mais ce n'est pas un design pattern qui te fait résoudre
un problème... c'est ta capacité à appréhender un problème et entrevoir des solutions qui est le plus important pour un technique, surtout pour un ingénieur...

sinon, on embauche de l'analyste programmeur et on lui fait pisser du code en espérant avoir le meilleur pisseur de code...

Pour moi, recruter, c'est avant tout se sentir bien avec son futur(e) collègue...

Après, les SSII sont un peu à part dans la mesure où souvent, le recruteur cherche du profil, comme dit plus haut, "docile"...

Je suis plutôt pour l'entretien technique, mais pas sous la forme d'un "résoudre un problème / Coder une fonction / etc..." mais plutôt de parler des expériences du candidat d'un point
de vue technique, technologie, méthodologie, aspiration personnelle, etc...

[dfiad77pro]

La période d'essai n'est absolument pas une façon viable de tester un candidat... un petit scénario pour illustrer le problème :

Le 1er janvier, tu décides d'embaucher un nouveau développeur. Tu publies une annonce, tu passes par des cabinets de recrutement, tu fais passer des entretiens, etc. Ça prend déjà du temps. Si tu te débrouilles bien, au bout de 2 mois, tu as trouvé un candidat qui fait l'affaire et accepte l'offre d'embauche. On est le 1er mars. Mais comme bien souvent, le candidat est déjà en poste et a une période de préavis de 3 mois. Il n'arrive donc que le 1er juin. Au bout de 2 semaines, il est clair que ta nouvelle recrue n'a pas les compétences requises : tu mets fin à la période d'essai. Résultat des courses, il s'est écoulé presque 6 mois, et tu n'as toujours pas ton nouveau développeur. Tout est à recommencer : 6 mois de perdus !

Si tu lui avais fait passé un entretien technique, tu aurais vu tout de suite qu'il n'avait pas le profil. Tu aurais peut-être passé un peu plus de temps à chercher, mais au final tu aurais eu un candidat valable, et tu n'aurais pas perdu 6 mois.

Pour moi, quelqu'un qui a les compétences requises n'a pas à craindre l'entretien technique. Je ne vois aucune raison de s'y opposer, à moins de vouloir cacher qu'on n'a pas les compétences.

j'ai eu ce cas ci dans ma boite, ou ils ont voulus recruter un "expert .NET" (version SS2I) pour compléter mon équipe.

Résultat ils n'ont pas fait d'entretient technique et on s'est retrouvé avec une personne très sympatique,
mais qui ne connaissait ni WPF, ni Entity Framework, ce qui pour moi est un comble.

Un Bon dev/expert dans une techno doit être un passionné !


Bref ,
on a perdu presque 1 ans depuis ce jour on me demande de faire des entretiens techniques (dans le cadre de .NET et certains domaines en JAVA),
mais je les fais à l'oral, je trouve ça bien plus humain et déterministe.

[Sodium]

Je trouve très utile de poser des questions techniques sur quelques éléments bien choisis.
Sans exiger d'un candidat qu'il puisse citer toutes les fonctions d'une API précise, des réponses même vagues peuvent montrer qu'il s'intéresse réellement au domaine et qu'il travaille d'une manière qui part dans la bonne direction.

[yahiko]

Un entretien technique c'est un premier filet de sécurité. C'est mieux que rien.

Maintenant, nul n'est tenu de tout connaître par coeur. Un bon développeur est aussi un développeur sachant où se trouve la bonne information et/ou comment y accéder via un moteur de recherche.

C'est pourquoi idéalement dans les tests techniques, les candidats doivent avoir accès à Internet. Si ces tests sont bien conçus (et là il y aurait par contre beaucoup à dire sur comment faire passer de bons tests techniques, mais j'ai l'impression que le topic a plus une volonté de polémique ^^), il ne devrait pas être possible de trouver trivialement la réponse toute faite aux problèmes posés aux candidats.

[el_slapper]

100% d'accord avec le blog de Jeff Atwood en lien plus haut : un test technique, ça permet d'éliminer les gnous(en gros, les gens qui sont bons, mais pas dans ce domaine). Pas de sélectionner les tous meilleurs.

Pour ça, seule la participation à un projet représentatif permet d'avoir une idée juste de la capacité réelle de la personne. Et comme c'est trop cher, on a recours à des artifices, qui sont légèrement mieux que de tirer à pile ou face, mais sont quand même des prédicteurs faibles.

_Coder sur un tableau blanc? C'est une compétence, qui se travaille, et assez différente d'un vrai code de production, ou l'une des difficultés majeures est de gérer la masse. Au tableau, on peut écrire quoi, 20 lignes?
_Répondre à un QCM de connaissance du langage? Bof, c'est principalement un exercice de mémoire. Intéressant, mais la corrélation avec le vrai talent est faible.
_Répondre à un QCM d'algorithmique? Même limite que le codage sur tableau blanc, le candidat peut être à l'aise avec les petits systèmes et perdu dans les gros.
_Faire un entretien à bâtons rompus sur la technique? Selon que l'on tombe sur le sujet de prédilection du candidat ou un sujet qu'il ne connait pas, la différence peut être énorme. Un vrai bon apprendrait vite, mais quand même pas en une demi-heure.
_Appeler des référents? Ouais, les copains du candidat qui vont forcément brosser dans le sens du poil. Quand je suis entré chez *****, éditeur de logiciel, en interne, j'ai donné le nom de 3 personnes en qui j'avais toute confiance. Sans compter l'effet dévastateur de l'homogénéité culturelle dénoncée dans le post original.
_Regarder du code open-source? Rien ne prouve qu'il est l'auteur principal.

Pour savoir si Lionel Messi est un bon footballeur, on ne lui fait pas passer des tests de dribble, on ne vérifie pas qu'il mesure plus de 1m80, et on ne compte pas les kilomètres parcourus pendant le match. On ne demande pas à ses anciens coéquipiers, parce qu'ils pourraient encenser leur pote ou au contraire le démolir par jalousie. On regarde un match, voire plusieurs, et on constate que oui, il est meilleur que les autres. Et comme en informatique, les matches sont à huis-clos et non diffusés, il faut les jouer en interne. C'est la période d'Essai - ou alors l'appel à un prestataire. Et ça coute un paquet de bras.

[Reward]

Bonjour,

Même avis que beaucoup, comme Tomlev, je dirais que c'est nécessaire, mais pas suffisant.

Nécessaire pourquoi ?

Le type qui te dit "Ouais ouais, je suis à l'aise en .NET", puis tu vois que en 30 minutes, il ne sait pas instancier une form, bon, il y a de quoi remettre en doute ce qu'il dit.

Mais comme dit el_slapper, ce n'est pas ça qui permettra de sélectionner les meilleurs, donc ce n'est pas suffisant.

Pour ce faire, ce qui à mes yeux est un moyen efficace, il y a "l'expérience" et le "réseau".

Je m'explique: Comme le dit Thomas, une période d'essai a un coût, et se trompait sur l'embauche c'est cher. Mais je suis sûr qu'autour de vous, dans votre réseau, vous connaissez des gens "de valeur".
Je sais c'est relatif, mais vous voyez ce que je veux dire; ce genre de personnes dont on pense qu'on les embaucherait bien, car on connait leurs compétences, mais surtout leurs états d'esprits sur du long terme.

Pas évident à mettre en place, et cela réduit drastiquement le scope. Par contre on sait ce qu'on achète

[Glutinus]

Une première expérience.

J'ai passé un entretien chez une grosse boite que je ne citerai pas et qui se trouve à Boulogne-Billancourt
Un ami qui y était m'a dit qu'il n'y avait pas d'entretien technique.
J'ai eu droit à un QCM !

A l'époque j'étais développeur Java. Alors OUI j'avoue que je n'étais pas bon. N'empêche que sur mon stage de cinq mois j'ai pleuré ma race et ai appris dans la douleur (merci Serge Tahé sur developpez !). J'ai fait la connerie de ne pas demander d'aide, voulant apprendre le plus vite, et j'ai mis trop de temps. N'empêche qu'à la fin j'ai monté une petite appli de quelques pages en JSP.

Je me suis fait défoncer au QCM. Et encore, heureusement que j'ai appelé la veille du troisième entretien pour me dire "ha oui on vous a pas dit il a été annulé" puis quand j'ai repris rendez-vous plus tard, "votre test technique est trop faible" (même pas qu'ils me rappellent...).

Trois semaines après je rentre dans une autre boite.
Encore une semaine après, appel :
"Monsieur Glutinus ? on a une mission pour vous !"
"Heu, mais je suis rentré chez un de vos concurrents !"
"Roh mais vous êtes en période d'essai ! Démissionnez et venez chez nous !"
"Je croyais que je n'avais pas un bon score au test technique ?"
"Ca ? Mais c'est du passé ! Nous on croit au potentiel des gens, pas aux connaissances à l'instant T"

Comme quoi, je suis pas sûr qu'ils savent vraiment comment utiliser leur test technique...

[Reward]

Et j'oubliais un élément essentiel: la passion ! On est bon dans ce qu'on fait quand on est passionné. Difficilement mesurable lors d'un test technique.

[yahiko]

J'ai peur du sous-entendu...

Comme la passion est difficilement mesurable lors d'un test technique, doit-on en conclure qu'il ne faut pas faire de test technique ?

[tomlev]

Et j'oubliais un élément essentiel: la passion ! On est bon dans ce qu'on fait quand on est passionné. Difficilement mesurable lors d'un test technique.

C'est vrai que c'est important et que ce n'est pas un test technique qui va permettre de le mesurer. Mais personne n'a dit qu'il fallait se limiter à un test technique... tu peux discuter avec le candidat aussi . En parlant de ses projets, la passion apparait généralement assez vite si elle est là.

[foetus]

Pour moi le gros problème des tests techniques ce sont les recruteurs qui ne connaissent rien au métier (de près comme de loin, juste des "buzzwords") et applique comme des glands une grille de correction

Mais, moi en tant que candidat, je peux louper les questions pour différentes raisons ou : je ne connais pas la technologie sur laquelle on m'interroge, un ancien souvenir confusant ... ou tout simplement cela me les casse de répondre à des âneries du style "int* a = ++*a+++b**d" ou "le problème du diamant"

Et en sachant que le pseudo test technique c'est la deuxième pré-étape avant le vrai premier rendez-vous, ça charcle direct

[tomlev]

ou tout simplement cela me les casse de répondre à des âneries du style "int* a = ++*a+++b**d" ou "le problème du diamant"

Autant le premier exemple est effectivement une question débile, autant c'est important de comprendre le problème du diamant... surtout si c'est pour un poste de dev C++ (évidemment si tu fais du Java ou du C# tu t'en fous un peu, vu qu'il n'y a pas d'héritage multiple)

[foetus]

autant c'est important de comprendre le problème du diamant...

[HS]En fait, c'est le problème du C++ qui est une boite à outils

Le problème du diamant existe parce qu'on ne veut pas tout péter (refactoring, et oui quelque part ta conception est un chouïa crasseuse) et donc on préfère faire "un pansement sur une jambe de bois", même si c'est une solution "bulletproof" (du moins je l’espère)

On peut aussi citer la notion d'amitié, les héritages à la mords-moi-le-nœud, les décalages de bits au lieu des opérateurs (pour l'optimisation soit disant), du pointeur intelligent partout ....
[/HS]

D'où, pour moi, la pertinence du test ... ou de la société qui l'a mise sur pied

[gangsoleil]

Bonjour,

Plus que l'entretien technique bête et bateau, je pense qu'une discussion autour des expériences du candidat -- ce que M. Bock appelle entretien comportemental, terme que je trouve mauvais -- est beaucoup plus profitable.

C'est ce que mon chef faisait dans mon ancienne entreprise, il ne s'est trompé qu'une fois sur vingt recrutements, ce qui est une performance extraordinaire, et la synergie au sein de l'équipe s'en ressentait, impactant dirctement les résultats -- positivement bien sur.

[deltree]

Oui pour l'entretien technique, mais non au tests écrits: En théorie c'est bien, mais en pratique ceux que j'ai vu étaient systématiquement débiles.
(les tests hein, je ne juge pas les gens).

Je pense que ça s'explique facilement par le fait qu'écrire un bon test technique prend du temps, doit être fait par quelqu'un d'un très bon niveau, et doit être maintenu pour rester valable dans le temps.

[Luckyluke34]

L'entretien technique est-il un bon processus d'évaluation d'un candidat ?

L'interview du dirigeant de chez Google ne traite absolument pas de cette question.

• Il critique les casse-tête (brainteasers) très stratosphériques parfois utilisés dans la Silicon Valley, comme déterminer le nombre de balles de golf qui rentrent dans un avion.

• Il indique aussi que la réussite des candidats aux entretiens chez Google ne préjuge en rien de leur réussite dans l'entreprise, mais sans préciser la nature technique ou pas de ces interviews, ni ce qui se passerait si ces entretiens n'étaient pas faits ou faits radicalement autrement. Par ailleurs il affirme privilégier les entretiens "comportementaux" :

“Give me an example of a time when you solved an analytically difficult problem.”

mais 1/ ce genre de question me parait être un grand classique de l'entretien d'embauche du moins en France, donc rien de révolutionnaire, et 2/ elle peut tout à fait faire partie d'un entretien technique où on va ensuite discuter des détails d'implémentation de cette solution.

• Quand il dit que les "résultats de tests n'ont pas de valeur", il ne s'agit pas de tests d'embauche mais d'examens en cours d'études et de dossier scolaire (G.P.A.).

Les constatations de Google concernent donc les critères d'embauche trop académiques et déconnectés de la réalité, en aucune manière la notion d'entretiens techniques qui est d'ailleurs ultra floue (s'agit-il juste de parler ? de coder en parlant ? d'un test technique écrit dont on débat après ? quel genre de questions / challenge ? etc. etc.)

Voilà, maintenant revenons au troll sur l'entretien d'embauche idéal qui conviendrait à tous les contextes de l'univers, car bien sûr il existe

[4sStylZ]

En face d'une nouvelle problématique, je m'en suis toujours sorti. Je réfléchie, je pose à plat le problème, j'ai le temps de faire des tests, de faire de la recherche. Je peux veiller tard si il le faut.

Dans un test technique, on me pose trente question que je me serait posé en 20 jours de boulots. On ne me donne pas les outils que n'importe quel développeur utilise (le web), on ne me laisse pas le temps de réfléchir, et j'ai en face de moi les juges qui peuvent en un clin d'œil me refuser «le poste de ma carrière».

À ceux qui arrive à rester calme, je vous dit bravo. Moi j'arrive à conserver mon calme même devant la plus grande boulette fait sur la prod. Mais en face de trois experts techniques, je ne trouve ni mes mots, ni de bonnes idées.

Il y a un dicton qui me vient en substance «Lance une balle à un homme, une fois qu'il l'a rattrapé au vol, dit lui que tu lui vas lui relancer, mais que si il ne la rattrape pas à nouveau tu lui met une balle dans la tête.».

[tomlev]

Dans un test technique, on me pose trente question que je me serait posé en 20 jours de boulots. On ne me donne pas les outils que n'importe quel développeur utilise (le web), on ne me laisse pas le temps de réfléchir, et j'ai en face de moi les juges qui peuvent en un clin d'œil me refuser «le poste de ma carrière».

Ce que tu décris, c'est un mauvais test... Pour un bon test d'entretien d'embauche, les questions doivent être suffisamment basiques pour ne pas avoir besoin de faire des recherches sur le web. Typiquement, pour un développeur C#, je demande (entre autres) quelle est la différence entre un type référence et un type valeur, ou bien le rôle du garbage collector ; c'est quelque chose que tout développeur C# devrait savoir expliquer (à moins d'être très débutant), et qui ne nécessite pas de recherches. Par contre, demander à quoi sert le 3e paramètre de la méthode Titi de la classe Toto, c'est crétin comme question... on n'est pas supposé connaitre la doc par coeur.

Si c'est un exercice à résoudre, il doit être suffisamment simple pour ne pas nécessiter plus de quelques minutes. On ne va pas demander à un candidat de développer un algo super complexe, juste de montrer qu'il est capable d'utiliser son langage pour résoudre des problèmes raisonnablement simples (un candidat qui sait pas faire un FizzBuzz sur un tableau blanc dans un langage qu'il prétend maitriser, c'est qu'il est pas capable d'aligner 3 lignes de code, donc pas la peine d'aller plus loin...)

[dfiad77pro]

Ce que tu décris, c'est un mauvais test... Pour un bon test d'entretien d'embauche, les questions doivent être suffisamment basiques pour ne pas avoir besoin de faire des recherches sur le web. Typiquement, pour un développeur C#, je demande (entre autres) quelle est la différence entre un type référence et un type valeur, ou bien le rôle du garbage collector ; c'est quelque chose que tout développeur C# devrait savoir expliquer (à moins d'être très débutant), et qui ne nécessite pas de recherches. Par contre, demander à quoi sert le 3e paramètre de la méthode Titi de la classe Toto, c'est crétin comme question... on n'est pas supposé connaitre la doc par coeur.

Si c'est un exercice à résoudre, il doit être suffisamment simple pour ne pas nécessiter plus de quelques minutes. On ne va pas demander à un candidat de développer un algo super complexe, juste de montrer qu'il est capable d'utiliser son langage pour résoudre des problèmes raisonnablement simples (un candidat qui sait pas faire un FizzBuzz sur un tableau blanc dans un langage qu'il prétend maitriser, c'est qu'il est pas capable d'aligner 3 lignes de code, donc pas la peine d'aller plus loin...)

Ce sont de bonnes questions ouvertes ça à l'oral !
ensuite, si la personne te dit qu'elle est allée voir le code du GC dans coreCLR et qu'elle t'en parle avec les yeux qui brillent ...... doux rêve

Normalement dans ce cas, si tu suis techniquement, t'es fixé sur une partie de ses compétences et tu as vraiment envie de conclure ton embauche...

Cela dit dans dans les entretiens SS2I c'est généralement ( sur ce sujet j'adore généraliser ) :

1) parlez nous de vous et vos expérience
2) le code suivant devrait vous expliquer la suite avec un peu d'humour

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public bool DetectionCandidatPotentiel(PIGEON p){
 
try{
 if (p.PretentionsSalariale> p.TrancheMinSyntec){
MessageOral.Show("Aurevoir "+ p.Prenom+" vous êtes trop cher !");
}
else{
MessageMental.Show("Aller , il faut qu'on le plume"); // TODO : dans un nouveau thread pour que le candidat ne le remarque pas 
return true; // si il sait négocier on le prend quand même car à ce niveau la on est largement gagnant
}
}catch(TruffeException tr){
//On ne fait rien car tout est formaté pour que cela n'arrive pas
}finally{
// On sourit quoi qu'il arrive et on parle d'une société jeune , dynamique et intégrée
}
// Toute erreur de formatage dans le process de recrutement entraîne le refus du candidat ( on ne se remet pas en question)
return false; 
}

bon j'ai caché 15 maladresses ( codage, concept...) , en plus ça fait un exercice !