Développeur·euse Full-stack

Capacité à structurer une décision sous incertitude : identification des contraintes, arbitrages explicites, consultation des parties concernées, validation a posteriori avec données. Bonus : la·le candidat·e mentionne avoir changé d'avis en cours de route ou avoir documenté la décision pour les futur·e·s. Les candidat·e·s qui décrivent une décision « évidente » avec recul révèlent qu'ils·elles n'ont jamais vraiment arbitré.

Méthode de debug structurée : reproduction, logs, instrumentation, hypothèses validées par expérimentation. Honnêteté sur la durée (un vrai bug de prod dure rarement < 30 min). Bonus : la·le candidat·e cite la cause profonde et le correctif systémique (pas seulement le hotfix). Les réponses « j'ai redémarré le service » sans diagnostic révèlent une faiblesse d'investigation.

Humilité technique et capacité à apprendre. Bonus : la·le candidat·e identifie ce qu'il·elle aurait fait différemment dès le départ. Les candidat·e·s qui n'ont « jamais vraiment dû refactorer leur code » mentent ou n'ont pas porté de code en production sur la durée.

Capacité à pointer une faiblesse technique sans braquer : commentaire factuel sur la PR (« voici le risque, voici comment je propose de le résoudre »), proposition d'une solution, escalade à la·au lead 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.

Clarification du besoin avant de négocier la timeline (peut-être que la feature peut être livrée en 2 phases, ou simplifiée). Proposition d'options : MVP en 1 semaine + V2 en 2 semaines ; coupes explicites de scope ; ajout de personnel. Les réponses « je peux le faire en 1 semaine si je travaille les week-ends » sont un drapeau rouge (signal de mauvaise gestion de soi).

Diagnostic d'abord : ne pas tout vouloir réparer en même temps. Priorisation par risque / impact (typiquement : monitoring d'abord pour voir, puis tests sur les zones critiques, puis automatisation du déploiement). Validation avec l'équipe et la·le lead avant d'engager. Les candidat·e·s qui se lancent dans la refonte complète révèlent un manque de pragmatisme.

Clarifications avant de proposer (volume attendu, contraintes de latence, devices supportés, persistance des notifs non vues). Architecture cohérente : push (WebSocket ou Server-Sent Events) vs pull (polling), persistence (DB de notifs), idempotence des envois, fallback email. Bonus : reconnaissance des zones d'incertitude (« je ferais un POC avant de m'engager sur WebSocket vs SSE »). Les candidat·e·s qui plongent dans le code sans clarifier les contraintes révèlent une faiblesse de design.

Méthode structurée : (1) augmenter le niveau de log temporairement sur les endpoints concernés, (2) corréler avec les métriques (latence, taille de payload, source), (3) identifier un pattern (heure de la journée, type de requête, utilisateur·rice spécifique), (4) hypothèses ordonnées (timeout DB, race condition, mémoire). Les candidat·e·s qui se précipitent sur « c'est sûrement la DB » sans investiguer révèlent un biais.

Mesurer avant d'optimiser : DevTools, Lighthouse, profiler côté serveur. Identifier le bottleneck (rendering, requêtes DB, payload, CDN). Hiérarchiser par effort × impact. Les réponses « je vais ajouter du cache » sans diagnostic révèlent un réflexe d'optimisation prématurée. Bonus : la·le candidat·e mentionne qu'une page à 8s en prod indique souvent un problème systémique (N+1 queries, payload énorme) plus qu'une optimisation locale à faire.

Compréhension de la pyramide de tests (beaucoup d'unitaires, moins d'intégration, peu d'e2e). Distinction entre couverture et utilité (90 % de couverture sur du code trivial vaut moins que 60 % sur la logique métier critique). Bonus : la·le candidat·e cite une fois où un test a évité une régression réelle. Les candidat·e·s qui répondent « je teste à 100 % » sans nuancer révèlent une faiblesse de jugement.

Transaction DB = atomicité + isolation gérées par la DB (ACID), bornée à la durée de la transaction. Lock applicatif = coordination entre processus / instances via Redis, Zookeeper, ou similaire ; utile quand la coordination dépasse une seule DB (microservices, queue de tâches). Risque de deadlock pour les deux. Les candidat·e·s qui ne savent pas distinguer ces deux mécanismes vont créer des race conditions en production.

Approche progressive : (1) cartographier les composants critiques et les patterns récurrents, (2) extraire les hooks et la logique métier d'abord (impact massif, risque faible), (3) découper les gros composants par boundary métier (pas par contrainte technique), (4) introduire un state-manager si nécessaire (Context ou Zustand pour PME, Redux si volume) seulement sur les zones où le props drilling est réellement douloureux. Les candidat·e·s qui veulent tout réécrire en React Server Components dès le jour 1 manquent de pragmatisme.

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. Les candidat·e·s qui décrivent avoir « expliqué leur logique » au reviewer au lieu de l'écouter révèlent une faiblesse de coachabilité critique pour le travail en équipe.

Posture de mentorat actif : pair-programming, reviews pédagogiques (pas juste « ok merge »), documentation des décisions, partage de bonnes pratiques. Les candidat·e·s qui répondent « j'aide quand on me demande » sans plus de précision révèlent une posture passive. En PME où l'équipe technique est petite, la capacité à transmettre est essentielle pour la pérennité.

Posture de partenariat : challenge constructif basé sur la faisabilité ou la complexité, proposition d'alternatives. Bonus : la·le candidat·e cite un cas où il·elle a accepté le brief initial après échange (n'est pas en mode opposition systématique). Les candidat·e·s qui décrivent les PMs / designers comme « ne comprenant pas la technique » révèlent une faiblesse de jeu d'équipe.