Discussion :

[Cedric Chevalier]

Au diable l'interview Technique d'avant embauche en entreprise
Un développeur estime que cette pratique est ridicule et sa réussite tient plus de la chance

Quel programmeur ne se souvient pas de ses premiers entretiens d'embauche en entreprise ? Les mains moites, le coeur qui bat à la chamade, la gorge serrée ; ce sont là, les signes annonciateurs du stress qu'on ressent en attendant son tour.

Une fois en face de son interviewer, il s'en suit une série de questions techniques qui, si on a la providence avec soi, cadre avec son domaine d'expertise. Le tout s'achève par un exercice, ou on est invité à écrire du code sur un tableau. Cependant, avec le stress accumulé lors des étapes précédentes, en est-on encore capable ?.

Il faut stopper cette folie. Un programmeur du nom de Jon Evans trouve que l'interview technique en entreprise est tout bonnement ridicule. Sa réussite tient plus à la chance qu'aux compétences réelles du programmeur. Pour lui, beaucoup de bons programmeurs ont été injustement mis à l'écart à cause de cette pratique.

« On reconnaît l'arbre à ses fruits ». Pour Evans, la façon ultime d'embaucher la bonne personne est avant tout de juger ses capacités par quelque chose qu'il a déjà produit. Les projets réalisés par le candidat sont dans ce cas d'une très grande aide.

L’entretien doit être un moment d’échange avec le candidat, au lieu de poser les questions techniques, le recruteur devrait essayer de savoir les outils déjà utilisés par celui-ci, les décisions qui l’on poussé vers ceux-ci, les problèmes techniques déjà rencontrés et comment ils ont été résolus, etc.

Et ce n'est pas tout. Dans la même logique, Evans poursuit en demandant de confier au candidat qui retient l’attention un autre projet à réaliser cette fois-là sous l'œil attentif de l'interviewer, histoire de voir en temps réel ce dont le candidat est capable. La décision de l'embaucher ne doit alors être prise qu'à ce moment là.


Source: Article de Jon Evans

Et vous ?

Jugez-vous avoir été une fois injustement mis à l'écart avec le processus d'embauche traditionnel ?

Que pensez vous alors de la vision de Jon Evans quand au processus d'embauche en entreprise ? Etes-vous d'accord avec lui ?

[garheb]

Le problème, ce sont les entretiens techniques faits par un RH (Que signifie SQL? ...).

Il propose donc de remplacer un exercice technique par... un projet technique. Quelle avancée. Surtout qu'il précise que le projet pourrait être un projet utile pour l'entreprise, vive la main d'oeuvre "gratuite", il fait encore pire que les stages, vivement les processus de recrutement dont le seul but est de produire du code qui sera utilisé ensuite par l'entreprise.

[Elbarto]

quand on veut utiliser les services d'un plombier est-ce qu'on s'amuse à le tester sur ses connaissances en plomberie ?

le choix se fait plutôt sur d'autres critères : prix et étendue des prestations, disponibilité,

ça devrait être donc pareil pour les programmeurs, le recruteur devrait évaluer le rapport qualité/prix, ce que la personne pourra apporter en entreprise, et non pas essayer de remettre en cause ses compétences en lui posant des questions infamantes,

