Panique sur le marché de l’emploi

• Le marché de l’emploi tech a évolué dans un sens défavorable aux développeurs, sous l’effet combiné de la hausse des taux d’intérêt, du recul du financement VC, de la contraction des dépenses des clients et de la standardisation des processus de recrutement
• Selon la trésorerie, le chiffre d’affaires et le stade de croissance d’une entreprise, la rémunération et la stabilité varient, et dans un environnement de taux élevés, les sociétés à forte dépendance au capital-risque sont les plus susceptibles de s’effondrer ou de se replier en mode survie
• Le recrutement tech moderne privilégie les tests de code et les entretiens comportementaux au détriment de l’expérience réelle du travail, en recopiant des procédures similaires des petites startups jusqu’aux grandes entreprises technologiques
• Les offres d’emploi façon « Everything Bagel » fusionnent dans un seul poste le travail de plusieurs équipes : développement applicatif, infrastructure, sécurité, support client, astreinte, optimisation des coûts, documentation, etc.
• Les métiers de la tech passent d’un rôle consistant à améliorer à la fois le produit et l’organisation à un rôle d’exécutant chargé d’appliquer les priorités d’autrui avec peu de marge de manœuvre, sans refléter correctement l’expérience ni le jugement des développeurs expérimentés

---

Le lien entre taux d’intérêt et emplois dans la tech

• Le point de départ est la fin d’un environnement de taux bas, proche de « l’argent gratuit », les taux étant remontés à plus de 5 %, ce qui renchérit le coût même de l’argent
• Quand les taux sont élevés, les organisations disposant de liquidités peuvent placer leur argent dans des options plus sûres, comme des produits de taux garantis par l’État, plutôt que d’investir dans des entreprises incertaines
• L’investissement dans les entreprises technologiques est considéré comme un actif risqué exposé à un futur incertain ; en période de taux élevés, les entreprises fragiles tombent et même les plus solides réduisent leurs effectifs au nom du « clean house »
• Il en résulte l’observation que des centaines de milliers de travailleurs tech très bien rémunérés se retrouvent face à un marché en manque d’emplois pendant 2 à 4 ans
• En période de hausse des taux, les emplois à temps partiel au salaire minimum ou dans la construction peuvent augmenter, mais les emplois tech restent bien plus étroitement liés au financement VC et aux dépenses des clients

Types d’entreprises et structure de rémunération

• Les entreprises technologiques se divisent en quatre catégories selon leur financement et leur stade de croissance
  • nepo company : entreprise capable de produire des produits irréalistes grâce à des financements issus de la famille, des relations ou d’autres sources déconnectées de l’épreuve du réel
  • speculation company : entreprise financée pour expérimenter des idées sans validation du produit, des clients ou du marché
  • initial growth company : entreprise qui, après l’apparition d’une demande initiale, cherche à accroître son chiffre d’affaires grâce à des financements de croissance
  • stable era company : entreprise stable disposant d’une stratégie répétable d’accès au marché, d’un accès aux clients et de revenus récurrents
• Dans un environnement de taux élevés, les entreprises les moins réussies dépendent davantage du financement VC et sont les plus secouées quand les flux de capitaux ralentissent ou disparaissent
• Les clients aussi voient leurs conditions de dépense se resserrer, ce qui peut entraîner en parallèle de l’attrition et une baisse des dépenses
• La speculation company est décrite comme un type d’entreprise qui paie entre 50 et 80 % du marché tout en attendant 200 à 500 % de travail en plus
• La initial growth company peut cumuler haut risque et faible rémunération, et lorsqu’une entreprise de croissance échoue, elle peut rester enfermée dans une combinaison de faible rémunération et de licenciements répétés
• Les stable era companies se divisent à nouveau en trois types
  • les entreprises qui croissent de manière stable tout en étant rentables
  • les entreprises qui alternent croissance et contraction selon les penchants d’un CEO célèbre
  • les entreprises qui dominent un ou plusieurs secteurs de l’économie et se cassent difficilement
• Les grandes entreprises modernes en phase de croissance peuvent, avec la rémunération annuelle en actions, offrir à des employés expérimentés l’équivalent de 10 000 à 50 000 dollars par jour, tandis que d’autres sociétés peuvent connaître dix ans sans hausse réelle des salaires ni rémunération en actions réellement valable

Des processus de recrutement incapables de distinguer les compétences réelles

• Trois contradictions reviennent sans cesse dans le recrutement tech
  • les exigences sont cassées
  • les processus d’entretien sont cassés
  • la plupart des entreprises suivent les mêmes exigences et les mêmes méthodes d’entretien
• Un recruteur peut ne pas être capable d’évaluer de manière fiable un candidat qui donne une meilleure réponse que celle qu’il attendait lui-même
• L’entretien tech moderne exige la réalisation improvisée de tâches sans rapport avec le travail réel ; l’échec conduit à considérer le candidat comme peu compétent, sans pour autant permettre d’identifier les profils de niveau supérieur
• Les tests de code façon Google et les entretiens comportementaux façon Amazon sont copiés dans toute l’industrie, des petites startups aux grandes entreprises
• Les entretiens comportementaux répètent des questions comme « Comment avez-vous résolu un conflit ? » ou « Parlez d’une erreur pour laquelle vous avez présenté vos excuses », et sont interprétés ici comme une façon d’observer comment le candidat gère l’équilibre entre progression et bienveillance
• Le fait de coder l’adéquation culturelle sous forme de questions-réponses peut conduire à une homogénéisation des personnalités, en filtrant les personnes qui s’écartent du tempérament moyen de l’entreprise
• À mesure que les entreprises ajoutent des étapes d’entretien tout en s’éloignant du travail réel, de l’expérience, des compétences et de la compréhension, l’ensemble de l’industrie tech peut devenir inefficace

Les offres d’emploi « Everything Bagel »

