Entretien pour un ingénieur DevOps : questions et préparation

Un entretien DevOps ressemble le moins possible à un examen d'outils. La liste des technologies, tout le monde la connaît si on a lu les offres d'emploi. On évalue autre chose : comment vous construisez le processus, ce que vous faites quand tout est cassé, et si vous savez choisir un outil en fonction de la tâche, et non de sa popularité.

En quoi consiste l'entretien

Étape	Ce qui est évalué
Présélection	expérience, stack, attentes salariales
Infrastructure	Linux, réseaux, conteneurs, orchestration
Pratique	analyse d’incident, diagnostic à partir des logs
Processus	CI/CD, versions, sécurité, travail en équipe

Sept sujets qui reviennent presque toujours

1. Qu’est-ce que CI/CD en pratique

La réponse « GitLab CI » n’est pas une réponse. On attend le parcours : commit → build → tests → artefact → déploiement dans l’environnement, avec rollback et ce qui se passe en cas d’échec à chaque étape. Une bonne réponse contient le temps de build et l’expérience antérieure d’amélioration.

2. Conteneurs et Docker

Couches de l’image et leur mise en cache, build multi-stage, pourquoi une image de 1 Go est un problème, comment transmettre les secrets, différence entre CMD et ENTRYPOINT. On demande souvent d’expliquer pourquoi le conteneur d’une application plante au démarrage.

3. Kubernetes

Pod vs Deployment, sondes readiness et liveness, redémarrages et leurs causes, limites de ressources et OOMKill, ConfigMap et Secret, Ingress. Question pratique : « le pod ne démarre pas — par où commencerez-vous ».

4. Infrastructure as Code

Terraform vs Ansible, state et verrouillage, plan avant application, idempotence. On vérifie si vous comprenez ce que fera `apply` avant son lancement.

5. Réseaux et équilibrage de charge

Ce qui se passe du navigateur à l'application : DNS, équilibreur de charge, TLS, proxy. Niveaux LAN, problèmes de MTU, différence entre L4 et L7. C'est ici que l'on écarte ceux qui « faisaient tout via des pipelines prêts à l'emploi ».

6. Surveillance et observabilité

Métriques vs journaux vs traçage, ce qu'est un SLO et un budget, pourquoi « la surveillance existe, mais les incidents ne sont pas visibles ». Cas pratique : les utilisateurs se plaignent, mais les métriques sont normales — que vérifiez-vous ?

7. Incidents et post-mortems

Ordre des actions en cas de panne de la prod, qui prend les décisions, comment communiquer, comment rédiger un post-mortem sans chercher de coupables. C'est la question préférée des recruteurs : elle montre l'expérience réelle.

Comment répondre à un cas d'incident

La structure fonctionne : symptôme → hypothèses → ce que je vérifie → solution → prévention.

« Les utilisateurs signalent des 502. Je regarde d'abord le répartiteur de charge : les upstreams sont-ils vivants. S'ils le sont — je vérifie les logs de l'application et les métriques de latence. Sur le projet précédent, la cause était l'épuisement du pool de connexions à la BD : l'augmentation du pool et l'ajout d'un timeout ont aidé. La prévention — une alerte sur l'utilisation du pool, et non sur les 5xx ».

— exemple de réponse issu de la pratique du débriefing d'entretien

Questions fréquentes

Combien de temps faut-il pour se préparer à un entretien DevOps ?

Une semaine à raison de 30–40 minutes : traiter sept sujets, se remémorer deux ou trois incidents réels avec des chiffres et parcourir une fois un dialogue complet. Le cas d'incident est plus important que la théorie — c'est sur lui que l'on recale le plus souvent.

Est-il indispensable de connaître Kubernetes ?

S'il figure dans l'offre d'emploi — oui, au moins au niveau des probes, des limites et de l'analyse d'un pod qui plante. Si l'infrastructure est sur des machines virtuelles, on vous interroge sur systemd, l'équilibrage de charge et le déploiement sans orchestrateur.

La programmation est-elle demandée ?

Oui — Python, Go ou Bash au niveau de scripts d'automatisation. Un live coding complet est plus rare, mais on peut vous demander de décortiquer le script de quelqu'un d'autre et d'y trouver une erreur.

Que faire si je ne connais pas un outil précis ?

Dites-le directement et montrez le principe : « je n'ai pas travaillé avec cet outil, mais le problème se résout de la même manière que X — via une description déclarative et une exécution idempotente ». L'interviewer vérifie la transposabilité de votre raisonnement, pas la connaissance d'une API.

Comment répondre aux questions sur les attentes salariales ?

Par une fourchette, et non par un seul chiffre, en vous appuyant sur le marché. Une analyse détaillée se trouve dans l'article négociations salariales.

Comment s'entraîner à un entretien avec l'IA ?

Décrivez la situation en une phrase — « entretien ingénieur DevOps, Kubernetes et CI/CD, quatre ans d'expérience » — et déroulez le dialogue dans le simulateur. L'entraîneur posera des questions sur votre rôle et analysera vos réponses après la conversation.

Et ensuite ?

Rappelez-vous deux de vos incidents et décrivez-les selon le schéma : symptôme — hypothèses — ce que vous avez vérifié — solution — prévention. Déroulez ensuite le cas à voix haute : ouvrez HintMeTalk AI, mode « Coach », décrivez le poste en une phrase. Après l'analyse, on voit où vous commencez à corriger sans avoir vérifié l'hypothèse.

Analyses pour d'autres rôles : Java, Python, frontend, analyste système.