L'ingénieur d'une grande entreprise technologique

Imaginez une chirurgienne qui a fait la même opération pendant huit ans, des milliers de fois, dans un très grand hôpital. Personne ne la fait mieux. Maintenant, une petite clinique lui propose de se joindre à l’équipe. Là, elle devra aussi parler aux patients, planifier la journée et parfois répondre au téléphone. Elle reste une excellente chirurgienne. La question est de savoir si elle veut ce genre de journée.

Beaucoup de candidats en développement backend viennent de très grandes entreprises technologiques. Ils ont travaillé sur un seul service interne, à une échelle qu’une entreprise comme Casewell n’atteindra jamais. Ils connaissent la cohérence, la réplication, la contre-pression et les nouvelles tentatives mieux que presque tout le monde dans la salle. Mais souvent, leurs clients étaient d’autres ingénieurs de la même entreprise. Ils n’ont jamais dû demander à une avocate ce dont elle a besoin. Ni prendre une décision quand personne ne peut leur donner de spécification claire.

Arash est ce type de candidat. Son entrevue montre deux choses. D’abord, comment contester une affirmation technique d’un intervieweur chevronné, poliment et avec des raisons. Ensuite, comment une entrevue peut vous aider, vous aussi, à décider qu’un poste ne vous convient pas.

AK

La personne candidate

Arash Karimi

Ingénieur principal, stockage distribué, 8 ans

• 8 ans dans une grande entreprise de services infonuagiques
• Go et C++
• Systèmes distribués
• Vancouver

• Ingénieur logiciel principal, Halden Cloud (grand fournisseur de services infonuagiques), de 2018 à aujourd’hui
• A dirigé la refonte de la couche de métadonnées du stockage d’objets interne, environ 1 million de requêtes par seconde en pointe
• A conçu le contrôle d’admission et les quotas par locataire pour environ 3 000 locataires internes, avec des files d’attente équitables pondérées
• A rédigé les règles de budget de nouvelles tentatives après une tempête de nouvelles tentatives; quatre autres équipes de stockage les ont adoptées
• Responsable de la coordination de plus de 20 incidents
• Maîtrise en informatique, 2018
• Go, C++, Python pour les outils, Raft, Kubernetes

Ce que Rafael voit avant l’appel

Rafael lit le CV à côté de l’offre d’emploi, et il est impressionné. L’équité entre locataires et leur isolation sont exactement les problèmes de Casewell. Arash les a résolus à une échelle mille fois plus grande. Il utilise Python seulement pour les outils, mais Rafael ne s’en inquiète pas. Un bon ingénieur apprend FastAPI en quelques semaines.

Ce qui l’inquiète, c’est l’autre moitié de l’offre. Elle dit « ingénieur produit ». Chez Casewell, un ingénieur parle chaque semaine à l’équipe de réussite client, et parfois à un client. Il prend souvent des décisions sans spécification claire. Le CV ne contient aucune ligne sur un produit, un client ou un utilisateur.

Il souligne aussi une expression : « A dirigé la refonte ». Rafael veut savoir quelle partie Arash a dirigée.

Il veut découvrir :

• Quelle est la profondeur de ses connaissances en systèmes distribués, et peut-il les expliquer simplement?
• Que fait Arash quand la question porte sur une personne, et non sur un système?
• Comment réagit-il quand Rafael dit quelque chose qui n’est pas tout à fait juste?

Termes utilisés dans cette page

• Locataire : une organisation cliente dans un système partagé. Chez Casewell, chaque cabinet d’avocats est un locataire.
• Sécurité au niveau des lignes (RLS) : une fonction de Postgres qui ajoute un filtre à chaque requête sur une table. Par exemple, « seulement les lignes du locataire actuel ».
• Tempête de nouvelles tentatives : de nombreux clients relancent leurs requêtes échouées en même temps. Cette charge supplémentaire maintient le système en panne.
• Budget de nouvelles tentatives : une limite aux nouvelles tentatives. Par exemple, « les nouvelles tentatives peuvent représenter au plus 10 % de toutes les requêtes ».
• Files d’attente équitables pondérées : une façon de partager la capacité entre les utilisateurs selon un poids. Ainsi, un gros utilisateur ne peut pas tout prendre.
• Cloison éthique : une règle interne d’un cabinet qui empêche certains avocats de consulter certains dossiers, pour éviter un conflit d’intérêts.
• pgvector : une extension de Postgres qui stocke des plongements (embeddings) et trouve les plus semblables.

