…et quand je dis ça, c’est pour dire qu’ils devraient s’orienter vers n’importe quel travail qui soit loin, trèèès loin du développement informatique. Même la moindre macro Excel devrait leur être interdite.
Revenons un peu en arrière. J’ai déjà parlé plusieurs fois sur ce blog des comportements qui me font halluciner quand je fais passer des entretiens d’embauche.
Sur mes 12 années de carrière, je dois en être à pas loin de 10 ans à faire passer des entretiens. D’abord pour des stagiaires, puis pour des développeurs et par la suite pour des profils très variés.
Pendant longtemps, je faisais passer mes entretiens de manière très classique : je commençais par présenter l’entreprise, puis le candidat déroulait son CV, puis je posais des questions minutieuses sur ses expériences, pour enfin poser des questions techniques variées. Plus le temps passait, plus je me rendais compte que les entretiens se ressemblaient un peu trop ; à l’en croire, le candidat est à chaque fois un caïd faiseur de miracles ; en creusant un peu, je vois bien qu’il ne connaît pas la moitié des miracles qu’il est censé avoir fait ; sans parler des réponses parfois très exotiques à mes questions techniques…
Il y a quelques années, pour gagner du temps, j’ai changé ma manière de faire. Je commence dès le début de l’entretien par faire passer des petits tests techniques. Si ces tests se passent bien, on enchaîne (présentation de l’entreprise, déroulage du CV, questions-réponses). Si par contre le candidat échoue lamentablement aux tests techniques, je mets fin à l’entretien.
Cela peut paraître brutal, mais pour commencer je considère que mon temps est précieux (et si on regarde ma charge de travail, c’est une constatation, pas un fanfaronnade). Ce qu’il faut voir, surtout, c’est que les tests en question ne sont pas compliqués ; j’y vois un filtre me permettant d’identifier immédiatement les gros mauvais qui ne devraient pas vouloir être payés à coder.
Je ne vais évidemment pas dévoiler ici la teneur de ces tests (et je modérerais agressivement les commentaires qui le feraient). Mais sachez que je fais faire un test de programmation élémentaire, qui demande juste le minimum de logique algorithmique. En fait, je ne le vois même pas vraiment comme un test de programmation ; quand j’étais en école d’ingénieur, on l’utilisait pour expliquer la programmation à ceux qui n’en avaient jamais fait : «Vous connaissez les fonctions en mathématique, voici ce qu’est une fonction en informatique»
Et globalement, j’ai un tiers des candidats qui réussit le test sans problème ; un tiers qui sue sang et eau mais qui finit par y arriver ; et enfin un tiers qui échoue lamentablement d’une manière qui ne devrait pas exister.
Pour tout dire, j’ai déjà eu (trop) d’entretiens qui n’ont duré que 15 minutes, le temps de se rendre compte que le candidat n’y arrivera jamais, m’obligeant quelques fois à conclure en disant «Je suis désolé, monsieur, mais vous n’êtes pas informaticien».
Honnêtement, je n’éprouve aucun plaisir à dire ça à quelqu’un. Qu’il sorte tout juste d’école ou qu’il ait 10 ans d’expérience, je me sens toujours aussi mal. Mais soit le candidat se rend compte par lui-même qu’il n’a pas le niveau qu’il devrait avoir, soit il cherche des excuses ridicules ; et dans ce dernier cas, il me paraît parfois nécessaire de lui ouvrir les yeux.
Au cas où vous vous poseriez la question, j’affirme que cela ne dépend pas de la technologie utilisée. J’ai travaillé pendant 4 ans dans une start-up qui développait des services mobiles en Perl. Ce langage étant peu répandu en France, on recrutait de manière très ouverte, et on avait le même pourcentage d’échecs retentissants. J’ai travaillé pendant 1 an dans un environnement Java EE, et on ne recrutait que des développeurs expérimentés sur ces technologies ; et là encore, le taux était identique. Depuis 6 ans je recrute des développeurs PHP, et c’est la même chose.
Que faut-il conclure de ce constat préoccupant ? Je ne pense pas qu’il s’agisse d’un problème avec les formations. Même si elles se multiplient − pour répondre à un besoin sans cesse croissant − elles semblent continuer à fournir les mêmes quotas d’excellent, de moyens et de mauvais informaticiens.
Je pense plutôt qu’avec le temps, le nombre global d’informaticiens a été multiplié dans de grandes proportions. Et parce qu’on vit dans une ère de zapping, où il faut aller très vite (surtout dans les recrutements !), on tombe statistiquement plus souvent sur le fond du panier − qui est comparativement plus représenté parmi les chercheurs d’emplois que le haut du panier, allez savoir pourquoi.
Facteur aggravant de ce phénomène, c’est de moins en moins par l’expérience professionnelle qu’on peut faire le tri dans les candidatures . Il faut rencontrer les gens pour les juger ; plus le niveau recherché est élevé, plus cela prend du temps pour le vérifier. C’est la raison pour laquelle cela prend moins de 15 minutes pour identifier quelqu’un qui n’est même pas informaticien. Après, entre un informaticien moyen et un bon informaticien, ça prend plus de temps pour faire le distinguo ; mais c’est une autre histoire.
J’ai tire un peu les même conclusions. Ton test technique, tu le fais passer sur ordi, papier ?
Celui dont je parle dans l’article est sur papier. L’excuse “Je ne sais pas coder sur papier, je code mieux sur ordinateur”, pour une fonction de seulement quelques lignes, m’a toujours fait marrer ; c’est souvent le signe de quelqu’un qui se lance toujours dans le code sans jamais réfléchir à ce qu’il va coder…
Un peu comme ceux qui me disent “Ah oui, mais c’est des maths, ça fait longtemps que j’en ai pas fait !”, alors qu’il s’agit d’un test d’algorithmie basique.
Bonjour,
Je suis dans une école privée d’informatique BAC+5 et je ne peux m’empêcher de faire le lien avec ce que je vois tous les ans…
Ce genre d’école coute cher (~9k€/an) et malheureusement, avec de l’argent on peut tranquillement être diplômé…
Tout est fait pour assurer le passage au maximum :
– des rattrapages de fin d’année bâclés pour ceux à qui il manque des crédits (quand on ne leur donne pas l’examen barrage qui manque)
– un semestre de redoublement (vous refaites un semestre de l’année précédente)
– et seulement après tous ces dispositifs le redoublement (extrêmement rare)
Et combien j’en vois sortir en redoublant un semestre chaque année quand ce n’est pas l’année complète. Combien se laisse porter dans des projets de groupe qui leurs assurent de très bonnes notes…
Ces gens oui, devraient changer de métier…
Je ne suis pour ma part pas du tout surpris de ce constat. Je l’avais du reste fait moi-même depuis longtemps. Mais on peut le décomposer dans un premier temps en évoquant la signification du terme « développeur » qui est encore pour beaucoup un fourre-tout où on trouve aussi bien des vrais développeurs capables d’élaborer du code à partir d’une page blanche que des intégrateurs tout juste capables de lire un code existant pour arriver tant bien que mal à modifier des templates afin de personnaliser une application. Ces derniers doivent assez volontiers se croire développeurs après avoir réussi à déployer un Joomla en oubliant jusqu’à l’idée même d’ouvrir un peu le code et en se contentant de remplir le formulaire d’installation…
Il y a aussi ceux qui, fraichement sortis de formation, aspirent surtout à devenir chef de projet sans passer par la case développement, ou alors le moins longtemps possible, et en toucher le salaire rien qu’en donnant des directives. Et sur ce point, je me souviens d’un billet sur le blog de Mageekguy posant la question (je paraphrase de mémoire, je n’ai pas retrouvé le post) « Et si les développeurs aspiraient à rester des développeurs ? ».
Un autre élément que j’ai pu constater lorsque je fréquentais beaucoup plus assidument les forums de PHPFrance, c’est qu’il y a une proportion tout à fait consternante de gens qui manquent singulièrement de sens logique, et en informatique, c’est, me semble-t-il, tout à fait rédhibitoire.
En fin de compte, la méthode consistant à commencer par un filtrage avec un test technique m’apparait comme cohérente et tout le monde perd moins de temps, le recruteur d’une part qui ne s’éternisera pas sur une discussion inutile puisque sans suite, et le candidat qui disposera de temps pour s’améliorer s’il n’a manifestement pas le niveau souhaité.
Reste cependant la question du libellé de l’offre de poste qui pourrait peut-être avantageusement être formulée de telle sorte qu’elle serve de pré-filtrage en indiquant bien les pré-requis incontournables liés au poste proposé, et surtout en indiquant qu’un premier entretien commencera justement par un test technique sur papier : les comiques seraient peut-être moins tentés de faire perdre son temps au recruteur en allant se faire ridiculiser ?
@Thomas : On est bien d’accord.
@Cyrano : Ton commentaire est plein de bon sens.
Oui, un intégrateur n’est pas un développeur. Oui, le sens logique est nécessaire en informatique.
Concernant l’intitulé du poste, je me suis rendu compte que ça ne changeait rien, pour de bonnes et de mauvaises raisons.
– Mauvaise raison : Même en cherchant un « Lead developer » ou un « Développeur senior confirmé », on continue à recevoir des CV de personnes sans expérience. Ou pire, de personnes qui ont de l’expérience, mais qui ne sont toujours pas des informaticiens à mes yeux.
– Bonne raison : Quand je cherche un développeur, je veux quelqu’un qui a la tête bien faite (si elle n’est pas encore bien pleine, on la remplira ensemble, pas de soucis). Et ça, ça peut être n’importe qui ; quelqu’un avec des diplômes aussi bien qu’un autodidacte ; quelqu’un avec plusieurs années d’expérience professionnelle aussi bien qu’un geek qui n’a codé que des projets personnels. Ce serait dommage de rater la bonne candidature.
Car il y a une constante : Les gens se pensent toujours meilleurs qu’ils ne le sont réellement.
Ce billet semble directement inspiré de ce post de Jeff Atwood! (lui-même inspiré par d’autres, qui sont en lien)
@Bertrand : J’adore le blog de Jeff Atwood. Mais j’avoue que ce spot m’avait échappé (à moins que je l’ai lu puis oublié, il date quand même de 2007).
Merci pour le lien, ce qu’il y dit correspond effectivement à ce que j’ai expérimenté par moi-même.
Je tiens à préciser une chose tout de même par rapport au commentaire de Thomas : J’espère bien que les écoles d’ingénieurs dont vous parlez ne forment pas que des « développeurs »… Il existe bien heureusement d’autres métiers en informatique.
Et je pense que le concept de « 1/3 des développeurs devraient changer de métier » s’applique à bien d’autres métiers..
Personnellement, j’ai fait une école d’ingénieur en informatique et réseaux avec beaucoup de développement. On nous demandait d’apprendre beaucoup de choses, en très peu de temps. J’ai été classé dans le groupe des « nuls ». Rassurez-vous je n’ai pas eu mon diplôme mais j’ai beaucoup appris une fois intégrée en entreprise.
Aujourd’hui je sais que le niveau demandé en école d’ingénieur était très élevé et c’était surement mieux ainsi.
Je suis restée dans le domaine de l’informatique et je me suis orientée vers le métier de fonctionnel et testeur. Je ne fais pas de développement mais j’ai des connaissances techniques qui m’aident au quotidien, entre autre à faire de l’analyse de bugs, interroger une BDD…
Aujourd’hui, je suis responsable d’une équipe de test et je sais que je possède les compétences d’un ingénieur informatique. Je vais valider le diplôme via une VAE. Il va falloir que je justifie et que j’argumente sur mes expériences et mes compétences acquises/développées en entreprise.
Une petite conclusion après ce long récit : faire une école en informatique ne veut pas dire « être développeur ». Et des gens qui prétendent être « les meilleurs » : il y en a dans tous les domaines malheureusement.
On a l’avantage en informatique de pouvoir juger rapidement des connaissances techniques des candidats.
@ Cyrano : je pense que c’est une très bonne idée de préciser dans vos annonces, que le candidat devra passer un test technique : cela découragera les « comiques ».
@ Amaury : Bien souvent, ce sont ceux qui se la « pète » le moins qui sont les meilleurs. La modestie est une bien grande qualité. Faut-il encore savoir la détecter…
@Henrix : Mon propos porte bien sur les développeurs. Des gens qui sont censés être capables d’analyser un problème, réfléchir et trouver des solutions, être créatif, être rigoureux, savoir communiquer, etc.
C’est sûrement applicable à tous les métiers. Peut-être qu’un tiers des cuisiniers ne savent même pas reconnaître un œuf cuit d’un œuf cru, même après l’avoir cassé…
Avez-vous essayé Codingame ?
J’ai quelques collègues CTO qui m’en parlent en bien…
J’aime beaucoup ton commentaire avec l’image de l’oeuf cru… Car je pense que tu a raison!
Très bon post, cela rejoint mes constatations… Ici, aux US, l’entretien commence par 2h au tableau blanc, et c’est pas des problèmes faciles. T’es sensé, dans un boulot de dev sénior, pouvoir te démerder pour expliquer au tableau blanc ce que tu ferais. Cela demande un peu d’entrainement si tu ne l’a jamais trop fait en condition de stress, c’est sur, mais bon, t’es pas pris en traitre, tout le monde fait ça. Si ca passe pas, tu passes pas à la suite.
@Amaury: « Car il y a une constante : Les gens se pensent toujours meilleurs qu’ils ne le sont réellement. ».
Mouais… pas toujours. Personnellement je m’arrive pas à me décider à « tenter ma chance » sur des emplois de dev ou d’autres, malgré mes 15 ans d’expérience, parce que je ne suis pas du tout sur de moi, en tout cas pas assez sur pour affronter d’autres candidats fourbes et tchatcheurs dans ces recrutements de dupes ou les RH cherchent plus des buzzword sur un CV que des personnes.
Content de lire que ça ne se passe partout de la même manière !
Bonjour,
pour avoir fait passer quelques entretiens dans mon ancienne SSII, j’ai rencontré des développeurs expert sur le CV avec 10 ans d’XP qui ne connaissaient même pas les moteurs MySQL, ou qui n’avaient pas connaissance des index.
Dans la société dans laquelle je travaille actuellement, on découpe le recrutement en 3 entretiens. Technique, une journée de test et un entretien avec le boss :p
En ce qui concerne la journée de test, j’ai trouvé ça intéressant, aussi bien pour la société qui a pu juger mes compétences de manière plus complète que dans un entretien classique, et de mon côté ça m’a permit d’analyser pendant une journée leur manière de travailler.
@Henrix : Je n’ai jamais parlé d’école d’ingénieur 🙂 et la différence existe. Je suis déjà tombé sur des boites qui cherchaient des ingénieur, des vrais.
Quant à mon école, à part des développeurs je ne vois pas ce qu’ils forment puisque c’est tout ce qu’on fait.
Je suis curieux de connaitre la situation dans les écoles d’ingé.
@Kristof : Non, jamais essayé Codingame. Faudra que j’y jette un œil.
@Bob : Je peux t’assurer que la plupart des gens qui recrutent sont comme moi, à la recherche de développeurs qui n’ont pas la grosse tête, qui sont capables d’être productifs tout en apportant des idées, qui veulent s’intégrer dans une équipe (apprendre d’elle et la faire grandir en retour). On passe très vite à travers les buzzwords et les fanfaronnades, pour essayer de voir les vraies qualités des candidats.
L’humilité est une grande qualité. Cultive-la, mais n’ai pas peur de sortir de ta zone de confort.
@Guillaume : Je pense que je vais écrire un article pour décrire l’ensemble de mon process de recrutement, qui est assez similaire.
@Thomas : Dans les écoles d’ingénieur (surtout les écoles privées), les gars se font bassiner pendant des années sur le fait qu’ils sont les meilleurs, qu’ils font partie de l’élite… et certains finissent par le croire. Mais ça ne change pas grand-chose aux proportions de bons et de mauvais, au final.
@Amaury : « L’humilité est une grande qualité. » : c’est ce que j’essaye de détecter au cours des entretiens.
Après quelques échanges techniques avec le candidat, je lui demande d’évaluer son niveau en PHP sur une échelle de 0 à 5. Peu importe le niveau, mais ça me permet de vite voir si sa réponse correspond au personnage.
Et je lui propose ensuite un QCM assez simple pour confirmer là aussi son niveau et son auto-évaluation. Et les charlots sont rapidement démasqués.
Bonjour à tous,
Est-ce que tu appliques ce process de recrutement aux stagiaires également (test technique, auto-évaluation…) ?
@Thomas : non, pour les stagiaires, je reste sur un entretien technique et j’essaye de voir si le candidat a bien la tête sur les épaules. Généralement, ils n’ont qu’une petite expérience en PHP et ils ne sont pas censés se prendre pour des caïds. Même s’il est important de voir que les bases sont bien présentes chez le candidat.
« être créatif » … comment peut-on être créatif quand on a passer au minimum 15 ans dans un système qui ne le demande pas ? Je pense que c’est au niveau de la formation bien avant les premières années de spécialisation qu’il faut commencer à revoir notre façon d’enseigner.
Personnellement, le premier test se fait sur le CV en fonction de l’expérience :
– ancien poste
– sinon formation en alternance
– sinon projet opensource/perso
S’il n’y a rien de tout cela, je ne pousse pas plus loin. Le développement informatique étant ce qu’il est, il n’est vraiment pas difficile de se forger une expérience significative sans avoir travaillé véritablement. Mais bon, quand on sait que les centres de formation préfèrent mettre l’accent sur le niveau de diplôme ET le profil bien soigné linkedin/facebook, il reste visiblement un long chemin à parcourir.
Je pense enfin que la formation en alternance y compris en école d’ingénieur est une alternative vraiment crédible, en tout cas beaucoup plus que les « stages » Il est dommage de constater que ce n’est pas la voie royale de formation …. alors que c’est sûrement la plus efficace. Bon c’est vrai que depuis qu’on prends des +5 pour aligner du code, je comprends que les +3 soient un peu à la ramasse mais c’est peut-être au recruteur à revoir le façon de voir pour ne pas penser que diplôme … surtout quand le-dit diplôme est d’un niveau assez révoltant.
@Gabriel : Les stages seraient sans doute plus crédibles s’ils étaient majoritairement pris comme tel par des entreprises et non comme un système pratique de main d’œuvre à bas coût. Un stagiaire, par définition, est en formation, il n’a donc pas encore l’autonomie d’un employé « normal ».
Je suis donc tenté de dire que prendre des stagiaires en entreprise ne doit pas se faire de la même manière qu’on fait le recrutement d’un employé. L’idée fondamentale qui devrait théoriquement présider au choix d’un stagiaire est de préparer la relève. On s’attachera donc moins à ses compétences et qualifications réelle qu’à l’individu lui-même, à ses capacités intellectuelles, sa logique, son niveau de conscience professionnelle. Son niveau technique viendra avec la pratique et le stage est fait pour lui en donner les bases essentielles. Il va de soi qu’une entreprise sera réticence à prendre en charge un stagiaire franchement nul : même s’il est en formation, il est quand même sensé avoir un niveau technique de base, même s’il est purement théorique, la pratique lui permettra d’ajuster son apprentissage en mettant l’accent sur la réalité du travail quotidien et ça éclairera ponctuellement des aspects théoriques qu’il n’aurait pas compris en cours.
Mais en fin de compte, l’alternance est en principe du même ordre : les périodes passées en entreprises sont là pour mettre en pratique un apprentissage théorique.
Lors de l’embauche d’un employé, je me poserais probablement moins de questions sur ce qu’il faisait lors des stages qu’il a suivi que sur les entreprises au sein desquelles il a fait ces stages, histoire d’avoir une idée de la manière dont ces stages ont été fait, comment a été pris en charge son apprentissage : était-il suivi par un employé expérimenté en mesure de transmettre un savoir ou bien surtout occupé à la photocopieuse et à apporter son café au chef de projet ? En poussant un peu la caricature, je serais presque plus intéressé par le CV de son coach que par le sien 😉
Mais blague à part, avoir en main ses rapports de stage peuvent se révéler tout aussi intéressants : écrit-il correctement, est-il méthodique, est-il aussi concis qu’exhaustif dans sa prose ? Ce sont des éléments qui ont une importance au moins aussi grande que ses qualifications techniques.
My 2¢
Dans ma promo, j’observe qu’il y a une adéquation entre le niveau technique du stagiaire, son sérieux et la qualité de son stage.
Les élèves les plus sérieux, les plus talentueux consacrent plus d’énergie à la recherche de stage et, le cas écheant, à sa selection. Ils obtiennent les meilleurs stages alors même que leur niveau technique n’a pas été testé.
Les moins sérieux s’y prennent au dernier moment et saute sur le premier stage qu’il trouve, et là forcement il ne faut pas s’attendre à un stage très enrichissant
@gabriel : Quelqu’un qui a «passé 15 ans dans un système qui ne le demande pas», c’est quelqu’un qui a raté quelque chose dans sa carrière. Une carrière, ça se gère, ça se mène ; il ne faut pas la subir.
Les formations en alternance seraient beaucoup plus crédibles que les formations classiques (cours + stages) ? Tout dépend des entreprises où sont réalisées les alternances ! Une personne qui passe 2 ans dans une entreprise inintéressante, à faire toujours la même chose, sans apprendre ni évoluer, aura perdu son temps. Dans une école d’ingénieur, faire un mauvais stage de 4 à 6 mois est rattrapable sur le stage suivant. En plus, quelqu’un qui « se cherche » peut essayer des entreprises et/ou des postes différents d’un stage à l’autre, alors qu’une alternance engage souvent sur une longue durée dans un contexte figé (même entreprise, même poste). Dernier point, si on imagine que les écoles sont là pour enseigner quelque chose, on peut penser qu’elles enseignent plus de choses quand les étudiants suivent des cours pendant 2 ans, plutôt que lorsqu’ils suivent des cours une semaine sur quatre ou un jour sur cinq.
L’un dans l’autre, au final, quelle que soit la formation et le parcours (alternance ou pas, 2/3/5 ans d’études ou autodidacte, expériences professionnelles ou personnelles, geek qui code le week-end ou pas, …), j’ai vu tellement de profils différents que je peux dire qu’il n’y a aucune recette miracle. Les candidats, il faut passer du temps avec eux pour savoir s’ils sont bons, s’ils ont du potentiel, s’ils peuvent s’intégrer à l’entreprise et à l’équipe, s’ils sont capables de réflexion, s’ils ont de l’imagination tout en restant pragmatiques, s’ils savent communiquer à l’écrit et à l’oral, …
Et dès qu’on voit qu’il y a un mismatch sur un critère important, il faut économiser le temps de tout le monde.
@Cyrano : Pour ma part, j’ai toujours passé beaucoup de temps à former les membres de mes équipes, qu’ils soient stagiaires ou employés. C’est certain qu’on ne va pas attendre les mêmes choses suivant qu’ils soient diplômés ou non, de la même manière qu’on ne va pas attendre la même chose d’un gars avec 8 ans d’expérience par rapport à un autre avec un an et demi derrière lui.
Donc, dans tous les cas, il faut former la personne jusqu’à ce qu’elle est le niveau qu’on attend d’elle. Trop de managers oublient cet aspect et «les laissent se débrouiller» (ce qui veut dire en fait les laisser dans leur merde).
@Amaury : «Donc, dans tous les cas, il faut former la personne jusqu’à ce qu’elle est le niveau qu’on attend d’elle. Trop de managers oublient cet aspect et «les laissent se débrouiller» (ce qui veut dire en fait les laisser dans leur merde).»
Tout à fait vrai, mais j’irais plus loin : c’est en plus faire un mauvais calcul, parce que c’est également oublier que l’efficacité globale de l’équipe sera limitée par les plus faibles, (comme les maillons d’une chaine), donc si on laisse certains éléments dans la médiocrité, ça coûte à tout les autres qui doivent compenser pour aboutir à un niveau de résultat acceptable tant pour le client que pour la direction. Former du monde, ça coûte cher, mais c’est à voir bien davantage comme un investissement que comme une dépense.
Mais de ce fait, j’ai personnellement tendance à croire qu’il n’est pas obligatoirement pertinent d’avoir des stagiaires parce que le temps qu’il convient de leur consacrer ne sera pas vraiment productif dans la mesure où c’est à considérer comme un investissement à long terme sur l’avenir de l’entreprise (dans la mesure où il devient envisageable de recruter le stagiaire à l’issue de sa formation bien entendu).
Et puis je crois également qu’il n’y a pas que les employés qui apprennent, les managers ont aussi beaucoup à y gagner/apprendre sur d’autres aspects.
@Cyrano : Tout à fait d’accord. On est sur la même longueur d’onde 🙂
C’est entre autre la raison pour laquelle j’ai toujours considéré les stages comme de la pré-embauche (donc stages de fin d’étude uniquement). Le but est d’investir sur le long terme, comme tu l’as expliqué, pas de prendre quelqu’un pour s’occuper des tâches subalternes.
Hello,
très intéressants, malheureusement dans le sens inverse les déconvenue sont aussi du même ordre. Je suis occupé a me chercher une nouvelles places et le nombre d’offre qui ne veulent rien dire, ne donne aucune indication sur le profile (la personne en elle-même) est assez effrayant.
Personnellement, j’ai toujours été étonné qu’il y ai si peu d’entretien ou on ne fait pas passer des simples tests comme tu le dis,même si ces tests ne sont pas très clair cela permet aussi au candidats de se faire un mini idée de où il tombe. Personnellement, cela ma rassuré et m’a permis de me dire, ok ici au moins, j’aurais des collègue avec un minimum de truc dans la tête …
Bonjour,
Tout d’abord, j’aimerais remercier l’auteur de cet article, il est toujours intéressant d’avoir ce genre de retour.
Personnellement, j’ai un BAC+3 et j’ai un peu plus de 3 ans d’expérience professionnelle, ayant démarré dans une start-up j’ai très vite gagné des responsabilités jusqu’à devenir responsable infrastructure, j’ai ainsi côtoyé beaucoup de candidats ainsi que de collègues développeurs.
Je suis tout à fait d’accord en ce qui concerne le niveau des développeurs, je pense que ce problème est lié à deux aspects :
1/ Le candidat : on manque cruellement de passionnés, la formation ne peut pas tout vous apprendre, on vous donne la base et il appartient à chacun d’exploiter cette base et de la fructifier par un travail personnel. De même, il est important dans nos métiers d’être rigoureux en terme de veille technologique car cela évolue très vite.
Beaucoup de professionnels sont désintéressés, ils font leur 35h hebdomadaire pour encaisser leur chèque à la fin du mois et basta !
2/ Les entreprise : Oui ! Elles sont aussi leur part de responsabilité ! Lorsqu’on impose des délais très courts aux projets, que l’on force les développeurs à coder de la merde, il ne faut pas s’attendre à ce que les gens gagnent en compétences. Par expérience, je peux dire que 75% des entreprises génère du code pourri, mal pensé, difficilement maintenable et souvent pourvu de failles de sécurité.
Car on cherche trop la rentabilité, on demande aux gens de coder vite un truc qui « marchouille », on s’en fou de savoir si le code est évolutif, s’il a été correctement documenté et on fait parfois totalement abstraction de l’aspect sécurité.
Alors lorsqu’une personne a fait ses 10 ans d’expérience dans ce genre d’entreprises (et dieu sait qu’elles sont nombreuses), ce n’est pas étonnant qu’ils ne soient pas du niveau qu’on n’attend d’eux.
Le gros problème à mon sens n’est pas tellement l’aspect « logique », car la logique je pense que cela ne s’apprend pas, on l’a ou on ne l’a pas ! Le problème est énormément lié aux architectures et patterns, combien de développeurs maîtrisent réellement les différents design patterns ? (proxy, factory, singleton,… ), souvent ils ne maîtrisent même pas les aspects basiques de la POO (héritage, interface, ,…).
Et là encore, le problème est aussi lié aux entreprises, plus particulièrement aux fameuses SSII, qui vous proposent des candidats nouvellement diplômés comme étant des gens expérimentés, pire, il y en a même qui propose des stagiaires comme consultant.
Je ne m’attarderais pas non plus sur les salaires français, qui n’ont rien de motivant, ni sur les politiques de grille salariales qui sont totalement aberrantes.
@Nassim : Je suis globalement d’accord avec ton commentaire. Je vais juste apporter quelques nuances :
– Oui, on manque de passionnés. Mais j’ai aussi vu beaucoup de « passionnés » dont le niveau technique n’était pas cohérent avec leur passion et leur ambition (car bien souvent les deux viennent ensemble). Donc la passion est un critère important, mais pas suffisant.
– Ce que j’ai pu voir durant toutes ces années d’expérience n’a rien à voir avec la connaissance de design patterns ou d’autres modèles d’architecture. Ça s’apprend au fil de l’eau, ce n’est pas un problème. Je persiste à dire que le fait qu’un informaticien ne soit pas capable de transformer un algorithme basique en code fonctionnel est un problème bien plus fondamental !
– Les salaires français n’ont rien de motivant ? Honnêtement, dans l’informatique, on n’est pas vraiment à plaindre. Compare avec d’autres métiers comme infirmière ou sage-femme, cuisinier, journaliste ou relecteur, et tant d’autres… Après, tout dépend des entreprises sur lesquelles on tombe, évidemment. Mais c’est tellement facile de dire qu’on travaille trop et qu’on n’est pas assez payé, alors que nous sommes dans une profession largement épargnée par la crise par rapport à la quasi-totalité des autres corps de métier.
@Nassim, pour ma part je suis d’accord sur le côté passion
Par contre en ce qui concerne le second point (les entreprises nous force à faire de la merde), je ne suis pas du tout d’accord !
Je trouve ça lamentable les développeurs qui justifie d’avoir fait de la merde à cause du délai donné !! Le choix de bien ou mal développer n’appartient qu’au développeur !
@Amaury : Je ne pense pas qu’on puisse comparer le métier d’informaticien à celui de cuisinier, je travaille au Luxmembourg et quand je compare mon salaire à celui de collègues français, rien mais alors là absolument rien ne pourrait me motiver à revenir bosser en France sauf si vraiment on me propose un projet qui m’éclaterait !
Le Luxembourg n’est pas une exception, au Canada, les salaires sont aussi bien meilleurs. Mais bon, je suis d’accord que ce n’est pas là la cause principale du problème de compétences.
@Guillaume: Je ne suis pas de ton avis, souvent, le développeur n’a pas le dernier mot en terme de délais de développement, le business met la pression (après cela dépend du type de boite, il y a aussi des D.S.I qui ont la vie facile). Partant du postulat, qu’un gros projet c’est 50% d’analyse, 20 % de développement et 30% de test, si les délais sont trop courts fatalement la phase d’analyse va être bâclée avec les conséquence que cela apporte à la qualité du code.
Bien coder ne s’arrête pas pour moi à utiliser la bonne syntaxe ou les bonnes fonctions, bien coder pour moi c’est faire du joli code, du code propre, c’est-à-dire un code évolutif, facilement maintenable, une application bien structurée et bien pensée.
Le problème de compétence est peut être aussi lié au formations, que cela soit par sa qualité ou par le manque de spécialisation. Par contre, mon entreprise galère depuis des mois à trouver un bon DBA MySQL ayant une première expérience.
En ce qui concerne les tests techniques, je ne suis pas contre des tests d’algorithmie lorsqu’ils sont bien pensés. Personnellement, comme je recrute plus des sysadmin (mon métier) et des DBA que des développeurs, j’ai des tests techniques plus orientés.
« Bien coder ne s’arrête pas pour moi à utiliser la bonne syntaxe ou les bonnes fonctions, bien coder pour moi c’est faire du joli code, du code propre, c’est-à-dire un code évolutif, facilement maintenable, une application bien structurée et bien pensée. »
On est d’accord la dessus 🙂
Pour le reste, je suis développeur et bâcler un projet juste pour satisfaire le market, ou même mon patron je ne suis pas d’accord.
Car effectivement le projet sera en PROD dans les délais, mais les coûts en RUN seront énormes, et c’est le DEV qui va se prendre la tête au niveau de l’évolution du produit …
Bon quoi qu’il en soit ce n’est pas le sujet principal :p
@Nassim : Pour les salaires, je maintiens que les informaticiens sont chanceux et ne s’en rendent pas compte. Je ne connais pas le Luxembourg (mais j’ai l’impression que là-bas, ce sont un peu tous les salaires qui sont globalement plus élevés qu’en France), mais je peux parler du Canada : une fois que tu as pris en compte les assurances-maladies complémentaires qu’il faut prendre pour être au niveau de la France, que tu as posé 3 semaines de congés sans solde pour t’aligner sur les 5 semaines que tu as en France, et que tu as converti les dollars canadiens en euros, l’écart de salaire n’est plus si évident. Mais on est d’accord, un développeur payé 45 K€ en France sera payé entre 80 et 100 K$ à Seattle. Mais de là à dire que si on a des mauvais informaticiens, c’est à cause de ça, faut pas déconner.
Sinon, tous les informaticiens de la Silicon Valley seraient des génies (cf. le lien donné en commentaire par Bertrand => c’est loin d’être le cas).
15 ans = primaire + collège + lycée <= On ne gère pas de carrière à ce niveau là, on subit un système défaillant. On apprends pas à être créatif ni réfléchir, on enregistre des données puis on recrache aux examens. Fatalement, quand arrive la vraie vie, on est forcément pas vraiment préparé.
@Gabriel :
« 15 ans = primaire + collège + lycée …. On apprends pas à être créatif ni réfléchir »
Absolument pas d’accord : être créatif, c’est une nature, ça ne s’apprend pas. En revanche, ça se cultive pour peu qu’on ait l’esprit un tant soit peu éveillé à la base. Par ailleurs, l’école est en principe justement là pour accroitre les facultés de raisonnement, donc la réflexion. Malheureusement, ça ne signifie pas que cet enseignement soit systématiquement couronné de succès. Par ailleurs, c’est aussi à mon avis une question d’éducation, et là, la responsabilité revient aux parents, et soit un gamin est incité à créer, soit on lui fournit tout, on lui donne du tout cuit prêt à l’emploi sans qu’il ait besoin de se creuser la cervelle, ou encore on le laisse collé devant la télévision à regarder des insignifiances pour demeurés. Selon le cas, la créativité sera plus ou moins accentuée ou alors complètement éteinte.
My 2¢
Pour la candidature d’un profil expérimenté un compte github ou stackoverflow est trés révélateur du niveau et de l’implication du candidat.
@ghislainf : En théorie, c’est vrai. Maintenant, si j’avais dû recruter uniquement des développeurs ayant travaillé sur des projets libres et/ou participant activement à des communautés de codeurs, je serais tout seul dans mon équipe technique…
Pas toujours, et j’en suis un bon exemple ! ^^ Maintenant j’arrive à me dire que si on me donne quelque chose à faire c’est que j’en suis capable, mais lors de mes études je me disais parfois « je vais jamais y arriver ».
Concernant ce que tu disais sur le test papier, je suis entièrement d’accord avec toi. Cela fait 2 ans que je ne suis plus étudiante et plus d’un an que je travaille, et je continue à écrire régulièrement des bout de code ou de requêtes sur mes brouillons pour y voir plus clair. C’est tout de même la base de ce qu’on apprend au début d’un cursus de développeur ! Si on n’est pas capable de faire un algorithme simple sur papier, on ne sera jamais capable de coder un projet complexe sur PC.
Après, j’avoue ne pas avoir lu tous les commentaires. Mais sur l’article, même si ça peut paraître dur, je ne peux m’empêcher de penser que tu as raison dans ton raisonnement. Il est juste dommage que les écoles laissent des gens qui ne sont pas faits pour ça continuer dans une voie où ils vont forcément échouer. La reconversion professionnelle n’est pas une honte, et je connais beaucoup de gens qui ont fait des études pour continuer dans une voie totalement différente.
Merci en tout cas pour cet article plein de bon sens. J’imagine que ce n’est pas toujours facile, donc bon courage ! ^^
T’as une autre bonne technique qui est un petit peu employé dans la boite où je travaille. Enfin en tout cas, ça a été un des critères de mon recrutement et de celui de mon meilleur collègue/camarade/pote. Notre chef attendait de nous une présence en ligne déjà active. C’est à dire, un blog, un twitter, un github, ou un je ne sais quoi genre stackoverflow montrant qu’on veille (donc avec une présence régulière et un contenu/activité pertinents), qu’on partage, et donc logiquement qu’on apprend de façon régulière. Au départ, on n’est peut-être pas d’excellents codeurs, ni même juste bons, mais cette attitude de présence en ligne ne peut que nous amener à progresser, à rester à jour et à amener de nouvelles idées.
A priori, il ne regrette pas ce choix. Bien entendu le test technique papier fait aussi partie de l’entretien et permet aussi d’écrémer. Quand je suis amené à donner un avis sur un recrutement, je procède de la même manière désormais, cette approche me semble intéressante à défaut d’être la bonne.
Oui, là encore je suis d’accord en théorie, mais en pratique j’aurais raté mes meilleurs développeurs si j’avais utilisé ce genre de critère. Tout le monde n’a pas envie de s’exprimer sur le(s) réseau(x), même parmi les très bons développeurs.
Et j’ai vu passer pas mal de mecs qui racontent que de conneries sur leur blog ou sur Twitter, ou qui lancent des projets qui ne sont que des forks de projets existants dont ils changent juste un truc mineur sans intérêt… Là encore, il n’y a pas de solution miracle pour séparer le bon grain de l’ivraie.
Disons que ça montre quelque chose. Ça « donne des points » au candidat.
Ah oui, on est d’accord, faut pas être exclusif en faisant ça. Sur une équipe de 5 devs + un inté, on n’est que deux à avoir un minimum de présence en ligne. Ça ne fait qu’ajouter des points qui restent non négligeables si on les attribue avec pertinence. C’est sur qu’un fork pour corriger des fautes d’orthographes… Comment dire ? OSEF.
Sinon tu as la possibilité de former tes devs. Un de nos devs a été recruté à la fraiche sortie d’école et un autre est apprenti. Donc avec encore tout à apprendre. Notre chef se charge de les former, il a mis en place un système de formation mensuelle (auquel je participe activement et où j’ai été « intéressé »). Ainsi ses devs « s’améliorent ». C’est un peu simpliste mais j’ai l’impression que coté efficacité, c’est excellent pour avoir de bons devs.
Je n’ai hélas pas le temps de lire vos commentaires, mais le survol est très intéressant. Lorsqu’on a en face de soi quelqu’un qui ne comprend pas le binaire, les opérateurs, l’hexa et les structures conditionnelles, les chaînes de caractère, on ne peut que zapper.
A contrario les recruteurs, qu’ils soient de la RH ou même DSI, sont priés de ne pas exposer une science qu’ils n’ont pas et surtout de croire qu’ils ont la science infuse surtout quand elle est fausse.
Leur méconnaissance leur fait avoir des préjugés néfastes pour l’informaticien qui arrive à prouver sa compétence, et même la véracité de ses ‘miracles’..
J’ai été des deux côtés du processus de recrutement..
Pour être du côté recruteur depuis quelques temps, je ne trouve pas la tâche facile. Je me suis fait « berner » dans mes premiers recrutements : je ne posais pas de questions ou pas les bonnes questions. Un entretien, ça se prépare, que l’on soit candidat ou recruteur. Je l’ai appris un peu tard.. Je ferai mieux les prochaines fois.
J’ai fait passer mes derniers entretiens avec un membre de l’équipe. Cela aide beaucoup.
> @Guillaume : Je pense que je vais écrire un article pour décrire l’ensemble de mon process de recrutement, qui est assez similaire.
Je suis preneur.
Bonjour,
Dès la fin des années 90 avec mes collègues directeurs de projets nous avons fait un constat similaire : marre des entretiens avec des « cadors » qui sont incapable du dixième de ce dont ils se vantent.
Dès lors, tous les recrutés (dev, admin ,… même les CP) ont dû passer les tests techniques préalables. On ne fournit pas de papier crayon mais juste une session sur un ordi. Au menu des tests (limités en temps à 15 minutes), sur une session en ligne de commande sur un terminal Unix (editeurs textes disponibles type ed, nano, vi, emacs…)
Exemples d’enchainements :
– ecrire un programme court qui affiche le contenu d’un fichier texte, recours aux appels système interdits [5 minutes] (souvent lorsque le candidat est stressé on lui autorise plusieurs langages parmi C/PHP/Ada/… , sachant que le C est demandé)
– ajouter un utilisateur, changer les droits d’un fichier (setuid, et immutable) [5minutes]
– créer un enregistrement à partir d’un autre une base de données en une seule requete (insert /select) pgsql, mysql (base et enregs fournis). [5 minutes]
man disponible (huh huh)
Suite phase papier 5 minutes : 2 algorithmes : déterminer lequel est le plus rapide (avec souvent un algo qui foire sur les deux !). barbre/hash tables/etc au menu
Au bout de 5 minutes, élimination de 60% des candidats !!! 85% au bout de 15 minutes. 92% au bout de 20 minutes…
Sont dispensés de tout ou partie des tests, des codeurs/admin qui ont publié du code/livres notoirement identifié (il ne viendrait à personne l’idée de demander à RMS ou AC de passer un tel test).
En entretien, on a les résultats (temps, historique des commandes) on pose quelques questions pratiques. Et on peut passer à l’entretien traditionnel (ou pas).
ChrysM
Merci pour ce retour d’expérience. C’est intéressant.
Hello,
Pour apporter un peu sur le sujet : j’ai fait passer qq entretiens aussi, et écrit des tests (pour un poste de dév php et un poste d’intégrateur), qui sont de simples « petits » projets (réaliser un système de commentaire pour le premier et intégrer une maquette pour l’autre), Ceci sur un ordi avec choix de l’environnement, de l’éditeur, accès au net à la doc tout ce que tu veux, seul dans un bureau avec une heure environ et l’instruction claire et nette que le but n’est pas de terminer ou arriver à un truc fonctionnel mais de voir comment la personne fait. Parfois le projet était fonctionnel, parfois pas, mais ça permettait de voir quelques points : code procédural ou objet, utilisation de librairies/frameworks ou pas et comment, sécurisation de requêtes sql et échappement html, etc. Parfois le résultat était vraiment nul et illustrait simplement que la personne en face (pourtant parfois en poste dans une entreprise prestigieuse) avait le niveau de quelqu’un qui vient de lire un tutoriel de phpdébutant, et même pas jusqu’au bout. Ce n’est pas un problème pour moi si la personne en face reconnait que son niveau est un peu faible et est ok pour être formée par nous, mais des fois on a en face quelqu’un qui se vante d’avoir pondu le truc du siècle… difficile. En tout cas c’était très utile pour entamer une discussion concrète.
Le problème avec ça c’est que maintenant j’ai passé beaucoup plus d’entretiens, parfois dans de très grosses boîtes, et je sais ce que c’est que d’être stressé au point d’en perdre tous ses moyens et ne plus savoir quoi faire. J’ai beau avoir une bonne expérience en code, j’ai loupé lamentablement la moitié de mes tests d’embauche. C’est un fait à prendre en compte je pense.
D’autre part certains tests techniques sont d’une débilité profonde : référence à une culture geek qui n’est pas partagée par tout le monde, questions tordues, ou sans rapport avec le job. Par exemple j’ai eu droit à : « à quoi correspond l’adresse mémoire 0xCA32 (au hasard) » pour un poste de dév PHP (où on ne touche jamais à la mémoire directement). Ou autres trucs bizarres que j’avais jamais vu avant et je pense que ces questions précises sont un risque car si on a une expérience / connaissance d’un langage/techno elle sera toujours biaisée. Par exemple je suis quasiment incollable sur SQLite mais si on me pose des questions sur ODBC j’y connais absolument rien, mais si je devais bosser dessus je ferais comme tout le monde : je lirais la doc. Donc être trop précis me semble une mauvaise idée.
Enfin et pour terminer sur mes expériences passées, je me dois de rappeler que les journées de « test » avant embauche doivent faire l’objet d’un contrat et d’une rémunération, j’ai eu trop souvent affaire à des entreprises qui voulaient simplement que je vienne bosser gratos pour la journée. C’est illégal. Et de plus quand je suis déjà en poste ailleurs je n’ai pas le droit de le faire en général (dépend du contrat).
Et le dernier côté pas rigolo : dans certaines entreprises le test de code est sur ordinateur, en indiquant qu’on peut faire ce qu’on veut (aller voir de la doc sur le web par exemple), mais la session est espionnée par le recruteur. Une fois il m’a été reproché d’avoir été consulter la doc pendant le test (alors que c’était autorisé dans les instructions du test) et une autre fois j’ai surpris un VNC caché dans une machine de test. Je serais donc tenté de refuser la plupart des tests de code sur ordinateur pour ces raisons, sauf si je peux utiliser le mien.
@bohwaz : Commentaire intéressant.
Dans mon article, je n’ai parlé que du premier entretien. S’il se déroule bien, je fais passer un second entretien, avec un test de développement sur machine (et pas du code qui sera utilisé par l’entreprise).
Commencer directement par un test de développement me semble inutile (il faut déjà filtrer le tiers de mauvais). Je suis d’accord sur le fait que c’est l’approche qui est importante ; surveiller électroniquement ne sert à rien, il faut sentir le candidat en discutant avec lui, en allant le voir régulièrement pendant le test.
D’accord aussi sur le fait que la quasi-totalité des questionnaires techniques hyper-pointus ne sert qu’à flatter l’ego de celui qui les a écrits.
J’aurai été curieux de passer le test, juste pour savoir si j’avais une tête « bien faite » (je suis encore étudiant).
Sinon, je comprends tout à fait votre « tri » mais de l’autre côté du miroir on est obligé de vendre du rêve pour au moins passer l’entretien – et on nous forme principalement à ça en école privée – parce que la plupart du temps les RH n’y connaissent rien et se fixent sur nos diplômes, notre « e-reputation » et le design de notre CV !
Attention, je ne dis pas que tout est négatif là dedans 🙂 j’ai commencé à faire de l’open source pour remplir mon CV. Non seulement j’ai appris beaucoup, mais j’y ai pris du plaisir donc au final je crois que cette compétition peut être saine si les postulants essaient réellement d’avoir le niveau technique pour lequel ils se vendent.
Perso, si j’échouais à votre test je bosserai dur pour revenir le passer jusqu’à l’obtenir 😀
… on est obligé de vendre du rêve pour au moins passer l’entretien…
Je me demande si cette formulation est très heureuse. J’ai pour ma part tendance à dire que le CV est en quelque sorte une mise en bouche, un apéritif qui doit éveiller chez le recruteur qui le lit une envie d’en savoir davantage. Je me méfie du terme de « rêve » en l’occurrence parce que ça peut très (trop ?) rapidement déraper vers des affirmations trompeuses, ce qui serait la pire erreur à commettre sur ce genre de document, d’autant plus qu’en entretien, il sera difficile de présenter un discours cohérent sur la base d’un texte artificiellement gonflé par quelques
exagérationsenjolivures, fussent ces dernière élégamment tournées.J’ajouterai qu’il faut aussi toujours garder à l’esprit qu’en bout de course, ce sera un chef de projet ou un directeur technique qui supervisera notre travail et lui n’attendra pas du rêve mais du code propre, efficace, maintenable, etc… Et de ce fait, il ne faut pas essayer d’endormir un responsable RH, ce n’est pas lui la cible : lui est là pour filtrer sur d’autres critères comme l’état d’esprit, le caractère, les sens de l’organisation et/ou des responsabilités, et d’autres éléments qui auront également une certaine importance au quotidien en marge des qualifications techniques.
Tout à fait d’accord avec la réponse apportée. À part dans les SSII, ce ne sont pas les RH qui recrutent, mais des techniciens (directeur technique, chef de projet, etc.). Donc vouloir faire de l’enrobage est dangereux : si ça se voit pendant l’entretien, il ne va pas durer très longtemps (c’est toujours difficile de se projeter dans le futur avec un mec qui essaye de me bananer pendant l’entretien d’embauche) ; et sinon, ça se verra pendant la période d’essai, qui sera alors rapidement écourtée. Dans tous les cas, c’est une ignoble perte de temps pour tout le monde.
Donc non, il ne faut pas vendre du rêve. Par contre, il faut montrer que tu as la tête bien faite, que tu es motivé, que tu as envie d’apprendre des choses, que tu n’as pas peur de travailler, que tu es humble et que tu sais que tu ne sais pas, que tu peux communiquer et travailler en équipe.
l’idée d’un test semble bonne après j’ignore si je serais capable de le passer mais on me dirait après 15 ans d’expérience que je ne suis pas informaticien ou que je ne sais pas développer parce que je n’ai pas su écrire un bout de code sur papier qui n’a rien à voir avec ce que je fait habituellement me ferais doucement rigoler… Il y a de très mauvais candidats tout comme hélas il y a aussi de très mauvais recruteurs…
@nanme : Sous-entendre que je suis un mauvais recruteur alors que tu n’as pas passé le test peut aussi faire doucement rigoler. Pour le coup, si tu es incapable d’implémenter le plus simple des algorithmes (3 à 5 lignes de code max), cela prouverait juste que tu as développé « mécaniquement » pendant 15 ans, et que je ne me risquerai jamais à te faire développer des trucs complexes… 🙂
Bonsoir,
Je comprend bien le fond du problème et en effet la recherche du bon candidat est compliqué. Ce qui m’a choqué c’est «Je suis désolé, monsieur, mais vous n’êtes pas informaticien», vous leurs dites vraiment ça?
Ce n’est pas dure, c’est plus que ça, c’est rabaissant.
Ne pourriez-vous pas arrondir les angles est dire quelque chose comme « Votre profile est intéressant et les compétences que vous devez acquérir pour correspondre à notre culture d’entreprise nous demanderais trop d’investissement. »
C’est, à mon sens, moins dure et même plus juste. Pour rebondir sur vos conclusions, le problème fondamental, à mon sens, est en même tant ce qui rend notre métier intéressant. Tout change très vite, on capitalise très peux de nos expériences, et il faut bien prendre le temps de ce former sur une technologie qui pourrait, ou pas, devenir la plus demandée sur le marché. Du coup, il n’est pas humiliant d’entendre que l’on ne correspond pas au profil. On se dit juste qu’on c’est planté de voie.
@Zeppi,
il est vrai qu’il conviendrait de toujours garder son calme et formuler des réponses posées.
Cependant, il faut bien admettre que la proportion de charlots sur le marché est tel que ça devient rapidement très agaçant de voir certains guignols se présenter à des postes pour lesquels ils n’ont pas la moindre qualification. Et puis le candidat ne pourra pas reprocher au recruteur un manque de franchise s’il est très direct au lieu de faire du « politiquement correct »
J’ajouterais que le coté technique importe moins que l’état d’esprit. Si on tombe sur un spécialiste en C++ alors qu’on cherche un spécialiste en PHP, l’aspect technique présentera certaines lacunes, mais l’approche globale pour programmer reste sensiblement la même. Alors dans le cas où le « prétendu » spécialiste en C++ raconte surtout n’importe quoi et démontre dans son discours que quel que soit le langage il n’a pas l’esprit d’analyse et l’approche appropriée, il fait perdre son temps à tous les recruteurs qu’il va rencontrer.
Et enfin, s’il se fait remettre à sa place par un recruteur, je crois qu’il serait inspiré dans un premier temps de se remettre en question, surtout s’il avait au départ une bonne image de l’entreprise en question, entends par là qu’il voyait une entreprise qui recrute des bons quitte à les former (dans une certaine mesure bien entendu, l’entreprise ne formera forcément pas un débutant complet).
Je suis tenté de conclure en citant un truc dont certains candidats devraient s’inspirer : il vaut mieux dans certains cas se taire et avoir l’air d’une buse que de l’ouvrir et, ce faisant, démontrer qu’on en est réellement une 😉
My 2¢
@Cyrano,
En effet, vos mieux ce taire que de dire n’importe quoi. Je l’ai constaté quand j’ai eu l’occasion d’être de l’autre coté de la barrière. Le candidat, parlait, parlait, parlait et plus il parlait plus il s’enfonçait.
C’est certain que c’est agaçant d’avoir fait venir des guignoles et d’après l’article, Amaury ne semble pas enchanté, je cite « Honnêtement, je n’éprouve aucun plaisir à dire ça à quelqu’un ». Il est là, et il faut lui dire non, autant le faire de manière satisfaisante.
Peut-être qu’il a moyen d’améliorer la sélection à la source. Une idée comme ça, à la base le candidat doit envoyer un CV et ça lettre de motivation. On pourrait ajouter une épreuve type QCM sur internet avec inscription et adresse e-mail unique pour éviter ceux qui vont le recommencer 20 fois. Bon, c’est une idée perfectible mais peut être qu’on pourrait chercher ensemble une technique efficace.
@zeppi : (tutoyons-nous, ce sera plus simple)
«vous leurs dites vraiment ça?»
Oui, ça m’est arrivé. La plupart du temps, j’arrondis les angles comme tu le suggères. Mais il y a eu quelques fois où le décalage était tellement grand entre la présentation du candidat (le contenu de son CV, ce qu’il dit savoir faire et les expériences qu’il dit avoir) et la réalité, que j’estime que je lui rends service en lui disant la vérité.
C’est comme si je postulais pour être garagiste. J’ai beau savoir comment fonctionne un moteur à 4 temps d’un point de vue théorique, je suis incapable de changer une bougie ou de faire une vidange. Dans une telle situation, le garagiste me mettrait sur un moteur et me demanderait de lui montrer où est le bouchon de vidange. Devant mon œil vide, et en voyant la sueur perler sur mes tempes, qu’est-ce qu’il devrait faire ? Me dire gentiment que mon niveau d’expertise n’est pas tout à fait au niveau dont il a besoin, ou me dire la vérité, c’est-à-dire que malgré ce que je prétends il est impossible que j’ai été responsable technique d’un garage automobile spécialisé dans les voitures de luxe ?
Ensuite, je ne suis pas d’accord avec l’idée que l’informatique évolue tellement vite qu’on ne capitalise pas sur l’expérience.
J’y répondrai en 2 temps :
– Mon test ne concerne pas une technologie particulière. Le fait de pouvoir implémenter un algorithme élémentaire dans un langage démontre juste que le candidat a le minimum nécessaire (un peu comme de trouver le bouchon de vidange pour un garagiste). Le fait que je le demande en PHP ne devrait pas effrayer quelqu’un qui postule en tant que “développeur PHP”… même si j’ai accepté qu’on me fasse ce code dans un autre langage pas trop éloigné (C ou Perl, par exemple).
– Quand on fait de la programmation système et/ou réseau, les technologies utilisées il y a 10 ans sont toujours celles qui sont utilisées aujourd’hui. L’approche MVC n’est clairement pas toute neuve quand on développe des sites Web (et encore plus ancienne pour les interfaces “lourdes”). Les langages qu’on utilise au quotidien sont là depuis longtemps, et même s’ils évoluent tous, ils nous font manipuler des concepts qui existent depuis belle lurette.
@Amaury,
Il y a frustration à interviewer un candidat de la sorte, c’est très claire dans l’article et dans tout les sens du terme. Aucuns tests ou près-test ne nous préserve du profile, que je vais baptiser, mythomane. Et dans le cas précis du mythomane, quoi qu’on lui dise il le prendra comme il veut.
Il y a le profile stressé, compétant mais incapable de soutenir une interview. On a beau le mettre à l’aise mais rien. Ce profil là, on ne lui rend pas service en le cassant de la sorte.
Il y a le profile vagabond, « j’ai vue de la lumière et je suis rentré ». Comme le mythomane quoi qu’on dise ça va pas rentrer.
En fait, je ne vois aucun avantage a réagir de la sorte.
Sur le sujet « on ne capitalise pas sur l’expérience »,
Un exemple, j’ai commencé ma vie professionnel en connaissant les bases du langage C et un peu de C++. C’était en 1997. Mais pour l’occasion je développais sur un logiciel nommé Director (de la société macromedia) avec sont langage Lingo. Un an après je pouvais me considérer d’un bon niveau, mais voilà que Director est mort. Que dire du temps passé à étudier Director? Le ratio temps/capitalisation est-il bon?
J’ai appris plein de chose avec Director, mais rien qui m’ait servi pour la suite.
Les fondamentaux sont nécessaire mais de loin pas suffisant dans le monde professionnel. A contrario, on arrive souvent a évoluer dans le monde professionnel sans les fondamentaux. Le résultat sont les horreurs que je dois débuguer, mais c’est la vie…
Ceci ne remet pas en question le test que tu propose, ça explique pourquoi on trouve de tout et de rien comme candidat. Et c’est encore plus vrais dans l’univers de PHP. Je connais de très bon développeur Joomla, mais je sais qu’il ne capte rien au fondement du modèle objet. Si ces personnes voit développeur PHP il se dise « c’est bon ». Potencier a énormément contribué en publient Symfony, et en même temps il a contribué à faire croire au dev. qu’il comprenne la notion d’objet. Alors qu’il ne font qu’appliquer les recettes. PHP est une technologie à part. Sur .net ou java tu trouverais moins de déchet car ces technos sont plus strict et imposent une certaine compréhension des fondamentaux.
Je vais peut-être dire quelque chose qui a tout d’une banalité à ce détail près que justement, c’est tellement banal que ce n’est en réalité jamais formulé.
Lorsqu’on procède au recrutement de quelqu’un, il y a du coté du recruteur un devoir absolument indispensable : cerner le besoin et exprimer de façon aussi claire et concise que faire se peut le profil qu’on recherche. Il y a de ce point de vue beaucoup de lacunes sur toutes les annonces proposées sur le marché et c’est valable dans un nombre incalculable de domaines : le demandeur sait en général ce qu’il veut, mais il est le plus souvent incapable de formuler son besoin correctement. Ça donne lieu à des offres parfois incomprises par ceux qui sont à l’affût desdites offres et, pour peu qu’ils soient en plus de simples beaux parleurs, on aboutit à des entretiens qui n’auraient tout simplement jamais du être. Cela dit, il n’en demeure pas moins que l’informatique dans son ensemble reste un domaine où certains s’imaginent qu’ils sont des spécialistes parce que la veille, ils ont le matin acheté un ordinateur tout neuf dans une grande surface, à midi elle était branchée et connectée au réseau, en milieu d’après-midi ils avaient téléchargé un Joomla ou un WordPress, avec un peu de bidouille, l’interface visuelle avait été intégrée et le soir, un nouveau site était en ligne : il n’y a pas là de quoi fanfaronner en se « faisant péter les bretelles », c’est presque à la portée de n’importe qui et ça ne fait pas de l’individu concerné un informaticien. C’est comme si on faisait de moi un laboureur parce que j’ai conduit un tracteur agricole auquel était attelé une charrue quadrisoc réversible, le labour requiert un minimum de connaissances.
L’informatique, c’est pareil. Donc envoyer bouler de façon un peu rude un comique de boulevard qui se la pète, ce n’est jamais dans l’idée de le rabaisser ou de l’humilier, même si les apparence, vues d’un coté politiquement correct, c’est justement le cas.
Imagine par exemple ceci : si ton fils se vante de quoi que ce soit de façon injustifiée et que tu lui mets le nez dans sa moutarde, tu ne trouveras pas ça humiliant pour lui parce que tu ne feras pas ça dans ce but, le but étant précisément de l’inciter à un peu de modestie, mais lui risque fort de trouver ça particulièrement difficile à avaler. Il y a (et il doit/devrait toujours y avoir) dans le reproche une incitation à l’amélioration et un coté pédagogique. Ce n’est pas plus facile pour celui qui se trouve dans la position d’autorité (attention, entre « autorité » dans le sens « faire autorité dans un domaine donné »
Reste que dans le cas d’un recruteur, c’est du temps donné à classer en perte brute dans le compte « pertes et profits », et je n’en connais pas un seul qui soit disposé à perdre du temps de cette manière, ce n’est pas sa vocation, celle-ci étant le plus souvent réservée aux écoles… CQFD …
😉
@Cyrano,
« Je vais peut-être dire quelque chose qui a tout d’une banalité », mais c’est exactement ça. L’univers de PHP est rempli de ce type de profile.
Si je reprend l’exemple du rapport père fils, pour moi mettre le nez dans le caca dans le style de l’article. C’est l’équivalent de mettre deux bonnes baffe à notre fils. C’est l’expression d’une frustration et on la justifie par l’éducation.
Poser une seule question algorithmique ne suffit pas. Quand tu as peu de temps, soit tu connais l’algo ou un algo proche soit tu connais pas et tu pourra pas répondre.
Moi je passerai à des tests généraux sur l’info: framework, design pattern, corriger un bout de code pour qu’il compile. Cela permet surement d’éviter les incapables et c’est suffisant.
Ne pas connaître comment faire une méthode fibonacci par exemple ne doit pas être un facteur d’exclusion. Après c’est dans la période d’essai qu’on voit la capacité du développeur.
@Titus : Tu n’as pas bien lu. Je donne la définition mathématique de l’algo. Ce n’est pas une question à la con dont soit tu connais la réponse soit tu sèches. C’est un test permettant de voir si le candidat est capable de traduire en terme informatique un énoncé simple (car le test est simple) et clair (difficile de faire plus clair qu’une définition mathématique, il n’y a aucune zone d’ombre).
Poser des questions d’ordre général sur l’informatique, comme tu le suggères n’est pas suffisant. Je le fais aussi, évidemment. Sauf que je peux embaucher des gars qui n’ont jamais utilisé un framework mais qui ont le potentiel d’apprendre (même si je préfère embaucher des gens ayant un minimum d’expérience sur un framework, n’importe lequel). Par contre, un gars qui a des années d’expérience sur tel ou tel framework, mais qui échoue à mon test, c’est un gars qui a survolé le développement web, et qui sera incapable de faire le moindre développement où il faut réfléchir un tant soit peu.
Tu prends l’exemple de la suite de Fibonacci. Mon test est plus simple que cette suite, mais pourquoi pas. Si je te donne la définition mathématique de fibo, tu dois être capable de m’écrire le code correspondant. Sinon tu n’as pas compris le principe de la récursion, tu seras incapable de faire le moindre calcul de statistiques, incapable de réfléchir aux relations entre des entités multiples.
Je suis tenté d’aller plus loin :
Je ne suis pas du tout d’accord avec cette assertion. Elle dénote au mieux une incompréhension de ce qu’est un algorithme. Or justement, un algorithme, c’est la décomposition logique en problèmes simples d’un problème complexe. En d’autres termes, c’est décomposer un problème complexe en un nombre indéterminé de problèmes à réponse binaire. À la limite, tu n’a même besoin d’aucune connaissance en informatique : tu es logique ou non, point barre. Si tu es logique, tu vas « naturellement » isoler les éléments nécessaires à la résolution du problème.
L’exemple typique que je donne à des non informaticiens qui me disent « je n’y connais rien en informatique » est le suivant : si tu veux préparer des frites, tu vas naturellement sans même y penser consciemment te poser une succession de questions; Est-ce que j’ai des pommes de terre. La réponse est binaire, si c’est « non », je me tournerai vers une alternative, sinon, question suivante, est-ce que j’ai de l’huile, là aussi la réponse est binaire, est-ce que j’ai un couteau pour éplucher mes patates, etc, etc.. c’est ça un algo, il ne faut pas chercher ailleurs et ce n’est pas du savoir, c’est de l’intelligence. À quelques exceptions près, un algo ne s’apprend pas, il se crée.
My 2¢ 😉
Je ne peux pas m’empêcher de lier ce sujet à cette illustration dont l’encre semble à peine sèche… Ah la poésie de certains CV 😀
Je ne peux pas m’empêcher de lier ce sujet à cette illustration dont l’encre semble à peine sèche… Ah la poésie de certains CV 😀
Malheureusement c’est souvent le cas …
Très bon 🙂
Assez d’accord avec ce post, mais d’un autre coté c’est assez logique.
Les bons informaticiens sont généralement assez vite engagé (la problématique reste cependant de les gardé 😉 )
Personnellement, je bosse depuis 9 ans dans l’informatique et ça fais 9 ans que je n’ai pas cherché de boulot. (j’espére etre en haut de la pile 😉 )
Votre test « avant entretien » est a mon avis une bonne stratégie. Contrairement au grosse boite qui propose un salaire en fonction du diplome, sans prendre en compte les réelles compétences.
Bonsoir,
Je relance le topic que je trouve intéressant, vos argumentations sont épurées, structurées.
Cependant, je constate que vous avez presque tous une pensée décomposée de manière binaire « si, le candidat n’est pas capable de m’expliquer un algorythme de base, je ne lui confierais pas quelque chose de plus complexe. »
Cette pensée est logique, mais tout résultat logique est issu d’un conditionnel ou suite de conditionnels.
Ce qui implique que pour faire démonstration d’humilité (ce que vous reprochez au peuple des mécréants), vous devez vous même faire preuve de logique tétravalente (« je suis arrivé 1er en caisse, donc logiquement je passe 1er, mais parce que cette personne a moins d’articles que moi, je peux briser la logique de base. »).
Exemple concret: « Eric est électricien dans le bâtiment, il installe le réseau électrique complet des habitations depuis 20 ans, pourtant Eric, ne connait rien au fonctionnement interne d’une ampoule (matériaux utilisés par les filaments etc…), il ne saurait pas expliquer quelle est la particularité technique des ampoules basse conso, mais Eric est reconnu dans son métier car il excèle dans la créativité de ses architectures ».
Refuser un poste à Eric sur le simple fait qu’il ne sache pas comment fonctionne une ampoule de manière technique est absurde et révèle plutôt une pensée limitative du recruteur qui n’a pas su employer une dimension tétravalente au recrutement pour juger idéalement des qualités du candidat.
Donc, je comprends votre point de vue, mais ne vous limitez pas au simple résultat logique.
Puis, même si votre but est de faire évoluer vos candidats en étant sec (humiliant) avec eux, souvenez-vous que Hitler a exclu dans sa perception mémorielle, les juifs de la racine humaine pour une raison d’infériorité, vous venez de faire la même avec certains développeurs, mais d’une autre façon.
Trouvez plutôt le moyen de les motiver d’une manière positive à exceller si vous voyez qu’ils n’ont manifestement pas le niveau, la plupart ne savent pas qu’ils n’ont pas le niveau car ils n’ont pas encore vus meilleurs qu’eux.
Faites celà, vous deviendrez vous aussi plus humble, promis :).
@Edd : J’avoue que je commence à être fatigué de me justifier.
Que ce soit clair : Je ne suis pas sec ou impoli ou méchant avec les candidats. Et il m’est arrivé dans quelques rares occasions de dire à quelqu’un qu’il n’était pas informaticien, parce que c’était une simple constatation ; il n’y avait rien de méchant là-dedans, et je pense qu’il vaut mieux aider une personne à s’en rendre compte plutôt que de la laisser croire qu’elle a la moindre qualité pour un job donné.
Si je postulais pour être commercial, un recruteur me dirait que je n’ai rien à faire à ce poste, et il aurait raison.
En l’occurrence, votre parallèle avec un électricien n’est pas bon. Pour faire une vraie comparaison, imaginez plutôt que vous cherchiez un électricien pour refaire toute votre installation électrique, et que le candidat n’est pas capable de brancher une ampoule, et qu’il vous répond que ce n’est pas de sa faute, que les bornes “+” et “-” sont mal indiquées…
Là c’est pareil. Je ne demande pas aux candidats de m’expliquer ce qu’il se passe à l’intérieur d’un microprocesseur, ou de me dire quelles sont les instructions appelées en assembleur (ce qui serait l’équivalent de votre «connaître le fonctionnement interne d’une ampoule»). Je lui demande d’implémenter un algorithme ultra-simple ; s’il n’est pas capable d’y arriver, je persiste à croire qu’il aura du mal lorsqu’il devra implémenter des algorithmes bien plus complexes − ce qui constituera l’essentiel de son travail !
Enfin, me comparer avec Hitler est tellement… je ne sais que dire. Bravo.
Finalement, l’idée est de recruter un mec capable et compétent. Et non un bricolo. Tout le monde est capable de changer une ampoule à partir du moment où il l’a fait une fois. Donc tout le monde pourrait être électricien (j’ai connu mes heures de gloire après avoir changé un néon une fois au boulot). Il en va de même avec le web. Si on te montre un outil genre DreamWeaver, oui, tu pourras faire un site web et même le publier. Et d’ailleurs, si t’es pas mauvais, t’arriveras même à faire un beau site, ergonomique et responsive, mais tu n’auras pas touché au HTML ou qu’à quelques détails. Ça ne fait pas de toi un développeur, juste un bricolo. Bricolo peut-être doué mais un bricolo quand même.
Toujours sur le même sujet, j’ai reçu un autre commentaire. Comme il était anonyme, j’allais le supprimer ; mais je vais vous en faire profiter :
Je remercie cette personne, ainsi que tous les autres ayant posté des commentaires du même acabit..
Vous avez évidemment raison, et je ne peux que vous inviter à créer une entreprise et à embaucher n’importe quel énergumène qui postule chez vous. Comme cela, vous participerez activement à l’amélioration des chiffres du chômage en France.
Du moins, jusqu’à ce que votre entreprise mette la clé sous la porte.
Aucun de vous ne semble s’être retrouvé face à une personne qui vous explique qu’il a eu un parcours exemplaire, qu’il est incroyablement bon, qu’il a sauvé des projets techniquement mal engagés, qu’il abat à lui seul le travail de 5 développeurs… et qui est incapable d’écrire le moindre bout de code qui tienne la route.
Mais, encore une fois, vous devez avoir raison. Une entreprise est une organisation philanthropique, et il faut être gentil et embaucher tous les mythomanes qui sont informaticiens uniquement dans leur tête. Après tout, la seule qualification à avoir pour être informaticien, c’est d’avoir un diplôme et des factures à payer, hein ?
Vous êtes mignons (oui, là je suis condescendant, c’est voulu).
Sur la question de l’humilité, je ne pense pas avoir besoin de recevoir de conseil, j’ai déjà montré bon nombre de fois sur ce blog que je reconnais mes limites et que je sais faire appel aux connaissances des autres.
Et quand j’explique à quelqu’un qu’il y a erreur de casting sur un entretien d’embauche, je lui donne des conseils. Oui, cela concerne le gars qui n’est pas informaticien contrairement à ce qu’il croit, mais aussi ceux qui se sentiraient manifestement mieux dans une plus grosse entreprise, ou sur un business différent. Je préfère passer une demi-heure à donner des conseils de gestion de carrière, plutôt que de passer le même temps à faire passer un entretien d’embauche qui ne sert à rien.
@MathRobin : On est d’accord. Mais fait attention, tu vas te faire traiter de dictateur sanguinaire 😉
@Amaury: Je comprends un peu mieux le sens de votre post, la personne qui a soulignée le facteur chômage est totalement hors course.
Une entreprise n’est pas une association, et un poste à pourvoir ne peut être soumis à mendicité, c’est une réaction qui vise à rejeter la faute sur autrui plutôt que de se remettre en question personnellement pour évoluer, nous avons affaire là à un pur problème de détresse humaine dans laquelle le posteur est seul responsable de sa situation.
@MathRobin: Evidemment, il y a différence entre bricoleur et développeur, c’est une évidence.
La qualité première d’un développeur est avant tout de réfléchir à des solutions à un problème, et on ne peut réfléchir à des solutions si l’on est incapable de comprendre les causes du problème, c’est pour çà que je suis contre tout copier/coller de code ou logiciel qui neutralise les facteurs cognitifs chez un développeur.
Ma comparaison est sans doutes mal choisie, mais je n’ai aucune représentation visuelle du test que vous demandez et comment elle peut être assimilée à l’expérience d’un développeur (si cette connaissance est capitale ou pas en fonction du vécu pratique).
Donc, tout ce que je voulais souligner est, la violence de vos propos vue d’un oeil extérieur.
Peut-être est-il plus sage de ne pas réagir « à chaud » dans un espace public contre un individu ou un groupe d’individus..
Il nous arrive tous de réagir à chaud comme celà, (facebook, rue, etc), les résultats escomptés sont dans la majorité des cas, loin de notre motivation première… Améliorer les échanges, le savoir…
Enfin, Ma comparaison (avec un dictateur) était sans doute un peu forte, mais d’un oeil extérieur, purement extérieur, l’analogie est indiscutable, vous isolez une « population » dite faible pour les extraire d’une communauté. Je le répète ce n’est que d’un point de vue externe.
L’analogie est forte, mais faite pour vous faire réagir… JE SAIS en âme et conscience que vous êtes logique et pragmatique (votre argumentation le prouve), et je m’excuse si vous vous êtes senti blessé.
Pour finir, voici ce que je conseillerais comme attitude, sur un test de fizzbuzz (simple mais efficace).
Si je reçois en entretien un candidat vantard, incapable de résoudre un test de fizzbuzz, je dirais simplement qu’il n’a pas encore le niveau, sans doute parce que son expérience ne l’a pas habituée à ce type de problématique simple, mais qu’il doit persister sur de la veille pour élargir son champ de compétences, si il souhaite évoluer sérieusement dans le métier.
Cela suffit.
Le bilan est véridique, indiscutable et met le candidat dans une posture d’évolution, pas d’humiliation, même non souhaitée par l’auteur des propos.
Voilà, bonne journée à vous, et votre blog est terriblement intéressant :).
Edd, dès le premier message tu obtiens un point Godwin. Très fort.
Ne se focaliser que sur le côté candidat n’aide pas à comprendre l’ensemble du problème.. La tâche d’un recruteur n’est pas facile et se tromper de personne à cause d’un entretien raté, c’est du temps perdu, de l’énergie perdu et finalement de l’argent perdu. Encore une fois, j’aime bien la démarche proposée ici et nul doute que je l’appliquerai bien mieux si l’occasion m’est donnée de refaire d’autres entretiens.
@Edd
Je trouve que l’exemple de l’électricien est intéressant mais en l’occurrence il est mal employé parce que les éléments de comparaison sont inappropriés.
Un électricien expérimenté qui ne connait pas le fonctionnement interne d’une ampoule, c’est l’intégrateur. Je ne parlerai pas de « bricolo », ce dernier étant l’amateur qui bricole à partir d’un CMS quelconque et qui serait bien incapable de construire ledit CMS. L’intégrateur en revanche a de bonnes notions mais a des compétences limitées à l’intégration, il va personnaliser le CMS à l »image de son client. Le développeur de son coté « connait le fonctionnement interne de l’ampoule » mais n’est pas forcément un intégrateur et ce n’est pas son boulot non plus.
Si j’ai un garage automobile et que j’ai besoin d’embaucher un mécanicien, je n’embaucherai pas un type qui conçoit des moteurs, je chercherai quelqu’un qui en comprenne le fonctionnement et qui sache le démonter et le réparer en remplaçant une pièce défectueuse, qui saura surtout au départ identifier une panne et son origine. Dans une entreprise qui développe des applications, si j’ai besoin d’embaucher un développeur, je chercherai quelqu’un connaissant un ou plusieurs langages de programmation et qui surtout saura s’en servir : mais la programmation, c’est avant tout de la logique : on construit en code un certain nombre d’instructions : si le candidat est incapable de définir ces instructions, quand bien même il maitriserait le langage, il ne saura pas écrire le programme, il ne me servira donc à rien et je n’aurai aucune raison et encore moins d’intérêt pour l’embaucher.
On peut tout à fait prendre conscience que beaucoup de gens ont besoin d’un boulot pour payer leurs factures, et que, de ce fait, beaucoup cherchent tous azimut et postulent dans toutes sortes d’entreprises. Mais dans bien des cas, ils perdent leur temps en sollicitant des entrepreneurs a qui ils font également perdre leur temps en ayant pas un minimum de compétences, indépendamment de leurs formation et/ou qualifications.
J’ai eu l’occasion de bavarder avec un nombre appréciable de gens de toutes sortes dans le domaine du développement depuis des années. Je peux dire qu’à ce jour, le personnage le plus intéressant que j’ai eu l’occasion de croiser n’était pas un développeur professionnel, il n’avait du reste aucune prétention dans ce sens, pourtant, je l’aurais embauché sans la moindre difficulté si l’occasion s’était présentée : il était (et est probablement toujours) cheminot à la SNCB et s’était un jour lancé dans la création d’un jeu de gestion en ligne : il lui manquait certes des connaissances techniques sur le langage, mais son approche et son état d’esprit le classait très en avant de certains prétendus professionnels qui se présentent à des entretiens d’embauche en étant incapables de faire le quart de ce que faisait ce gars là.
Le problème est que lorsqu’une entreprise publie une offre d’emploi, la proportion d’incapables qui se présente est considérable. La patience du recruteur est souvent mise à rude épreuve. Si on rejette une candidature, on isole pas une catégorie de gens en déclassant qui que ce soit : on ne classe rien du tout, on cherche quelqu’un qui est déjà classé dans une catégorie, celle des gens capable de répondre aux besoins de l’entreprise. On doit trier parmi ceux qui se présentent pour distinguer ceux qui sont dans cette catégorie de ceux qui prétendent l’être. Il n’y a là aucune ségrégation subjective basée sur des à-prioris comme le sous-entend la comparaison hautement discutable avec Hitler.
Cela étant, il serait aussi opportun de correctement définir les termes : ainsi, qu’entend-on par « développeur », ou par « intégrateur » ou « bricoleur » ? En général, même si j’admets volontiers que ce n’est pas toujours le cas, le recruteur décrit un poste à pourvoir en indiquant des pré-requis. Le candidat qui se présente en ne répondant pas au départ aux critères indiqués va très rapidement se faire repérer et va rapidement agacer le recruteur lors de l’entretien. Si ce dernier l’envoie bouler, je ne jetterai pas le blâme sur le recruteur mais sur le candidat prétentieux. Si le recruteur indique « débutant accepté », un bricoleur pourra se présenter, selon son état d’esprit et son ouverture face à l’apprentissage, le recruteur pourra choisir de le garder pour le former et l’amener à l’excellence professionnelle attendue d’une développeur confirmé, mais pour un poste de spécialiste confirmé indiqué comme tel, un débutant ou un amateur, même enthousiaste et ouvert, n’a aucun intérêt à venir faire volume dans la cohorte de candidats si ce n’est pour courir le risque de se faire renvoyer rapidement dans le cordes.
My 2¢
Très intéressant article et commentaires.
Je voyais bien que le marché est rempli de devs arrivés là un peu par hasard, mais au point de ne pas écrire un algo de 5 lignes, je tombe de haut.
Niveau ego, j’ai toujours l’impression d’être mauvais, mais ça doit tenir au fait que je m’évalue systématiquement en comparaison de ceux qui savent ce que je ne sais pas, ce qui rend toute surestime inateignable, puisqu’il y’aura toujours une marche a passer avant de commencer a être potable.
Par contre, je ne suis pas sur qu’il n’aurait pas été préférable de me penser le roi du monde et de vendre ça a qui se laissera berner, parce qu’a être trop honete vis a vis de mon niveau, c’est moi qui vais bientôt changer de boulot faute d’en trouver (alors que, si je suis très loin d’être un crack, je suis pourtant bien développeur).
Très vrai. Tout aussi vrai qu’il y a beaucoup trop de mauvais recruteurs/directeurs techniques/ directeurs qui essaient de réaliser des tests/quizz/qcm/questions techniques.
Faire croire que connaitre les details de PHP 5.4 fait de toi un bon développeur … On est loin de la compréhension juste générale de ce que signifie développer. C’est un ensemble d’éléments qui dépasse le simple par coeur.
C’est pour cela que j’ai toujours dit que les tests techniques en entretien, c’est de la merde. Ca ne représente absolument pas la valeur d’un futur employé. Si un mec apprend tout bien par coeur et te récite comme une belle poesie, est ce que ca en fait un bon codeur ? je ne crois pas.
@Sendo : cet avis est peut-être un peu trop tranché. Il faut à mon sens prendre en compte les éléments qui seront considérés dans l’analyse du test par le recruteur. La nature même du test peut également être prise en compte : un simple QCM présentera un plus ou moins grand intérêt selon la nature même des questions qui sont posées. Si les réponse ne font appel qu’à de la connaissance brute sans la nécessité de faire appel à un minimum de logique seront effectivement d’un intérêt discutable. Il y a aussi les tests proposés en ligne assortis d’un délai maximum : personnellement, ce type de test m’agace au plus haut point et j’en ai envoyé un ou deux balader sans regret, considérant que l’important est d’obtenir le bon résultat, pas d’aller vite. Bien sûr, il est important de ne pas trainer en chemin, mais lors d’un test, c’est juste parfait pour stresser un postulant ce qui va l’amener obligatoirement à commettre des erreurs parfois idiotes, erreurs qu’il n’aurait probablement jamais faites dans des conditions normales.
Bref, le débat pourrait durer, mais je crois volontiers qu’il pourrait aussi amener à l’élaboration de tests « intelligents »
@Amaury : Très intéressant comme blog.
Je suis actuellement dans une école d’ingénieur par alternance en dernière année. Je ne connais pas le niveau de mes camarades dans leur entreprise respective, mais je peux déjà qu’en cours, un bon tiers (ahaha) a un niveau lamentable. Ils ne se donnent d’ailleurs pas la peine de progresser. Et je ne pense pas que ça changera quand ils chercheront de l’emploi !
Je relance ce post en étant « un peu » à la bourre pour ajouter mon grain de sel. L’approche est bonne, mais de mon point de vu, incomplète.
Savoir exprimer un énoncé sous forme d’un programme qui marche est une chose (et oui, c’est la base). Savoir bien coder en est une autre.
Dans 95 % des cas, le développeur va être amené à coder sur des applications commencé avant lui et qui continueront après. Dans un tel contexte, un développeur a beau coder le plus complexe des algorithmes sans faute, si ce n’est pas lisible ou pas testé, c’est tout simplement mauvais. Le bon développeur va être capable de produire du code robuste, testé, évolutif et lisible.
Et c’est évaluable. Si un candidat commence à vous parler de TDD, de design émergeant, de SOLID, YAGNI, KISS, de refactoring (et autre pratiques sympathiques !), et qui quand on lui parle de design pattern, ne répond pas immédiatement « singleton », il est possible qu’il soit vraiment bon.
Autre point, le développement n’est pas une course de vitesse. Laisser 5 minutes à un candidat pour implémenter une fonction comme je l’ai vu plus haut ne correspond en rien à la réalité de notre métier. En 5 minutes, pas de place à la réflexion, qui est (devrait) pourtant être au coeur de notre métier, et je ne vous parle pas du stress !
Mieux vaut donner un sujet plus vaste avec beaucoup plus de temps, voir demander au candidat de le préparer chez lui, et ensuite faire une revue de code avec lui. Ce dialogue devrait permettre de comprendre le raisonnement qu’il a suivit et en apprécier la qualité (ou la pauvreté, c’est au choix ! ).
Bonne journée tout le monde !
@jérome : Oui et non. Oui, le fait d’implémenter un algorithme simple ne veut pas dire que la personne saura faire un vrai développement. Par contre, si un développeur n’est pas capable d’implémenter un algo simple, il ne pourra jamais faire le moindre développement de qualité. Donc il ne s’agit pas d’un test absolu, mais d’un premier filtre pour écarter les plus mauvais.
Parce que j’ai déjà eu des discussions qui semblaient intéressantes avec des candidats qui manipulaient très bien tout un tas de concepts techniques pointus, mais une fois devant un clavier, ces mêmes candidats n’avaient pas du tout la logique nécessaire à la pratique de la programmation.
Bonjour,
Cette histoire de tests remonte à une vingtaine d’années déjà et je la pratique encore (ou la fait pratiquer maintenant). Je l’ai évoqué dans mon commentaire ici même il y a 2 ans maintenant.
Je comprends votre réaction mais elle est le fait de ne pas avoir lu la cause , ni les conditions de passage ce qui vous aurait évité un contre-sens.
L’objectif en 5 minutes est de vérifier que le recruté est réellement capable d’écrire un code de 5/10 lignes en C/ADA/PHP/ enfin bref le langage qu’il souhaite : qui contient une boucle avec un test de sortie (ou pas selon l’intelligence de l’algorithme envisagé). C’est bien beau d’annoncer des choses sur ses connaissances en algorithmique, c’en est une autre d’en être réellement capable.
Un exemple de test type (on en change à chaque fois) : afficher le contenu de /etc/password (bref l’équivalent de cat à programmer). S’il faut 3 heures à un ingénieur chevronné pour écrire cela, tout réfléchi qu’il soit, je vous laisse le recruter, il ne sera pas accepté chez nous.
Que tu développes Web ou noyau temps réel, si tu ne sais pas faire un truc comme ça, un conseil : change de métier.
Désolé pour le côté abrupt 🙂
@chrysm : Ça rejoint assez ce que j’exprimais dans un autre commentaire il y a pas mal de temps maintenant : l’algorithme¸ ça ne s,apprend pas : on sait ou non le construire et pour ça, il faut être et rester dans la logique pure, quelle que puisse être la complexité de ce qui doit être développé.
La validité d’un test ne dépendra donc pas tant de la complexité du problème soulevé que de la manière dont on pourra évaluer le sens logique du candidat pour effectuer la construction visant à aboutir au résultat voulu. On pourra ensuite ajouter d’autres critères comme la manière d’écrire le code, de l’indenter, de le commenter et autres petits détails, mais qui resteront toutefois des détails, indispensables certes, mais complémentaires seulement si on garde l’accent principal sur la logique mise en œuvre.
@Amaury
Vous avez bien sûr raison, et votre dernière phrase serait d’ailleurs une accroche vers un autre article évoquant les qualité faisant un bon développeur. Mais en parcourant les commentaires, j’ai trouvé qu’au final le développement était beaucoup trop souvent réduit à l’algorithmie, ce que je trouve dommageable. C’est pourquoi je trouve qu’il est important de rappeler que coder ce n’est pas que de l’algorithmie. Une petite remarque concernant les concepts que j’ai évoqué : j’entendais les tester non à l’orale, mais par une mise en application.
@Chrysm
Nous vous inquiétez pas pour moi, je n’ai aucun problème avec l’algorithmie et j’ai parfaitement lu le contexte et la cause de l’article. J’explique d’ailleurs au dessus à Amaury les raisons de mon post.
Ensuite à mon tour d’être direct : si vous réduisez le développeur à un simple « pisseur de code » qui recrache gentillement ce qu’il a appris lors de ses piscines en école, je pense que vous avez une assez triste vision du métier de développeur. Si un quelqu’un ne maîtrisant pas les bases de l’algorithmie ne mérite en effet pas l’appellation de développeur, je ne croîs pas que le 100m départ lancé en codage de cat soit un test bien enrichissant. Que peut-on bien déduire d’un tel test qu’on ne puisse par quelques questions ‘pratiques’ bien placés ? Et si vous prenez le temps de me relire, je n’ai jamais parlé de « laisser 3 heures à un candidat pour coder un cat », mais d’avoir un sujet plus vaste, avec donc plus de temps, ce qui pourraît permettre de condenser plusieurs niveau d’entretien en un et ainsi d’avoir plus d’informations sur le niveau réel du candidat.
Je suis un développeur, et fier de l’être. Et un recruteur qui ne me propose que ce genre de test (que j’ai toujours passé jusqu’à présent) lors d’un entretien ne me donne pas envie de travailler pour lui.
Après vous avez votre avis sur la question, que je suppose très honorable et lié à votre expérience, mais votre ton paternaliste, votre tutoiement, et vos insinuations, vous les gardez pour vous.
Jérôme
@jerome : Chacun sa vision de la chose, bien sûr. Je persiste à penser qu’un développeur qui n’est pas capable d’implémenter un algo hyper simple (dont on lui donne la définition) ne sera pas capable d’imaginer et d’implémenter un algo plus complexe quand il devra développer une vraie application.
Évidemment, ce test ne doit pas servir comme seul critère. Dans mon processus de recrutement, il y a quelques tests techniques très simples (dont celui de l’algo), qui me permettent de faire un premier filtre. Suivi d’un entretien plus classique. Si le candidat me semble passer cette première étape, il revient pour un exercice de codage sur machine qui dure une demi-journée, qui sert à le juger suivant plusieurs critères (qualité du code produit, cheminement intellectuel pour résoudre les problèmes, connaissances en génie logiciel, qualité et quantité de sa communication, dosage entre chercher seul tout mais ne pas rester tanké sur un point bloquant, etc.), qui se termine par un debriefing. Le recrutement ou non du candidat se fait à la lumière de l’ensemble des informations que ces étapes auront permis de récolter.
Donc on est d’accord : « un recruteur qui ne (me) propose que ce genre de test » ne fait pas son travail. Le test simple d’algorithmie doit évidemment être complété avec d’autres tests plus étoffés, pour les candidat qui passent ce premier filtre.
@Amaury
On est effectivement d’accord.
Je m’excuse de la véhémence de mon précédent post, mais ce que je considère comme étant un manque de correction de la part de Chrysm m’a vraiment enervé.
Un article assez directement en lien avec le sujet a été très récemment posté sur developpez.com. Le contenu n’est vraiment pas dénué d’intérêt.
Excellent article et malheureusement vrai….
Dans ma boite, c’est le directeur technique qui fait passer les entretiens et il ne pose aucune question technique…..
Résultat : 2 développeurs viennent d’être embauchés (donc en période d’essai), qui étaient censés avoir 4 ans et 10 ans d’expérience.
Celui censé avoir 4 ans a en réalité 0 expérience et 0 compétence : il a juste fait quelques heures d’informatique il y a quelques années pendant ses études de physique. Il ne peut absolument rien coder, juste faire quelques copier-coller hasardeux et buggés.
Celui qui a 10 ans d’expérience n’est pas vraiment mieux : il se contente aussi de faire des copier-coller qui produit un code baclé, illisible, bourré de fautes et de code mort…
Le pire dans tout ça ? Le directeur technique est au courant, la DRH est au courant, tout le monde est au courant, mais personne ne fait rien… Prétextes invoqués : « il faut leur laisser le temps de s’améliorer » et « c’est pas facile de trouver des développeurs ».
Hello,
Ton blog est une vraie mine d’or et de remise en question. Merci pour ton engagement ….
Quand je recrute je les met sur un projet en cours, à leur charge de résoudre le bug ou développer la fonction que j’attend, accès à Google compris, ça suffit pour trier, où ils me présentent un de leur projet, et je les faits communiquer sur leurs choix, c’est la seule chose qui fonctionne concrètement, les « tests » d’algorithmique et compagnie ne servent à rien. Après les jugements de valeur sur toi t’es développeur, toi t’en est pas digne, bla-bla-bla, ça me fait vomir…
Et encore, cet article très intéressant prend en compte le postulat du développeur web diplômé. Quid de l’autodidacte ? Comme il est très justement dit dans certains commentaires ci-dessus, beaucoup d’écoles informatique délivrent des diplômes à des élèves qui doivent leur sanction uniquement aux notes obtenues grâce aux travaux de groupe. De l’autre côté on a un nombre croissant d’autodidactes qui se forment sur le web et peuvent probablement, pour certains, devenirs de bons dev. Encore faut-il leur en laisser la chance, c’est à dire ne pas filtrer que sur le diplôme.
@Rok : On est d’accord, je fais faire du vrai développement au deuxième entretien. Ça dure une demi-journée, donc il faut faire un premier filtre, je ne peux décemment pas investir autant de temps avec toutes les personnes qui pensent correspondre au poste.
Désolé de te soulever le cœur, mais quand je prends le temps d’expliquer à quelqu’un où sont ses lacunes, c’est justement dans une démarche pédagogique et positive (un peu comme ce blog). Après chacun voit midi à sa porte.
@Autodidacte : Je ne fais pas de discrimination en fonction des diplômes, et je conseille toujours de ne pas en faire. Maintenant, je dois malheureusement reconnaître que mes plus grosses déconvenues sont venues de personnes autodidactes qui croyaient savoir programmer.
Mon Dieu la prétentionnnnnn !!! « Mon temps est précieux » . Ou les remarques du style » vous n’êtes pas informaticien » . A cause de gens comme vous que le monde part en cacahuète. Je pense que votre problème est plutôt d’ordre psychologique. Pas mal de journalistes , hommes politiques et j’en passe n’y connaissent strictement rien et pourtant sont là. Moi je conçois l’informatique comme un vaste univers open source où l’intérêt n’est pas de savoir lequel est le moins informaticien mais qui pourra proposer quelque chose d’avant gardiste et innovant
[quote]@Edd : J’avoue que je commence à être fatigué de me justifier.
Que ce soit clair : Je ne suis pas sec ou impoli ou méchant avec les candidats. Et il m’est arrivé dans quelques rares occasions de dire à quelqu’un qu’il n’était pas informaticien, parce que c’était une simple constatation ; il n’y avait rien de méchant là-dedans, et je pense qu’il vaut mieux aider une personne à s’en rendre compte plutôt que de la laisser croire qu’elle a la moindre qualité pour un job donné.
Si je postulais pour être commercial, un recruteur me dirait que je n’ai rien à faire à ce poste, et il aurait raison.
En l’occurrence, votre parallèle avec un électricien n’est pas bon. Pour faire une vraie comparaison, imaginez plutôt que vous cherchiez un électricien pour refaire toute votre installation électrique, et que le candidat n’est pas capable de brancher une ampoule, et qu’il vous répond que ce n’est pas de sa faute, que les bornes “+” et “-” sont mal indiquées…
Là c’est pareil. Je ne demande pas aux candidats de m’expliquer ce qu’il se passe à l’intérieur d’un microprocesseur, ou de me dire quelles sont les instructions appelées en assembleur (ce qui serait l’équivalent de votre «connaître le fonctionnement interne d’une ampoule»). Je lui demande d’implémenter un algorithme ultra-simple ; s’il n’est pas capable d’y arriver, je persiste à croire qu’il aura du mal lorsqu’il devra implémenter des algorithmes bien plus complexes − ce qui constituera l’essentiel de son travail !
Enfin, me comparer avec Hitler est tellement… je ne sais que dire. Bravo.[/quote]
Il a raison et à la fois non. Mais je ne le dirais pas de cette façon. Il n’y a pas de vérité axiomatique quant au fait de « juger » (par essence de ce simple mot) d’une qualité de recruteur comme elle n’existe pas plus pour un développeur « jugé » comme mauvais. Il s’agit d’interprétation comme ce qui fait office de gouvernance dans ce bas monde. Par conséquent, il serait inutile de vous « justifier », cela n’en changerait pas le résultat au regard de ceux qui en ont « décidé » ainsi (étymologie latine pour signifier le décès, en l’occurrence de l’opinion – rien que ça). Vous n’arriverez pas à un consensus.
En revanche, vous vous démontez l’un et l’autre par des vérités qui sont les vôtres également et vos propres interprétations. Du coup, nous sommes là face à un cas classique de défaillance de perception du monde des autres. Autrement dit, une pensée séquentielle dont l’allégorie consiste à quelques moutons entourés d’une barrière dans l’esprit et l’âme. La comparaison avec Hitler touche par la symbolique que l’on y associe, mais l’aveugle y voit plus clair avec soudainement une prise de distance et beaucoup d’abstraction pour extraire les méta-données utiles d’une idée, à savoir celle que ce personne a démonté une logique par une axiome qu’il ne satisfait pas comme hypothèse.
Tout cela pour en arriver à une vérité qui est la mienne et qui est celle de beaucoup d’autres également. La faute à :
– Un système éducatif qui prône le « savoir » et le « bourrage de crâne » plutôt que la détection des multiples intelligences propres à chacun, afin d’orienter efficacement
– A la qualité intrinsèque de certaines écoles dites « côtées ». Je rigole encore de cet élitisme ambiant dans lequel je baigne depuis 5 ans et que j’ai pu apercevoir également durant mes études. La majorité des personnes sortant de ces écoles ne savent RIEN faire, si ce n’est effectuer des calculs appris par coeur ou appliquer des méthodes de management basé sur un postulat normo pensant (et donc complètement remis en cause en 2016)
– A l’éducation parentale mais ça vous l’avez dit
– Bref, tout un tas de facteurs qu’il est difficile de maîtriser, d’autant plus pour un domaine porteur, en constante évolution et qui n’est pour le rien du monde à comparer avec les autres métiers citées qui ne demandent pas le même investissement personnel en dehors (un ingénieur en informatique est A VIE étudiant). De plus, le saviez-vous, même si cette notion est légèrement obsolète face au concept de multiples intelligences, le quotient intellectuel requis et obtenu pour le métier est supérieur dans les statistiques que les autres métiers. Or, nous ne naissons pas tous égaux à ce niveau. Que faire ? Revenir au premier point et l’orientation tardive et erronée.
Enfin, deux mots pour symboliser l’avenir:
– Esprit libéré / entreprise libérée
– Absence de hiérarchie: les « anciens chefs » doivent désormais être contributeurs de la productivité
=> Amélioration passive de la productivité, de la qualité de vie au travail et de l’investissement inconscient des employés
@Boumediene : Ahahahah
Et le jour où vous laisserez votre voiture au garage pour faire vérifier les niveaux d’huile, et que vous la récupérerez avec des pneus de camions (mais toujours en manque d’huile), vous direz à votre garagiste que le gars qui s’en est occupé est génial parce qu’il a proposé quelque chose d’avant-gardiste et innovant ? Vivement qu’il en fasse profiter le monde en mettant ça en open source.
Bravo 🙂
Bonjour Amaury,
j’ai lancé ma start-up il y a un an sans aucun profil CTO dans l’équipe. J’ai fait un site wordpress qui fait le travail pour le moment mais je souhaite maintenant recruter des développeurs, voir mon prochain CTO, pour commencer la construction de la machine de guerre 🙂
Je souhaiterais faire passer un test de logique informatique aux candidat, pourrais tu m’aider avec ton test?
Merci beaucoup pour ton aide
Guillaume de mycuistot.fr
Cher Amaury F,
Selon le principe de Peter, « tout employé a tendance à s’élever à son niveau d’incompétence, ainsi, tout poste sera occupé par un employé incompétent » (je cite de mémoire). Cela veut dire que ce qui motive le travail, au delà du salaire, c’est la soif d’apprendre. Et le jour ou l’on n’a plus rien à apprendre, et bien on n’est plus efficace, simplement parce que l’on ne trouve moins de sens à son travail.
Je trouve réducteur le fait de juger un candidat à ses compétences uniquement. Si l’on cherche la pérennité, dans l’embauche d’un collaborateur, on devrait plutôt s’attacher à déceler les talents et les potentiels. C’est ainsi que peuvent naitre les innovations les plus sérieuses. Plutôt que de faire comme vous le faites, en prenant comme étalon vos compétences……. Je pense que c’est une facilité que vous vous accordez, mais qui à mon sens n’est pas très efficiente.
Je vous invite à vous intéresser à tous ces jeunes plein de talent qui ne demande qu’à s’exprimer (je parle du talent), et qui n’ont comme réponse à leur recherche, « vous n’avez pas d’expérience »
Bonne continuation
@Guillaume : Je te contacte par email pour en parler.
@Mourad : Attention à ne pas confondre « Amaury » (créateur de ce blog) et « Amaury F. » (qui a laissé un commentaire).
Je ne peux qu’aller dans votre sens. Le niveau de compétence brut n’est pas le seul indicateur qui doit guider vers l’embauche d’un candidat.
Bonjour Amaury,
Je voudrais préciser un point.
Quand vous recrutez un développeur sénior (je parle d’un vrai sénior qui a les compétences d’un sénior et non pas quelqu’un qui a développé pendant 10 ans ) , d’abord pour quelle raison est-ce qu’il va aller chez vous ? est-ce qu’il chôme ? Pourquoi est-ce que quelqu’un qui est un vrai sénior qui n’a pas encore atteint la quarantaine chômerait ?
A moins d’ indiquer un salaire très élevé dès le départ dans l’offre , il n’y aurait aucune chance que des vrais séniors viennent postuler à votre offre.
Donc je veux surtout dire qu’il faut arrêter de chercher des vrais séniors quand on n’a pas les moyens de les payer avec un salaire largement supérieur à ce qu’ils gagnent déjà , et çà il faut l’ indiquer dès le départ dans l’offre.
Ne soyez pas étonné que seuls les dev juniors postulent à votre offre.
@Magicien : Ce n’est clairement pas un problème de salaire. Ce n’est pas le fait d’indiquer un salaire mirifique dans une offre qui fera venir des séniors qui ne seraient pas venus sinon ; et ça ne garantira pas non plus que les mauvais (qu’ils soient juniors ou séniors) ne postulent pas…
Je trouve cet article intéressant mais franchement (après c’était peut-être des sacrés lascars) mais dire que les candidats ne sont pas informaticiens juste parce qu’ils n’ont pas réussit un test technique… Franchement… Non, désolée, non. Certaines personnes, diplomés ou non, aimeraient avoir un emploi mais ne savent pas forcément ce qu’elles sont capables de faire réellement ! Et casser les gens pour leurs dires qu’ils ne sont pas fait pour sa !! Un exemple: Quelqu’un qui à fait un bac et même un BTS dans un domaine qu’il n’aime pas va faire une reconversion et va passer une formation pour devenir développeur web, formation qui se passe très bien.Après sa formation, il commence sur le marché du travail et voudrait bien trouver un emploi. Manque de bol, pas assez d’expériences. Il cherche, il continue, il se démonte pas et là une entreprise lui répond et il décroche un entretien. Il passe le test technique et malheureusement échoue lamentablement (stress, peur, incompréhension) et le recruteur finirait par lui dire ‘change de métier’. Change de métier, non mais vous imaginer ? Le gars à déjà changer de métier, changer de voix, vous imaginer le coup dur ? Deux solutions: le gars se démonte pas et se dit que ce recruteur là, c’est qu’un con, ou il se démonte complètement et va aller vers un métier qui ne lui correspond pas, et toute sa vie, il aura des regrets. Toute sa vie. J’ai lu aussi quelques commentaires sur la logique, comme quoi cela ne s’apprend pas mais c’est quoi ces conneries !! Bien sûr que cela s’apprend et surtout dans le domaine du développement web !! Car le mec peut avoir la meilleure logique du monde entier, si il ne sait pas quels outils il à en main, cela ne sert à rien ! Imaginez un gars hyper logique, on lui demande d’enfoncer un clou mais ne connaît pas le marteau. Il va se creuser la tête et au bout d’un moment va y arriver au bout d’une heure peut-être. Si il connaissait le marteau, c’était régler en 5 secondes. Dans le développement web, c’est pareil. Si tu as une certaine logique mais que tu connais pas l’outil qui te permettrait d’y arriver plus facilement, c’est mort. La logique dans le domaine du développement, cela s’apprend, tout ou presque, peut-être appris à force de travail et d’acharnement, tout le monde ou presque en est capable. Alors j’étais pas là aux entretiens, ils vous ont sûrement énerver, mais je vous retourne juste le truc et je vais aller plus loin: Si vous n’êtes pas capable de garder votre calme, vous ne devriez pas être recruteur. Je caricature, je part loin en disant sa, mais je pense qu’il y a quand même une part de vérité là-dedans. Et c’est pas pour être offensent non plus que je dit sa mais j’imagine des jeunes développeur tomber sur cet article et se dire ‘Si je suis pas capable de passer ces tests, je suis qu’un bon à rien’
Bonjour @Amaury,
Je trouve votre Article pertinent et juste, ainsi que de nombreux commentaires. C’est ce dont je m’efforce à croire, preuve de constat dans la promo dans laquelle je me trouve et peut être même les autres que j’ai pu remarquer. Mais je n’ai pas le recul suffisant pour pouvoir constater et juger comme vous le faites.
J’ai surtout la forte impression que nous sommes bel et bien formés avant tout à être de vrais « Bricoleurs passe partout » sans vraiment chercher à comprendre le fondement même d’un code bien écrit, maintenable et évolutif. Quant à moi, le travail personnel et la recherche sont les seules justifications plausibles, de la à se dire « Développeur » … c’est autre chose, néanmoins je travail dur pour ça, pour mériter ce titre.
En effet, si je venais à postuler dans quelques années, et vouloir me présenter comme un faiseur de miracle, mais la vérité serait telle-que je ne saurais pas aligner quelques lignes de codes, qui découlent d’un test en adéquation avec le poste. Je n’aurais aucun mal à accepter et entendre cette phrase, qui a fait polémique auprès de certaines personnes. Il est de rigueur d’être franc, honnête et professionnel, aussi bien envers soi que la personne concernée.
En revanche, pour quelqu’un qui a travaillé dur, se sous-estime mais vise à vouloir faire de son mieux, s’il échoue a l’un de vos tests, entendre ce genre de chose, raisonnerait comme un coup de tonnerre, pour finir droit au coeur. Je pense qu’il est donc judicieux de scinder et mâcher ses mots selon le profil (question de discernement, dont je suis sûr que vous faites preuve).
Ceci étant juste mon avis selon ma petite expérience acquise à ce jour, ce sujet m’aura fortement interpellé.
Je trouve d’une tristesse inouïe ce discours qui rend la profession élitiste plutôt que d’entre aide.
J’ai commencé ma carrière de développeur avec à l’esprit qu’un bon dev est un dev humble.
Je vois malheureusement 10 ans plus tard que ce beau principe à disparu.
On ne peut pas tout connaitre mais on peut tout apprendre, il serait bien de ne pas l’oublier dans vos grands discours de dev au dessus du lot …
J’ai choisi le développement pour sa diversité, sa créativité; sa collectivité, sa transmission et parce que j’ai un esprit qui a besoin de travailler plus qu’a taper sur des clous toute la journée, sans dénigrement, chacun son truc.
Malheureusement, trop de gens comme vous dans cette profession, qui déshumanise et dénature complètement le métier en vous laissant manger par le monde capitaliste qu’il fait vivre.
Ce spectacle macabre me désespère et me force à vous demander, mais pour qui vous prenez VOUS ?
@Vince : Je ne vais pas me justifier une énième fois. Relis tous les commentaire, je pense avoir bien précisé le contexte dans lequel ce genre de chose est arrivée.
Pour reprendre ton exemple, quelqu’un qui se dirait « monteur de meuble professionnel » mais qui ne connaîtrait pas l’existence du marteau, est-ce que tu aurais vraiment envie de lui confier le montage de ta cuisine ??? L’embaucher dans ton entreprise de montage de cuisines ? Non, tu lui rends un plus grand service en lui expliquant − gentiment et poliment − qu’il n’est pas encore « monteur de meuble professionnel », et tu prends du temps (alors que ton temps est compté et précieux) pour lui indiquer les moyens qui s’offrent à lui pour le devenir.
@Pierre : Oui, ça ne s’apprend pas vraiment à l’école. Quelque part, les stages et l’expérience professionnelle sont là pour ça… Mais sont très conditionnés par les personnes avec qui on va travailler, les méthodes mises en place dans les entreprises que l’on fréquente, etc.
@cocoweb : Là non plus, je ne vais pas me justifier. Je l’ai fait assez dans tous les commentaires précédents. Je pense être très humain avec les gens que je reçois. Et lorsque je dis à quelqu’un qui ne sait pas coder une fonction d’addition (oui, oui, on parle bien de ce niveau-là) qu’il n’est pas informaticien, je me sens très à l’aise pour le dire ; d’autant plus que je prends le temps pour aider les gens à réfléchir à leur carrière, leur donner des directions, parfois leur conseiller des formations ou des entreprises…
Maintenant, ton message m’amuse un peu. Sauf s’il s’agit d’une immense coïncidence homonymique (pas compliqué de connaître ton nom à partir du lien que tu as donné), tu es quelqu’un que j’ai embauché il y a près de 9 ans, et dont j’ai rapidement mis fin à la période d’essai. Je peux comprendre ton ressentiment, qui s’exprime ici de manière un peu ridicule. Dis-toi juste que si je ne t’ai pas gardé, c’est d’une part parce que ton niveau technique était loin d’être celui que tu croyais avoir, mais surtout parce que ton attitude avec moi et tes collègues n’était pas acceptable. Je te suggère de passer à autre chose et de laisser mon blog tranquille, merci 🙂
Que voulez-vous. Y a pas de boulot pour tout le monde. On est prêt à se faire passer pour n’importe qui pour pouvoir manger ailleurs qu’au restos du cœur.
C’est assez paradoxal mais tellement cohérent par rapport au marché qui sévit en France.
Je ne doute pas de ton caractère humain auprès de ton entourage, mais je trouve ici beaucoup de ressemblances avec peut être 75% des « experts » techniques qui montrent beaucoup de suffisance et d’arrogance vis à vis des candidats. Je ne doute pas de ton caractère humain mais rien que le fait d’avoir idée de dire « vous n »êtes pas informaticien monsieur » est d’une arrogance extrême.
Peut être que le cher monsieur a sublimé ses expériences et qu’il ne mérite pas le statut qu’il s’est arrogé, m’enfin ce n’est pas une raison.
Par contre, je rejoins sur un point, beaucoup trop négligé en France : c’est une question de temps ! Le recruteur prend de son temps pour faire cet entretien, mais surtout (et c’est beaucoup trop sous estimé), le candidat prend de son temps pour être à l’entretien, et l’employeur doit prouver que ce poste a une quelconque valeur.
Bien trop souvent, il y a une impressio nauséabonde que le candidat doit jouer sa vie pour un poste moyen (ou pas) et que la société n’a rien à justifier l’intérêt.
C’est malheureusement l’immobilisme ambiant en France, qui doit changer. Et ce la passe par un changement des mentalités des candidats, qui ne sont plus des jeunes diplômés et qui doivent comprendre qu’ils doivent un peu avoir d’estime pour eux. Et que s’ils doivent prouver leur « valeur » auprès du recruteur, ils doivent également analyser si ce poste mérite leur présence.
Sans parler de la différence entre le marché anglo saxon et français sur le statut du développeur, mais ça c’est une autre histoire …
J’ai eu a faire passer des entretiens cette année pour recruter 2 devs dans ma boite.
J’ai décidé de leur faire passer un fizzbuzz plus 3 petites fonctions tout aussi ridicules.
Autant je n’ai pas eu l’arrogance de dire à 75% qu’ils n’étaient pas programmeurs, autant c’est pas l’envie qui manquait.
Je n’aurais jamais pensé avant cette expérience qu’on puisse voir autant de candidats non programmeurs se présenter pour un poste de programmeur.
Parce que je rejoins l’auteur, quand on est pas capable de faire une boucle, quand on ne sait pas que tout langage offre une fonction modulo, alors qu’on a « des années d’expériences », ça pose question.
Je n’ai pas souvent eu l’occasion de creuser la façon de faire le fizzbuzz (qui est très parlante sur la façon de travailler) 75% n’arrivaient tout bonnement pas a le produire.
@Sendo : Tu peux penser ce que tu veux. Je me suis justifié un certain nombre de fois (lis bien tous les commentaires). Lorsque je dis à quelqu’un qu’il n’est pas informaticien, c’est une réalité. Libre à toi de croire que je suis un trou du cul pédant et arrogant, mais il y a des cas où c’est rendre service à la personne, surtout lorsque je passe ensuite une demi-heure à donner des conseils de carrière.
@Geekureuil : Merci pour ce retour d’expérience.
Au final, je vais bloquer les commentaires sur ce fil de discussion. Je pense qu’il y a eu assez de messages me disant que je suis un connards, et assez de messages disant que ce que je décris est une réalité. Je ne vois pas comment il est possible d’apporter quelque chose de nouveau à cette discussion, on tourne un peu en rond. Si quelqu’un a envie de dire quelque chose à ce sujet, je suggère de commencer par lire les 108 commentaires avant de vouloir ajouter quoi que ce soit.
Merci à tous pour votre participation.