L'interview technique est-il adapté pour les recrutements ?
Un développeur estime que cette pratique est ridicule et devrait mourir
Le 2013-06-28 20:02:17, par Cedric Chevalier, Expert éminent sénior
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 ?
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 ?
-
garhebMembre avertiLe 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.le 28/06/2013 à 21:45 -
LycheExpert éminentje 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..le 29/06/2013 à 0:38 -
JaroddMembre expérimenté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 mauvaisMais 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. le 29/06/2013 à 10:20 -
LaurentC33Membre habitué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..
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 évidentele 29/06/2013 à 8:59 -
thierrylerRédacteurLes entretiens techniques, quand ils ne sont pas conduits par des commerciaux mais par des vrais techos, ça se transforme souvent en cassage de candidat. Et quand le candidat s'en sort trop bien, ça fait peur et on ne le prend pas car il est trop dans la qualité. Arf... (histoire vécue)
Je viens justement de passer plusieurs entretiens techniques. Des QCM bidons qui ne testent même pas le niveau débutant. Mais aussi des questions hypers complexes du style "expliquez MVC en une phrase. vous avez 30 secondes"...
Tiens, un conseil que j'applique régulièrement. Quand on commercial me donne un QCM (ou un test) technique, il me laisse en général tout seul dans une salle pendant une demi heure, voire une heure. Et ben je peux vous dire que mon iPhone est mis à contribution à chaque question pour laquelle j'aurais le moindre doute, surtout sur les questions qui ont l'air trop simple ou qui demande de la culture hyper spécifique (genre quelle est la différence entre EAP1 et EAP2)... Faut juste faire gaffe à ne pas avoir tout juste et ne pas être trop bon de manière générale car les entreprises ont peur des bons profils... Vous vous dites que c'est de la triche d'utiliser Google en entretien ? Moi non, au contraire, car une fois engagé, ça sera un de mes outils principaux, avant même Eclipse...le 29/06/2013 à 21:06 -
thierrylerRédacteurMon idée du CRUD en 30-45 minutes n'est pas une mauvaise idée
Avec un pc sans internet, un serveur web, mysql (avec la base de créé), et la doc php en mode hors ligne
CRUD: Create Read Update Delete, (tableau de listage des enregistrements, formulaire d'ajout/modification/affichage)
Note: ce qui est important:
1. est-ce que le candidat estime avoir le temps de faire l'exercice, si non quel partie il pense avoir le temps de faire dans le temps imparti
2. l'application fonctionne t'elle à la fin ?
3. qualité du code (commentaire, nomenclature des fonctions/variables)
4. discussion au sujet du code fourni (ce qu'il améliorerait si il avait plus de temps...)
Quant à ne pas avoir accès à Internet, c'est encore plus crétin. En 2013, une boite qui n'a pas le Web, faut qu'elle se pose des questions. Je travaille connecté en permanence et je double check tout.
Après si vous voulez juste recruter un pisseur de code bidon, bah autant économiser mes 45 min, pour les passer avec mes enfants, et aller voir ailleurs où on fait de la qualité...le 01/07/2013 à 13:06 -
erwanlbInactifHeureusement 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.....le 29/06/2013 à 10:12 -
LycheExpert éminentêtre en situation professionnel est beaucoup plus révélateur des compétences d'une personne que lui faire remplir un QCM tranquillement posé derrière une table et un stylo.
Après, 1 semaine de test, rémunéré j'espère ^_^le 01/07/2013 à 12:05 -
LSMetagExpert confirméMouais...Quand tu dis que tu as bossé sur des projets en .NET 3.5 et 4.0, on te sert des trucs sur du .NET 1.0, complètement has been, que tu n'as jamais touché (car pas assez vieux) et dont les mécanismes sont assez différents.
Encore faut-il que le temps imparti ne soit pas taillé à la serpe, t'obligeant à faire à l'arrache une bidouille qui va créer d'autres problèmes par la suite...
Honnêtement c'est ça qui m'a fait arrêter les SSII. Tu peux très bien faire du code de qualité dans le temps imparti. Sauf que dans les boîtes où tu travailles pour une entreprise et non un utilisateur final, on te force à faire de la merde ! Tu leur signale des erreurs corrigeable en 15 minutes, ils t'envoient chier parce que personne ne s'est plaint...jusqu'à ce qu'ils se plaignent et où à ce moment les 15 minutes on les a pas forcément. Et évidemment, t'as souvent droit à l'"historique", fait de façon pourrie, ne satisfaisant pas les utilisateurs (performances, bidouilles à faire, bugs récurrents mais c'est comme ça...) et difficile à maintenir. Bref, quand un "client" décide à la place de ses utilisateurs, et ce avec une simple logique business, l'ambiance est pas top.
Je me souviens d'une fois où on nous a refusé une livraison : Pourquoi ? Parce qu'on avait multiplié par 3 les performances de l'appli et que ça n'avait pas été demandé...le 01/07/2013 à 13:11 -
el_slapperExpert éminent séniorFaut se méfier, des fois les réponses ne sont pas celles attendues.
"el_slapper, tu vas nous faire ce traitement en COBOL/MVS"
"C'est ballot, les données sont sous UNIX, les référentiels sont sous UNIX, nous fournissons le fichier final sous UNIX, et les transferts entre UNIX et MVS ne marchent jamais, ici. Ca va couter bonbon en maintenance. Et on a plein de gens comme Christine qui rêvent de faire du JAVA - et qui savent faire."
"Oui, mais le développement COBOL coute deux fois moins cher que le développement JAVA. La maintenance, c'est pas notre budget, c'est le votre, alors on s'en fout."
"Pauvre Christine...et pauvre budget maintenance."
2 ans plus tard, les transferts plantaient toujours régulièrement. Plus tard, en cours de management, on m'a appris que la MOA était une aberration purement française, parceque c'est donner bien trop de pouvoir au client. J'avais un exemple en tête tout trouvé pour illustrer.
Et, pour revenir au sujet, Christine avait été recruté suite à un test technique en Java. Pour, au final, faire du cobol. Et, contrairement à moi, elle n'aimait pas le cobol.
Pauvre Christine...le 01/07/2013 à 14:48