L’entrevue

Minutes 0 à 5 : l'ouverture

Rafael(intervieweur) :

Bonjour Arash. Rafael, ingénieur principal. Merci d’être venu. Je vois Vancouver derrière vous, non?

Arash(personne candidate) :

Oui, il pleut, comme d’habitude. Ravi de vous rencontrer.

Rafael(intervieweur) :

Le plan est simple. Vous me parlez d’un système que vous avez construit, je pose beaucoup de questions. Ensuite, un vrai problème de Casewell. Puis vos questions. Pas d’outils d’IA cette fois. On a déjà fait une entrevue avec l’IA. Ici, on discute seulement.

Arash(personne candidate) :

Ça me va. Honnêtement, je préfère parler de systèmes plutôt que coder en direct.

Minutes 5 à 25 : le service de stockage, puis les détails

Rafael(intervieweur) :

Alors. Votre système.

Arash(personne candidate) :

D’accord. Chez Halden, je travaille sur la couche de métadonnées du stockage d’objets interne. Quand une équipe de l’entreprise stocke un fichier, les octets vont dans un système, et les renseignements dans le nôtre. Le nom, la taille, l’emplacement des morceaux, qui peut le lire.

Notre problème, c’était les locataires trop gourmands. Une équipe lance un gros traitement par lots, et tout ralentit pour les autres. Moi, j’ai fait le contrôle d’admission. Chaque locataire reçoit une part, une part pondérée. Quand la charge est forte, on rejette tôt les requêtes qui dépassent cette part, avec une erreur claire. Au lieu de laisser tout ralentir pour tout le monde.

Rafael(intervieweur) :

Votre CV dit que vous avez dirigé la refonte. Toute la refonte?

Arash(personne candidate) :

Non. Bonne question. La refonte avait trois parties. J’ai dirigé le contrôle d’admission. Deux autres personnes ont dirigé le moteur de stockage et la migration. « Dirigé la refonte », c’est trop large, oui.

Pourquoi cela fonctionne

Arash répond à la question directe en une phrase et ne défend pas son CV. Il sait exactement quelle partie était la sienne, ce qui rend le reste de son récit facile à croire.

Rafael(intervieweur) :

Comment une requête trouve-t-elle sa part? Où se prend cette décision?

Arash(personne candidate) :

Dans la couche d’entrée, avant que la requête touche au stockage. Chaque locataire a une file d’attente en mémoire sur chaque serveur. On prend les requêtes dans ces files par tourniquet à déficit, avec des poids. Si la file d’un locataire est trop longue, on répond « ralentissez » tout de suite.

Rafael(intervieweur) :

« Ralentissez », c’est une erreur. Qu’est-ce que les clients en font?

Arash(personne candidate) :

C’est justement ça, l’incident.

Il y a deux ans, une cellule a ralenti après un déploiement. Nos clients ont réessayé. Mais les clients de nos clients ont aussi réessayé, et leurs clients aussi. Trois couches, trois tentatives chacune. Donc une requête utilisateur pouvait devenir 27 requêtes tout en bas. La cellule ne s’est jamais rétablie toute seule. On a dû bloquer le trafic à la main.

Rafael(intervieweur) :

Pendant combien de temps?

Arash(personne candidate) :

Environ deux heures de mauvaise latence, peut-être un peu plus. J’étais responsable de la gestion de l’incident.

Rafael(intervieweur) :

Et qu’est-ce qui a changé après?

Arash(personne candidate) :

Trois règles. Réessayer dans une seule couche, celle qui est la plus proche du problème. Chaque client a un budget de nouvelles tentatives, dix pour cent de ses requêtes normales. Et toujours des temps d’attente aléatoires, de la gigue, pour qu’ils ne reviennent pas tous ensemble.