• Une offre d’emploi « Everything Bagel » est un type d’annonce qui demande à un seul Software Development Engineer d’assumer trop de responsabilités à la fois
• Exemples d’exigences mentionnées
  • écrire des applications en React, Vue, TypeScript, Node, Python, Rust et Go
  • maintenir des applications existantes en PHP, Ruby et C
  • déployer l’infrastructure avec AWS, Docker, Kubernetes, Terraform, Lambda, EventBridge et Step Functions
  • optimiser les coûts AWS, gérer le CI/CD, l’astreinte 24/7, les logs, le monitoring, les alertes et l’observabilité
  • assurer la sécurité des applications, la sécurité des dépendances et la sécurité d’infrastructure liée à SOC-2
  • faire du support client, du support interne, de la revue de code, du mentorat et de la documentation
  • maintenir 37 plugins JavaScript SaaS et des scripts de tracking supplémentaires
• Ce type d’exigences pour un seul poste correspond en réalité à un travail de 5 équipes et d’une vingtaine de personnes
• Une partie du secteur est vue comme ayant abandonné l’idée que les techniciens doivent avoir une spécialisation, en reportant aussi l’exploitation sur des développeurs sans expérience opérationnelle, selon la logique « devops means DEVS DO OPS »
• On ne peut guère espérer de bons résultats quand un développeur applicatif doit aussi jouer le rôle d’architecte AWS à temps partiel, d’autant que ce type de compétence demande en général plus de 5 ans d’effort concentré
• Des exigences excessives rendent le travail physiquement impossible ; chaque item peut représenter plusieurs jours de travail par semaine, si bien qu’on commence déjà en retard dès le premier jour

Problèmes d’organisation et d’infrastructure vus sur le terrain

• Plusieurs entreprises affirmaient que « le site est lent », alors qu’en réalité elles ne surveillaient même pas les métriques AWS de base ni l’administration du système, laissant les problèmes s’installer
• Une entreprise faisait tourner tout son service sur un unique MySQL à 2 cœurs et 16 Go de RAM ; la base de données avait atteint 3 To et le CPU restait à 99,99 % pendant deux ans
  • Après passage à un serveur ARM de 64 Go avec des reserved IOPS, le temps de transformation des données par batch est passé de 16 heures à 20 minutes, et le retard de réplication de 4 à 6 semaines à un niveau quasi temps réel en dessous de la seconde
• Une autre entreprise dépensait 5 000 dollars par mois pour un cluster de recherche inutilisé, tout en n’utilisant qu’environ 500 dollars de ressources mensuelles pour le cluster réellement en production
  • Après déplacement des ressources vers le cluster de production et migration vers ARM, le temps de réponse utilisateur est passé de 7 secondes à 200 ms
• Une entreprise dont l’API interne de traitement de données tournait sur les deux mêmes EC2 2 cœurs que le serveur web client mettait 20 heures à exécuter les batchs
  • Après migration vers des conteneurs à autoscaling basés sur ECS-on-EC2, 20 à 50 conteneurs traitaient en parallèle et le temps de traitement est tombé à 30 minutes
• Une entreprise dont l’outil de transfert de données de MySQL vers Redshift prenait 80 heures exécutait d’abord SELECT COUNT(*) sur une table de 3 milliards de lignes, puis parcourait toute la table avec LIMIT/OFFSET
  • En introduisant des curseurs de base de données, l’écriture en streaming vers S3 et la compression en mémoire, le temps d’extraction est passé de 80 heures à 40 minutes
• Si l’on sous-estime l’expérience en administration système et en architecture au nom du « cloud native », il peut ne plus y avoir personne pour détecter les problèmes, qui restent alors ignorés pendant longtemps
• Même quand les clients partent, certains VC exigent « plus de commerciaux », ce qui aboutit parfois à des structures avec 5 développeurs pour 50 personnes en vente et marketing
• Lorsqu’une entreprise en baisse de chiffre d’affaires s’accroche à son idée initiale et à une stratégie centrée sur la vente au lieu de pivoter ou d’améliorer le produit, les développeurs ne peuvent pas construire le produit souhaité et l’entreprise finit par échouer

Un marché de l’embauche où l’expérience et les réalisations réelles sont ignorées

• L’idée de fond est que le mode de recrutement tech est passé, en 10 à 20 ans, d’une évaluation simple du fait de « bien se débrouiller avec un ordinateur » à une structure centrée sur le statut social et les jeux d’entretien
• La résolution improvisée de problèmes et la manière d’en parler pèsent davantage que le travail réel, l’expérience et les compétences
• Les projets personnels et les réalisations concrètes ne seraient pas non plus suffisamment pris en compte dans l’évaluation en entretien
  • mpreg : système de traitement de données distribué avec résolution automatique de dépendances par tri topologique hiérarchique
  • Amélioration du traitement CRC : code mentionné comme utilisé pour des formats de fichiers mondiaux et la validation d’informations de station spatiale
  • icli : CLI pour le trading d’actions manuel et automatisé
• L’industrie se serait rapprochée du statut social, politique et du pouvoir davantage que des compétences réelles, avec l’idée que le recrutement devrait aller dans le sens de créer plus de « nous »
• Le secteur confie à une seule personne des tâches beaucoup trop larges tout en n’évaluant pas suffisamment l’expérience réelle lors de l’embauche, créant une structure difficilement tenable pour les candidats

La marge de manœuvre des développeurs et le pilotage produit

• La conclusion est que les emplois de l’industrie tech étaient liés à des financements spéculatifs excessifs, et qu’avec la baisse des capitaux et des clients, les emplois ont disparu eux aussi
• De nombreux rôles tech se seraient transformés en positions de « software servant », chargées d’exécuter les tâches et priorités définies par des équipes produit non techniques
• Dans un modèle d’Engineering-led management, ce sont les personnes qui font le travail qui définissent le produit, parlent aux utilisateurs, établissent les exigences et implémentent les fonctionnalités
• Le rôle du développeur consistait autrefois à résoudre des problèmes à l’échelle de l’ensemble du business, mais il se rapprocherait aujourd’hui d’un rôle d’exécutant de gestion de projet, chargé d’appliquer les idées et priorités d’autres personnes
• À rôle et effort égaux, les écarts de rémunération se sont creusés : 400 dollars par jour dans une entreprise, 20 000 dollars par jour dans une autre, ce qui renforce le sentiment d’impuissance des candidats
• Construire de bons produits, de bons systèmes, ainsi que des produits et une économie en croissance reste la direction vers laquelle les techniciens devraient tendre

