Ingénieur logiciel Questions d'entretien & Réponses

Exemple de réponse

Dans une précédente entreprise, l'équipe voulait adopter une base NoSQL pour une nouvelle fonctionnalité de suivi de commandes, alors que les schémas d'accès impliquaient des jointures complexes entre clients, commandes et paiements. Je pensais qu'une base relationnelle classique convenait mieux à ce cas d'usage. J'ai préparé une note technique comparant les deux approches sur nos schémas d'accès réels : temps de requête estimé, complexité de migration et coût de maintenance à un an. J'ai proposé un spike de deux jours pour tester les deux options sur un sous-ensemble de données de production anonymisées. Les résultats étaient nets : les requêtes multi-tables prenaient 4 fois plus de temps sur la base NoSQL et nécessitaient de dupliquer des données dans plusieurs collections. L'équipe a changé d'approche sans que personne ne perde la face. Ce que j'ai retenu : une mesure chiffrée déplace une décision d'équipe bien plus vite qu'un argument d'autorité.

Exemple de réponse

Nous avions trois semaines pour livrer une fonctionnalité de collaboration en temps réel nécessitant des WebSockets, une technologie que je n'avais jamais utilisée en production. J'ai réservé mes matinées, mes heures les plus concentrées, à un apprentissage ciblé : construction d'un prototype jetable dès le premier jour pour toucher les vraies difficultés, lecture de la spécification, puis étude du code de deux bibliothèques open source matures pour voir comment elles géraient des cas limites comme la reconnexion après coupure réseau, l'ordonnancement des messages et le nettoyage des connexions zombies. J'ai aussi organisé deux sessions de pair programming avec un collègue d'une autre équipe qui avait déjà une expérience WebSocket en production, ce qui m'a fait gagner au moins une semaine sur les pièges classiques. Nous avons livré dans les temps, après des tests de charge simulant 500 connexions simultanées avant la mise en production. La fonctionnalité n'a connu aucun incident durant le premier trimestre suivant son lancement.

Exemple de réponse

Notre API grand public affichait une latence au 95e centile de 800 millisecondes, ce qui générait des tickets support récurrents sur la lenteur perçue de l'application mobile. J'ai profilé les endpoints les plus lents avec un outil d'APM et identifié trois schémas de requêtes N+1 dans notre couche ORM, en particulier sur l'endpoint de liste des commandes qui chargeait les informations client une par une. J'ai réécrit ces requêtes avec des jointures explicites et un chargement en lot, puis ajouté un cache Redis avec une expiration de 5 minutes pour une consultation des permissions utilisateur très sollicitée en lecture. La latence est tombée à 120 millisecondes au 95e centile, une amélioration de plus de 6 fois. Le plus grand défi a été de convaincre l'équipe produit d'investir deux semaines dans une tâche invisible pour l'utilisateur final : j'ai construit un tableau de bord reliant directement la latence de l'API au taux d'abandon du panier, ce qui a rendu l'argument business immédiatement évident et a débloqué le budget.

Exemple de réponse

Nous avons lancé une fonctionnalité de recommandation de produits développée sur deux mois, avec un algorithme de scoring assez sophistiqué, et l'engagement des utilisateurs était quasi nul : moins de 2 % de taux de clic sur les recommandations affichées. Nous avions optimisé l'algorithme pour maximiser le taux de clic prévu selon nos données historiques, mais les utilisateurs trouvaient les suggestions hors sujet une fois en situation réelle. J'ai mené un post-mortem sans chercher de responsable individuel, et nous avons identifié la cause racine : nous n'avions jamais interrogé un seul utilisateur avant de construire la fonctionnalité, tout reposait sur des hypothèses issues des données. J'ai rédigé une synthèse d'une page présentant ce constat à l'équipe produit, et proposé d'ajouter systématiquement une phase de découverte utilisateur, avec au moins 5 entretiens qualitatifs, avant tout développement de fonctionnalité majeure. Ce changement de processus a duré plus longtemps que la fonctionnalité elle-même : nous menons désormais ces entretiens avant chaque lancement important, et deux fonctionnalités ultérieures ont été redéfinies grâce à ce que nous y avons appris.

Exemple de réponse