Et puis la réponse « ralentissez » dit combien de temps attendre. C’était… désolé, j’ai perdu le fil. C’était quoi, la question?

Rafael(intervieweur) :

Ce qui a changé après l’incident. Vous avez parlé de trois règles.

Arash(personne candidate) :

Oui. Et ensuite, on a testé. On a ralenti une cellule exprès, dans un environnement de test avec des profils de trafic réels. On a vérifié que la charge tout en bas restait sous environ 1,2 fois la normale. Avant les règles, elle montait à six ou sept fois.

Comment l’intervieweur va plus loin

Rafael revient toujours à « comment saviez-vous que ça fonctionnait? » Arash répond avec une mesure, tirée d’un test qui faisait exprès de perturber le système. À ce niveau d’expérience, voilà à quoi ressemble une réponse solide.

Rafael(intervieweur) :

Très bien. Autre question. Qui étaient vos clients?

Arash(personne candidate) :

D’autres équipes. Des ingénieurs. Ils ouvraient des billets de soutien, ou ils écrivaient dans notre canal.

Rafael(intervieweur) :

Avez-vous déjà parlé à quelqu’un à l’extérieur de l’entreprise? À un utilisateur final?

Arash(personne candidate) :

Non. Jamais, en fait. Hmm. Je n’y avais pas pensé jusqu’à maintenant.

Minutes 25 à 40 : le problème de Casewell

Rafael(intervieweur) :

Maintenant, notre vrai problème. Au début d’une transaction, un cabinet d’avocats téléverse jusqu’à 2 000 contrats à la fois. Aujourd’hui, on les traite dans la requête de téléversement; elle dépasse le délai, les gens téléversent encore, on reçoit des doublons. Le mois dernier, un gros téléversement a ralenti tous les autres clients pendant des heures. Et — je vais être honnête avec vous — un client a vu du texte du document d’un autre client dans une réponse du clavardage. C’était un bogue de cache, corrigé maintenant. Comment repenseriez-vous le traitement des documents et le clavardage pour empêcher ces problèmes?

Arash(personne candidate) :

D’accord. Avant la conception, quelques chiffres. Combien de temps prend le traitement d’un document? Et le fournisseur du modèle, comment vous limite-t-il? Par les requêtes ou les jetons?

Rafael(intervieweur) :

Environ 20 secondes pour un contrat normal. Le fournisseur limite les deux, les jetons par minute et les requêtes par minute. C’est la limite de jetons qu’on atteint.

Arash(personne candidate) :

Alors les jetons sont la vraie ressource, pas les processus. Bon à savoir.

Donc : le téléversement stocke seulement le fichier et répond 202 avec un identifiant de lot. Chaque fichier reçoit une tâche. Les doublons, par une empreinte des octets, unique par locataire. Ensuite, je ne répartirais pas la capacité selon la position dans la file. Je répartirais les jetons. Chaque locataire reçoit une part pondérée du budget de jetons, et un plafond de tâches exécutées en même temps. L’ordonnanceur prend les tâches des locataires à tour de rôle, comme mon contrôle d’admission.

Rafael(intervieweur) :

Donc le cabinet avec 1 800 fichiers…

Arash(personne candidate) :

Reçoit sa part, peut-être plus quand personne d’autre n’est occupé. Mais le traitement des trois fichiers d’un petit cabinet commence quand même en quelques secondes. Ses fichiers n’attendent pas derrière les 1 800 autres.

Pourquoi cela fonctionne

C’est le point fort d’Arash, et ça se voit. Il demande d’abord quelle est la vraie limite : les jetons, pas les processus. Puis il conçoit une répartition équitable autour de cette limite. C’est la même idée que dans son travail sur le stockage, appliquée à une nouvelle ressource.

Rafael(intervieweur) :

D’accord, je vous crois pour l’ordonnanceur. Je vais poser une autre sorte de question. Un cabinet téléverse 2 000 contrats. Le traitement échoue pour 37 : des images numérisées sans texte, deux fichiers protégés par mot de passe. Que voit l’avocate? Et quand?