[GN⁺]

Avis de Hacker News

• Ce n’est pas un problème propre au génie logiciel ou aux secteurs voisins. Des connaissances en Europe, dans des domaines très différents allant de la finance à la mode, essaient aussi de changer de poste ou d’obtenir une promotion verticale ou horizontale, mais échouent assez lourdement
  La plupart des recrutements aujourd’hui ne regardent pas le parcours d’une personne ni ce qu’elle pourrait apporter : ils consistent surtout à faire franchir des filtres les uns après les autres. Un CV déposé sur un portail d’emploi ressemble davantage à un sédiment qui coule tout au fond de la pile ; il vaut donc mieux utiliser autant que possible son réseau et ses connaissances
  Moi aussi, j’ai été touché par la baisse des emplois tech, et après avoir essayé d’entrer dans une société de conseil en logiciel, je suis resté 8 mois sur le banc. J’ai fini par partir et revenir à l’évaluation d’entreprises et fiscale ; même le sous-emploi vaut mieux que rien, surtout mentalement
  La source originale contient aussi une petite formule : « j’ai glissé sur cette banane comme un singe paresseux »

  • Le point central, c’est que « le recrutement aujourd’hui multiplie les filtres sans regarder le parcours des personnes ni ce qu’elles pourraient apporter ». Lors d’une candidature précédente, on m’a posé des questions du genre « avez-vous de l’expérience en C++ ou en algorithmes de graphes avancés ? », alors que rien de tout cela ne figurait dans mon profil ni dans mon CV
    Et pourtant, ils ont réagi comme si mes 10 ans d’expérience en logiciel et domaines connexes étaient soudain devenus nuls et non avenus. Traiter quelqu’un qui a appris et utilisé plusieurs langages comme s’il était incapable de faire du C++ parce qu’il n’en a utilisé qu’un peu, implicitement, c’est étrange
    Une entreprise avait écrit dans son annonce que l’expérience Python n’était pas nécessaire, puis a enchaîné, dès le premier entretien téléphonique, des questions d’implémentation Python bas niveau. Dans ce cas, je ne comprends pas pourquoi ils font passer un entretien : c’est une perte de temps pour tout le monde
    Au final, les entreprises ne savent absolument pas recruter et, pour les mêmes raisons, ne savent pas non plus faire du mentorat ni former. Cela dit, du point de vue des candidats, cela peut aussi servir de filtre naturel : un endroit qui ne sait pas recruter a de bonnes chances de ne pas être un bon endroit où travailler
  • Ces dernières années, j’ai mentoré des diplômés en informatique, et il arrive que certaines entreprises demandent, dans le processus d’entretien, des exercices excessifs du type construire une application ou un site web entier. Dans ces cas-là, je conseille de refuser, mais en pratique c’est plutôt rare
    Beaucoup se plaignent aussi de procédures d’entretien trop longues, mais quand on creuse, il s’agit souvent de 4 à 5 heures au total. Les standards de l’époque où l’on embauchait après seulement quelques entretiens courts, il y a quelques années, ont déformé les attentes ; les jeunes ingénieurs embauchés à ce moment-là semblent désormais trouver toute quantité d’entretiens déraisonnable
    Comme Reddit dit de refuser tous les exercices, je dois souvent convaincre des gens de ne pas rejeter même un exercice simple de moins de 60 minutes. C’est frustrant de voir quelqu’un au chômage depuis des mois « courageusement » refuser encore une tâche qui pourrait faire avancer sa candidature avec un investissement de temps minimal
    Autre problème : les personnes qui arrêtent leur recherche dès qu’une entreprise leur répond. Il faut leur répéter que la recherche d’emploi n’est pas un traitement séquentiel, mais un traitement parallèle. Passer un entretien avec une seule entreprise lente puis attendre des mois une réponse désavantage fortement le candidat
    Il existe clairement des boucles d’entretien excessives, mais dans le cas moyen, je ne pense pas que ce soit aussi mauvais que ce qu’on lit sur Internet
  • Le titre semble avoir plus ou moins fonctionné, mais la partie Minions semble avoir beaucoup moins bien pris
    La sortie d’exemple prétend résumer « Panic! at the Tech Job Market » avec une formule comme LIKE SLUGS THROUGH THE HOURGLASS, THESE ARE THE DAYS OF OUR TECH TRIUMPHS, puis organise les taux d’intérêt, le recrutement tech et les types d’entreprises, mais elle ne semble pas avoir vraiment répondu aux consignes Minions
  • L’Union européenne est dans une forme de récession, et le lien entre taux d’intérêt et chômage est bien connu. Il n’est donc pas surprenant qu’il soit devenu plus difficile de trouver un emploi en Europe après la hausse des taux par la BCE. Heureusement, les taux baissent désormais
    Ce qui demande vraiment une explication, c’est pourquoi seul le secteur tech américain a connu licenciements et gels des recrutements alors que le marché de l’emploi américain dans son ensemble est resté exceptionnellement solide pendant plusieurs années. La réponse semble être les taux d’intérêt, mais il faut expliquer correctement pourquoi la tech est plus touchée que des secteurs comme le voyage ou les loisirs
    Personnellement, je pense que les taux d’intérêt jouent un rôle en périphérie, mais prendre février 2020 comme point de référence du recrutement tech, comme le fait l’auteur, n’était pas une bonne idée. Janvier 2020 et la période précédente étaient relativement normaux, mais la pandémie a fait exploser le recrutement tech, faisant passer le graphique de 70 à 220
    Si l’on fait trois ans de recrutement en un an, il faut bien s’arrêter à un moment, et la hausse des taux a servi de signal d’arrêt. Comme cela a coïncidé avec une période où tous les autres secteurs étaient, de fait, en congé forcé sur instruction du gouvernement, cela explique aussi pourquoi la tech paraît différente des autres secteurs en 2024
  • La formulation de la source originale m’a amusé, alors j’ai demandé à ChatGPT de résumer la page pour voir s’il suivrait les consignes ; il m’a sorti un court paragraphe sur le revenu de base. Or il n’y avait rien de tel dans le texte original
    Quand je lui ai demandé pourquoi il s’était trompé, après avoir prétendu qu’il venait de faire un résumé, il a répondu qu’en réalité il ne pouvait pas résumer une page web. Je lui ai dit que ça n’avait aucun sens ; le message a alors été supprimé et une notification indiquant une violation de la politique de contenu de ChatGPT est apparue
    Au final, l’ordinateur a menti une fois, puis encore une fois, puis il a censuré la réaction par peur qu’elle ne vexe l’ordinateur. Je ne comprends pas comment les gens utilisent ce genre de déchets
    En essayant avec Gemini, j’ai obtenu un résumé sur les taux d’intérêt et les licenciements, ce qui était plus proche du résultat attendu

