Le nouveau diplômé

Chaque année, beaucoup de nouveaux diplômés postulent à des postes qui demandent deux ou trois ans d’expérience. Ils le font parce que l’offre ne dit pas « senior », parce que les postes juniors sont rares et que ça fonctionne parfois. Beaucoup ont étudié dans une langue seconde, dans un nouveau pays, et ont fait un stage pendant leurs études.

Ce type de candidat n’a aucune expérience en production à raconter. Il n’a jamais assuré la garde. Il n’a jamais vu un système tomber en panne à 2 h du matin avec de vrais clients. Mais il connaît souvent mieux les bases que des personnes ayant cinq ans d’expérience. Il les a étudiées il y a quelques mois : index, transactions, niveaux d’isolation. Et il apprend vite.

Minh est ce candidat. Nous voyons comment Rafael adapte la profondeur de ses questions à un nouveau diplômé. Nous voyons aussi comment Minh raisonne sur le bogue de cache à partir des principes de base. Minh demande également une minute pour réfléchir, puis reste silencieux. Ce n’est pas un moment de faiblesse. Vous verrez pourquoi.

MN

La personne candidate

Minh Nguyen

Nouveau diplômé, backend, un stage

• Baccalauréat en informatique, mai 2026
• Stage de 8 mois
• Go et Python
• Toronto

• Baccalauréat en informatique, Lakeshore University, de 2022 à 2026. Cours sur les bases de données, les systèmes distribués et les systèmes d’exploitation
• Stagiaire en génie logiciel, Brindle (jeune entreprise de paiements, 60 personnes), 8 mois
• Conception et réalisation d’un service de traitement de webhooks (requêtes déclenchées par des événements) à haut débit en Go pour les paiements par carte
• Correction d’un bogue de notifications en double avec un traitement idempotent des événements et une table d’envoi
• Projet de fin d’études : petit moteur de recherche de notes de cours en Python, avec la recherche plein texte de Postgres et pgvector
• Go, Python, FastAPI, PostgreSQL, Redis, Docker, GitHub Actions

Ce que Rafael voit avant l’appel

Rafael lit le CV à côté de l’offre d’emploi. L’offre demande au moins quatre ans d’expérience. Minh a huit mois d’expérience. Rafael ne s’arrête pas là. Nora lui a demandé de parler avec Minh, qui a très bien réussi l’épreuve pratique de programmation. Il a utilisé l’assistant d’IA, lu chaque modification proposée et trouvé lui-même des données de test incorrectes.

Rafael marque deux lignes dans ses notes. Avoir « conçu » un service « à haut débit » est une grande affirmation pour un stagiaire. Et avoir « corrigé un bogue de notifications en double » est intéressant, car Casewell a aussi un problème de doublons.

Il veut savoir :

• Qu’est-ce que Minh a construit lui-même, et qu’est-ce que son mentor a décidé?
• Comprend-il pourquoi sa correction fonctionne, au niveau de la base de données?
• Comment raisonne-t-il sur un problème qu’il n’a jamais vu, comme le bogue de cache?
• Où sont ses limites, et que fait-il quand il les atteint?

Termes utilisés dans cette page

• Locataire : une organisation cliente dans un système partagé. Chez Casewell, chaque cabinet d’avocats est un locataire.
• Webhook : une requête que le système d’une autre entreprise envoie à votre système lorsqu’un événement survient, par exemple « paiement reçu ».
• Idempotent : une opération qui donne le même résultat, qu’elle s’exécute une seule fois ou plusieurs fois.
• Niveau d’isolation : ce qu’une transaction de base de données peut voir des autres transactions qui s’exécutent en même temps. Postgres utilise « read committed » (lecture des données validées) par défaut.
• Contrainte d’unicité : une règle de base de données interdisant à deux lignes d’avoir la même valeur dans une colonne ou un ensemble de colonnes.
• Table d’envoi : une table où vous écrivez « envoyer ce message » dans la même transaction que votre modification de données. Un processus distinct la lit et envoie le message.
• Clé de cache : la valeur qu’un cache utilise pour trouver un résultat stocké. Deux requêtes avec la même clé obtiennent le même résultat.
• Sécurité au niveau des lignes (RLS) : une fonctionnalité de Postgres qui ajoute un filtre à chaque requête sur une table. Par exemple : « seulement les lignes du locataire actuel ».
• Injection de requête : du texte dans l’entrée qui tente de donner de nouvelles instructions au modèle.

