Ce que testent vraiment les entretiens d'ingénieur backend

Vous cherchiez une liste de questions. Il en existe beaucoup, et la plupart sont inutiles, car un processus backend n'est pas un test répété quatre fois. Ce sont trois ou quatre tests différents, menés par des personnes différentes, évaluant des compétences différentes, et une liste les aplatit en connaissances fragmentaires. Quelqu'un qui récite le théorème CAP échoue quand même à l'épreuve de conception. Quelqu'un qui résout le problème de tableau en quinze minutes échoue quand même au deep dive sur son propre travail.

Ce qui suit est la structure de la chose, et ce que la personne en face écoute vraiment.

La structure du processus

Pour un poste backend de niveau intermédiaire ou senior dans une entreprise de plus de cinquante ingénieurs environ, le processus est généralement un sous-ensemble de :

1. Entretien recruteur, 20-30 minutes. Stack technique, niveau, préavis, localisation et visa, attentes salariales, si vous êtes d'astreinte actuellement et si vous acceptez de l'être.
2. Appel avec le hiring manager, 30-45 minutes. Ce dont vous êtes responsable, ce que vous avez livré, pourquoi vous partez. Parfois une légère sonde technique.
3. Un exercice de code. En direct dans un éditeur partagé, en direct dans votre propre repo en binôme avec un ingénieur, ou un exercice à emporter que vous soumettez puis présentez.
4. Une épreuve de conception système, 45-60 minutes, tableau blanc ou canvas Excalidraw vierge.
5. Un deep dive sur quelque chose que vous avez construit, parfois fusionné avec l'épreuve de conception, parfois séparé.
6. Une épreuve comportementale ou cross-fonctionnelle, souvent avec un ingénieur d'une autre équipe ou un product manager.

Les petites entreprises compressent cela : un appel fondateur, un exercice à emporter, un entretien final sur site qui fait tout à la fois. Les processus des grandes entreprises tech ajoutent une épreuve dédiée au système de valeurs de l'entreprise et peuvent peser beaucoup plus lourdement le code algorithmique. La question de savoir si un screening algorithmique intense prédit la performance en poste est réellement contestée — vous trouverez des ingénieurs avec des opinions fortes dans les deux sens et très peu de preuves publiques dans un sens ou l'autre. C'est toujours la porte d'entrée dans beaucoup d'endroits, donc la question pratique n'est pas de savoir si c'est juste mais si cet employeur particulier l'utilise. Demandez au recruteur. Il vous le dira, et le format qu'il nomme vous dit quoi préparer.

Qui est vraiment dans la salle

L'épreuve de code est généralement menée par un ingénieur senior de l'équipe ou proche, parfois avec une seconde personne silencieuse qui prend des notes. Ils ont une grille d'évaluation. Ils n'essaient pas de vous piéger, et à la troisième épreuve ils s'ennuient surtout, ce qui est pire.

L'épreuve de conception est plus souvent un ingénieur staff ou principal, ou un senior expérimenté qui fait ça fréquemment. Cette personne a des opinions sur les queues, et elle a été réveillée à 04h00 par quelque chose que vous êtes sur le point de décrire avec désinvolture.

Le deep dive peut être le hiring manager ou un tech lead. Leur travail est d'établir si les décisions dans vos histoires étaient les vôtres ou vous ont été données.

Cela importe car la même réponse est notée différemment selon qui demande. « Nous avons utilisé Kafka » est un fait pour un recruteur, un point de départ pour un manager, et pour l'ingénieur staff c'est une invitation à demander pourquoi pas SQS, quelle était votre clé de partition, et ce qui est arrivé à l'ordre quand vous avez dû retraiter.

L'exercice de code, et ce qu'il évalue vraiment

Trois formats dominent, et ils évaluent des choses différentes.

Screening algorithmique. Généralement 45 minutes, un ou deux problèmes, hash maps et deux pointeurs et le traversal de graphe occasionnel. L'évaluation est surtout : êtes-vous arrivé à une solution fonctionnelle, avez-vous parlé en le faisant, avez-vous remarqué la complexité, l'avez-vous testé. Le silence est le mode d'échec courant, pas l'erreur.

