Full-Stack Engineer

Mainloop AI est une société d'ingénierie à Barcelone. Nous détenons ce que nous construisons et nous ne rendons de comptes qu'à nous-mêmes. Vous avez la partie intéressante d'une société nouvelle, avec un vrai client et de vrais produits dès le premier jour.

Ce que nous construisons, c'est le logiciel qui automatise le travail des services professionnels — dans une quinzaine de pays, pour des entreprises qui se noient dans les processus. Nous travaillons en deux moitiés. L'une entre dans une entreprise, comprend ce qui s'y passe réellement, et construit un prototype assez vite pour prouver que cela vaut la peine d'exister. L'autre — celle-ci — reprend ce prototype et en fait quelque chose dont une entreprise dépend. La plupart des équipes d'automatisation n'ont que la première moitié, et c'est pourquoi la plupart ont un tiroir plein de démos et rien en production.

Nous recrutons les ingénieurs de la seconde moitié.

Nous recrutons à deux niveaux, et nous préférons le dire plutôt que vous laisser deviner. Il y a quatre postes juniors et un poste senior. Les postes juniors sont ouverts aux personnes qui sortent d'études et aux jeunes ingénieurs en général : ce que nous cherchons là n'est pas un parcours, c'est l'appétit. Vous voulez devenir très bon très vite, et vous construisez déjà avec des agents de code (Claude Code, Cursor, Codex ou équivalents) parce que vous les avez trouvés intéressants et non parce qu'on vous l'a demandé. Le poste senior s'adresse à quelqu'un qui porte du logiciel en production depuis des années et qui est prêt à poser l'architecture dans laquelle les autres construisent. Postulez à la même annonce dans les deux cas — dites-nous lequel vous pensez être, et nous en parlerons lors du premier échange.

En quoi consiste vraiment le poste

Chaque produit que nous détenons est mené par deux personnes : un Product Owner et vous. Le PO tient la relation avec le métier, les besoins et la feuille de route. Vous tenez le développement, l'architecture, la qualité et la mise en production. C'est une vraie prise en charge : votre nom sur quelque chose que des gens utilisent, avec l'autorité de décider comment cela se construit.

Et vous ne le ferez pas sur une seule chose éternellement. Notre portefeuille est délibérément varié : des plateformes utilisées quotidiennement par des consultants dans une quinzaine de pays, des produits nativement agentiques que nous inventons au fil de l'eau, et l'outillage interne qui fait tenir toute la méthode. De nouveaux projets arrivent en continu de l'autre moitié de l'équipe. Vous circulerez entre eux, et cette variété est l'une des meilleures choses du poste : vous avez la profondeur sur quelque chose qui est à vous et la variété d'une équipe qui démarre quelque chose de neuf chaque trimestre.

Dans une année type, vous allez :

• Reprendre un produit et en faire le vôtre. Il arrive documenté, durci et prêt — d'un collègue passé à la suite. Et on ne vous laisse pas lire 40 000 lignes seul : chaque dépôt embarque les fichiers de contexte que lisent nos agents, nous avons de la recherche et de la navigation de code sur tout le parc, et vous avez Claude Code pointé dessus. S'orienter dans un système inconnu est une compétence dans laquelle vous deviendrez très bon ici, et nous vous donnons les outils qui en font une journée plutôt qu'un mois.
• Le garder en mouvement. Un produit qui cesse d'évoluer cesse d'être utilisé. Votre PO et vous décidez de la suite et vous la livrez.
• Concevoir plus que vous ne tapez. Plus de détails plus bas — c'est la partie de ce poste la plus différente du précédent.
• Démarrer quelque chose de neuf. De nouveaux produits arrivent régulièrement, et la personne qui les porte est celle qui est prête pour le suivant.

Vous allez devenir très bon en construction avec des agents d'IA

C'est la partie que nous soulignerions. Nous sommes une équipe d'ingénierie native à l'IA, vraiment — pas une équipe qui a ajouté une licence Copilot. Chaque ingénieur a son propre abonnement Claude Max et un orchestrateur de bureau qui fait tourner plusieurs agents de code en parallèle, chacun sur sa branche. Vous apprendrez à piloter cela correctement : comment en tirer qualité et vitesse en même temps, où cela échoue, et comment s'asseoir devant un diff et déterminer si c'est réellement juste — ce qui est une compétence, et une de celles sur lesquelles il vaut la peine de prendre son temps.

Ce qui change ce que le poste donne au quotidien. Bien moins de votre semaine part à taper de l'implémentation. Bien plus part sur ce qui décide réellement si un logiciel est bon : ce qu'il faut construire, quelle forme lui donner, où sont les arêtes dures — puis à descendre dans le détail précisément là où le détail compte. C'est un poste plus architectural et plus stratégique que ne l'était le même intitulé il y a trois ans, et c'est la direction que prend toute la profession. Vous serez devant, pas en train de rattraper.

