Développeur·euse Back-end

Méthode structurée : reproduction ou observation directe, formulation d'hypothèses, validation par logs, métriques, ou expérimentation ciblée. Honnêteté sur la durée et les fausses pistes. Bonus : la·le candidat·e cite la cause profonde (pas seulement le hotfix) et la mesure préventive mise en place après (post-mortem, alerte ajoutée, test de régression). Les réponses « j'ai redémarré le service et tout est rentré dans l'ordre » sans diagnostic révèlent une faiblesse d'investigation.

Capacité à structurer une décision sous incertitude : clarification des contraintes, alternatives évaluées, arbitrages explicites entre simplicité et flexibilité future, consultation des parties concernées, validation a posteriori. Bonus : la·le candidat·e mentionne une décision dont il·elle reviendrait aujourd'hui, ou un ADR écrit pour la postérité. Les candidat·e·s qui décrivent une décision « évidente » avec recul n'ont pas vraiment arbitré.

Humilité face aux hypothèses initiales : la·le candidat·e reconnaît la limite, mesure avant d'agir (profiling, métriques, charge réelle vs synthétique), arbitre entre optimisation locale et refonte. Bonus : la·le candidat·e identifie en rétrospective le signal qu'il·elle aurait pu lire plus tôt. Les profils qui « n'ont jamais eu de problème de charge » mentent ou n'ont pas servi de trafic réel.

Capacité à pointer une faiblesse sans braquer : commentaire factuel sur la PR (« voici le risque concret, voici un correctif suggéré »), proposition d'une solution chiffrée, escalade à la·au lead ou à la sécurité si la PR est mergée malgré le commentaire. Les candidat·e·s qui « laissent passer parce que c'est un·e senior » révèlent une faiblesse de courage technique critique sur un poste back-end.

Clarification du besoin réel avant de négocier la timeline : quel volume de données, quelle latence acceptable, quelles fonctionnalités vraiment indispensables (filtres, scoring, surlignage). Proposition d'options explicites : MVP via ILIKE Postgres en 1 semaine puis vraie indexation en V2, ou périmètre coupé. Les réponses « je peux le faire en 1 semaine en travaillant les week-ends » sont un drapeau rouge.

Diagnostic d'abord, pas de grand soir : priorisation par risque opérationnel. Typiquement : (1) observabilité minimale pour voir avant d'agir (métriques de base, logs structurés, dashboard d'incident), (2) sécuriser le pipeline de déploiement (rollback rapide, un environnement de staging fiable), (3) remettre les tests critiques au vert sur les zones métier sensibles, (4) plan plus long pour le reste. Validation explicite avec l'équipe et la·le lead avant d'engager.

Clarifications avant de proposer : volume attendu, criticité, contraintes de latence, SLA promis aux clients. Architecture cohérente : file de messages persistante, retries exponentiels bornés, dead-letter queue, idempotence côté récepteur, signature HMAC, isolation des clients lents (rate-limit ou worker dédié). Observabilité : taux de succès par client, latence p99, taille de la file. Bonus : reconnaissance des zones d'incertitude (« je prototypierais Kafka vs RabbitMQ vs SQS selon le volume réel avant de m'engager »). Les profils qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design.

Méthode structurée : (1) augmenter temporairement le niveau de log et activer le tracing sur les endpoints concernés, (2) corréler avec les métriques (latence p99, taille de payload, connexions DB, mémoire, GC), (3) chercher un pattern (heure, type de requête, utilisateur·rice spécifique, ratio sur un pod précis), (4) hypothèses ordonnées : pool DB saturé, timeout amont, race condition, OOM, panic non récupérée. Les candidat·e·s qui se précipitent sur « c'est sûrement la DB » sans investiguer révèlent un biais d'investigation.

Mesurer avant d'optimiser : EXPLAIN ANALYZE sur la requête, profilage côté application, vérification du pool de connexions. Identifier le bottleneck réel : index manquant, N plus 1, payload énorme, sérialisation coûteuse, lock de table. Hiérarchiser par effort fois impact. Les réponses « j'ajoute Redis devant » sans diagnostic révèlent un réflexe d'optimisation prématurée. Bonus : la·le candidat·e note qu'un écart p50 vs p95 aussi violent suggère un comportement par cas (utilisateur·rice avec gros dataset, lock occasionnel) plutôt qu'une lenteur uniforme.

Transaction DB : atomicité plus isolation gérées par la base, bornée à une seule DB ; isolation forte au prix de conflits visibles (serialization failures à retry côté applicatif). Lock applicatif : coordination entre processus ou instances quand la coordination dépasse une seule DB (microservices, déduplication de jobs, leader election). Risques distincts : deadlock vs lock perdu en cas de crash du détenteur (d'où les TTL et le fencing token). Les candidat·e·s qui ne savent pas distinguer ces deux mécanismes vont créer des race conditions en production.

Compréhension claire : la·le client·e fournit une clé d'idempotence (entête HTTP), le serveur la persiste avec la requête et la réponse, et toute requête ultérieure avec la même clé renvoie la réponse stockée sans re-jouer l'effet de bord. Détails attendus : contrainte UNIQUE sur la clé en DB, gestion du conflit (renvoyer la réponse cachée, pas une 409), TTL raisonnable (24-48h typique), interaction propre avec la transaction métier (idéalement même transaction ou compensation). Les profils qui répondent « je vérifie si ça existe déjà avant d'insérer » créent une race condition classique.

Compréhension de la pyramide : beaucoup d'unitaires sur la logique métier, moins d'intégration ciblées sur les frontières (DB, files de messages, API externes), peu d'end-to-end. Distinction entre couverture et utilité : 90 % sur du code trivial vaut moins que 60 % sur le cœur métier. Bonus : la·le candidat·e cite une fois où un test a évité une régression réelle, ou un type de bug que les tests n'attrapent pas (race conditions, problèmes de configuration prod). Les profils qui répondent « je teste à 100 % » sans nuancer manquent de jugement.

Ouverture : capacité à dissocier le code de l'ego personnel. Bonus : la·le candidat·e cite une fois où il·elle a changé d'avis grâce à une review et explique ce qui l'a fait basculer. Les candidat·e·s qui décrivent surtout avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour un poste où la qualité du code est partagée.

Posture de mentorat actif : pair-programming, reviews pédagogiques (pas juste « ok merge »), documentation des décisions importantes (ADR), partage en réunion d'équipe ou en lunch and learn. En PME où l'équipe back-end est souvent petite (3-8 personnes), la capacité à transmettre est essentielle pour la pérennité du code. Les candidat·e·s qui répondent « j'aide quand on me demande » sans plus de précision révèlent une posture passive.

Posture de partenariat : challenge constructif basé sur la faisabilité, la complexité, ou le coût opérationnel à long terme (le·la back-end vit avec les schémas et les contrats d'API qu'il·elle expose). Proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange. Les profils qui décrivent les PMs ou front-end comme « ne comprenant pas la complexité technique » révèlent une faiblesse de jeu d'équipe.