L'essentiel repose sur deux opérations : l'écriture (à partir d'une URL longue, générer un code court) et la lecture (à partir d'un code court, rediriger vers l'URL d'origine). Pour le code court, j'utiliserais un encodage Base62 d'un identifiant auto-incrémenté : cela donne environ 3,5 milliards de codes possibles avec 6 caractères, et on peut passer à 7 caractères si le volume l'exige. Le chemin d'écriture interroge une base de données pour stocker la correspondance, puis met immédiatement à jour un cache. Le chemin de lecture passe d'abord par le cache, par exemple Redis, avec repli sur la base de données en cas d'absence, puis remplissage du cache pour les requêtes suivantes. À l'échelle, les lectures dépassent très largement les écritures, souvent dans un rapport de 100 pour 1 ou plus, donc le taux de succès du cache est le facteur de performance déterminant. J'ajouterais une limitation de débit sur les écritures pour éviter les abus et le spam de création de liens, et je stockerais séparément la date de création, l'identifiant utilisateur et les statistiques de clics dans une table analytique distincte, afin de garder le chemin de lecture aussi léger et rapide que possible. Pour la répartition géographique, un CDN devant le service de redirection réduit encore la latence perçue par l'utilisateur final.

Exemple de réponse

Un processus est un programme indépendant en cours d'exécution, avec son propre espace mémoire, que le système d'exploitation isole de celui des autres processus. Un thread est une unité d'exécution légère au sein d'un processus, partageant la mémoire et les ressources avec les autres threads du même processus. Utilisez des threads quand les tâches doivent communiquer fréquemment et partager un état : ils sont nettement moins coûteux à créer et à faire changer de contexte, ce qui les rend adaptés à des serveurs web gérant de nombreuses requêtes concurrentes. Utilisez des processus pour l'isolation : si l'un plante, les autres continuent de fonctionner. La mémoire physique reste toutefois une ressource partagée : sans limite explicite, un processus peut l'épuiser et conduire le système à tuer ce processus ou un autre. Cette isolation convient bien aux architectures à base de workers, dans lesquelles chaque tâche doit rester indépendante des autres. En pratique, je privilégie les threads pour le parallélisme au sein d'un même service quand la mémoire partagée simplifie le design, et les processus quand j'ai besoin d'isolation mémoire stricte ou de faire tourner des services totalement distincts. En Python, le GIL empêche les threads d'offrir un vrai parallélisme CPU, donc le multiprocessing s'impose souvent pour les traitements intensifs en calcul, tandis que les threads restent pertinents pour les opérations d'entrée-sortie, comme les appels réseau, où le GIL est relâché pendant l'attente.

Exemple de réponse

La cohérence à terme signifie qu'un système distribué finira par renvoyer la même valeur pour une clé donnée sur tous les nœuds, mais pas nécessairement de façon immédiate après une écriture. Les écritures se propagent de manière asynchrone entre les répliques, donc une lecture effectuée juste après une écriture, sur un nœud différent, peut renvoyer une valeur périmée pendant une fenêtre de quelques millisecondes à quelques secondes selon la topologie du système. J'accepterais la cohérence à terme pour des compteurs de mentions J'aime sur les réseaux sociaux, la synchronisation des préférences utilisateur entre plusieurs appareils, ou la mise à jour des niveaux de stock d'un catalogue produit affiché aux visiteurs : des cas où une valeur légèrement obsolète pendant une seconde ou deux ne cause aucun préjudice réel. Je ne l'accepterais en revanche jamais pour des transactions financières, des jetons d'authentification et de session, ou toute donnée dont l'obsolescence pourrait entraîner une décision business erronée, un double débit, ou un problème de sécurité. Dans ces cas, je choisirais un système garantissant la cohérence forte, quitte à accepter une latence ou une disponibilité légèrement inférieures lors d'une partition réseau.

Exemple de réponse

En Java, la JVM utilise un ramasse-miettes générationnel. Le tas est divisé en jeune génération et vieille génération selon la durée de vie des objets, une hypothèse qui reflète le fait que la plupart des objets meurent jeunes. Le ramasse-miettes effectue donc des cycles mineurs fréquents et peu coûteux sur la jeune génération, généralement en quelques millisecondes. Les objets qui survivent à plusieurs cycles sont promus vers la vieille génération, collectée moins souvent mais à un coût plus élevé, puisqu'elle contient davantage de données vivantes à parcourir. Les collecteurs modernes comme G1 et ZGC minimisent les pauses stop-the-world en effectuant la majorité du travail de façon concurrente avec l'exécution de l'application, au prix d'une consommation CPU en arrière-plan légèrement supérieure. Le compromis global est une surcharge mémoire et une latence de pause imprévisible : le ramasse-miettes échange du débit contre une gestion automatique de la mémoire. Pour les objets gérés sur le tas, elle évite les erreurs liées à une libération manuelle, comme la double libération ou l'accès à une zone déjà libérée. Cette gestion automatique n'empêche toutefois pas les fuites de mémoire : un objet conservé par erreur ne peut pas être collecté tant qu'il reste accessible. Sur des systèmes sensibles à la latence, comme des services de trading ou des API critiques, j'ai déjà ajusté la taille du tas et les paramètres du ramasse-miettes pour réduire la fréquence des pauses majeures, et dans des cas extrêmes déplacé les allocations du chemin critique hors du tas pour éviter toute pression sur le ramasse-miettes.