Quelques précisions, pour que vous sachiez comment nous tenons la qualité :

• Chaque changement est relu par un agent avant qu'une personne ne le signe. Cela donne un retour rapide, et vous n'êtes jamais bloqué à attendre qu'un collègue trouve le temps.
• Chaque développement embarque des tests, et la barre est à 100 % au vert. Unitaires, de fumée contre la chose réellement en service, et de bout en bout au niveau du navigateur. Sur ce point nous sommes stricts — c'est ce qui permet à une petite équipe de livrer vite sans rien casser.
• Tout ce qui embarque de l'IA est livré avec des évaluations — un jeu d'entrées noté, pas un « ça avait l'air correct quand j'ai essayé ». Le choix de modèle est géré de façon centralisée, donc personne ne reste échoué sur un modèle abandonné.
• Ce que nous valorisons, c'est le jugement. Les agents rendent l'écriture de code bon marché, ce qui rend juger le code précieux. Ici, l'ancienneté se mesure à la qualité de vos décisions, pas à votre volume de production.

Si vous utilisez sérieusement des agents et que vous avez des avis sur là où ils cassent, nous voulons les entendre. Si vous êtes curieux sans être encore dedans, c'est très bien aussi : bien enseigner cela est une chose pour laquelle nous comptons être connus.

« Si les agents écrivent le code, à quoi je sers ? »

C'est la question juste face à une annonce comme celle-ci, alors voici notre réponse clairement : les agents sont la partie la plus rapide de l'équipe et la moins fiable, et ce n'est pas un problème que nous voyons disparaître. Tout ce qui rend un logiciel réellement bon passe encore par une personne.

Ce qui reste à vous, définitivement :

• Transformer un besoin en une spécification réellement juste. Votre PO apporte ce dont le métier a besoin ; comment cela se construit est à vous. Un agent construira exactement ce que vous spécifiez, magnifiquement, même quand ce que vous avez spécifié avait la mauvaise forme — le travail consiste donc à passer de « ils ont besoin de ça » à une spécification assez précise pour que la bonne chose sorte de l'autre côté. C'est l'heure la plus difficile de votre semaine et la seule que rien n'automatise.
• L'architecture. Les agents sont excellents dans un système bien formé et discrètement destructeurs dans un système informe. Quelqu'un doit décider de la forme, tenir la ligne sur une base de code pendant des années, et savoir lequel des raccourcis d'aujourd'hui devient la réécriture de l'an prochain.
• Juger ce qui sort. Le code d'un agent est aussi assuré qu'il soit juste ou non. Il compile, il passe le test qu'il s'est écrit lui-même, et il est subtilement faux d'une façon que seul quelqu'un qui comprend le domaine attrapera. C'est la chose la plus précieuse que vous faites ici, et elle devient plus précieuse à mesure que les agents accélèrent, pas moins.
• La responsabilité. Quand quelque chose casse en production, on n'appelle pas un agent, il ne s'excuse pas auprès d'un utilisateur, et il ne décide pas d'un retour arrière. Une personne en répond. Ici, cette personne c'est vous — et la prise en charge n'est pas quelque chose que nous comptons confier à un modèle.
• Tout ce qui est humain. Être en désaccord avec votre PO correctement et être écouté, lui dire qu'une fonctionnalité est une mauvaise idée avant qu'elle soit construite, accompagner celui qui arrivera après vous, et savoir quand la réponse honnête est « il faut réécrire ».

Notre position honnête : nous sommes natifs à l'IA parce que cela rend une petite équipe capable de bien plus que sa taille — pas parce que nous pensons que les ingénieurs sont la partie superflue. Nous recrutons moins d'ingénieurs, meilleurs, et donnons à chacun plus de levier, ce qui est l'inverse de recruter moins parce qu'on en a moins besoin. Vous taperez moins et ferez considérablement plus du travail pour lequel vous êtes probablement entré en ingénierie.

Comment nous construisons — et comment le standard évolue

Nous avons une stack posée, et c'est la même dans la plupart des dépôts, délibérément. Chaque projet part du même squelette, et le code partagé vit dans des paquets partagés que tout le monde publie et que tout le monde utilise. Le gain est réel : une équipe de deux peut reprendre un produit jamais vu et être utile le jour même, ce qui est la seule raison pour laquelle une équipe de cette taille peut porter autant de produits — et c'est ce qui rend le passage d'un projet à l'autre indolore plutôt qu'un mois de montée en charge.