• Il m’arrive de déprimer en pensant que je gagne moins de la moitié de la rémunération chez Google, mais quand j’ouvre les yeux, je vois les enseignantes de maternelle de ma fille s’occuper de 30 tout-petits en gagnant même pas la moitié de ce que je gagne. Les infirmières et les médecins travaillent dans des conditions où il est difficile de tenir ne serait-ce que quelques mois, et c’est pareil pour les supermarchés, les stations-service, la police, les pompiers, le travail social et les enseignants.
  Du coup, je ne sais pas vraiment de quoi nous devrions nous plaindre. Qu’il s’agisse de la rémunération « basse » d’une startup de 3 personnes ou autre, nous sommes très bien payés pour résoudre des puzzles de code toute la journée.
  Mieux vaut arrêter de se comparer à son ami qui travaille chez Google, et apprendre à cultiver un état d’esprit paisible et heureux.

  • En tant que Xoogler, je dirais que Google n’est plus ce qu’il était. En échange de salaires élevés, il faut accepter le fait que la plupart des gens avec qui vous travaillez se demandent surtout combien d’argent supplémentaire ils peuvent soutirer à Google.
    S’occuper de jeunes enfants semble, même en apparence, être une meilleure façon d’employer l’unique vie qui nous est donnée.
  • Il m’arrive d’avoir du mal à croire qu’il soit éthique de gagner autant d’argent avec si peu d’efforts. Un jour, en télétravail, je visitais le village avec ma femme ; j’ai payé 500 Kč pour une addition de 360 Kč, et en voyant la serveuse paniquer parce qu’elle ne savait pas combien rendre, j’ai immédiatement eu ma réponse.
  • Mon père a récemment pris sa retraite après avoir travaillé comme concierge dans une école, et il disait être enfin soulagé tant ce travail broyait les gens. Mon conjoint est infirmier et redoute régulièrement d’aller travailler. Moi, en revanche, je ne redoute pas d’aller au travail ; j’ai même l’impression de progresser.
    Je pense que je continuerais à faire ce métier même si je n’avais pas besoin d’argent. Je peux faire quelque chose que j’aime vraiment, utiliser mes compétences pour être utile et rendre d’autres personnes heureuses. Et en plus, je gagne environ trois fois plus que mon père et mon conjoint.
    Beaucoup de gens sur HN vivent dans une bulle. Ils n’ont aucune idée de ce qu’est le monde extérieur. En pratique, ils ont été traités comme des membres de la royauté. Où qu’il soit, personne n’aime qu’on lui retire ce qu’il possède ni reculer. Même quand on a commencé plus loin que le point d’arrivée de quelqu’un d’autre.
    Pensez-vous que la programmation ne sert à rien ? Pensez-vous qu’aucune entreprise n’a besoin de technologie ? Vous finirez simplement par travailler dans des entreprises utiles qui contribuent réellement à la société, plutôt que dans des entreprises tech qui fabriquent des choses addictives pour vendre de la publicité.
  • Il faut se plaindre de tout ce qui vient d’être dit. Tout le système est cassé.
    Tout le monde devrait avoir le droit de vivre sans être soumis à des conditions aussi terribles, mais nous continuons à le permettre socialement parce que nous ne les considérons pas comme nos égaux. Quand on peut personnellement s’en sortir, il devient facile d’ignorer la souffrance que les autres endurent.
    Si tout le monde pouvait vivre mieux, j’accepterais volontiers d’avoir moins. En réalité, l’accumulation de richesse est tellement énorme qu’il ne serait même pas nécessaire de sacrifier tant que ça. Il suffirait de redistribuer cette richesse.
    Il ne faut pas essayer de résoudre des problèmes systémiques par des solutions individualistes. Je ne vois pas comment avoir l’esprit paisible et heureux quand tout le monde souffre en dehors de notre petite bulle.
    L’attitude consistant à dire « notre bulle est moins mauvaise que les autres, alors soyons heureux » est tragique. Il faut se rappeler que nous sommes tous dans le même bateau.
  • Comme je travaille dans le jeu vidéo, mon objectif n’a jamais été de viser une rémunération totale de plus de 300 000 dollars.
    Mais travailler dans le jeu vidéo signifie aussi qu’il faut, dès le départ, renoncer dans une certaine mesure à l’idée d’un « esprit paisible et heureux ».