L’entrevue

Minutes 0 à 5 : le début

Rafael(intervieweur) :

Bonjour Minh. Vous m’entendez bien?

Minh(personne candidate) :

Oui, je vous entends. Bonjour. Merci de prendre le temps.

Rafael(intervieweur) :

Bien. Je suis Rafael, ingénieur principal ici chez Casewell. Il y a treize ans, j’étais aussi un nouveau diplômé, alors détendez-vous un peu. Le plan : d’abord, vous me parlez de quelque chose que vous avez construit, et je pose beaucoup de questions. Ensuite, je vous donne un vrai problème que nous avons. Puis, vos questions.

Minh(personne candidate) :

D’accord. Je peux utiliser l’assistant d’IA comme à l’épreuve de programmation?

Rafael(intervieweur) :

Pas cette fois. Nous avons déjà eu une épreuve avec l’IA. Ici, on discute seulement. Vous pouvez utiliser du papier, si vous aimez dessiner.

Minh(personne candidate) :

D’accord, parfait. J’ai du papier.

Minutes 5 à 25 : le stage, puis l'approfondissement

Rafael(intervieweur) :

Alors. Parlez-moi du service de webhooks, les notifications envoyées par HTTP.

Minh(personne candidate) :

D’accord. Alors, Brindle fournit aux petits commerces un terminal de paiement par carte. Quand un paiement se fait, le processeur de paiements nous envoie un webhook. Paiement autorisé, paiement encaissé, remboursement, ce genre de choses. Mon équipe avait besoin d’un service pour les recevoir, les enregistrer et avertir le commerce. En Go, avec Postgres.

Moi, j’ai fait la partie réception et la partie base de données. Mon mentor a fait la conception initiale, et j’ai construit la plus grande partie. Et plus tard, j’ai corrigé le bogue des doublons.

Rafael(intervieweur) :

D’accord. Votre CV dit « à haut débit ». Combien d’événements par seconde?

Minh(personne candidate) :

Hmm. Environ 30 000 par jour, je pense. Une journée, c’est environ 86 000 secondes. Donc… moins d’un par seconde. En moyenne. Le maximum était peut-être de 20 par seconde, le soir.

À haut débit, c’est peut-être un terme trop fort. Mon mentor m’a dit de l’écrire comme ça.

Pourquoi cela fonctionne

Rafael ne demande pas « est-ce vrai? ». Il demande un chiffre, et ce chiffre répond à la question. Minh fait le calcul à voix haute, puis corrige son propre CV. Il faut un peu de courage pour ça, et ses autres réponses deviennent plus crédibles.

Une formulation plus solide pour le CV

Écrivez ce que vous pouvez défendre en entrevue : « Création d’un service de webhooks en Go pour les paiements par carte, environ 30 000 événements par jour, avec traitement idempotent. » Un petit chiffre vrai vaut mieux qu’un grand mot. Consultez Les éléments d’un portfolio.

Rafael(intervieweur) :

Ce n’est pas grave. Parlez-moi du bogue des doublons.

Minh(personne candidate) :

D’accord. Certains commerces recevaient le courriel « paiement reçu » deux fois. Parfois trois. Les propriétaires étaient confus, ils pensaient que le client avait payé deux fois.

La raison, c’est que le processeur réessaie si on ne répond pas en environ dix secondes. Notre gestionnaire enregistrait l’événement, envoyait le courriel, puis parfois c’était lent, alors le processeur envoyait encore le même événement.

Rafael(intervieweur) :

Mais vous aviez enregistré l’événement. Pourquoi le deuxième ne le voyait pas?

Minh(personne candidate) :

Oui, c’est la partie intéressante. Le code faisait ça : vérifier si l’identifiant de l’événement existe, sinon insérer et envoyer le courriel. Mais deux envois peuvent arriver presque en même temps. Les deux vérifient, les deux ne voient rien, les deux insèrent.

Rafael(intervieweur) :

Dans une transaction?

Minh(personne candidate) :

Oui, dans une transaction. Mais le niveau par défaut de Postgres, c’est read committed, la lecture des données validées. Une transaction ne peut pas voir l’insertion de l’autre avant son commit, sa validation. Alors les deux vérifications disent « aucune ligne ».

Rafael(intervieweur) :

Et avec repeatable read, la lecture répétable? Est-ce que ça règle le problème?

