Questions d'entretien Développeur Backend : réponses et exemples

Réponse type

Je pars des besoins des consommateurs pour définir des points d'accès clairs et cohérents, en respectant les conventions REST. Je versionne l'API dès le départ, je documente chaque endpoint et je prévois la rétrocompatibilité. Je pense aussi à la pagination, à la gestion des erreurs et aux limites de débit pour garantir robustesse et lisibilité dans le temps.

Réponse type

Je mets en place une supervision avec des métriques, des journaux structurés et des alertes sur les seuils critiques. J'utilise des mécanismes de reprise comme les nouvelles tentatives et les disjoncteurs pour gérer les défaillances. Des tests de charge réguliers et des plans de retour arrière complètent ce dispositif pour limiter l'impact des incidents.

Réponse type

J'identifie d'abord le goulet d'étranglement par la mesure, car il peut être au niveau du processeur, de la base de données ou du réseau. J'applique ensuite la mise en cache, la mise à l'échelle horizontale et l'optimisation des requêtes selon le cas. Je conçois les services sans état autant que possible pour faciliter la réplication.

Réponse type

Je valide systématiquement les entrées, j'utilise des requêtes paramétrées contre les injections SQL et je chiffre les données sensibles. J'applique le principe du moindre privilège et je gère l'authentification avec des standards éprouvés comme OAuth. La sécurité est traitée à chaque étape, pas comme un correctif final.

Réponse type

J'analyse les schémas d'accès attendus : volume, fréquence de lecture et d'écriture, besoins de cohérence. Je choisis ensuite entre relationnel et NoSQL en fonction de ces contraintes, puis je normalise ou dénormalise selon les performances visées. Je documente le schéma et prévois sa migration future.

PUT remplace intégralement une ressource avec les données fournies et est idempotent. PATCH applique une modification partielle, ne mettant à jour que les champs spécifiés. On choisit PATCH quand on veut éviter de renvoyer l'objet entier pour une simple correction.

Un index est une structure qui accélère les recherches en évitant de parcourir toute la table, souvent via un arbre B. En contrepartie, il ralentit les écritures et consomme de l'espace disque, car il doit être maintenu à jour. On l'ajoute sur les colonnes fréquemment filtrées ou jointes.

La cohérence forte garantit que toute lecture renvoie la dernière écriture, au prix de la latence et de la disponibilité. La cohérence éventuelle accepte un délai pendant lequel les répliques convergent, offrant une meilleure disponibilité. Le théorème CAP impose ce compromis dans les systèmes distribués.

Une file de messages, comme RabbitMQ ou Kafka, découple les producteurs des consommateurs en stockant les messages à traiter. Elle est utile pour absorber les pics de charge, traiter des tâches asynchrones et améliorer la résilience. Si un consommateur tombe, les messages restent en attente.

On peut utiliser des verrous, des transactions avec niveau d'isolation approprié ou des opérations atomiques. Le verrouillage optimiste détecte les conflits au moment de l'écriture via un numéro de version, tandis que le verrouillage pessimiste bloque l'accès à l'avance. Le choix dépend du taux de contention attendu.

Une requête de rapport saturait la base aux heures de pointe. J'ai analysé le plan d'exécution, repéré une absence d'index et une jointure inefficace. J'ai ajouté l'index manquant et réécrit la requête, divisant le temps d'exécution par dix et soulageant l'ensemble du système.

Une fuite de connexions à la base a fait tomber un service un soir. J'ai redémarré le service pour rétablir le trafic, puis analysé les journaux pour identifier le pool mal configuré. J'ai corrigé la configuration, ajouté une alerte sur le nombre de connexions et documenté l'incident pour éviter sa récurrence.

Une équipe mobile avait besoin d'un accès aux données utilisateur. J'ai recueilli leurs cas d'usage, proposé un contrat d'API documenté et organisé une revue avant développement. La collaboration en amont a évité les retouches, et l'API a été adoptée sans friction.

Un module monolithique rendait chaque évolution risquée. J'ai d'abord ajouté des tests de caractérisation pour sécuriser le comportement existant, puis extrait progressivement des services bien délimités. Le code est devenu testable et les nouvelles fonctionnalités ont pu être livrées beaucoup plus vite.