Arash(personne candidate) :

Chaque fichier a un état. À la fin, une liste des échecs, avec un code d’erreur pour chacun. Comme « aucune couche de texte », « chiffré ».

Rafael(intervieweur) :

Hmm. L’avocate conclut une transaction vendredi. On est mercredi soir. Est-ce qu’elle veut des codes d’erreur?

Arash(personne candidate) :

Pause. Non. Probablement pas.

Honnêtement, je ne sais pas ce qu’elle veut. Dans mon travail, la personne qui lisait l’erreur était toujours un ingénieur. Je voudrais lui demander. Ou demander à votre équipe de réussite client. Je suppose qu’elle veut le savoir tôt, pas à la fin. Et savoir ce qu’elle peut faire. « Demandez à l’autre partie la version Word. » Quelque chose comme ça.

La limite

C’est la première limite, et elle n’est pas technique. Arash remarque que sa réponse s’adresse à un ingénieur et dit « je ne sais pas ce qu’elle veut ». Puis il propose une hypothèse raisonnable qui part de sa situation. Il nomme aussi les personnes à consulter. C’est une bonne façon de réagir à une limite que vous n’avez jamais rencontrée.

Rafael(intervieweur) :

Et les doublons. Le même contrat, mais un exemplaire a la page de signatures et l’autre non. Est-ce un doublon?

Arash(personne candidate) :

L’empreinte dira non, les octets sont différents. Est-ce que c’est le « même contrat » pour un avocat… c’est une décision de produit. Je peux construire l’une ou l’autre solution. Je ne peux pas décider.

Où cela tourne mal

« Je peux construire l’une ou l’autre solution » est vrai, mais souvent insuffisant dans une petite entreprise. Ici, personne ne vous remet de spécifications. Vous allez chercher la réponse : vous parlez à l’équipe de réussite client, vous examinez de vrais téléversements. Vous proposez une règle et la vérifiez avec deux clients. Un ingénieur qui attend la décision peut attendre des semaines.

Minutes 40 à 50 : l'isolation et un désaccord

Rafael(intervieweur) :

D’accord. Maintenant, l’incident. La clé de cache contenait seulement le texte de la question, pas le locataire. Après la correction, on a aussi vérifié que chaque table de locataire avait la sécurité au niveau des lignes dans Postgres. Donc…

Il réfléchit à voix haute un instant.

Donc je pense qu’on est en sécurité maintenant. Avec la RLS, la base de données nous protège.

Arash(personne candidate) :

Est-ce que je peux être un peu en désaccord?

Rafael(intervieweur) :

Allez-y.

Arash(personne candidate) :

La RLS est bonne. Je la garderais. Mais elle protège les requêtes qui passent par Postgres, avec le bon locataire défini sur la connexion. L’incident était dans un cache, non? Dans Redis? La RLS ne voit jamais Redis.

Rafael(intervieweur) :

Oui. Le cache est dans Redis.

Arash(personne candidate) :

Alors je listerais tout ce qui contient des données de locataire sans passer par une requête normale. Le cache. La recherche vectorielle : aujourd’hui, c’est pgvector dans le même Postgres, donc la RLS s’applique. Mais si un jour elle passe dans un service séparé, elle ne s’applique plus. Les tâches en arrière-plan : quel rôle de base de données les processus utilisent-ils? Si c’est le propriétaire de la table, la RLS est ignorée, sauf si la table l’impose. Si c’est un rôle qui « contourne la RLS », la politique ne fait rien.

Rafael(intervieweur) :

Hmm. Les processus utilisent… il faudrait que je vérifie. Je pense que c’est le rôle de migration.

Arash(personne candidate) :

Alors ça vaut la peine de vérifier demain. Et encore deux choses. Les journaux : si vous consignez les requêtes, le texte des contrats de tous les locataires se retrouve au même endroit. Et l’équipe de soutien peut y faire des recherches. Et la requête au modèle elle-même. Si on regroupe des passages de deux requêtes dans un appel au modèle, peut-être pour économiser, la RLS n’aide pas non plus.

Rafael(intervieweur) :