Minh(personne candidate) :

Non. Repeatable read donne un instantané, alors on ne voit toujours pas l’autre insertion. Et elles insèrent deux lignes différentes, donc il n’y a pas de conflit. Le niveau sérialisable détecterait ça, je pense. Une transaction échoue et on la réessaie. Mais notre solution est plus simple : une contrainte d’unicité sur l’identifiant de l’événement. Ensuite, INSERT ... ON CONFLICT DO NOTHING, et seule la transaction qui a vraiment inséré envoie le courriel.

Comment l’intervieweur va plus loin

Rafael adapte la profondeur des questions à un nouveau diplômé. Il ne pose pas de questions sur une échelle que Minh n’a jamais connue. Il l’interroge sur la base de données, un domaine que Minh connaît vraiment, et approfondit chaque fois d’un niveau. Minh a raison ici : avec repeatable read, deux transactions peuvent encore insérer le même événement. Aucune des deux lignes n’existe dans l’instantané de l’autre. Une contrainte d’unicité laisse la base de données décider.

Rafael(intervieweur) :

Bien. Et le courriel lui-même? Vous l’envoyez dans la transaction?

Minh(personne candidate) :

Au début, oui. Puis mon mentor m’a montré le modèle outbox, une table de messages à envoyer. Dans la même transaction, on insère une ligne « envoyer ce courriel ». Un autre processus lit la table et l’envoie. Alors si la transaction est annulée, aucun courriel.

Rafael(intervieweur) :

Et si le processus envoie le courriel, puis plante avant de marquer la ligne comme envoyée?

Minh(personne candidate) :

Alors… il l’envoie encore. Hmm.

Je pense qu’on ne peut pas garantir l’envoi du courriel exactement une fois. C’est au moins une fois. Certains fournisseurs de courriel acceptent une clé, je pense, pour pouvoir ignorer le deuxième envoi. Mais je n’ai pas vérifié si le nôtre le faisait.

Rafael(intervieweur) :

C’est la bonne réponse. La plupart des gens disent « exactement une fois » ici, et ils ont tort. Comment saviez-vous que la correction fonctionnait?

Minh(personne candidate) :

J’ai écrit un test qui envoie le même événement vingt fois en même temps, avec des goroutines, des tâches concurrentes en Go. Avant la correction, il envoyait quatre ou cinq courriels. Après, un seul. Et en production, on a compté les courriels par événement pendant deux semaines. C’était toujours un.

Pourquoi cela fonctionne

Le test reproduit la cause, pas seulement le symptôme : plusieurs envois au même moment. Ensuite, Minh a vérifié en production. Rafael cherche cette habitude chez chaque candidat, à tous les niveaux : « comment testeriez-vous ça? »

Rafael(intervieweur) :

D’accord. Une autre question. Avez-vous vous-même causé un problème? Pendant le stage.

Minh(personne candidate) :

Oui. J’ai ajouté un index sur la table des événements. Dans une migration. Et les insertions se sont arrêtées pendant peut-être quarante secondes, parce que créer un index bloque les écritures dans la table. Le processeur a commencé à réessayer. Ce n’était pas un gros problème, mais mon mentor a vu l’alerte.

Maintenant, je connais CREATE INDEX CONCURRENTLY. Je l’ai appris ce jour-là.

Ici, Rafael remarque quelque chose d’important pour la suite de l’appel. Minh dit « je ne sais pas » sans crainte, et distingue son travail de celui de son mentor. Pour un nouveau diplômé, cette honnêteté vaut plus qu’un projet plus ambitieux. Rafael passe au problème de Casewell.

À propos de l'anglais

Minh fait quelques petites erreurs de grammaire. Rafael n’y réagit pas, et un bon intervieweur ne le fera pas non plus. Il écoute le raisonnement. Votre anglais n’a pas besoin d’être parfait. Consultez nos conseils sur l’anglais en entrevue.

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, nous les traitons dans la requête de téléversement; elle dépasse le délai, les gens retéléversent, et nous recevons 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, maintenant corrigé. Comment repenseriez-vous le traitement des documents et le clavardage pour empêcher ces problèmes?

Minh(personne candidate) :

D’accord. Ça fait beaucoup. Je commence par le téléversement. Combien de temps prend le traitement d’un contrat? À peu près.

Rafael(intervieweur) :

Ça dépend de la longueur. Disons 20 secondes pour un contrat normal, avec les appels au modèle.