• Avant, je pensais que les entretiens de code étaient un rite de passage sans aucun rapport avec le travail quotidien, mais après être revenu sur le marché de l’emploi en tant qu’ingénieur senior/staff après une longue pause, je penche à contrecœur vers l’idée qu’ils ne sont peut-être pas si mauvais.
  J’ai l’impression de les réussir grâce aux compétences accumulées ces dernières années, et si c’est le cas, les entretiens de code captent peut-être bien un certain signal. Plus je deviens senior, plus je m’éloigne de l’idée que les entretiens de code sont totalement dénués de sens.

  • Il y a plusieurs types d’entretiens de code. Poser des questions de base directement applicables au travail, filtrer les connaissances fondamentales pour vérifier que la personne n’a pas menti sur son expérience, observer le raisonnement et s’assurer qu’elle peut produire du code fonctionnel, tout cela me paraît acceptable.
    En revanche, demander de résoudre sur-le-champ, dans un temps limité, des problèmes extrêmement obscurs qui n’ont rien à voir avec le travail quotidien, puis éliminer la personne si la réponse est fausse ou pas optimale, ressemble davantage à un processus pour filtrer des débutants exploitables à bas coût.
  • À mon avis, il existe deux types de programmeurs : ceux qui peuvent écrire du code pour construire quelque chose, et ceux qui peuvent construire quelque chose tout en étant assez à l’aise pour expliquer oralement la théorie de l’écriture de code. Le deuxième groupe est cinq fois plus utile que le premier, et les entretiens de code testent à quel groupe on appartient.
    Le premier groupe a tendance à penser que l’aisance théorique n’est pas importante, mais lorsqu’il faut résoudre de vrais problèmes, c’est le deuxième groupe qu’on recherche. Une équipe qui sait seulement écrire du code sans pouvoir théoriser à son sujet risque d’empiler des montagnes de déchets que quelqu’un d’autre devra reconstruire plus tard.
    Bien sûr, certaines personnes n’arrivent pas à théoriser rapidement, ou pas devant d’autres, ou pas dans une situation d’entretien très stressante. Il faut régler ces problèmes de format. Les questions obscures de culture générale sont également inutiles.
    Malgré tout, l’objection de base selon laquelle « les tests de code n’évaluent pas les compétences nécessaires au travail quotidien » me paraît étrange. Ce ne sont pas des compétences utilisées tous les jours, mais ce sont des compétences qu’il faut pouvoir mobiliser quand c’est nécessaire, et elles soutiennent le travail quotidien. C’est comme un mécanicien : il n’utilise pas la théorie du moteur tous les jours, mais je n’aurais pas envie de laisser longtemps ma voiture à un mécanicien qui ne comprend pas le fonctionnement d’un moteur.
  • Je n’ai jamais compris pourquoi les gens détestent autant les entretiens de code. Du point de vue de l’employeur, il est normal de vouloir vérifier un minimum les capacités réelles, au-delà de l’impression donnée à l’oral.
    J’ai vu beaucoup de solutions absurdes de la part de candidats. On leur donne un kata très simple : prendre un petit programme qui produit une sortie console, le refactorer proprement et ajouter une fonctionnalité ; la moitié n’arrive même pas à le faire fonctionner. Beaucoup ne font aucun effort sur la propreté du code. Tout ce qui est demandé, c’est de le faire fonctionner et de le rendre présentable.
  • La dernière fois que j’ai passé des entretiens et résolu quelques problèmes LeetCode, la plupart se résolvaient trivialement par une combinaison d’implémentation d’itérateurs, d’opérations de réduction, puis d’ajout de mémoïsation si nécessaire.
    Tous les problèmes ne sont pas comme ça, mais ces trois étapes semblent couvrir assez généralement la plupart des problèmes d’entretien de code de niveau facile ou moyen. Quand je cherchais mon premier emploi, je ne connaissais pas du tout ce genre de choses, donc j’ai eu l’impression que les problèmes d’entretien de code devenaient plus faciles avec le temps.
    Même si je n’ai pas beaucoup utilisé Python en pratique, le mot-clé yield est presque de la triche sur les problèmes LeetCode.
  • Personnellement, les tours de code pour les postes senior/staff sont devenus plus faciles. Même avec les mêmes questions, l’expérience de l’intervieweur et les signaux recherchés sont différents : on regarde la résolution de problème, la communication, les tests, etc.
    Les tours de code pour les niveaux junior et « SDE II » ont une toxicité particulière : des SDE tout juste promus les transforment en compétition entre le candidat et eux-mêmes. Il m’est même arrivé qu’un intervieweur soit vexé parce que j’avais proposé une solution plus simple que celle qu’il avait imaginée.

• Le texte en lui-même est globalement bon, mais l’auteur semble surestimer fortement les niveaux de rémunération. Il y a un passage où il dit qu’un fabricant de tracteurs, une entreprise stable et non tech, paie 5 000 à 10 000 dollars par jour.
  Même en incluant les taxes, en divisant par deux, et en ne parlant que des employés software, une rémunération moyenne de près d’un million de dollars par an n’a aucun sens. La moyenne des ingénieurs software aux États-Unis est d’environ 135 000 à 150 000 dollars, et cette moyenne inclut aussi les ingénieurs FAANG dans les tranches de rémunération les plus élevées.

  • L’ensemble du texte ressemble surtout à une exagération qui n’ajoute pas grand-chose au-delà de « quand les taux d’intérêt montent, les financements en capital-risque diminuent ». Même en incluant les avantages, les chiffres sont énormément gonflés.
    Il existe bien des individus qui touchent ce niveau, mais d’après ce que j’avais entendu, une rémunération totale annuelle de plus d’un million de dollars correspondait au niveau des ingénieurs des premiers temps de Google, du calibre licorne.
  • À 5 000 à 10 000 dollars par jour, sur une base de 250 jours ouvrés par an, cela fait 1,25 à 2,5 millions de dollars par an. Je ne sais pas d’où vient l’idée qu’un fabricant de tracteurs paierait ça.
    C’était probablement une faute de frappe avec un zéro en trop. 500 à 1 000 dollars par jour, cela ferait 125 000 à 250 000 dollars par an, ce qui est beaucoup plus plausible.
  • Il utilise peut-être un calcul du genre « rémunération journalière moyenne calculée sur les jours réellement travaillés pendant toute une carrière, en tenant compte de la croissance exponentielle des actions ».
    Dans le texte original, il est dit que, dans l’environnement technologique moderne, les entreprises stables de « croissance hyperscale » versent aux profils expérimentés l’équivalent de 10 000 à 50 000 dollars par jour, en incluant la valeur des actions qui croît exponentiellement chaque année.
    Un salaire de 250 000 dollars ne fait qu’environ 1 000 dollars par jour, mais si l’on peut accumuler 50 millions de dollars en actions d’entreprises à forte croissance sur une carrière de 40 ans, cela donne en moyenne 5 000 dollars par jour.
    C’est un calcul assez douteux, qui aurait dû être expliqué plus clairement, et cela reste une hypothèse très ambitieuse, mais d’après les indices disséminés dans le texte, c’est probablement ce qu’il voulait dire.
  • Sous la mention « available for employment » de son CV, il y a un lien vers la rémunération Google L10 et un poste d’Amazon distinguished engineer. Il semble donc que son niveau de référence attendu en matière de rémunération se situe dans le top 0,01 %, voire au-delà, de l’échelle des ingénieurs software.
  • C’est absurde. Il n’a aucune notion du marché de la rémunération, et si ses attentes sont à ce point décalées, ce n’est pas surprenant qu’il ne soit pas embauché.
    Cela se voit aussi dans son CV : il semble penser que son niveau approprié chez FAANG serait L10. C’est un niveau extrêmement rare, et avec son parcours, il a 0 % de chances d’être calibré à ce niveau.
    Tout le texte peut se résumer à un sentiment de légitimité excessivement gonflé.
    https://matt.sh/files/a-resume/resume.html