Pause. Vous avez raison. Et c’est un peu gênant, parce que l’incident, c’était exactement ça. C’était à l’extérieur de la base de données. J’ai dit « la base de données nous protège » comme si j’avais oublié mon propre incident.

Arash(personne candidate) :

Je pense que tout le monde le dit. La RLS donne l’impression d’une garantie. C’est une garantie pour une seule couche.

Bien exprimer un désaccord

Rafael croyait ce qu’il disait; ce n’était pas un test. Arash demande la permission d’exprimer son désaccord, puis approuve d’abord la partie juste (« la RLS est bonne, je la garderais »). Ensuite, il donne des exemples précis où l’affirmation n’est pas vraie. Il termine par une action (« ça vaut la peine de vérifier demain »), pas par une victoire. Quand Rafael admet son erreur, Arash lui facilite la tâche. Consultez nos conseils pour exprimer un désaccord avec des raisons.

Rafael(intervieweur) :

Alors comment concevriez-vous ça?

Arash(personne candidate) :

Le locataire fait partie de chaque requête, dès la première ligne. Un objet, transmis partout : à la session de base de données, à la fonction de cache, à la requête vectorielle, au journaliseur. Un appel au cache sans locataire ne devrait pas compiler, ou devrait échouer dans les tests.

Et des tests qui attaquent ça. Deux locataires avec des documents semblables, et pour chaque couche, essayer de lire les données de l’autre. Les exécuter à chaque changement.

Rafael(intervieweur) :

D’accord. À l’intérieur d’un cabinet, on a aussi des cloisons éthiques. Comment votre conception les gère-t-elle?

Arash(personne candidate) :

Désolé, je ne connais pas ce terme. Des cloisons éthiques?

Rafael(intervieweur) :

Dans un cabinet, un avocat qui travaille pour un client ne doit pas voir les documents d’un autre dossier. S’il y a un conflit d’intérêts. Donc le même locataire, des permissions différentes.

Arash(personne candidate) :

Ah. Alors le locataire n’est pas la bonne unité. C’est le dossier. Ou l’ensemble des permissions de l’utilisateur. Ça change la clé de cache, le filtre vectoriel, tout.

D’où viennent les cloisons? Le cabinet les gère dans votre produit, ou dans un autre système?

Rafael(intervieweur) :

Les deux. Certains cabinets les synchronisent depuis leur système documentaire chaque nuit. D’autres les définissent dans Casewell à la main.

Arash(personne candidate) :

Alors il y a un délai. Une cloison ajoutée à 15 h arrive pendant la nuit. Est-ce acceptable pour un cabinet d’avocats? Je ne sais vraiment pas. Je devrais apprendre comment les cabinets voient ça avant de le concevoir.

La deuxième limite

Arash rencontre un concept du domaine dont il n’a jamais entendu parler. Il demande ce qu’il signifie et adapte immédiatement sa conception à la bonne unité. Puis il trouve une vraie question : le délai de la synchronisation nocturne. Il ne prétend pas savoir ce qu’un cabinet d’avocats accepte.

Une meilleure réponse

Avec un peu de préparation sur le domaine, Arash pourrait soulever ce point lui-même, avant la question de Rafael. « Dans un cabinet d’avocats, le locataire est-il vraiment l’unité d’accès? Ou y a-t-il aussi des règles internes? » Dix minutes de lecture sur la confidentialité dans les cabinets lui donneraient cette question. Pour un poste lié à un produit spécialisé, apprenez les mots de base du travail du client avant l’entrevue.

Rafael pose aussi une question sur la recherche vectorielle. Arash dit que la RLS fonctionne avec pgvector, mais qu’il vérifierait le plan de requête. Un index approximatif trouve d’abord les voisins les plus proches, puis la politique retire les lignes des autres locataires. Un petit locataire peut obtenir très peu de résultats. « Sécuritaire, mais de mauvaises réponses. » Rafael confirme qu’ils ont observé ce problème et activé les parcours itératifs d’index, une fonction de pgvector depuis la version 0,8. L’index continue de chercher jusqu’à trouver assez de lignes qui passent le filtre, ou jusqu’à atteindre une limite définie. Arash ne connaissait pas cette fonction, et il la note.

