@clementmarcotte : 100% d'accord et je suis informaticien de formation (ayant l'age d'avoir connu word perfect).
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
@clementmarcotte : 100% d'accord et je suis informaticien de formation (ayant l'age d'avoir connu word perfect
Ce processus de recrutement a l'air assez élaboré par rapport à tout ce que j'ai pu voir jusqu'à présent, c'est à dire des entretiens trop focus sur le code, ou à contrario, trop focus sur l'humain.
Par contre, prenons du recul: ce genre d'entretien n'a de sens que s'il est appliqué à l'ensemble de la population d'une équipe, et pas seulement au dev. Et oui, je songe aux managers et autres CP non techniques, n'ont ils pas eux aussi leurs preuves à faire ?
Evaluaion technique ?
Je vais avoir le même besoin, sauf que ce sera sans doute avec un grand débutant... malheureusement, ce ne sera souvent qu'en période d'essai qu'on aura vraimentun retour.
Par contre 2 pistes :
- lui parler d'une problématique vécue qu'on a soit pas vraiment résolue soit dont on est pas super satisfait de la résolution (contournement...)
- voir s'il reconnait ses limites ou veut réinventer la poudre. Ex. nous voulons remplacer les codes à barres par des Datamatrix, vous saurez faire ?
Bref, faire comme tiple bite ! Après tout ce temps passé, vous aurez plein d'idées
Ce serait quand même ormal d'indemniser les candidats au-delà d'un simple entretien...
Faut surtout arrêter le délire d'évaluation des compétences - surtout quand on a des papiers d'universitaires.
A titre personnel après 5 ans d'études, qu'on viennent me faire des tests de première année (sur les threads par exemple, ou de l'orienté objet) c'est limite du manque de respect par rapport à notre formation.
J'ai déjà passé des journées complètes à faire des "tests" - ceci de manière non rémunérée. On a déjà fait de gros
Mieux vaut un développeur "moyen" qui soit super motivé, qu'une rock-star qui s'emmerde. Surtout que le développeur qui fait de l'excellent code va souvent en faire trop. Combien de fois j'ai eu des codes superbes (avec des interfaces partout), mais qui sont impossible à faire évoluer tellement le développeur a voulu trop en faire...
A titre personnel, j'évalue un candidat par rapport à son papier de base, son expérience. Ensuite est-ce que le job qu'on veut lui donner le passionne, est-ce qu'on peut lui donner ce qu'il a envie de faire? Mieux vaut un passionné qui est dans son élément, qu'une rockstar qui fait ce qui ne l'intéresse pas!
Est-ce qu'on va demander à un médecin de poser une perfusion pour l'évaluer? Est-ce qu'on va faire à un avocat un jugement de test? Il y a un dénigrement de la profession de développeur (au niveau des universitaires) qui est vraiment décevantOn a fait nos preuves en décrochant des papiers qui méritent d'être pris en considération.
Il y a sur-enchère de ces tests, et des certifications qui sont faites en quelques jours (Prince2, PMP, certifications java, Microsoft, etc..) par rapport à des formations de plusieurs années dans notre domaine. A la fin il faut arrêter ce délire ou il faut rémunérer cet effort d'évaluation du candidat avec le prix qu'on paye un consultant.... J'ai toujours donné mon temps gratuitement, payé mes déplacements, payé mon parking - ceci pour que des employeurs potentiels ne sachent pas se décider.
Le dénigrement vient, je pense, en partie parce que justement le papier sert à pas grand chosel, c'est franchement pas compliqué de l'avoir...Envoyé par gabriel.klein
Il y a un dénigrement de la profession de développeur (au niveau des universitaires) qui est vraiment décevant
Ah c'est sûr que les certifs valent pas plus. Le problème reste toujours là : comment on évalue dans un minimum de temps parce que ca coûte cher le recrutement!
Quand on voit les kilos de BAC+5 avec 4 ans de métier infoutus d'aligner 10 lignes de code(pas 11, 10), on comprend mieux la nécessite de tester. Et puis : recrute-t-on un footballeur juste sur son tampon de centre de formation? Non, on le prend à l'essai, ou on regarde ses performances passées. En informatique, à quelques exceptions près(open source), il est quasi impossible de regarder les performances passées. Et comme les gens détestent être pris à l'essai, on réduit la semaine d'essai du footballeur à sa plus simple expression : des tests techniques.
Qu'est-ce que cela peut-être agaçant de lire des raisonnements à l'emporte pièce de la part de personnes qui justement se targuent d'être des informaticiens de qualité (donc en principe rompus à la logique).Faut surtout arrêter le délire d'évaluation des compétences - surtout quand on a des papiers d'universitaires.
A titre personnel après 5 ans d'études, qu'on viennent me faire des tests de première année (sur les threads par exemple, ou de l'orienté objet) c'est limite du manque de respect par rapport à notre formation.
J'ai déjà passé des journées complètes à faire des "tests" - ceci de manière non rémunérée. On a déjà fait de gros
Mieux vaut un développeur "moyen" qui soit super motivé, qu'une rock-star qui s'emmerde. Surtout que le développeur qui fait de l'excellent code va souvent en faire trop. Combien de fois j'ai eu des codes superbes (avec des interfaces partout), mais qui sont impossible à faire évoluer tellement le développeur a voulu trop en faire...
A titre personnel, j'évalue un candidat par rapport à son papier de base, son expérience. Ensuite est-ce que le job qu'on veut lui donner le passionne, est-ce qu'on peut lui donner ce qu'il a envie de faire? Mieux vaut un passionné qui est dans son élément, qu'une rockstar qui fait ce qui ne l'intéresse pas!
Est-ce qu'on va demander à un médecin de poser une perfusion pour l'évaluer? Est-ce qu'on va faire à un avocat un jugement de test? Il y a un dénigrement de la profession de développeur (au niveau des universitaires) qui est vraiment décevant
Il y a sur-enchère de ces tests, et des certifications qui sont faites en quelques jours (Prince2, PMP, certifications java, Microsoft, etc..) par rapport à des formations de plusieurs années dans notre domaine. A la fin il faut arrêter ce délire ou il faut rémunérer cet effort d'évaluation du candidat avec le prix qu'on paye un consultant.... J'ai toujours donné mon temps gratuitement, payé mes déplacements, payé mon parking - ceci pour que des employeurs potentiels ne sachent pas se décider.
Il semble évident qu'il vaut mieux avoir "un seul bras" que "pas du tout". Et alors? Deux bras c'est mieux néanmoins.
Je ne vois pas pourquoi sur ce type de sujet, il y a toujours des personnes qui pensent être compétentes et en même temps ne semblent pas comprendre la problématique à laquelle tente de répondre ce type de démarche. Après tout si vous êtes comptétent :
- vous devez savoir que le diplôme ne veut plus dire grand chose. Des ingénieurs informaticiens qui ne comprennent pas grand chose à grand chose il y en a beaucoup...
- vous ne devriez avoir aucun souci avec la démarche d'évaluation puisque, sauf malchance, votre profil devrait sortir du lot.
Les sociétés qui ont besoin de développeurs de qualité - sans même parler de rock star - (ce n'est bien évidemment pas le cas de toutes les sociétés - certaines gèrent du bétail) sont confrontées actuellement à la médiocrité de masse en informatique et dans ce cadre, elles tentent d'élaborer des stratégies qui vont leur permettre de simplifier et réduire les coûts de la démarche de recrutement.
Si vous êtes rémunéré 45 000€/an, il en coûtera au minimum 90 000€ à l'entreprise qui vous embauche entre votre rémunération, les charges, les frais de structure, contraintes réglementaires, etc ... Je trouve cela limite "manque de respect" (pour reprendre vos termes) d'imaginer être embauché sans évaluation de compétences au regard de votre coût.
Pour déterminer la compétence d'un développeur, je ne vois que 2 possibilités:
- Le gars est connu et reconnu pour ses compétences (notoriété), et là il n'y a rien à faire (à part essayer de le convaincre), il vous enverra certainement sur les roses au premier test que vous lui mettrez sous le nez.
- Etre compétent soi-même (en tant que recruteur), un entretien en face à face (d'égal à égal) vous permets en quelques questions bien ciblées de vous faire une idée bien précise, à condition de maîtriser son sujet, ou d'accepter d'être surpassé par son interlocuteur. Sauf erreur de casting manifeste, 2 heures de dialogue décontracté me semblent un minimum pour se faire une idée, on oublie le CV, le diplôme et les expériences. Des gens qui blablatent en surface mais qui sont des coquilles vides se révèlent assez vite, des gens qui ne sont pas capables d'aligner 2 mots se montrent parfois étonnant lorsqu'on gratte au bon endroit et qu'on arrive à les mettre en confiance. Le but est de savoir si le candidat maîtrise les concepts inhérents au poste, s'il sait comment fonctionnent les choses, s'il est acteur ou spectateur de son domaine de compétence. A adapter bien sûr au poste en question.
Pour en revenir à ma petite personne, j'en ai passé des tas de tests "techniques" dans mes premières années en tant que professionnel du développement, avec globalement ce sentiment : à côté de la plaque
Quelques petits exemple de tête:
- Quand je créé un nouveau controlleur dans le framework Bidul celui-ci hérite de quelle classe (avec le nom exact du package) ?
- Que fait telle fonction de telle API dans tel Framework ?
- Que fait le code ci-dessous [...] avec 3 récusions imbriquées, et des variables appelées a b c d ...
- Comment s'appel le nouveau système de vue de la dernière version du framework ...
- Ecrire un algorithme qui permute les lettres des mots d'une phrase
Sans rire, ces exercices sont représentatifs du boulot de leurs développeurs au quotidien ?
A défaut d'évaluer la compétence terrain du développeur, c'est riche en informations (négatives) sur la société qui les fait passer.
Il y a une méthode certaine pour se planter dans ses recrutements : laisser un système automatique le faire à sa place.
@Kropernic
Tu trouveras un très bon article qui pourrait t'aider là: Guide de survie à l'usage des recruteurs
Merci ! Je vais lire cela
Pourquoi cela ? Le développeur lui il arrive lorsque le projet est spécifié et repart aussitôt que le développement est terminé. Après si le produit fini ne répond pas au besoin il faut s'en prendre au client qui n'a pas impliqué les utilisateurs finaux, au chef de projet qui à élagué certaines parties pour ne pas rogner sur la marge, à l'architecte qui a pondu une architecture inadaptée etc ... Il faut se réveiller car l'époque des services informatiques internes où les développeurs étaient aussi des experts fonctionnels proches des utilisateurs finaux c'est du passé. D'où l'importance pour le client de relire ses spécifications et de ne pas assumer que celui qui va réaliser le projet connais les habitudes et le métier de celui qui va utiliser la solution au quotidien.Étant avant tout un utilisateur final devenu développeur autodidacte, et en "évaluant" les développeurs en partant du produit fini, il me semble que personne ne pense à vérifier l'empathie des développeurs.
La programmation pure a de nos jour une image négative (On connais le terme pisseur de code dans les SII...) je me souvient d'une époque où si tu était programmeur tu étais vu presque comme une star du rock
La charge de travail augmentant, mon boss a décider d'embaucher quelqu'un pour bosser avec moi. Il s'est d'abord tourné vers une boîte de recrutement et donc entretient selon niveau d'étude etc... etc... Cela n'a rien donné de concluant. Je lui ai proposé de simplement faire paraître une annonce dans les journaux locaux et de m'occuper moi-même du recrutement (puisque après tout la personne doit bosser avec moi...). Etant autodidacte et ayant souvent travaillé seul, je n'ai pas une réelle vision de mon niveau en programmation. j'ai donc sélectionné une personne selon mes critères et avec ces simples questions : En quoi tu as déjà programmé ? Simple interprétation d'un organigramme. Détection d'une simple erreur de syntaxe dans un code. Ces trois questions passées j'ai ensuite soumis un problème au candidat. Ce problème inclus des éléments techniques qui sont à priori inconnus ou mal connus par lui et surtout (très important) par moi. je nous donne une heure pour bosser dessus à deux pour voir ce qui ressort... Et j'ai trouvé la perle rare : un programmeur avec de bonnes bases algorithmiques. Ce n'est pas un tueur dans un langage précis mais il est opiniâtre et finit toujours par trouver une solution pour obtenir exactement l'effet ou la fonctionnalité voulue. C'est à dire une personne qui sait transformer sa culture informatique en inventivité. Le tout c'est d'avoir la fibre et la rigueur... Après le reste n'est que littérature
EDIT :
Ou mais on y revient je crois. Et de plus en plus d'entreprises comprennent qu'il est bon d'avoir une petite équipe de dev sous la main. Moi ou je travaille, mon patron a vite fait le compte et s'est aperçu qu'il était plus rentable pour lui d'avoir deux ou trois développeurs multitâches sous la main que de louer les services d'une boîte d'informatique. Et tout le monde y gagne. j'ai un pote qui bosse dans une SII et il est très content de ne plus faire de code (c'est du travail de petite main pour lui), il est analyste fonctionnel (quel terme
C'est un peu la tarte à la crème, c'est quoi un développeur compétent ?
- un qui connait pleins de langages ?
- un qui sait lire un CDC et/ou dialoguer avec les clients ?
- un qui sait sortir une fonction en moins de 20 secondes ?
- un qui sait docilement s'insérer dans une équipe projet ?
...
De notre côté, on se pose la question depuis des années, et on s'est arrêté sur la même réponse que Triplebyte : un bon vieux QCM suffit pour apprécier, après c'est du face à face avec le recruteur...
A vrai dire, je n'ai aucune compétence dans ce domaine mais si je devais recruter un développeur, je m'attacherais plutôt à voir ses compétences en modélisation/organisation de code.
La capacité à écrire une sorte de "hello world" sans documentation ou répondre à un quizz (quoique je n'ai pas vu le quizz dont parle l'article) ne me semble pas représentatif des compétences nécessaires pour mener à bien un projet de bonne taille.
Par contre, il est assez simple de faire un petit modèle objet ou un petit algorithme sur une feuille de papier, de discuter d'architecture et d'organisation générale de code, de documentation, de tests unitaires et voir si déjà le candidat sait un peu de quoi on parle et dans quelle mesure sa philosophie s'accorde avec celle de la boîte.
Il me semble que la capacité à écrire un programme trivial en 45 minutes ne donnera que très peu d'information sur le niveau de la personne. Un peu comme si on demandait à une entreprise en bâtiment de construire une niche de chien pour la choisir dans le cadre d'un appel d'offre concernant un immeuble de 25 étages.
En effet, pas simple d'imaginer un "test" technique pour évaluer un développeur.
Ce que je ferais plutôt que demander à un candidat de réaliser un bout de code, ce serait plutôt de commenter un code existant.
Je prendrais un petit exemple en interne avec justement un ensemble représentatif de traitement, GUI, test unitaire, ....
Un exemple avec bien sur un peu de legacy et de "code qui pue" mais aussi avec des morceaux bien gaulés.
Je le laisserai étudier cela un moment (20-30 min) avec pourquoi pas un tableau blanc et un PC avec internet s'il veux.
Et ensuite on commente ensemble.
Cela devrait permettre de voir sa façon à entrer dans un code obscure, à être critique sur un travail donné, à connaître sa vision d’exigence qualité ....
Petit bonus: voir comment il réagi, après avoir bien critiquer ce code, en disant "En faite, c'est moi qui est développé cela!".
L'attitude d'un candidat face à une relation 'critique' à un supérieur (ici, un recruteur) peut être intéressant pour cerné aussi sa personnalité.
Intéressant aussi a mettre en parallèle s'il a critiqué le code ou le réalisateur du code, ce qui n'est pas pareil.
C'est exactement ce qu'on a fait pour les derniers recrutements dans mon équipe. Avec un taux de réussite étonnamment bas par rapport à ce qu'on attendait.
Certains candidats qui paraissaient bien sur papier et en entretien téléphonique n'avaient quasiment rien à dire sur du code pourtant assez pourri. Donc ça a plutôt servi d'énorme écrémage que de révélateur de talent. Je dirais que c'est un test de deuxième niveau sur une échelle de 1 à 3, le dernier palier étant la façon dont le candidat code lui-même. Ce n'est malheureusement pas toujours possible de le tester (manque de temps, crainte de la qualification en "travail déguisé") et de toute façon ces derniers temps sur une vingtaine de candidats à l'entrée, j'en ai rarement vu plus d'un sortir OK du deuxième stade.
Nous allons très prochainement recruter un nouveau collaborateur ici.
Vu qu'on développe en full stack (depuis l'analyse du MCD de la db jusqu'aux tests du produit fini), je pensais lui faire faire un petit exercice complet sur 1h de temps.
Un truc bateau du genre, faire l'analyse pour un soft de gestion de cabinet vétérinaire par exemple. C'est pas trop complexe pour pas que ça prenne 2 semaines mais pas trop simple histoire de voir s'il a les bases dans tout ce qu'on veut.
Vous en pensez quoi ?
Marrant que personne n'ait pensé à la meilleure solution pour évaluer un développeur...
C'est pourtant simple !
Sous couvert de lui proposer un "test technique" accompagné d'un développeur expérimenté dans la boîte (qu'on appellera bob pour la suite , on le met face à un projet codé VOLONTAIREMENT avec les pieds. Avec du code de daube, de l'anti pattern, l'application complète de toutes les mauvaises pratiques possibles et imaginables... Et non branché sur un référentiel de source (pour éviter qu'il puisse voir un historique ou qu'il commit quoi que ce soit)
Bob présente le projet tout pourri au candidat comme un projet terminé très important sur lequel beaucoup de personne sont passées, et lui dit que le défi technique est d'optimiser le temps de traitement et la charge mémoire. Bob devra rester extrêmement sérieux dans tout le process.
Important de dire et de préciser que le projet est terminé pour justifier du fait qu'on ne va pas utiliser son temps pour travailler réellement sans être payé.
L'idée, c'est de voir si rapidement le candidat est capable des éléments suivants :
- voir les énormités dans le code
- savoir expliquer pourquoi c'est des horreurs
- savoir expliquer comment mieux faire (sans trop en faire)
- savoir expliquer comment il compte s'y prendre pour le faire
- voir s'il le fait de lui même sans rien demander ou s'il demande s'il a aussi le droit de modifier plus profondément les choses
- savoir expliquer ce qu'il fait et pourquoi il le fait
- voir s'il va faire un commentaire sur l'absence de référentiel de source
- savoir résoudre le problème qu'on lui a demandé à la base
Bref, voir si le candidat a un esprit d'analyse technique suffisant par rapport à ce qu'on lui demande, voir s'il est capable d'expliquer les concepts sans qu'on lui pose des question scolaires ("Qu'est ce que le polymorphisme? Où trouver du polynectar pour atteindre cet état? Qu'est ce qu'une variable? Pouvez-vous expliquer le concept de réentrance dans un EJB stateless?"... A part le polynectar, j'ai eu toutes ces questions dans cet ordre dans un entretien...), voir s'il est capable d'échanger, de communiquer...
Mais sans lui dire qu'on va lui montrer un code volontairement pourri à améliorer (ne jamais révéler le but d'une analyse de ce genre si vous ne voulez pas que le résultat soit faussé)
Par contre, ça implique d'avoir quelqu'un de compétent techniquement qui soit lui même apte à communiquer...
EDIT : ce qui est à peu près la proposition de @Laurent 1973 un peu plus haut avec des trucs en plus... J'aime bien le twist de Bob qui avoue être l'auteur à la fin pour voir la réaction
Ben, si tu lui demandes juste de faire l'analyse, ça va pas tester toutes ses bases
Pour moi une heure sur un exercice ouvert à faire de bout en bout, c'est beaucoup trop peu. Il faut réduire le scope (genre demander de coder un petit bout d'algo plutôt qu'une appli entière) ou fermer la question : demander de faire une revue de et/ou améliorer un code déjà existant. Se contraindre soi-même à faire l'exercice avant en tant que recruteur est aussi un bon test de faisabilité.
Pas vraiment convaincu sur le côté "supercherie". Ca peut induire d'autres biais : le candidat peut ne pas oser critiquer du code ou du moins pas autant que s'il était au courant qu'il n'est pas réellement en prod, il peut essayer de trouver une cohérence et une logique là où il n'y en a pas et s'enliser dans des réflexions complètement à côté de la plaque... Ca m'est arrivé plusieurs fois, la pression de devoir réussir un entretien d'embauche implique souvent une baisse du sens critique, du second degré et de la capacité à penser hors des clous du candidat.
Répondre avec citation
Partager