Questions d'entretien Ingénieur logiciel

Ma première étape est de reproduire le problème de façon fiable. Un bug intermittent que je ne peux pas reproduire est bien plus difficile à corriger qu'un bug que je peux déclencher de façon constante. Une fois que je peux le reproduire, je formule une hypothèse sur la cause racine en me basant sur les symptômes, puis j'ajoute des logs ciblés ou j'utilise un débogueur pour tester cette hypothèse. Je travaille de l'extérieur vers l'intérieur, en partant du point le plus proche de l'échec observable et en remontant la pile d'appels. J'évite de changer plusieurs variables à la fois, car cela rend impossible de savoir ce qui a réellement corrigé le problème. Si je bloque après 30 minutes, je demande à un collègue : un regard neuf est presque toujours plus rapide qu'un effort solo prolongé.

J'écris des tests dans le cadre du développement, pas comme une réflexion après coup. Pour toute fonction non triviale, j'écris des tests unitaires couvrant le chemin nominal, les cas limites et les modes d'échec. J'utilise la revue de code comme porte de qualité et j'essaie de donner du contexte aux reviewers en gardant les pull requests petites avec des descriptions claires. J'investis aussi dans la lisibilité : une fonction facile à comprendre est plus facile à tester et à maintenir. Je m'appuie sur des outils d'analyse statique et des linters dans la CI pour détecter les problèmes avant la revue. Quand je trouve un bug en production, ma première action après la correction est d'écrire un test de régression pour que le même bug ne revienne pas silencieusement.

Tôt dans ma carrière, j'ai construit un pipeline de données qui lisait la configuration depuis des variables d'environnement sans couche de validation. Cela fonctionnait bien en local et en staging, mais en production une variable manquante a causé un échec silencieux qui a pris des heures à diagnostiquer. Je validerais maintenant toujours et échouerais rapidement au démarrage : si une valeur de configuration requise est manquante ou malformée, le service devrait refuser de démarrer et enregistrer une erreur claire. Plus généralement, j'ai appris à investir dans l'observabilité dès le début. Les logs et métriques ajoutés après coup sont toujours moins utiles que ceux conçus dès le départ.

J'utilise Cursor comme éditeur principal et je m'appuie fortement sur lui pour le code boilerplate, la génération de tests unitaires et les refactorisations simples. Pour cette catégorie de travail, il a considérablement réduit mon temps, et il me permet de me concentrer sur les parties d'un problème où j'apporte vraiment de la valeur. Pour la revue de code, je trouve l'IA utile pour détecter les problèmes évidents et suggérer des cas limites que j'aurais pu manquer, bien que je fasse toujours une passe manuelle avant que quoi que ce soit ne parte en review. Je suis plus prudent pour les décisions architecturales complexes : la fenêtre de contexte ne capture pas suffisamment du système pour lui faire confiance là, et les suggestions tendent à être génériques. Mon évaluation honnête est que l'IA m'a rendu plus rapide sur les problèmes bien connus et s'est avérée moins utile sur les problèmes vraiment nouveaux. Je révise aussi soigneusement tout ce qu'elle produit car le code généré par l'IA peut être subtilement incorrect de façons qui ne font pas échouer les tests évidents.

J'ai rejoint une équipe en cours de projet sur un monolithe legacy avec une documentation minimale. Plutôt que de plonger directement dans la fonctionnalité qui m'avait été assignée, j'ai passé la première semaine à lire le code autour de la zone que j'allais toucher, à exécuter la suite de tests et à cartographier manuellement le flux de données. J'ai aussi trouvé la personne qui avait géré cette zone le plus longtemps et fait une session en binôme avec elle pour combler le contexte que je ne pouvais pas obtenir du code seul. Quand j'ai commencé à faire des changements, je les ai gardés petits et isolés pour que chaque pull request soit facile à revoir et à annuler. La fonctionnalité a été livrée à temps.

Mon équipe a décidé d'utiliser un mécanisme de polling pour synchroniser l'état entre deux services. Je pensais qu'une approche événementielle serait plus scalable et réduirait la charge inutile. Je l'ai soulevé lors de la revue de conception avec une courte comparaison écrite des deux approches, couvrant les compromis en complexité, latence et overhead opérationnel. L'équipe a décidé de procéder avec le polling en citant le délai de livraison plus rapide et la familiarité existante. J'ai été en désaccord mais j'ai pleinement adhéré une fois la décision prise. Six mois plus tard, nous sommes passés aux événements quand le problème de charge s'est matérialisé. Je n'ai pas considéré cela comme une validation : la décision initiale avait du sens compte tenu des contraintes de l'époque.

Notre environnement de développement local nécessitait une configuration manuelle en 12 étapes, non documentée et incohérente d'une machine à l'autre. Les nouveaux ingénieurs perdaient régulièrement une demi-journée à le configurer. J'ai passé un vendredi après-midi à écrire un script shell et un README qui automatisaient l'ensemble du processus de configuration, testé sur une machine vierge, et ouvert une pull request. Cela a pris quatre heures au total. Depuis, les nouvelles recrues sont opérationnelles en moins de dix minutes. Je l'ai ensuite ajouté à la checklist d'intégration pour qu'il reste maintenu.

Un processus est un programme indépendant avec son propre espace mémoire, ses descripteurs de fichiers et ses ressources OS. Les threads sont des unités d'exécution qui vivent dans un processus et partagent son espace mémoire. La différence pratique clé est l'isolation : un crash dans un processus n'entraîne pas automatiquement un autre, alors qu'un crash dans un thread peut affecter tout le processus. J'utilise plusieurs processus quand j'ai besoin d'une isolation forte, par exemple lors de l'exécution de code non fiable. J'utilise des threads quand j'ai besoin de concurrence avec un état partagé et que la surcharge de la communication inter-processus serait trop élevée. En pratique, pour le travail I/O-bound, j'utilise souvent les patterns async/await en premier.

Je commencerais par clarifier les exigences : volume d'écriture attendu, ratio lecture/écriture, durée de vie des URLs et si des analytics sont nécessaires. Pour le service principal, je générerais une clé courte en encodant un ID unique (l'encodage base62 d'un entier auto-incrémenté est simple et sans collision). Je stockerais le mapping dans une base de données avec la clé courte comme clé primaire. Pour les lectures, qui dépassent largement les écritures, je mettrais un cache (Redis) devant la base pour servir la redirection avec une latence inférieure à la milliseconde. La redirection est un HTTP 301 (permanent) ou 302 (temporaire) selon que l'on souhaite le cache du navigateur. Le chemin de lecture est sans état et facilement scalé horizontalement.

Les bases SQL stockent les données dans des tables avec un schéma fixe et utilisent des transactions ACID pour garantir la cohérence. Elles sont excellentes quand vos données ont des relations claires et que la cohérence est critique. Les bases NoSQL échangent certaines de ces garanties contre de la flexibilité et de la scalabilité horizontale. Les bases documentaires comme MongoDB fonctionnent bien quand vos données sont hiérarchiques. Les bases clé-valeur comme Redis excellent pour les lookups simples à haut débit. Les bases colonnes comme Cassandra sont conçues pour les workloads time-series ou à forte écriture. Mon point de départ par défaut est une base relationnelle. Je passe au NoSQL quand j'ai un pattern d'accès spécifique que le modèle relationnel gère mal.