Exemple de réponse

D'abord, j'évalue la gravité et l'exploitabilité réelles : cette faille est-elle activement exploitée, et notre usage spécifique de la bibliothèque nous expose-t-il vraiment ? Si le risque est réel, j'escalade immédiatement au tech lead et au référent sécurité, et nous traitons le sujet comme un incident plutôt qu'une tâche de sprint ordinaire. Je cherche en priorité une version corrigée de la bibliothèque et je vérifie sa compatibilité avec le reste de nos dépendances. À défaut de correctif disponible, je vérifie si nous pouvons atténuer le risque dans notre propre code, par exemple en désactivant la fonctionnalité vulnérable ou en filtrant les entrées concernées, en attendant un correctif officiel ou en envisageant de changer de bibliothèque si le mainteneur est peu réactif. Je communique clairement et rapidement le statut à l'équipe et aux parties prenantes : qui est concerné, quel est le risque concret, ce que nous faisons, et sur quel calendrier. Le périmètre du sprint change en conséquence sans négociation : les correctifs de sécurité passent devant toute autre tâche planifiée, et je documente la décision pour la rétrospective.

Exemple de réponse

Je ne touche à rien avant d'avoir compris le système, même sous la pression du délai. Je passerais la première journée à cartographier les points d'entrée, le flux de données et les dépendances clés, en exécutant le code localement et en traçant des requêtes réelles à travers le système. Avant d'écrire la moindre ligne de code pour la nouvelle fonctionnalité, j'ajouterais des tests de caractérisation autour des zones que je dois modifier : des tests qui capturent fidèlement le comportement actuel du système, avant toute amélioration. Ce sont mes filets de sécurité pour détecter toute régression involontaire. Ensuite, j'apporterais les changements les plus limités et les plus ciblés possibles pour ajouter la fonctionnalité, avec des tests unitaires propres et complets pour tout le nouveau code que j'écris. Je résisterais activement à l'envie de tout refactoriser au passage : c'est une conversation séparée avec l'équipe et le product owner, avec son propre calendrier, son propre budget et sa propre évaluation des risques.

Exemple de réponse

Je m'assure d'abord de bien comprendre son approche en détail avant de la critiquer : parfois, la complexité apparente répond à des contraintes réelles, de scalabilité future ou de conformité, que je ne perçois pas encore avec mon niveau d'information. Je pose des questions ouvertes pour comprendre précisément ce qu'il ou elle cherche à optimiser, et sur quel horizon de temps. Si après cette clarification je reste convaincu que mon approche est plus adaptée à notre contexte actuel, je rédige une brève comparaison écrite : les compromis concrets de chaque option, ce que l'on gagne et ce que l'on perd dans chaque cas, et ma recommandation avec le raisonnement complet derrière. Je la présente sous forme de question ouverte : voici ce que je vois, est-ce que je passe à côté d'une contrainte importante ? Cette formulation ouvre un vrai dialogue et évite un affrontement de positions. Si, après discussion approfondie, l'ingénieur senior maintient son choix, je m'y engage pleinement et je l'exécute avec le même sérieux que si c'était mon idée : un désaccord d'architecture mérite une bonne discussion argumentée.

Exemple de réponse

Je ne donne jamais un chiffre unique pour un périmètre flou : ce chiffre deviendra un engagement ferme dans l'esprit de tout le monde, alors qu'il n'était qu'une supposition de départ. Je pose d'abord des questions de clarification précises pour cerner l'exigence centrale et identifier les inconnues les plus risquées : quels cas limites doivent être gérés, quelles intégrations externes sont concernées, quel niveau de qualité est attendu au lancement. Puis je donne une fourchette assumée : sur la base de ce que je sais aujourd'hui, c'est 3 à 5 jours de développement, mais ces trois questions ouvertes pourraient facilement pousser cela à 2 semaines si les réponses sont défavorables. Je nomme explicitement ce dont j'ai besoin pour affiner l'estimation : une décision produit sur le comportement d'un cas limite précis, l'accès à un système externe pour tester une hypothèse, ou une journée dédiée pour explorer la partie la plus incertaine avant de m'engager sur un chiffre définitif. Une bonne estimation reste une conversation continue avec les parties prenantes, ajustée à mesure que les inconnues se résolvent.