Exercice réaliste. De plus en plus commun dans les entreprises de taille moyenne. Parser ce fichier et l'exposer via HTTP. Implémenter un rate limiter. Ajouter un endpoint à ce repo existant. Ici l'évaluation est plus proche d'une vraie revue de code : gérez-vous les erreurs ou les avalez-vous, validez-vous les entrées, vos noms ont-ils du sens, avez-vous écrit un test, avez-vous remarqué l'ambiguïté dans la spec et demandé plutôt que deviné.

Binômage sur une vraie base de code. Vous serez déposé dans un repo inconnu avec un bug ou une petite fonctionnalité. Cela teste la navigation plus que la rédaction : pouvez-vous trouver où vit la chose, lisez-vous les tests d'abord, l'exécutez-vous avant de le changer.

Dans les trois, la question du langage se pose. Si vous choisissez Go, attendez-vous à ce que quelqu'un demande l'annulation de contexte, les fuites de goroutines, ou pourquoi vous avez utilisé un channel là où un mutex était plus simple. Si vous choisissez Java, attendez-vous à la JVM : heap versus off-heap, ce qu'une pause full GC fait à votre p99, le dimensionnement du pool de threads, et quelque chose en forme de Spring sur les scopes de beans ou les limites transactionnelles. Python invite le GIL et si votre appel bloquant vient de bloquer la boucle d'événements. Node invite la même question dans des vêtements différents. Choisissez le langage que vous écrivez vraiment, pas celui qui sonne senior selon vous.

Conception système : les questions dans la question

L'énoncé sera large — concevoir un raccourcisseur d'URL, un service de notification, un système de réservation de billets, peu importe ce que l'intervieweur a fait quarante fois. L'énoncé n'est pas le test. Le test est l'ensemble des questions de suivi, et elles sont assez prévisibles car ce sont les choses qui cassent vraiment en production.

Idempotence. « Le client appelle POST /payments, timeout, et réessaie. Et maintenant ? » Une bonne réponse cherche une clé d'idempotence fournie par le client, une contrainte unique dans la base de données, et une décision sur quoi retourner sur le doublon. Une très bonne réponse mentionne l'outbox transactionnelle, car vous êtes sur le point de publier un événement sur ce paiement et l'écriture et la publication ne sont pas atomiques.

Sémantiques de livraison. Presque chaque queue que vous nommerez est at-least-once. Donc : comment ne facturez-vous pas le client deux fois, et quelle est votre fenêtre de déduplication, et où vit l'état de dédup, et que se passe-t-il quand il expire. Si vous dites « exactly-once » sans immédiatement qualifier ce que vous voulez dire, vous avez donné à l'intervieweur sa prochaine question.

Propagation d'échec. « Votre service appelle un service en aval qui vient de devenir lent — pas down, lent. » La réponse qu'ils veulent parcourt la chaîne : les requêtes tiennent les connexions plus longtemps, le pool sature, votre propre queue grandit, votre latence augmente, vos appelants timeout et réessaient, et les réessais amplifient la charge sur la chose qui peinait déjà. Puis les atténuations : des timeouts qui sont vraiment définis, des budgets plutôt que des timeouts par appel, un backoff exponentiel avec jitter, des circuit breakers, des bulkheads, du load shedding. L'expression « retry storm » vous donne du crédit car elle montre que vous en avez vu une.

Données. Attendez-vous à des questions d'index formulées comme des symptômes plutôt que de la théorie : une requête qui était rapide le mois dernier et est lente maintenant sans changement de code. Retournements de plan, statistiques obsolètes, une hypothèse de sélectivité qui a cessé de tenir alors que la table grandissait, contention de verrous, bloat et comportement de vacuum dans Postgres. Attendez-vous à une question de migration de schéma — renommer ou diviser une colonne sans downtime — où la réponse attendue est expand and contract : ajouter la nouvelle colonne, double-écriture, backfill par lots, déplacer les lectures, arrêter d'écrire l'ancienne, la supprimer plus tard.

Caching. « Ajouter un cache » est le début de la conversation. Les questions de suivi sont la stratégie d'invalidation, TTL versus éviction explicite, ce qui arrive à l'origine quand une clé chaude expire et qu'un millier de requêtes arrivent en même temps, et si vous êtes prêt à servir des données obsolètes et pour combien de temps.

Mesure. Si vous dites qu'un système est rapide, quelqu'un demandera comment vous le savez, et la bonne monnaie est les percentiles et les taux d'erreur, pas les moyennes. Savoir pourquoi la moyenne cache le problème — et que l'utilisateur qui expérimente le p99 est souvent votre utilisateur de plus haute valeur, car il a le plus de données — est une petite chose qui se lit comme de l'expérience.

