Questions to Ask in a Backend Developer Interview

L'entretien se termine bien, puis le recruteur lâche : « Des questions de votre côté ? » Vous bafouillez deux généralités, vous sortez, et vous réalisez que vous n'avez rien appris sur le poste. Ce moment vaut 15 % du temps d'entretien, et c'est souvent là que se joue la différence entre un candidat moyen et un candidat qui a l'air d'avoir déjà le job.

Poser de bonnes questions sert à deux choses. Vous décidez mieux, parce que vous obtenez des informations que la fiche de poste ne contient pas. Et vous montrez que vous pensez comme quelqu'un qui va résoudre des problèmes, pas comme quelqu'un qui cherche juste un salaire.

Voici 12 questions, regroupées par ce qu'elles révèlent. Elles marchent pour un poste backend junior comme pour un poste confirmé, à adapter selon votre niveau.

Ce que l'équipe vit vraiment#

Ces questions sortent le discours officiel et ramènent la discussion sur le quotidien.

Combien de personnes gèrent ce service en production, et qui est d'astreinte ?

L'astreinte est le révélateur numéro un de la santé d'une équipe backend. Si personne n'est d'astreinte, demandez qui est réveillé à 3 h du matin quand ça casse. La réponse vous dira si le système est tenu par de l'outillage sérieux ou par deux personnes fatiguées.

Quelle a été la dernière panne sérieuse, et qu'est-ce que l'équipe en a gardé comme changement concret ?

Une équipe qui répond « on n'a pas de pannes » ment ou ne surveille rien. Une équipe qui raconte une panne, l'analyse et la mesure corrective est une équipe qui apprend. Notez si la mesure corrective est technique (tests, alerte, rollback automatique) ou morale (« on fait plus attention »).

Comment se passe la revue de code, et qui la fait ?

Vous apprendrez si le code part en production sans relecture, si une seule personne bloque tout, ou si la revue est un vrai moment de travail d'équipe. Demandez un exemple de dernière revue qui a changé une fonctionnalité.

Qui décide de l'architecture, et comment une décision technique importante est-elle prise ?

Certains postes portent le titre d'ingénieur backend mais consistent à implémenter des tickets écrits ailleurs. D'autres vous laissent choisir la base de données. Vous devez savoir dans lequel vous entrez.

Ce que l'entreprise valorise#

Les priorités réelles ne sont pas celles du discours de recrutement.

Quels sont les deux ou trois objectifs de l'équipe pour les six prochains mois ?

Si la réponse est floue, c'est un signal. Demandez ensuite ce qui a été dépriorisé pour tenir ces objectifs, parce que les priorités se voient aux renoncements.

Sur quoi l'équipe passe-t-elle le plus de temps : le développement de nouveautés, la dette technique, le support, ou la maintenance ?

Aucune de ces réponses n'est mauvaise en soi. Un poste à 70 % de maintenance vous apprendra beaucoup sur l'exploitation, mais vous éloignera du produit. Un poste à 90 % de nouveautés avec une dette partout vous épuisera en six mois.

Comment sont décidées les migrations techniques, par exemple un changement de version de langage ou de base de données ?

Une migration gérée avec un plan, des étapes et un moyen de revenir en arrière, c'est sain. Une migration lancée sur un coup de tête par un lead qui part en congé deux semaines après, c'est un poste à haut risque.

Ce qui rend quelqu'un bon dans ce poste#

Ces questions vous donnent les critères d'évaluation réels, pas ceux du descriptif.

À quoi ressemble une première réussite concrète à trois mois sur ce poste ?

La réponse doit être précise. « Vous livrez la nouvelle API de facturation et vous prenez l'astreinte » est une bonne réponse. « Vous êtes intégré à l'équipe » n'en est pas une.

Quels sont les critères utilisés pour les augmentations et les promotions dans cette équipe ?

Beaucoup de managers évitent cette question. Demandez-la poliment, à la fin. Si on vous répond « ça dépend du contexte » sans rien de plus, attendez-vous à des décisions opaques.

Comment le travail est-il estimé, et que se passe-t-il quand une estimation est dépassée ?

Vous découvrirez si l'équipe est jugée sur des dates impossibles ou sur des résultats. Une équipe qui ajuste les estimations sans blâmer les gens est une équipe où on peut travailler longtemps.

Les risques que personne ne mentionne#

Ces trois questions dérangent un peu. C'est leur but.

Quel est le plus gros risque technique que vous voyez sur ce système aujourd'hui ?

Posez-la à un ingénieur, pas aux RH. La réponse dit beaucoup sur la lucidité de l'équipe. Si on vous cite « la scalabilité » sans exemple, la personne improvise.

Pourquoi ce poste est-il ouvert : création, remplacement, ou départ ?

Un remplacement après six mois est un signal à creuser. Demandez simplement : « Qu'est-ce qui n'a pas marché ? » Le ton de la réponse compte autant que le contenu.

Si vous deviez refaire une décision technique de l'an dernier, laquelle changerait-vous ?

