Les compétences réellement exigées

Le socle technique, dit franchement

Python et SQL font l’essentiel du travail. Python parce que l’écosystème est écrit dans ce langage et que l’équipe data du client l’aura déjà. SQL parce qu’une large part du déploiement consiste à rapprocher des enregistrements entre des systèmes qui ne s’accordent pas sur ce qu’est une fiche, et parce que celui qui sait écrire la requête lui-même à onze heures du soir n’est pas bloqué.

Au-delà, l’exigence porte sur l’étendue plutôt que sur la profondeur, et elle est singulière. Vous héritez de ce que le client possède : un schéma d’authentification de 2016, une file de messages que personne ne maintient, un entrepôt de données dans un produit que vous n’avez jamais employé. Personne ne peut se préparer au cas précis. Ce qui se prépare est l’habitude de devenir rapidement productif dans un système inconnu, qui est une compétence réelle et surtout de la pratique.

Du côté des modèles, ce qu’il faut est diagnostique. Pourquoi la recherche remonte-t-elle le mauvais passage pour cette classe de requêtes. Pourquoi le système est-il fluide et faux exactement sur les cas qui comptent pour le client. Pourquoi se dégrade-t-il quand le document est un scan plutôt qu’un fichier. Savoir répondre à cela est le métier ; savoir entraîner un modèle ne l’est pas, et les candidats se sur-préparent sur le second parce qu’il ressemble davantage à un titre.

Les quatre qui décident vraiment

Entendre le vrai problème. Les clients décrivent leurs problèmes dans leur vocabulaire, après les avoir déjà simplifiés, le plus souvent de bonne foi. Le problème énoncé et le problème réel diffèrent la plupart du temps. La compétence est autant une technique qu’une disposition : demander à voir les cinq dernières fois où la chose a été faite, plutôt que de demander comment elle se fait. Les descriptions sont idéalisées, les exemples contiennent les exceptions, et les exceptions sont le projet.

Rester utile quand ce n’est pas technique. Une part importante des déploiements bloque sur quelque chose qu’aucun effort d’ingénierie ne résout : une file de validation, une équipe dont la prime dépend de l’ancien processus, un sponsor qui est passé à autre chose. Les ingénieurs qui considèrent cela hors de leur périmètre se retrouvent bloqués et le restent. Ceux qui réussissent trouvent la plus petite chose qui puisse encore avancer, et maintiennent le projet en vie pendant un mois où rien n’était possible.

Savoir ce qu’il ne faut pas construire. Le jugement le plus précieux du métier, et le plus difficile à prouver, puisque la réussite ressemble à un projet terminé plutôt qu’à un artefact que l’on puisse montrer. Tout déploiement contient trois ou quatre demandes du client qui ne changeront rien. Les construire toutes est la façon dont un projet de six semaines en devient un de six mois. Refuser bien, de sorte que le client se sente entendu plutôt qu’écarté, est la compétence réelle.

Supporter l’ingrat. Le métier contient beaucoup de travail qu’un bon ingénieur produit jugerait au-dessous de son niveau, placé juste à côté d’un travail qui demande une vraie profondeur. Nettoyer un export à la main parce que cela prendra deux heures quand le pipeline propre en prendrait deux semaines. Assister à une réunion pour entendre une phrase. Qui a besoin que tout le métier soit intéressant sera malheureux, et c’est la raison de départ la plus fréquente, avant les déplacements.

Trois exigences affichées qui comptent moins qu’il n’y paraît

Une expertise pointue sur une technologie précise. Les annonces listent ce que les comptes actuels emploient. Le temps que vous soyez productif, les comptes auront changé. Ceux qui recrutent le savent et en tiennent compte, quoi qu’annonce l’offre.

Une expérience préalable du secteur exact. Elle aide réellement, et elle n’est pas la contrainte qu’on imagine. La connaissance d’un métier s’acquiert en quelques semaines par quelqu’un que cela intéresse. L’intérêt, lui, ne s’acquiert pas, d’où la question à préparer : non pas savoir si vous connaissez le secteur, mais s’il vous intéresse assez pour que vous l’appreniez.

Les certifications. Une certification cloud n’est pas un handicap et départage rarement. Elle prouve que vous avez appris quelque chose de structuré, ce qui, dans un métier aussi peu structuré, est un signal faible. Le signal fort est d’avoir livré dans l’environnement de quelqu’un d’autre et de savoir raconter ce qui s’est mal passé.

Ce qu’il faut construire pour le démontrer

Le portfolio qui fonctionne pour ce métier diffère de celui qui fonctionne pour l’ingénierie produit, et la différence est instructive. Un projet personnel propre et bien architecturé démontre la mauvaise chose. Ce qui démontre la bonne est une intégration désordonnée entre deux systèmes qui n’étaient pas faits pour se parler, accompagnée d’un compte écrit des trois choses qui ne fonctionnaient pas comme documenté.

Le récit compte plus que le code. Un ingénieur capable d’expliquer pourquoi le champ nommé `statut` contenait quatre valeurs dont personne ne pouvait rendre compte, et ce qu’il en a fait, démontre exactement le jugement pour lequel le poste recrute. Un ingénieur avec un dépôt superbe et aucune histoire de ce qui a mal tourné démontre qu’il n’a pas encore travaillé dans ces conditions.