Le deep dive sur votre propre travail

Cette épreuve décide la séniorité plus souvent que l'épreuve de code. L'énoncé est une version de « parlez-moi d'un système que vous avez conçu ou substantiellement changé. » Puis :

• Quelles étaient les alternatives, et pourquoi les avez-vous rejetées ?
• Qu'avez-vous raté ?
• Qu'est-ce qui a cassé après la livraison ?
• Comment saviez-vous que ça fonctionnait ?
• Que feriez-vous différemment maintenant ?
• Qui était en désaccord avec vous, et que s'est-il passé ?

L'intervieweur teste si vous étiez celui qui prenait les décisions. Les candidats qui ont hérité d'une conception la décrivent magnifiquement puis n'ont rien quand on leur demande les alternatives, car il n'y en a jamais eu de leur point de vue. C'est bien — dites-le, et décrivez une décision qui était vraiment la vôtre, même si elle était plus petite. Un choix bien raisonné sur comment backfill deux cents millions de lignes est une meilleure preuve qu'un compte-rendu vague d'une architecture que quelqu'un d'autre a dessinée.

Ayez les détails de déploiement prêts. Feature flag ou déploiement progressif, quel était le kill switch, quelle métrique vous avez surveillée, quel était le plan de rollback, et si vous avez dû l'utiliser. Ayez un incident prêt dans lequel vous étiez la cause. Blameless est la culture ; assumer l'erreur sans théâtralité est le signal.

À quoi ressemble une réponse superficielle

De l'autre côté de la table, voici les signaux :

• « Nous avons utilisé Kafka parce que ça scale. » Pas de clé de partition, pas de consumer group, aucune mention de quelle garantie d'ordre vous aviez besoin ou avez perdue.
• « On ajouterait Redis. » Cache énoncé comme la solution, sans histoire d'invalidation, sans TTL, sans réflexion sur le stampede.
• « Microservices. » Offert comme une architecture plutôt qu'un compromis — aucune mention de la transaction que vous venez de perdre, de l'appel réseau que vous venez d'ajouter, ou comment vous les déployez ensemble de toute façon maintenant.
• « On indexerait cette colonne. » Sans notion de cardinalité, coût d'écriture, ou si la requête l'utiliserait du tout.
• « C'est eventually consistent. » Utilisé comme une réponse plutôt qu'une description d'un problème que vous devez ensuite gérer dans l'UI ou le job de réconciliation.
• « C'était rapide, genre 50 millisecondes. » Moyenne, à quelle charge, mesurée où.
• « Nous avons cent pour cent de couverture de test. » Mentionné sans aucun compte-rendu de ce que les tests assertent vraiment, s'ils tournent contre une vraie base de données, ou comment les flakes sont gérés.
• « Il faudrait que je vérifie ça. » Bien pour un détail de syntaxe. Pas bien comme réponse à ce qui arrive quand le service en aval de votre service devient lent.

Le fil commun est un nom là où devrait être un compromis. Nommer une technologie n'est pas une réponse ; décrire ce qu'elle vous coûte et pourquoi vous avez accepté ce coût en est une.

Que faire ensuite

Quatre choses, dans l'ordre de combien elles feront bouger l'aiguille.

Écrivez deux de vos propres systèmes, correctement. Un diagramme, les trois décisions que vous avez vraiment prises, les alternatives, ce qui a cassé, ce que vous avez mesuré. Une heure chacun. C'est l'épreuve la plus souvent perdue et la moins souvent préparée.

Répétez la chaîne d'échec à voix haute. Downstream lent, saturation du pool, amplification de retry, et les quatre atténuations. Si vous pouvez le dire couramment, une grande fraction des questions de suivi de conception deviennent la même réponse dans des costumes différents.

Choisissez un langage et soyez prêt pour ses aspérités. Un paragraphe chacun sur le modèle mémoire ou modèle de concurrence, comment vous trouveriez une fuite, et comment vous profileriez un endpoint lent.

Demandez au recruteur ce qu'est l'épreuve de code. Algorithmique, réaliste, ou binômage. Il vous le dira, et les trois demandent une préparation différente. Se préparer pour la mauvaise est la perte évitable la plus courante dans ce processus.