Une personne qui ne voit aucune erreur à revoir n'a pas beaucoup reculé sur son travail. Une personne qui explique un choix raté et ce qu'elle en a tiré est exactement celle avec qui vous voulez bosser.

Exemple concret : poser une question sur la dette#

Version molle : « Vous avez de la dette technique ? » Réponse attendue : « un peu, comme partout ». Inutile.

Version travaillée : « Sur les trois services les plus critiques, quel est celui dont vous auriez le plus peur de modifier la logique de paiement un vendredi soir, et pourquoi ? »

Cette formulation donne un cadre, une échelle, un cas réel. La personne doit nommer un service, expliquer un risque, et vous apprenez en 30 secondes ce que six mois de documentation ne vous diraient pas.

Les questions à éviter#

Trois catégories posent problème.

Les questions dont la réponse est sur le site de l'entreprise. « C'est quoi votre mission ? » montre que vous n'avez pas regardé. Renseignez-vous avant, par exemple avec l'outil d'analyse d'offre qui vous aide à repérer ce qu'une annonce dit vraiment entre les lignes.

Les questions purement égoïstes posées trop tôt : télétravail total, nombre de jours de congés, primes. Ces sujets sont légitimes, mais traitez-los à l'étape RH, pas en conclusion d'un entretien technique. Sinon vous donnez l'impression de négocier avant d'avoir montré quoi que ce soit.

Les questions pièges du style « quel est votre plus gros défi ? » posées sur un ton de test. Posez-les en curieux, pas en examinateur. Le ton change tout.

Comment lire les réponses#

Une réponse creuse n'est pas toujours un refus de répondre. Parfois la personne n'a pas l'information, ou n'a pas le droit de partager les chiffres. Distinguez le « je ne peux pas dire » du « je ne sais pas ».

Observez trois choses. La précision des exemples. La cohérence entre ce que disent le manager et l'ingénieur présent. Et la façon dont la personne parle des collègues absents, parce que c'est comme ça qu'elle parlera de vous dans six mois.

Si une réponse vous inquiète, creusez sur le moment plutôt que de reporter. Un « comment l'équipe a géré ce cas la dernière fois ? » posé calmement vous donnera plus qu'une semaine de réflexion après coup.

Vous pouvez aussi tester la cohérence de votre propre candidature avant l'entretien : le vérificateur de compatibilité avec les offres vous montre si votre CV parle le même langage que l'annonce.

Combien de questions poser#

Cinq à sept questions en 10 à 15 minutes, c'est bien. Plus, et vous virez à l'interrogatoire. Moins, et vous paraissez peu intéressé.

Préparez-en huit, parce que certaines seront couvertes pendant l'entretien. Gardez votre liste sur une feuille ou un carnet, et barrez au fur et à mesure. Les candidats qui notent pendant l'entretien sont perçus comme plus sérieux, et de toute façon vous oublierez la moitié des réponses.

Un dernier point de méthode : posez vos questions dans l'ordre où la conversation les appelle, pas dans l'ordre de votre liste. Un entretien est une discussion. Les meilleures questions sont souvent celles qui découlent d'une réponse précédente.

Pour trouver des offres où ce type de discussion est possible, commencez par des annonces récentes et filtrées plutôt que par des candidatures de masse, par exemple sur notre page d'offres d'emploi en développement backend.

Outils gratuits#

• jobrise.io/fr/free-ats-checker/
• jobrise.io/fr/free-jd-decoder/
• jobrise.io/fr/jobs/
• jobrise.io/fr/blog/

Questions fréquentes#

Combien de questions faut-il poser en fin d'entretien développeur backend ?

Cinq à sept questions en 10 à 15 minutes, c'est le bon rythme. Préparez-en huit pour avoir de la marge si certaines sont déjà couvertes pendant l'échange.

Faut-il poser des questions sur le salaire en entretien technique ?

Non, gardez ça pour l'étape RH ou l'entretien avec les ressources humaines. Les questions sur la rémunération, les congés et le télétravail se traitent quand la discussion porte sur les conditions, pas à la fin d'un entretien technique.

Que faire si le recruteur répond « vous n'avez pas de questions ? »

Répondez honnêtement que si, et sortez-en une ou deux de votre liste. Cette phrase est souvent une relance automatique, pas un jugement, et elle arrive même quand l'entretien s'est bien passé.

Les questions techniques sont-elles plus importantes que les questions sur l'équipe ?

Non, les deux se complètent. Les questions techniques vous disent sur quoi vous allez travailler, les questions sur l'équipe vous disent avec qui et dans quel état d'esprit, et c'est souvent ce second volet qui décide de votre durée de vie sur le poste.

Comment préparer ses questions avant un entretien backend ?

Relisez l'annonce, notez ce qui reste flou, et formulez une question par point flou. Vérifiez d'abord que votre CV correspond au poste avec un outil de vérification de compatibilité, puis testez la lecture de l'annonce pour repérer les sujets à creuser.