la solution pourrait consister à inverser le processus de recrutement, que le candidat choisisse lui même son futur patron ( cas d'un marché en pénurie ) ou idéalement se mettre en auto-entreprise / consultant informatique

[imikado]

Personnellement j'ai rarement eu des entretiens techniques: quelques questions de temps en temps, mais pas d'exercice à faire, sauf une fois:
on m'avait donné un accès à un serveur web et demandé de faire un CRUD pour voir comment je codais.

Je suis pour demander au candidat de montrer comment il code, comment il réfléchit: l'entretien c'est bien, mais j'ai déjà eu des profils qui passaient l'entretien technique mais était à la ramasse quand il fallait coder (bloquait sur des erreurs php simples, se prenait la tête sur des petits problèmes...)

Si je peux proposer une idée: c'est de proposer au candidat de coder sur un portable déconnecté d'internet, avec juste la documentation php, un serveur web et mysql, on lui laisse 30 minutes pour faire un CRUD*, et on regarde ensuite le résultat:
- on lui demande si il s'en sent capable (la capacité à évaluer une tache à faire)
- code commenté oui/non
- programmation POO oui/non
- factorisation oui/non
Etat d'avancement du projet au bout des 30 minutes: rien ne marche 2/3 de fait mais fonctionnel, 2/3 de fait mais rien ne fonctionne...

CRUD: Create Read Update Delete, ce sont les pages qui permettent de lister/ajouter/afficher/modifier et supprimer des enregistrement.

[mboudraa]

Avant d'être recruté chez Xebia, on m'a demandé de réaliser un projet chez moi avec des specs plus ou moins précises. J'avais 2 semaine pour le faire chez et le renvoyer.
L'entretien technique s'est faut avec un développeur tres expérimenté et tout le long il me posait des questions sur mes choix techniques, sur les tests unitaires réalisés, me demandait de faire des évolutions directement sur sa machine.

Ça a duré 1h30 et j'ai trouvé ça génial et très instructif.

Les entretiens techniques sont nécessaires mais il faut simplement qu'ils soient bien faits et qu'ils aient une vrai valeur ajoutée.

[Lyche]

je me rappel d'une SSII qui lorsque j'avais présenté pour eux en 2010 m'avaient fait passer un test en .Net sur le framework 1.0. Je le fais et ça colle. Puis, finalement, j'ai décidé d'accepter une autre opportunité qui me parassait plus adaptée à mon profil.

2ans et demi plus tard, lorsque je cherchais à nouveau du travail (comme quoi mon premier choix n'était pas si bon) cette entreprise m'a à nouveau contacté. J'ai repassé un entretiens technique, qui était exactement le même... .Net 1.0, mêmes questions grotesques sur une technologie qui n'était déjà plus utilisée

Bref, tout ça pour dire que, non seulement c'est coup de bol de tomber sur des questions auxquelles ont peut répondre. Mais qu'en plus, il faut avoir du bol pour tomber sur un questionnaire qui soit pas complètement à la masse...

J'ai un profil de dev SQL, et je me retrouve 3 fois sur 4 à faire des test en .net... bonjour le niveau de recruteurs..

[SylvainPV]

Personnellement je n'ai jamais eu à produire du code en entretien. En revanche j'ai dû passer des tests de personnalité, de mémoire et de logique. Je pense que le diplôme et l'expérience sont suffisants pour attester d'un niveau technique.

Après, ce ne sont pas les connaissances techniques pures qui font le bon développeur. On peut être un crack et n'avoir aucune créativité, ou être incapable de bosser en équipe, ou ne pas savoir s'imposer/prendre la parole...

[Paul TOTH]

je me souviens avoir passé un QCM technique de présélection avec des questions du type: sur un routeur vous mettez un câble droit ou un câble croisé ? ... j'ai répondu : celui qui est livré avec et j'ai été retenu tout de même

[LaurentC33]

On peut être un crack et n'avoir aucune créativité, ou être incapable de bosser en équipe, ou ne pas savoir s'imposer/prendre la parole..

Tu as entièrement raison Sylvain

Je sais que ça va en faire bondir certains, mais quand on est un développeur qui a été emmené à utiliser plusieurs langages au cours de sa carrière, faire un test de code n'est pas hyper pertinent.
Je suis passé du php à java, C#, as3 et maintenant Pascal.
Je ne me rappelle pas toujours du nom précis de tel ou tel méthode (souvent obligé d'aller sur la doc sur certaines), mais je pense être un bon développeur, et le fait d'avoir travaillé sur de nombreux langages et je pense un bon point.
Je fait du code php propre depuis que j'ai fait du java et du C# par exemple...

Enfin tout ça pour dire que je trouve ça un peu archaïque.
J'ai plein de projets divers et varié à montrer, mais c'est sur qu'un débutant, à par lui faire passer des tests, aucune solution évidente

[rthomas]

Oh que si il faut des tests techniques.
Voici un exemple vécu:
- deux entretiens téléphonique par deux personnes différentes car la personne habite à 700 km
- un entretien dans nos locaux avec deux personnes : ok bon pour le poste
- un test technique sur le sujet que le candidat maîtrise le mieux : horreur et déception.

Quand le candidat et persuadé d'être très bon c'est parfois difficile de le détecter sans test technique.
Ce test à permis d'éviter un déménagement et une période d'essai raccourci.

Déjà rencontré trois fois des dev persuadés d'être très bon et au final rien de rien. J'en ai même vu un qui n'avait rien crée comme code après trois mois, tellement persuadé d'être bon et superbe manipulateur.

=> un test technique permet de détecter les manipulateurs.
45 minutes sur un sujet maîtrisé, 15 minutes sur un nouveau sujet.

[erwanlb]

Avant d'être recruté chez Xebia, on m'a demandé de réaliser un projet chez moi avec des specs plus ou moins précises. J'avais 2 semaine pour le faire chez et le renvoyer.
L'entretien technique s'est faut avec un développeur tres expérimenté et tout le long il me posait des questions sur mes choix techniques, sur les tests unitaires réalisés, me demandait de faire des évolutions directement sur sa machine.

Ça a duré 1h30 et j'ai trouvé ça génial et très instructif.

Les entretiens techniques sont nécessaires mais il faut simplement qu'ils soient bien faits et qu'ils aient une vrai valeur ajoutée.

Heureusement qu'on demande pas ça à un maçon tiens....

Bonjour Mr, le but de l'entretien est de bâtir une maison de 80m², vous avez 2 mois.....

[erwanlb]

Quand le candidat et persuadé d'être très bon c'est parfois difficile de le détecter sans test technique.

Tu mets exactement le doigt sur le problème....l'incapacité des recruteurs a être assez compétent pour trouver la bonne personne avec ou sans test technique et peu importe la méthode de recrutement...

Avant d'avoir des bons ou mauvais profils, avant d'avoir des bons ou mauvais entretiens et avant d'avoir fait le bon ou le mauvais choix....on a des recruteurs qui sont bien souvent des incapables et qui grâce à des batteries de tests essaient de se persuader que grâce à ça ils vont tomber sur le bon...même si avec tout ça ils passent aussi parfois à côté !

Les entretiens techniques, qui se répètent, durent longtemps, etc c'est une manière pour le recruteur de se déresponsabiliser de tout, une manière de se dire "moi j'ai fait mon boulot"...et au passage ça a occupé son temps...

[Jarodd]

Je suis plutôt d'accord avec l'article. J'ai souvent été recalé sur des tests techniques oraux, parce que la question était imprécise (car la RH ne comprenait pas ce qu'elle me demandait), parce que la question est idiote et sans intérêt (quel est le second paramètre de la méthode xxx), ou simplement parce qu'avec le stress de l'entretien + le fait de sortir d'une journée/semaine délicate et pesante, on n'est pas enclin à répondre immédiatement à des questions techniques pendant 1h, à l'heure où d'habitude on rentre chez soi pour se reposer. J'ai d'ailleurs quitté plusieurs fois l'entretien au milieu du test, pour qu'on me dise "vous avez 2/5 dans cette section, c'est trop nul". Pas besoin d'attendre la fin, je leur renvoie le compliment de toute façon.

Pour moi le seul aspect technique de l'entretien valable, c'est la discussion ouverte, sur des problématiques générales, du genre : "on a telle problématique, on a tel élément en main, que proposez-vous pour résoudre le problème ?" Et tout le monde rebondit sur les propos de l'autre, parfois même le technos répond "ah oui je n'avais pas pensé à ça". Généralement j'ai ces questions dans les petites structures, où tout le monde touche à tout et que l'esprit bidouille règne, et jamais dans les grosses boîtes, où la RH ne fait que lire ses fiches et mettre des plus ou des moins en face des questions.

De plus baser tout l'entretien sur l'aspect technique n'est pas forcément une bonne chose. Pour ma mission actuelle, j'avais loupé le test technique, pourtant simple (sur un langage que je touche un peu mais qui n'est pas mon coeur de métier). Grosses goutes sur le front, hésitations orales sur la suite de l'entretien, regard noir du commercial, j'étais persuadé d'avoir tout loupé. Et finalement j'ai été pris. Le client m'a avoué cette semaine qu'il avait rencontré des candidats ayant réussi le test, et globalement bien meilleurs que moi, mais il m'a préféré car même j'ai été moins bon que les autres techniquement, j'ai été choisi sur la personnalité et le comportement général, et sur le fait que j'étais moins sûr de moi, que je n'arrivais pas en terrain conquis, rempli de certitudes et incapable de changer d'opinion. Au final la mission se passe extrêmement bien, il n'a pas l'air de regretter son choix, et je lui ai même appris quelques trucs, donc je ne dois pas être si mauvais Mais en 6 ans, j'ai fait pas mal d'entretiens, et c'est la seule fois que l'aspect technique est le seul qui compte, je trouve cela dommage.

[sinople]

C'est bien plus pertinent de se baser sur les projets déjà réalisé par le postulant. Mais c'est beaucoup plus difficile à vérifier la véracité de ses références et ça prend beaucoup de temps. C'est donc quelque chose qui se réalise en fin de processus de recrutement et pas au début...

Quelques bonnes veilles questions bateaux permettent de filtrer les profils menteurs. Et l'exercice technique permet d'analyser la réaction du candidat sous stress (et oui ça arrive de devoir travailler sous pression en entreprise...). De plus parfois c'est juste l'approche qui est jugée et non pas le résultat.

Ne pas oublier que ces processus d'entretiens (les premières passes en tout cas) ont pour objectif de virer les mauvais et non de garder TOUT les bons. Et ceci à moindre coût :-)

Un bon profil, temporairement mauvais sous le stress, se fait peut être discriminé. C'est moche pour lui mais le recruteur il s'en fiche...

Concernant le travail à réaliser à la maison, je le réalise et j'envoie une facture par la même occasion (savoir facturer ces clients et une compétence non?)

[devyreham]

J'ai eu des entretients où justement je retournais les questions au potentiel employeur. Quand ils deviennent trop exigeants il faut leur demander ce qu'ils offrent en échange.

Avoir un job ne signifie plus rien dans l'economie actuelle. Est-ce que la boîte a des revenus? (car certains sont en train de couler et vous payent avec des credits d'impots...)
Nombre d'effectifs techniques? j ai ete dans une mission ou y en avait 0...donc j'etais le seul informaticien.
Les clients et les projets? Pas ceux sur la brochure de 2011.

Exemple avec le recruteur d'une compagnie aerienne majeure:
"Citrix (virtualisation,acces distant) vous l'utilisiez dans quel cadre?"
Je repond en detail puis lui demande l'air faussement interessé "Vous utilisez aussi Citrix alors ici?"
Le gars te répond NON

[DevArt]

« On reconnaît l'arbre à ses fruits »

Ok, sauf que beaucoup de développeurs viennent en se vantant de produit auquel ils ont à peine participé.

Comment savoir si il est réellement la personne qui a développé le produit qu'il présente, ou qu'il a juste participé occasionnellement développement ?

L'interview technique + 1 journée de test est pour moi la meilleure manière de pouvoir estimer le niveau d'un développeur, et sa capacité d'adaptation.

[DevArt]

Avoir un job ne signifie plus rien dans l'economie actuelle. Est-ce que la boîte a des revenus? (car certains sont en train de couler et vous payent avec des credits d'impots...)
Nombre d'effectifs techniques? j ai ete dans une mission ou y en avait 0...donc j'etais le seul informaticien.
Les clients et les projets? Pas ceux sur la brochure de 2011.

Avant, chaque entretien pour ma part c'est societe.com, et une série de question que je leur pose au téléphone avant même de prendre la peine de me déplacer.

- Nombre de teckos
- Volumétrie, charge
- Méthodologie de travail
- Fourchette de salaire (je me déplace pas pour un suivant expérience quand il s'agit d'un poste précis)

Il faut éviter la perte de temps et dans les 2 sens.

[Phelim]

Comme un maçon peut faire visiter un chantier en cours, un développeur peut facilement partager du code sur des plateformes comme github sur des projets assez simple.
Les écoles ne poussent pas encore assez dans ce sens, je pense que ça va venir.

Des environnements comme linkedin permettent d'avoir une synthèse consolidé beaucoup plus complète et accessible des compétences qu'un CV classique.

Alors oui, aujourd'hui, je pense que nous sommes entre 2 eaux. Les pratiques des RH sont en train d'évoluer, enfin c'est mon impression.

[Linunix]

Et vous ?

Jugez-vous avoir été une fois injustement mis à l'écart avec le processus d'embauche traditionnel ?

Que pensez vous alors de la vision de Jon Evans quand au processus d'embauche en entreprise ? Etes-vous d'accord avec lui ?

Oh hélas, Non.

Je suis complètement d'accord avec J.Evans, cette vision est totalement réelle, et devrait être appliqué partout.

En accord avec ses dires, je pense qu'on ne peut pas juger (juger ses compétences) quelqu'un pendant 10 à 20 minutes(voire plus)... il y a trop de facteurs qui jouent...

Le facteur du stress est le plus important, il peut conduire à une perte du contrôle du langage, une incompréhension des questions de l'interviewer, et encore...

[Franck.H]

Tiens tiens... je suis passé par là il y'a pas très longtemps donc je suis encore chaud

Je n'est pas eu d'entretien vraiment technique, c'était plutôt des questions sur ce que je faisait, ce que j'ai fait par le passé, ce que je connais en technologies (langages, plateformes, etc...). Par contre les tests ça oui j'en ai eu et c'est vrai que ça deviens vite démoralisant car souvent ce sont des sujets que l'on ne vois pas souvent.

Prenons un exemple pour mon cas personnel, j'ai eu 80% des tests sur les bases de données alors que bien sûr, le poste est Développeur .Net. J'ai eu une seule question concernant la programmation où je devais écrire une fonction (sur papier sinon c'est moins marrant) détectant les palindromes, pas compliqué c'est vrai

Par contre les bases de données j'ai morflé, c'est vrai, le poste traite surtout de l'informatique de gestion mais j'avais le sentiment qu'ils préféraient que je sois bon en SGBD et nul en programmation

Je pense que des tests permettent effectivement de bien différencier les candidats (par ailleurs j'ai eu le poste alors je vais pas me plaindre non plus) mais je trouve que souvent les tests ne reflètes pas les postes et demander de coder sur papier mais pité arrêtez quoi, qu'est-ce qui empêche de mettre un ordinateur portable sur la table pour écrire du code, c'est plus rapide et plus lisible.