IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'interview technique est-il adapté pour les recrutements ?
Un développeur estime que cette pratique est ridicule et devrait mourir

Le , par Cedric Chevalier

297PARTAGES

4  4 
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 erreur dans cette actualité ? Signalez-nous-la !

Avatar de garheb
Membre averti https://www.developpez.com
Le 28/06/2013 à 21:45
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.
12  0 
Avatar de Lyche
Expert éminent https://www.developpez.com
Le 29/06/2013 à 0:38
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..
11  0 
Avatar de Jarodd
Membre expérimenté https://www.developpez.com
Le 29/06/2013 à 10:20
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.
8  0 
Avatar de LaurentC33
Membre habitué https://www.developpez.com
Le 29/06/2013 à 8:59
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
7  0 
Avatar de thierryler
Rédacteur https://www.developpez.com
Le 29/06/2013 à 21:06
Les 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...
8  1 
Avatar de thierryler
Rédacteur https://www.developpez.com
Le 01/07/2013 à 13:06
Mon 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...)
Ce que j'ai le temps de faire en 45 min : ranger mes affaires et me barrer. Car en si peu de temps, je ne peux produire que de la merde. 45 min c'est le temps qu'il me faut pour coder proprement le calcul de la suite de Fibonacci.

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é...
7  0 
Avatar de erwanlb
Inactif https://www.developpez.com
Le 29/06/2013 à 10:12
Citation Envoyé par mboudraa Voir le message
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.....
5  0 
Avatar de Lyche
Expert éminent https://www.developpez.com
Le 01/07/2013 à 12:05
Citation Envoyé par Luckyluke34 Voir le message
Je trouve que l'auteur se tire un peu une balle dans le pied avec ce titre "The Technical Interview Is Dead".

De loin on peut penser que poser des questions techniques c'est mal, et pourtant quand on regarde point par point ce qu'il propose, il y a de la technique à l'étape 1 et 5 du processus de recrutement, et même beaucoup de technique. Je ne vois pas trop en quoi faire du pair programming avec des éventuels futurs collègues sur un projet pendant une semaine n'est pas aussi une forme de "passer sur le grill d'un test technique", au moins au début.

Et dire "l'entretien technique est mort" quand on affirme d'autre part que les brainteasers (tests de logique générale) ne servent qu'à recruter des gens qui ne savent pas coder... mouais
ê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 ^_^
5  0 
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 01/07/2013 à 13:11
Citation Envoyé par pmithrandir Voir le message
En fait, on a un problème avec pas mal de gens qui postule...

Après, pour répondre aux questions... non, on n'interroge pas sur une techno que les gens ne connaissent pas.
C'est a ca que nous sert la fiche d'auto évaluation.

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.

Citation Envoyé par pmithrandir Voir le message

Par contre, pour les fan du projet technique, j'ai comme un soucis...

déjà, ca prend un max de temps... en plus, l'important n'est pas juste de livrer un code de qualité, mais de la faire dans le temps imparti. Voir un projet vitrine fait en 10 fois plus de temps que ce que je pourrais payer... bof
En plus, il va forcement y avoir pas mal de monde qui fera ce projet, et le gardera sous le coude pour 6 mois ou 1 ans... voir 5... pas super intéressant.

Pour les projets réels, c'est bien joli quand le projet est public, mais ca n'a jamais été mon cas... le projet a toujours été mis en place et inaccessible depuis le net. Et c'est toujours difficile d'estimer la part qu'a fait un développeur...
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é...
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 01/07/2013 à 14:48
Citation Envoyé par LSMetag Voir le message
Je l'ai fait d'une SSII (qui devait quand même s'occuper de la gestion de la signalisation d'une ville !)

Un nouveau projet en .NET en 2013.

- En quoi allez vous le faire ? => C#, .NET 3.5, Winforms
- Pourquoi ne le faites vous pas en WPF (remplaçant des Winforms) ? => Parce qu'on n'a pas les compétences.
- Heu... WPF ça date de 2008 quand même et on est en 2013, d'autant que les Winforms ne sont plus supportés par Microsoft => "mouche qui volent..."
Faut 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...
5  0