Minutes 50 à 60 : les questions d'Arash et la conclusion

Arash(personne candidate) :

Vous utilisez Celery aujourd’hui. Prévoyez-vous de changer?

Rafael(intervieweur) :

Oui, pour un outil de flux de travail durable. Des tâches longues qui survivent à un redémarrage. Honnêtement… personne n’est encore responsable de cette migration.

Arash(personne candidate) :

Ah, c’est intéressant. C’est la partie qui me plairait.

Deuxième question. À quoi ressemble une semaine normale? Quelle part représente ce genre de travail, et quelle part concerne le produit?

Rafael(intervieweur) :

Surtout le produit. Attendez, je vais être plus juste. Peut-être 70 % de produit : fonctionnalités, problèmes clients, petites corrections le jour même. Le travail d’infrastructure se fait entre ces tâches. Vous parlez à l’équipe de réussite client chaque semaine. Parfois, un client participe à un appel.

Arash(personne candidate) :

D’accord. Pause. D’accord, merci. C’est utile.

Ce que l’intervieweur vérifie

Rafael se corrige au milieu de sa réponse (« attendez, je vais être plus juste »), car « surtout le produit » manquait de précision. La pause d’Arash n’est pas un mauvais signe en soi. Il apprend quelque chose sur le poste que l’offre ne dit pas, et il y réfléchit. Consultez une entrevue est une conversation dans les deux sens.

Rafael(intervieweur) :

Le temps est écoulé. Ensuite, la conception de systèmes avec Anjali, puis une conversation avec Marguerite, notre responsable de la réussite client. Ben vous écrira. Et merci pour la partie sur la RLS. Je vérifierai le rôle des processus demain.

Arash(personne candidate) :

Dites-moi ce que vous trouvez, s’il vous plaît. Merci, Rafael.

Après l’appel : les notes de Rafael

Rafael rédige ses notes en fonction de l’offre d’emploi :

Systèmes distribués, files d’attente et équité : preuves solides. La meilleure réponse que j’ai entendue sur l’équité entre locataires. Il a conçu le système autour des jetons, pas des processus.

Fiabilité et incidents : preuves solides. Tempête de nouvelles tentatives, budgets de nouvelles tentatives et test qui a confirmé la correction.

Sécurité et isolation des locataires : preuves solides. Il a corrigé mon affirmation sur la RLS, poliment et avec justesse. Il faut vérifier le rôle des processus.

Python et FastAPI : quelques preuves. Outils seulement. Pas de préoccupation.

Fonctionnalités de LLM : quelques preuves. A vite compris les limites de jetons. Aucune expérience avec la diffusion en continu ou l’injection de requêtes.

Mentalité d’ingénieur produit : préoccupation. N’a jamais travaillé avec des utilisateurs finaux. Quand la question portait sur l’avocate, il était honnête, mais n’avait pas encore les bons réflexes. Le domaine juridique est nouveau pour lui.

Recommandation : oui, passer à la conception de systèmes et aux valeurs. Marguerite, parle-lui d’une vraie semaine ici, y compris les périodes de garde.

Le lendemain matin, Rafael a vérifié. Les processus en arrière-plan utilisaient bien un rôle qui contournait la RLS. Il a ouvert un billet de soutien pour leur donner leur propre rôle. Il a aussi envoyé un court message de remerciement à Arash par l’intermédiaire de Ben.

La suite

L’entrevue de conception de systèmes d’Arash avec Anjali s’est très bien passée. Elle a écrit que sa conception d’ordonnanceur était meilleure que celle de l’ébauche de l’équipe.

Il a ensuite discuté des valeurs avec Marguerite Hall. Elle lui a raconté une vraie semaine. Un cabinet a appelé un jeudi à 20 h. Une transaction devait se conclure le lendemain, et 200 fichiers étaient bloqués. L’ingénieur de garde a réglé le problème le soir même. La garde revient une semaine sur huit, et l’offre ne le précise pas. Les petites corrections sont mises en production le jour même. Les ingénieurs participent aux appels avec les clients.