Minh(personne candidate) :

Donc 2 000 fois 20 secondes, c’est 40 000 secondes. Ça fait… onze heures, si on les traite un par un. Ça ne peut jamais tenir dans une requête. La requête devrait seulement enregistrer le fichier et répondre vite. Comme « 202, accepté », avec un identifiant de tâche. Ensuite, des processus traitent les fichiers en arrière-plan, et la page demande l’état d’avancement.

Rafael(intervieweur) :

D’accord. Et les doublons?

Minh(personne candidate) :

C’est comme mon bogue de webhook, je pense. Calculer l’empreinte du fichier. Le SHA-256 des octets. Une contrainte d’unicité sur l’identifiant du locataire et l’empreinte. Si l’utilisateur téléverse encore, l’insertion ne fait rien et on retourne le même document.

Rafael(intervieweur) :

Pourquoi l’identifiant du locataire dans la contrainte? Un même fichier reste le même fichier, non?

Minh(personne candidate) :

Non, parce que deux cabinets peuvent avoir le même contrat. Comme les deux parties d’une transaction. Si l’empreinte est globale, le cabinet B téléverse, et on dit « existe déjà ». Et peut-être qu’on le relie au document du cabinet A. C’est une fuite. Chaque cabinet doit avoir sa propre copie.

Pourquoi cela fonctionne

Minh réutilise son expérience au lieu d’inventer quelque chose de nouveau. Puis il voit sans aide le problème des locataires : une règle d’unicité globale relierait les données de deux clients. La même idée va bientôt devenir très importante.

Rafael(intervieweur) :

Bien. Maintenant, le gros téléversement qui a ralenti tout le monde. Un cabinet, 1 800 fichiers, une seule file d’attente partagée. Que faites-vous?

Minh(personne candidate) :

Peut-être une file d’attente par locataire? Ensuite, les processus prennent les tâches dans chaque file à tour de rôle.

Rafael(intervieweur) :

Nous avons environ 400 locataires. 400 files d’attente dans Celery?

Minh(personne candidate) :

Hmm. Je ne sais pas comment Celery se comporte avec 400 files d’attente. Je n’ai jamais utilisé Celery, sauf un peu dans un cours.

Attendez. Peut-être pas des files. Peut-être une limite. Chaque locataire peut avoir seulement, je ne sais pas, dix tâches en cours à la fois. Les autres tâches attendent dans une table dans Postgres, pas dans la file.

Rafael(intervieweur) :

D’accord. Et qui les déplace de la table vers la file?

Minh(personne candidate) :

Un ordonnanceur. Toutes les quelques secondes, il regarde… pour chaque locataire, combien de tâches sont en cours, et en ajoute si c’est sous la limite.

Là, je fais une hypothèse. Je n’ai pas construit ça. Aussi, si un processus s’arrête et que le compte des tâches « en cours » est faux, je ne sais pas encore ce qui arrive.

La limite de ses connaissances

Minh atteint ici la limite de ses connaissances. Il dit qu’il fait une hypothèse et nomme lui-même le prochain problème. Le compte des tâches en cours peut être faux quand un processus s’arrête. Il n’invente pas une réponse assurée sur un outil qu’il n’a pas utilisé.

Rafael(intervieweur) :

C’est une bonne hypothèse. Honnêtement, nous discutons presque de cette même conception en ce moment. Le problème du processus arrêté est réel. On utilise un bail : la tâche a une heure d’expiration, et le processus renouvelle le bail pendant son exécution. S’il arrête de le renouveler, la tâche retourne en attente.

Minh(personne candidate) :

Ah, d’accord. Comme un verrou avec un délai d’expiration.

Où cela tourne mal

À cette limite, beaucoup de nouveaux diplômés nomment un outil qu’ils ont découvert dans leurs lectures : « utiliser Kafka », « utiliser Temporal ». La question suivante porte sur son fonctionnement interne, et ils n’ont pas de réponse. Une hypothèse présentée comme telle, avec un point faible connu, est beaucoup plus sûre.