• Cet auteur est connu pour avoir un sentiment de légitimité étonnamment élevé. Après quelques contributions mineures à Redis, il a tenté une prise de contrôle hostile.
  Vu sous cet angle, ce n’est pas très surprenant qu’il ait du mal à trouver un emploi correspondant à ses attentes.
  https://news.ycombinator.com/item?id=9176800

  • Quand antirez dit que « les personnes ayant apporté des contributions importantes à la base de code de Redis se comptent sur les doigts d’une main, et il resterait encore des doigts ; Matt Stancliff est l’une d’elles », il semble bien qu’il ait été un contributeur clé.
    Cela dit, l’affaire citée date pas mal et a peu de rapport avec le sujet actuel. Son fort sentiment de légitimité est quand même un peu gênant.
    https://groups.google.com/g/redis-db/c/PxFeA0fHgO4/m/zD4IWbXlMOgJ
  • Comme c’est un long texte, j’ai d’abord compati, mais au bout de quelques centaines de mots, cela ressemblait surtout à une plainte du type « pourquoi mon travail, manifestement suffisant, ne débouche-t-il pas sur une embauche ? ». Cela tient davantage du sophisme et d’un ego un peu surdimensionné que d’une preuve concernant l’ensemble du marché de l’emploi.
  • Il semble avoir acquis aujourd’hui une certaine conscience de lui-même. Mais à l’époque où il a fait cette proposition étrange à la conférence, il est très probable que ce n’était pas le cas.
    À voir le lien GitHub Sponsors en haut du texte, il semble convaincu que quelqu’un souscrira à un sponsoring de 12 000 dollars par mois.
  • Ces contributions n’étaient pas mineures. Je ne vois pas de quoi tu parles.

• Comme le dit l’expression, « si ça a l’air idiot mais que ça marche, ce n’est pas idiot » : s’il était assez intelligent pour voir tous les problèmes de ses anciens employeurs et que ces entreprises ont quand même échoué, peut-être qu’il n’était pas l’employé idéal qu’il pense être. S’il estime que les entretiens de programmation sont trop bas de gamme pour lui et ne laissent passer que des gens inférieurs, mais qu’il ne peut pas payer son loyer, peut-être que ces entretiens ne sont pas si bas de gamme que ça.
  Réduire une requête de 7 secondes à 40 ms, ou un traitement batch de 40 heures à 20 minutes grâce à ses connaissances d’AWS, fait rarement la différence entre le succès et l’échec d’une entreprise. Les dysfonctionnements de management, eux, font souvent cette différence ; mais si l’on se contente de les retenir comme matière à billets de blog cyniques, cela ne donne pas de raison de vous embaucher.
  Souhaiter que les entreprises gèrent mieux leurs systèmes, c’est une bonne chose jusqu’à un certain point, mais se concentrer trop fortement sur la conception de bases de données et la réduction des coûts AWS, c’est devenir le tailleur de pierre du milieu dans la fable de McKinsey.

  • Tu veux dire qu’en tant qu’administrateur système, il aurait aussi dû résoudre les problèmes de produit, de vente et de marketing ? À certains postes, les choses que l’on peut faire sont limitées. Même quand on signale aux gens qu’ils sont en train de commettre des erreurs coûteuses, il peut être vraiment difficile de les convaincre.
    Si l’équipe marketing fait n’importe quoi, on peut dire « le marketing est catastrophique », mais au-delà du signalement, il est difficile d’agir. Même en le formulant de manière très diplomate, si l’on n’est pas assez haut dans la hiérarchie, c’est difficile à corriger depuis l’ingénierie.
    Une fois, un ami du CEO est arrivé comme nouveau responsable marketing ; j’ai exprimé poliment mes inquiétudes sur ses décisions marketing, et le CEO m’a remonté les bretelles. Ensuite, ce responsable a abîmé la marque et semé la confusion chez les clients.
  • S’il était assez intelligent pour voir tous les problèmes et que l’entreprise a échoué, il était peut-être au contraire l’employé idéal.
    Dans la plupart des rôles, techniques ou non, les recruteurs préfèrent quelqu’un à qui l’on dit « saute » et qui répond « à quelle hauteur ? », plutôt que quelqu’un qui répond « non » ou « pourquoi ? ».
    Il faut être assez senior pour bien faire le travail, mais pas au point que son manager se sente junior face à vous.
  • C’est une interprétation mignonne de croire que voir les problèmes et recevoir l’autorité pour les résoudre vont toujours ensemble.
    Tu es probablement l’un des intervieweurs ou employés dont parle le texte.
  • Je me demande quelle est la fable de McKinsey.
  • Son ton et celui-ci semblent coupés dans le même tissu.