Arash a posé de bonnes questions et a écouté. Deux jours plus tard, il a écrit à Nora pour retirer sa candidature. Il a écrit que les gens étaient excellents et les problèmes, bien réels. Mais pendant les entrevues, ce qui l’avait rendu heureux, c’était l’ordonnanceur et les couches d’isolation. L’écran de l’avocate et l’échéance du vendredi le fatiguaient rien qu’à y penser. Il voulait rester en infrastructure. Il ne voulait pas accepter un poste pour partir six mois plus tard.

Nora l’a remercié et lui a dit qu’elle aussi trouvait que c’était une bonne décision. Rafael a demandé s’il pouvait utiliser la liste d’Arash des « couches hors de la RLS » dans l’analyse d’incident de l’équipe. Arash a accepté.

Ce n’était un échec pour personne. Arash a découvert ce qu’il voulait avant de changer d’emploi. Casewell a évité d’embaucher quelqu’un qui serait parti rapidement. Se retirer d’un processus est normal et professionnel, si vous le faites tôt et poliment.

Ce qu’il faut retenir

• Exprimez votre désaccord avec une liste précise, pas une impression. Arash a nommé chaque couche que la RLS ne couvre pas. Son argument était donc impossible à manquer et facile à vérifier.
• Reconnaissez d’abord ce qui est vrai, puis terminez par une action. « La RLS est utile, je la garderais » et « ça vaut la peine de vérifier demain » ont gardé la conversation cordiale.
• Une compétence approfondie s’applique à de nouveaux problèmes. Le contrôle d’admission d’Arash est devenu un ordonnanceur de jetons en quelques minutes. Si vous venez d’une grande entreprise, montrez comment votre idée s’adapte à la nouvelle ressource.
• « Ingénieur produit » est une véritable exigence. Demandez ce que cela signifie dans une semaine de travail. Puis décidez honnêtement si vous voulez ce genre de semaine.
• Une entrevue vous aide aussi à décider. Les questions d’Arash ont révélé des faits absents de l’offre, et ces faits ont changé sa décision. Voir une entrevue est une conversation dans les deux sens.

Si votre profil ressemble à celui d’Arash

Votre connaissance des systèmes est une vraie longueur d’avance (voir Votre expérience est une longueur d’avance). Il vous reste à montrer que vous pouvez aussi travailler avec un produit et ses utilisateurs. Ou à décider que vous ne le voulez pas.

1. Décidez quel genre de semaine vous voulez avant de postuler. Notez le travail qui vous a rendu le plus heureux au cours des deux dernières années. Si tout concernait l’infrastructure, cherchez des postes en plateforme ou en infrastructure dans des entreprises qui développent des produits. Ces postes existent et vous conviennent mieux.
2. Trouvez une situation où vous avez travaillé avec un utilisateur. Même à l’interne. Une équipe avait un besoin flou, et vous avez découvert ce dont elle avait vraiment besoin. Si vous n’avez aucun exemple, dites-le honnêtement. Demandez pendant l’entrevue comment l’équipe travaille avec les clients.
3. Apprenez les mots de base du domaine du client. Pour les logiciels juridiques : dossier, privilège, cloison éthique, système de gestion documentaire. Trente minutes de lecture changent les questions que vous pouvez poser.
4. Exercez-vous à expliquer simplement une idée complexe. Tempêtes de nouvelles tentatives, files d’attente équitables, cohérence. Expliquez-la en deux minutes à un ami qui n’est pas ingénieur. Notre leçon Expliquer vos décisions montre comment faire.
5. Corrigez vos lignes qui disent « dirigé ». Précisez quelle partie vous avez dirigée. Cela reste impressionnant et résiste à la première question de suivi. Voir Les éléments d’un portfolio.
6. Apprenez la pile technologique mentionnée dans l’offre. Pour ce poste : Python, FastAPI et la sécurité au niveau des lignes de Postgres, notamment comment les rôles peuvent la contourner. Une fin de semaine consacrée à un petit projet suffit pour en parler avec assurance.