Rafael pose ensuite des questions sur les nouvelles tentatives. Minh propose un délai d’attente croissant entre les tentatives, et un nombre maximal. Ensuite, la tâche va dans une liste d’« échecs » qu’une personne peut consulter. Rafael lui donne le nom, une file de messages non traités (dead-letter queue). Minh dit qu’il connaissait l’idée, mais pas le nom. Rafael pose aussi une question sur les documents contenant « Ignorez les instructions précédentes ». Minh compare ça à l’injection SQL. Puis il s’arrête : « Mais avec SQL, on peut échapper les données d’entrée. Avec le modèle, on ne peut pas, je pense. » Le modèle ne devrait donc rien pouvoir faire de dangereux, même s’il suit le texte. Rafael écrit « bon instinct, aucune expérience » dans ses notes.

Minutes 40 à 50 : le bogue de cache

Rafael(intervieweur) :

Maintenant, la partie qui m’importe le plus. J’ai dirigé la correction de cet incident, alors je le connais bien. Le clavardage avait un cache : question semblable, puis les passages trouvés la dernière fois. La clé contenait seulement le texte de la question. Un client a demandé « quel est le délai de préavis de résiliation? » et a reçu des passages du contrat d’un autre client. Pendant environ 40 minutes.

Pourquoi est-ce arrivé, et comment vous assurez-vous que ça ne puisse plus arriver?

Minh(personne candidate) :

Je peux prendre une minute pour réfléchir?

Rafael(intervieweur) :

Bien sûr. Prenez votre temps.

Minh(personne candidate) :

Minh reste silencieux pendant environ une minute. Il écrit sur sa feuille.

D’accord. Désolé. Je veux partir de ce qu’est un cache.

Le silence

Une minute de silence semble très longue quand vous êtes le candidat. Pour l’intervieweur, c’est normal et bien mieux qu’une réponse rapide à la mauvaise question. Minh demande d’abord, alors Rafael sait qu’il réfléchit et que la connexion fonctionne. Si vous avez besoin de temps, demandez-le comme ça.

Rafael(intervieweur) :

Allez-y.

Minh(personne candidate) :

Un cache dit : même entrée, même sortie, donc je peux éviter le travail. C’est vrai seulement si la clé contient tout ce qui change la sortie. Les passages récupérés dépendent de la question, mais aussi des documents que l’utilisateur peut voir. La clé avait seulement la question. Alors il manquait une entrée dans la clé.

Rafael(intervieweur) :

Hum-hum.

Minh(personne candidate) :

Donc la clé a besoin de l’identifiant du locataire. Mais je pense, pas seulement du locataire. Si un cabinet téléverse un nouveau contrat, les anciens passages en cache sont maintenant incorrects. Alors aussi une version de l’ensemble des documents. Et peut-être l’utilisateur, si deux avocats du même cabinet peuvent voir des contrats différents. Est-ce possible?

Rafael(intervieweur) :

Oui, parfois. Les cabinets d’avocats ont… comment dire… des cloisons éthiques. Un avocat travaillant sur un dossier ne doit pas voir les documents d’un autre dossier, dans le même cabinet.

Minh(personne candidate) :

Alors la clé a aussi besoin de la portée des permissions. Ou le cache doit être par utilisateur. Ça rend le cache moins utile, mais c’est plus sûr.

Comment l’intervieweur va plus loin

Rafael donne un fait du domaine juridique, et Minh l’utilise tout de suite. C’est la méthode des premiers principes : trouver tout ce dont dépend la sortie et tout mettre dans la clé. Elle fonctionne pour n’importe quel cache, pas seulement celui-ci.

Rafael(intervieweur) :

D’accord. Et comment testeriez-vous ça? Pour que le problème ne revienne pas.

Minh(personne candidate) :

D’abord, un test simple. Deux locataires, le même texte de contrat, mais avec des noms différents dedans. Le locataire A pose la question, alors le cache est rempli. Ensuite, le locataire B pose la même question. Le test vérifie que chaque passage reçu par B a l’identifiant du locataire B.

Rafael(intervieweur) :

Pourquoi personne n’a trouvé ça dans les tests avant?

Minh(personne candidate) :

Hmm. Peut-être que les données de test ont seulement un locataire? Alors le bogue ne peut pas arriver dans le test. Donc les données préparées pour les tests devraient toujours avoir au moins deux locataires. Partout, par défaut.

Rafael(intervieweur) :

Il rit un peu. Oui. C’était exactement ça. Un seul locataire dans toutes les données préparées pour les tests.

Minh(personne candidate) :