• La situation actuelle est vraiment mauvaise, mais d’après ce que je comprends, ce sont les jeunes diplômés et les juniors qui souffrent le plus. Comme le secteur paraissait très rentable, beaucoup de gens se sont rués vers le software engineering, et il y a eu une surproduction de diplômés en informatique.
  Il est difficile de convaincre une startup de parier sur quelqu’un sans expérience, et les entreprises matures préfèrent aussi embaucher un senior au prix de 1,5 personne pour lui faire faire un travail similaire, plutôt que de payer deux juniors. Avant, même les entreprises de catégorie C avaient des pipelines menant des stages à des postes à temps plein, mais aujourd’hui cela semble beaucoup plus rare.
  La hausse des taux d’intérêt, les investisseurs qui ne cherchent que ce qui est en vogue, et l’incertitude à court terme semblent avoir rendu plus difficile de convaincre les investisseurs de financer de nouveaux produits ou fonctionnalités, ainsi que la croissance des effectifs d’ingénieurs nécessaires.
  Ces dernières années, beaucoup de personnes talentueuses ont été licenciées, ce qui donne aux entreprises un net avantage dans le recrutement. Beaucoup d’entre elles sont prêtes à accepter de fortes baisses de salaire, donc il y a moins de raisons de choisir quelqu’un de moyen.

  • Pour moi, cela a été exactement l’inverse. Les deux dernières années ont été la meilleure période que j’aie connue dans la tech depuis le début des années 2010.
    Vers 2019, j’ai sérieusement envisagé de quitter le secteur. Toute l’industrie s’était transformée en grind LeetCode, en course à la rémunération totale, et en armée de drones ordinaires. Il était difficile de trouver des gens qui travaillaient sur des problèmes exigeants et intéressants, sans même parler de vrais problèmes, et les personnes avec qui je travaillais ne s’intéressaient absolument pas à la programmation ni à l’informatique.
    Mais ces deux dernières années, j’ai travaillé avec plusieurs équipes qui faisaient des choses vraiment chouettes, et j’ai aussi rencontré des équipes composées uniquement de personnes tenaces et brillantes. En particulier, on a commencé à construire des projets en utilisant de nouvelles astuces et techniques autour de l’IA.
    Aujourd’hui, beaucoup de petites équipes qui résolvent des problèmes difficiles sont financées, et on recommence à trouver des programmeurs intéressants, talentueux et franchement bizarres. Les gens qui aiment construire des choses et résoudre des problèmes retrouvent du travail.
    En tenant compte de l’inflation, j’ai l’impression d’être payé moins que depuis longtemps, mais le travail est enfin redevenu amusant. Je peux hacker avec des gens obsédés par l’idée de construire.
  • Du point de vue d’une entreprise qui recrute des talents juniors, la proposition de valeur n’est pas particulièrement attractive à cause de la mode récente des changements de poste tous les 1 à 2 ans. Si vous les formez pour qu’ils partent ensuite, ou s’ils exigent dès le départ un salaire permettant d’acheter quelqu’un d’expérimenté, l’investissement perd de son intérêt.
  • Je ne sais pas s’il y a une surproduction de diplômés en informatique, mais je ne vois absolument pas d’excès de juniors engineers correspondant au moins à mes attentes.
    Pour moi, un junior engineer est quelqu’un qui connaît les algorithmes et les structures de données, maîtrise vraiment au moins un langage de programmation, et peut écrire rapidement de petits programmes dans ce langage. Il peut ne pas avoir d’expérience professionnelle, ne jamais avoir travaillé sur un projet de plus de 10 000 lignes, et ne pas connaître CI/CD ou Docker, mais il doit savoir coder.
    Or la plupart des candidats juniors que je vois en entretien ne savent pas coder. Ils ne peuvent même pas écrire 5 lignes de code pendant l’entretien dans le langage qu’ils prétendent préférer. Ce n’est pas différent de postuler comme cuisinier junior sans savoir cuisiner, ou comme chauffeur de taxi junior sans savoir conduire.
    Un junior devrait être « riche en connaissances mais sans expérience », alors que dans l’IT, beaucoup de gens semblent bizarrement considérer que cela veut dire « sans connaissances ni expérience ».
    Si quelqu’un peut me dire où trouver ces junior engineers surproduits, je les recruterai avec plaisir.
  • Une autre raison pour laquelle c’est devenu plus difficile pour les junior engineers, c’est qu’il y a beaucoup plus de nearshore et offshore outsourcing qu’avant. Zoom et consorts sont bien meilleurs qu’il y a dix ans, et tout le monde s’est habitué au télétravail.
    J’ai travaillé avec d’excellents ingénieurs en Amérique latine et en Europe de l’Est, et aujourd’hui c’est presque pareil que de travailler avec des ingénieurs basés aux États-Unis. Leur anglais est bon, les horaires se chevauchent suffisamment, et l’Amérique latine, en particulier, est l’exact opposé du cauchemar de l’outsourcing indien du milieu des années 2000.
    De toute façon, 99 % des interactions avec les gens se font sur Zoom ou Meet, donc l’endroit où ils se trouvent ne change pas grand-chose. Il devient donc difficile de payer un développeur junior américain avec un salaire américain, car pour le même montant, voire moins, on peut trouver un excellent développeur senior en Amérique latine ou en Europe de l’Est.
  • Avant, c’était « un senior au prix de 1,5 personne plutôt que deux juniors », mais aujourd’hui on est plus proche de « on retire carrément l’offre d’emploi et on fait travailler plus dur les seniors existants, parce qu’on sait qu’eux non plus n’ont pas d’options ».
    Plusieurs postes auxquels je candidatais ou pour lesquels je passais des entretiens ont été annulés, et deux amis m’ont dit que la même chose se produisait dans leur entreprise. Dans un cas, une équipe de 5 personnes est devenue une équipe de 2 qui exploite un service critique pour une compagnie aérienne.
    Oui, c’est mauvais pour les nouveaux entrants, et c’est peut-être pire qu’on ne le pense.

