- Ce court poème en prose part de l’affirmation « You are not a real engineer » et superpose dans un même contexte un refus après entretien et l’imagerie d’un monstre mythologique
- Le sujet est dépeint comme un être transcendant à la taille humaine, doté d’une tête de lion, de seize ailes, de centaines d’yeux et d’une ceinture en forme de serpent
- Son souffle semblable à des nuages d’orage, sa voix pareille au rugissement du vent et ses pas qui font faner l’herbe renforcent sans cesse son immense puissance
- À la fin, la formule de refus de recrutement « nous ne proposerons pas ce poste pour le moment » est suivie de la raison : « nous recherchons quelqu’un de plus technique »
- Même un être destructeur est rejeté au motif qu’il n’est pas quelqu’un de plus technique, ce qui révèle l’absurdité du critère de « vrai ingénieur »
Une description qui s’étend jusqu’à l’être mythologique
- La phrase d’ouverture est « You are not a real engineer » : elle déclare directement au sujet qu’il n’est pas un vrai ingénieur
- Le sujet prend ensuite les traits d’un être à la stature humaine et à la tête de lion, avec seize ailes blanches et des centaines d’yeux semblables à des torches
- Sa ceinture est un serpent, son souffle un rassemblement de nuages d’orage, et sa voix s’apparente au rugissement du vent
- Devant ses pas, l’herbe se fane, et sa langue, noire comme un abîme profond, apporte la fin à tout ce qu’elle touche
Le retournement créé par la formule de refus de recrutement
- La conclusion bascule soudain d’une description écrasante vers la formule polie d’un refus dans un processus de recrutement
- Après « nous ne proposerons pas ce poste pour le moment » vient la justification : « nous recherchons quelqu’un de plus technique »
- Le choc entre les images mythologiques précédentes et la banale phrase de refus de recrutement finale met en évidence la fragilité de l’expression « vrai ingénieur »
1 commentaires
Avis Hacker News
Ces temps-ci, j’ai renoncé à l’idée de recruter des ingénieurs de génie pour des postes où 80 % du temps de travail consiste à construire des applications CRUD
C’est du gaspillage d’argent et de vivier de talents, ce n’est pas bon non plus pour le candidat, et cela crée un risque à long terme pour l’entreprise. Ces personnes finissent souvent par s’ennuyer et commencent à surconcevoir juste pour faire travailler leur cerveau
Pour la plupart des ingénieurs, il suffit largement de bien écrire les opérations de création, modification, suppression et lecture au niveau de la base de données et de l’API, d’appeler l’API depuis le frontend, et d’avoir une gestion des erreurs correcte ainsi qu’une approche de débogage décente
Cela dit, j’ai vu des programmeurs « corrects » produire des résultats « passables », et j’ai aussi vu de meilleurs programmeurs travailler 5 fois plus vite sans travailler 5 fois plus longtemps, être presque autonomes, ne pas nécessiter qu’un QA reste derrière eux pour vérifier que les tickets marqués comme terminés le sont vraiment, et résoudre les problèmes de manière créative sans qu’on ait à débrouiller le dépôt Git à leur place quand ça dérape
Pas besoin d’un cerveau hyperactif, mais de bons / très bons programmeurs font une énorme différence, même sur des projets qui paraissent techniquement ordinaires
En ce moment, je suis à fond sur Steve Howe, et j’ai lu une remarque de lui disant en gros qu’il aimerait que les guitaristes se concentrent sur le fait de devenir des musiciens. La différence entre codeurs et ingénieurs est un peu du même ordre
J’ai vu beaucoup de programmeurs techniquement plus compétents que moi, mais cela n’en faisait pas de meilleurs ingénieurs. Le fait que je sois entrepreneur et que j’aie aussi un certain bagage en marketing y joue beaucoup
Beaucoup d’entreprises sous-estiment les compétences non liées au code qui font réellement un ingénieur. C’est comme embaucher un boucher au lieu d’un chef et se demander ensuite pourquoi le plat n’est pas bon
Obtenir une licence dans un domaine technique, travailler comme ingénieur n°52354 chez Ingersoll Rand ou Boeing, devenir expert d’un domaine complexe mais limité, puis partir à la retraite 30 ans plus tard, c’est aussi une excellente carrière. C’est une définition tout à fait valable du mot « ingénieur », et ces personnes, même si elles peuvent paraître ennuyeuses, ont probablement une vie personnellement très épanouie
J’ai beaucoup réfléchi à cette question récemment : la direction a tendance à voir l’ingénieur standard comme un centre de coûts, tandis que la valeur d’une personne comme celle décrite dans l’article déborde de l’ingénierie jusqu’à d’autres départements qui génèrent directement du chiffre d’affaires, ce qui la met à l’abri de ce genre de critiques
Je suis sans doute moi aussi un ingénieur de ce type, mais j’ai essayé de remplacer mon mépris pour ce stéréotype par une attitude plus collaborative
Le marché réel valorise davantage les codeurs Spring Java que les ingénieurs C++ qui travaillent sur du matériel
J’ai connu les deux côtés. J’ai subi les caprices opaques et les petites humiliations du processus de recherche d’emploi, et j’ai aussi interviewé puis recalé des candidats expérimentés qui parlaient bien mais étaient incapables de coder un problème de niveau FizzBuzz dans quelque langage que ce soit
Ce n’est pas une question de choisir entre « les entretiens techniques sont nuls » et « le marché de l’emploi regorge de candidats non qualifiés ». Les deux peuvent être vrais, et je pense qu’en pratique ils sont liés, un peu comme sur un marché des lemons
On peut être embauché alors qu’il existe objectivement meilleur que soi, et on peut être le candidat idéal tout en étant éliminé dès le screening téléphonique. Au final, cela relève presque de la chance, et ceux qui disent le contraire mélangent souvent biais du survivant et refus d’admettre que la procédure elle-même est défectueuse
Le fait de juger qu’un candidat expérimenté ne sait même pas résoudre un exercice de niveau FizzBuzz reflète aussi, à mon avis, la pensée cargo cult qui empoisonne le recrutement. Je connais des ingénieurs FANG qui doivent s’entraîner pendant des semaines à des exercices de code golf, à des quiz d’algorithmes et de structures de données qui ne ressemblent pas au vrai métier de l’ingénierie logicielle, juste pour passer un premier entretien
Je vais jusqu’à penser que ces exercices relèvent davantage du retrait de l’échelle que d’une véritable évaluation technique. J’ai déjà été éliminé d’office pour un poste C++ d’applications desktop parce que je ne connaissais pas placement new, et un ami candidat à un poste backend a créé un service Spring de zéro qui passait tous les tests d’intégration, mais il a été recalé parce que le contrôleur n’avait pas de commentaires. Il y a des intervieweurs qui traitent comme une grande épreuve technique ce qui pourrait être corrigé par une simple ligne de commentaire dans une PR
Les recruteurs se trompent aussi. Recruter quelqu’un avec succès est vraiment difficile
Parfois, cela vous évite simplement de travailler avec des gens que vous n’auriez de toute façon pas aimés. Ils ne sont même pas très doués pour inventer des prétextes plausibles à votre non-recrutement, et une grande partie tient à la chance
Par exemple, ils ont peut-être eu l’impression que « vous ne semblez pas être un partisan de Trump », et se sont dit qu’ils ne seraient pas à l’aise avec vous. Si vous n’êtes vraiment pas de leur genre, avez-vous vraiment envie d’y travailler ?
La recherche d’emploi me déprime toujours, et je n’ai pas d’autre réponse que de ne pas mettre trop d’espoir dans un poste précis. En même temps, il ne faut pas non plus écarter trop vite des opportunités qui ne paraissent pas extraordinaires
Mon premier manager dans mon emploi actuel était affreux, et il n’y avait pas beaucoup de bonnes personnes, mais ils sont partis et j’ai été promu. Comment aurait-on pu prévoir ça ? Les recruteurs ne peuvent pas non plus vous prévoir, et l’ensemble du processus est assez aléatoire et inconfortable
Quand c’est moi qui fais passer des entretiens, j’ai des priorités. D’abord, mon manager m’a donné un conseil très simple : « essaie de recruter quelqu’un de bien ». Je préfère travailler avec un bon développeur, gentil, avec qui on s’entraide et on s’entend bien, plutôt qu’avec quelqu’un qui pense devoir toujours imposer sa volonté et mériter les pleins pouvoirs parce qu’il se croit un génie ultra-productif
Ensuite, je regarde si le candidat s’intéresse au logiciel, ou au moins à quelque chose. S’il n’a même pas un peu de passion pour le logiciel, la tech ou quelque chose en lien avec le travail, comment pourrait-il apprendre ce qu’il faut et qui n’apparaît pas sur son CV ? Il faut s’attendre à ce que les gens n’arrivent pas comme des « produits finis », mais qu’ils apprennent
Même avec une bonne procédure d’entretien, je pense qu’on peut tout à fait éliminer des candidats qui auraient en réalité très bien fait le travail
Comprendre correctement si quelqu’un convient au poste demande trop de temps d’entretien, tant pour l’employeur que pour le candidat. Du point de vue de l’employeur, c’est aussi une mauvaise allocation des ressources, et c’est difficile à accepter pour le candidat
Dans l’idéal, le candidat viendrait au bureau et réaliserait seul un petit projet de code sur une journée, mais en pratique ce n’est pas réaliste