C'est un défaut, pas une camisole. Certains projets ont réellement besoin d'autre chose : une charge qui relève proprement de Python, un runtime qui doit être en périphérie, une contrainte client que nous n'avions pas anticipée. Dans ce cas nous nous adaptons, délibérément et avec le raisonnement écrit. Ce que nous ne faisons pas, c'est redécider les cinq mêmes questions sur chaque nouveau dépôt par habitude.

Et vous avez voix au chapitre sur ce qu'est le standard. N'importe qui peut proposer un changement : quelque chose de neuf réellement meilleur, quelque chose vers quoi nous devrions monter, quelque chose que nous avons raté. Une proposition est instruite sérieusement face aux alternatives, elle obtient une réponse, et si la réponse est non vous obtenez le raisonnement. Plusieurs des choix ci-dessus seront différents dans deux ans, et ceux qui les changeront seront les ingénieurs de l'équipe.

Ce qu'il vaut mieux savoir d'emblée

• Vous portez les incidents de votre produit pendant les heures de bureau. L'autre face de la même pièce — le support n'est pas expédié à une équipe séparée ; il fait partie de la prise en charge, et c'est ce qui vous garde honnête sur la qualité.

Ce que nous cherchons

Lisez ceci comme la description de l'ingénieur que vous serez ici, pas comme une liste avec laquelle il faut arriver. Presque personne ne coche tout le premier jour, et nous préférons recruter quelqu'un qui a l'instinct et former le reste — c'est une grande partie de ce à quoi sert le certificat. Si plusieurs de ces points sont vrais de vous et que les autres ressemblent à des choses que vous voulez apprendre, postulez.

• Vous avez porté quelque chose et vous pouvez l'appeler vôtre. Que ce soit en entreprise, à l'université ou sur un projet personnel démarré seul à la table de la cuisine n'a réellement aucune importance — ce qui compte, c'est que vous avez pris les décisions, vécu avec, et que vous savez nous détailler celles que vous avez ratées.
• Vous êtes à l'aise sur le front et le back d'une application web. Nous ne séparons pas ces rôles. TypeScript solide si vous l'avez ; si votre langage était autre chose et que vous êtes bon, dites-le.
• Vous testez correctement — des tests unitaires et de bout en bout ou de fumée contre la chose réellement en service. Un agent en écrira l'essentiel ; s'assurer que la couverture est réellement là est votre travail, et vous savez regarder une suite héritée et dire pourquoi elle est mauvaise.
• Vous utilisez des agents de code dans votre travail et vous lisez leur production comme celle d'un collègue.
• Vous savez reprendre une base de code que vous n'avez pas écrite et expliquer ce qu'elle fait avant de la modifier.
• Anglais courant. C'est notre langue de travail — nous travaillons dans une quinzaine de pays. L'espagnol est réellement utile au quotidien. Le catalan n'est pas requis.
• Barcelone. C'est une équipe qui s'assoit ensemble, surtout la première année.

Pour les quatre postes juniors en particulier, lisez la liste ci-dessus comme une direction de marche plutôt que comme un droit d'entrée. Ce dont nous avons réellement besoin le premier jour est plus étroit et nous le dirons franchement : vous savez construire une application web qui marche de bout en bout, vous avez utilisé un agent de code assez sérieusement pour avoir des avis sur là où il se trompe, et vous voulez devenir bon à cela plus vite qu'un poste normal ne le permettrait. Un diplôme, un bootcamp, un parcours autodidacte et une pile de projets personnels conviennent tous. Des années de production portée ne sont pas attendues — c'est à cela que servent le poste senior et le certificat.

Ce que vous avez étudié nous est égal. Ce qui compte, c'est ce que vous avez construit et si vous savez nous détailler les décisions qu'il contient.

Comment nous recrutons — les deux tours bâtis pour ce poste

1. Un échange de trente minutes. Ce que vous avez construit, comment vous travaillez, et comment vous y réfléchissez. Nous vous demanderons de nous détailler quelque chose que vous avez construit, puis de justifier une décision précise à l'intérieur. Cela ne se prépare pas et ne cherche pas à vous piéger ; c'est ainsi que nous distinguons la compréhension de la familiarité.
2. Un projet. Nous vous donnons un brief et un environnement de travail pour le construire, avec Claude Code déjà installé et relié à une clé, pour que vous construisiez comme nous construisons réellement plutôt que d'en parler devant un tableau. C'est du vrai travail et non une énigme, vous le faites à votre rythme — pas de semaine à poser, pas de vols, rien qui exige d'être déjà disponible — et nous reprenons ensemble ensuite ce que vous avez construit.

Mainloop · Barcelone. Postulez avec quelque chose que vous avez construit et un paragraphe sur une décision technique que vous avez ratée.