• Ces 15 dernières années, j’ai recruté des gens, principalement des ingénieurs, à temps plein, et je suis fortement d’accord avec une bonne partie des critiques de Matt sur le recrutement moderne.
  La plupart des entretiens techniques ont aussi peu de rapport avec la performance au travail que de recruter un boulanger en lui demandant comment les orbitales électroniques créent des liaisons de gluten, puis de l’éliminer s’il ne peut pas dessiner immédiatement une configuration orbitale valide.
  L’analogie de Matt fonctionne bien pour un recrutement transactionnel de type prestataire, mais beaucoup moins dans une situation où les deux parties s’attendent à travailler ensemble pendant plusieurs années. Les entreprises qui recrutent des ingénieurs doivent généralement faire en sorte que les gens cuisent du pain en équipe, et ces équipes sont parfois très grandes.
  Quand les responsabilités deviennent de plus en plus fragmentées, on finit réellement par avoir besoin d’au moins un boulanger capable de dessiner une configuration orbitale valide. Et une fois qu’on a trouvé un boulanger solide en mécanique quantique, il faut encore vérifier que cette personne n’est pas horrible à côtoyer au travail.
  C’est pour cela que le recrutement par recommandation était et reste roi. Le meilleur test pour savoir si quelqu’un travaille bien, c’est de travailler avec lui pendant quelques années.

  • Le recrutement par recommandation n’existe pratiquement nulle part en réalité.
    Même quand je recommandais des personnes que je savais être d’excellents software engineers, au point de mettre mon propre emploi en jeu pour les garantir, elles étaient traitées exactement comme n’importe quel autre candidat.
  • Désormais, c’est la réalité. Même les boulangers passent des entretiens comme ça.
  • Si vous n’êtes pas une entreprise tech du top 1 %, cette logique ne tient pas vraiment. Toutes les entreprises tech pensent qu’elles doivent produire « le meilleur pain » et qu’elles ont donc besoin des meilleurs boulangers.
    Ce n’est pas réaliste, mais si des investisseurs vous donnent des millions de dollars à dépenser, il faut bien les dépenser d’une manière ou d’une autre.
  • Ce raisonnement du type « il faut un boulanger capable de dessiner des configurations orbitales » contribue à ce marché du recrutement toxique.
    Le problème se résume au fait qu’il y a trop de candidats et trop peu de postes. Les histoires d’inflation, de cuisson du pain, de taux d’intérêt ou de team building ne sont que des symptômes d’un sentiment de droit acquis.
    S’il n’y avait eu que deux candidats, vous n’auriez pas pensé comme ça.

• Les calculs « sur un coin de table » de l’article m’ont tous laissé perplexe
  Je ne sais pas d’où vient cette base « par jour ». On ne sait pas clairement s’il s’agit de la rémunération de dirigeants ou de celle d’ingénieurs middle/senior. 5 000 à 10 000 dollars par jour, cela fait 1 à 3 millions de dollars par an ; c’est possible, surtout les années où l’action a beaucoup monté, mais ce n’est pas aussi courant que l’article le laisse entendre
  J’ai aussi du mal à croire que de tels chiffres viennent « non pas de Google ou Apple, mais d’une entreprise de tracteurs ou d’industrie lourde qui performe régulièrement depuis des années ». Il parle de sociétés cachées, mais j’aimerais savoir s’il a des exemples. En général, dans les entreprises non tech, les ingénieurs logiciel sont des centres de coûts, et leur rémunération est bien plus basse
  La note disant « si l’on considère que l’inflation réelle et le coût de la vie augmentent de 7 à 13 % par an » devrait aussi fournir les bases du calcul, si l’on veut soutenir une inflation aussi exceptionnelle sur les dix dernières années

  • Comme l’auteur dit avoir plus de 20 ans d’expérience, il semble en fait se comparer à des postes de niveau VP. Beaucoup de quadragénaires et plus que j’ai rencontrés chez les FAANG étaient effectivement senior staff ou au-dessus, ou director et au-dessus, donc les chiffres ne sont peut-être pas aussi délirants qu’ils en ont l’air au premier abord
    Cela dit, pour atteindre ces montants, il faut sans doute aussi prendre en compte la hausse de la valeur des actions. Et je pense qu’il y a beaucoup plus de gens qui quittent carrément les FAANG que de gens qui y atteignent un niveau VP

• Il y a peut-être de bons points enfouis dans l’article, mais ce qui ressort à la lecture, c’est surtout une amertume avec très peu d’introspection. Il donne l’impression de quelqu’un avec qui il serait difficile de travailler et qui rejetterait la responsabilité sur les autres

  • J’ai commencé à lire, mais dès le début j’ai senti ce ton amer, comme une plainte de 115 000 mots
    Il donne l’impression de se répéter, jusqu’à montrer une photo de lui pour prouver qu’il fait du sport. Chacun sa méthode, mais on peut se demander si ses échecs en entretien ne relèvent pas plutôt d’un problème d’attitude que de compétences
  • Je me suis arrêté au passage du genre : « Je n’ai jamais réussi un entretien de code. Les entretiens de code recrutent les mauvaises personnes ! »
  • Je ne comprends pas pourquoi la rémunération semble être le seul critère pris en compte dans tout l’article. L’argent, c’est bien, mais ce qu’on construit compte aussi, non ?
  • Je comprends la citation : « La comparaison est la pire des émotions et la mort du bonheur. Je compare ma situation à celle de gens entrés chez Apple ou Microsoft il y a vingt ans et qui ne sont jamais partis »
    Mais si l’on a la chance de connaître ce genre de personnes, ne pourrait-on pas aussi utiliser ces relations pour renforcer sa carrière ?
    Certaines personnes entrent dans la bonne entreprise au bon moment et gagnent des millions de dollars, mais si mon prochain poste me rapportait 150 000 dollars, je pense que j’en serais assez satisfait selon la région. Ce serait bien si le télétravail restait largement possible, pour pouvoir vivre dans un endroit où le coût de la vie est plus bas
    Cela dit, l’auteur ne semble pas considérer 150 000 dollars comme une grosse somme, et d’après le contenu de l’article, il a effectivement plus d’expérience et de séniorité que moi