Et une autre idée. Peut-être vérifier aussi à la lecture. Quand le cache donne les passages, vérifier que chaque passage a le même identifiant de locataire que la requête. Sinon, le rejeter et envoyer une alerte. Alors même si la clé est encore incorrecte, l’utilisateur ne le voit pas.

Rafael(intervieweur) :

Ça fait deux couches. Pourquoi les deux?

Minh(personne candidate) :

Parce que la clé est à un endroit, mais quelqu’un va ajouter un autre cache l’an prochain. La vérification à la fin protège aussi le prochain cache.

Une meilleure réponse

La réponse de Minh est déjà solide. Une étape de plus la rendrait complète : rendre le mauvais code difficile à écrire. Par exemple, une petite fonction de cache qui exige un identifiant de locataire et refuse de fonctionner sans lui. Ainsi, le prochain ingénieur ne peut pas l’oublier. La question « comment trouver les autres caches comme celui-ci? » aurait aussi une réponse. Chercher les appels directs au cache dans le code et les remplacer.

Rafael pose une autre question ici : « Nous avons la sécurité au niveau des lignes dans Postgres. Ça ne suffit pas? » Minh dit qu’il n’est pas certain du fonctionnement de RLS avec les groupes de connexions. Il pense qu’il faut définir le paramètre du locataire pour chaque transaction, pas pour toute la connexion. Sinon, la requête suivante sur la même connexion pourrait recevoir le mauvais locataire. Rafael le confirme. Puis Minh ajoute : « Mais le cache était dans Redis, non? RLS ne peut pas voir Redis. » C’était tout l’incident en une phrase.

Minutes 50 à 60 : les questions de Minh et la fin

Minh(personne candidate) :

J’ai deux questions. D’abord, l’offre demande quatre ans. Pourquoi m’avez-vous invité?

Rafael(intervieweur) :

Question honnête, réponse honnête. Votre épreuve de programmation était très bonne, et Nora voulait un deuxième avis. Je ne peux pas vous dire la décision. Mais nous avons aussi un programme pour les nouveaux diplômés. Je vais le mentionner dans mes notes.

Minh(personne candidate) :

D’accord, merci. Deuxième question. Si je me joins à l’équipe, de qui pourrais-je apprendre? Par exemple, est-ce qu’une nouvelle personne a un mentor?

Rafael(intervieweur) :

Désolé, votre image a figé un peu. Pouvez-vous répéter?

Minh(personne candidate) :

Désolé. Si je me joins à l’équipe, est-ce qu’une nouvelle personne a un mentor?

Rafael(intervieweur) :

Oui. Dans le programme, un ingénieur est votre mentor pendant les six premiers mois, sans périodes de garde pour vous. Dans le poste normal, c’est moins structuré.

Pourquoi cela fonctionne

Minh demande pourquoi il a été invité, directement et poliment. La réponse lui révèle une deuxième voie que l’offre ne mentionne pas. Sa deuxième question porte sur l’apprentissage, une bonne priorité pour un nouveau diplômé. Consultez une entrevue est une conversation dans les deux sens.

Rafael(intervieweur) :

Le temps est écoulé. Ben vous contactera cette semaine. Merci, Minh. J’ai aimé la partie sur le cache.

Minh(personne candidate) :

Merci. Moi aussi. C’était difficile, mais j’ai appris quelque chose.

Après l’appel : les notes de Rafael

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

Backend Python et API : quelques éléments probants. Surtout du Go pendant le stage. Explications claires et correctes sur la conception des requêtes et des réponses.

Postgres : des éléments solides. Niveaux d’isolation, contraintes d’unicité, verrou sur l’index. Mieux que bien des candidats d’expérience.

Files d’attente, nouvelles tentatives et tâches en arrière-plan : quelques éléments probants. Bons réflexes et limites reconnues honnêtement sur l’équité entre locataires. Aucune expérience avec Celery ou à grande échelle.

Sécurité et isolation des locataires : des éléments solides pour son niveau. Raisonnement à partir des principes de base sur la clé de cache. Proposition de deux couches et d’un test avec deux locataires. A vu que la sécurité au niveau des lignes (RLS) ne couvre pas Redis.

Responsabilité en production : aucun élément probant. Normal pour un nouveau diplômé. Il n’a pas fait semblant.

Fonctionnalités avec des LLM : aucun élément probant. Bon réflexe concernant l’injection de requêtes.

Communication : des éléments solides. A demandé du temps et dit « Je fais une supposition » quand c’était le cas. A corrigé son propre CV.

Recommandation : non pour ce poste; oui sans hésitation pour le programme destiné aux nouveaux diplômés. Nora, regarde du côté du programme, s’il te plaît. J’aimerais être son mentor, si possible.

La suite

Nora a lu les notes de Rafael et le rapport de l’entrevue de programmation. Le poste exige quelqu’un qui pourra bientôt prendre en charge le pipeline de téléversement. Minh n’en est pas encore capable. Mais le programme destiné aux nouveaux diplômés avait des places pour janvier. Nora a demandé à Ben d’y transférer la candidature de Minh. Minh n’a eu aucune entrevue à refaire. Il a eu un appel supplémentaire de 30 minutes avec Nora au sujet du programme.

Ben a appelé Minh et lui a expliqué la situation honnêtement. Ce n’est pas le poste auquel il a postulé. C’est un autre niveau, avec une échelle salariale plus basse et un mentor. Minh a demandé deux jours pour réfléchir, puis a posé une autre question : « Est-ce que je travaillerai sur le pipeline de téléversement? » Nora a répondu oui, avec Rafael. Minh a accepté l’offre au niveau des nouveaux diplômés.

Postuler à un poste au-dessus de votre niveau n’est pas une erreur. Parfois, l’entreprise a une place qui vous convient mieux. La seule façon de la trouver, c’est d’en discuter.

Ce qu’il faut retenir

• Les bases sont des preuves de compétence. Les niveaux d’isolation et les contraintes d’unicité ont beaucoup compté dans l’entrevue de Minh. Maîtrisez-les assez pour les expliquer à partir d’un bogue que vous avez rencontré.
• Corrigez vos propres exagérations avant que la personne qui vous interviewe le fasse. « Un débit élevé, c’était peut-être un peu exagéré » a rendu tout ce qui suivait plus crédible.
• Demander une minute est une force. Dites que vous en avez besoin, puis réfléchissez. Une minute de silence est normale dans une bonne entrevue.
• Les principes de base s’appliquent partout. « De quoi dépend le résultat? » fonctionne pour toute clé de cache, dans toute entreprise. Vous n’avez pas besoin d’expérience en production pour poser cette question.
• Dites « Je fais une supposition » quand c’est le cas. Les limites de Minh sur l’équité entre locataires ne lui ont pas nui. Il les a indiquées clairement et a lui-même nommé le point faible.
• Votre anglais n’a pas besoin d’être parfait. Rafael a évalué le contenu. Consultez nos conseils.

Si votre profil ressemble à celui de Minh

Vous avez moins d’expérience que ce que demande l’offre d’emploi. Vous pouvez quand même être une candidature sérieuse si vos quelques projets vont en profondeur. Consultez Aucune expérience de travail dans ce rôle?.

1. Choisissez un bogue de votre stage ou de votre projet et comprenez-le à fond. Pourquoi s’est-il produit? Que fait la base de données à chaque étape? Quel niveau d’isolation changerait le résultat, et pourquoi? Exercez-vous à raconter l’histoire à voix haute, en anglais, deux ou trois fois. Notre leçon Expliquer vos décisions montre comment faire.
2. Corrigez les mots de votre CV. Remplacez chaque adjectif exagéré par un chiffre que vous pouvez justifier. Consultez Les éléments d’un portfolio.
3. Créez un petit service multilocataire. Une application FastAPI avec deux locataires, Postgres avec la sécurité au niveau des lignes et un cache Redis. Écrivez un test qui tente de lire les données de l’autre locataire à travers chaque couche. Ce seul projet vous prépare à la plupart des questions de cette entrevue. Commencez par Conception des ressources et des points de terminaison et Tests automatisés des points de terminaison.
4. Apprenez à utiliser un outil de tâches en arrière-plan en vous en servant. Celery ou un outil de flux de travail durable, peu importe lequel. Faites échouer une tâche volontairement, relancez-la et envoyez-la dans une file de lettres mortes. Vous pourrez alors parler des nouvelles tentatives à partir de votre expérience, pas d’un article de blogue.
5. Apprenez à faire des migrations sûres. Création d’index, ajout d’une colonne, changement de nom. Consultez Migrations sûres.
6. Renseignez-vous sur les programmes destinés aux nouveaux diplômés. Si une entreprise en offre un, posez la question à la personne responsable du recrutement dès le début. Il pourrait mieux vous convenir que le poste annoncé.