Questions d'entretien pour Platform Engineer

Les responsables du recrutement dans les entreprises disposant d'équipes plateformes matures rapportent que 60 % des candidats échouent aux entretiens techniques non pas par manque de connaissances spécifiques aux outils, mais par défaut de réflexion en conception de systèmes et en capacité à expliquer les décisions d'infrastructure en termes business [1]. Les entretiens en Platform Engineering diffèrent des entretiens DevOps généraux sur un point essentiel : les intervieweurs évaluent si vous considérez l'infrastructure comme un produit interne. Un candidat qui peut expliquer comment il a mesuré la satisfaction des développeurs vis-à-vis de sa plateforme Kubernetes démontre un état d'esprit fondamentalement différent de celui qui se contente de décrire la configuration du cluster.

Points clés à retenir

• Attendez-vous à un entretien en trois étapes : adéquation comportementale/culturelle, approfondissement technique et conception de systèmes
• Les questions comportementales se concentrent sur la pensée plateforme-comme-produit : empathie développeur, collaboration interéquipes et leadership en gestion d'incidents
• Les questions techniques testent les mécanismes internes de Kubernetes, la conception IaC et l'architecture d'observabilité — pas seulement l'utilisation superficielle des outils
• Les scénarios situationnels évaluent comment vous priorisez les demandes concurrentes de plusieurs équipes
• Préparez 4 à 5 récits STAR couvrant l'impact sur la plateforme, la réponse aux incidents et les améliorations de l'expérience développeur
• Ayez 3 à 5 questions prêtes qui démontrent que vous avez étudié les défis d'infrastructure de l'entreprise

Questions comportementales (format STAR)

1. Décrivez une situation où vous avez créé une fonctionnalité de plateforme que les développeurs ont initialement rejetée. Comment avez-vous favorisé l'adoption ?

**Pourquoi cette question est posée :** Les Platform Engineers construisent des produits internes. L'adoption est la métrique ultime. Cette question teste si vous comprenez la gestion du changement et l'empathie développeur, pas seulement l'implémentation technique.

**Cadre de réponse STAR solide :**

• **Situation :** Les développeurs créaient plus de 50 tickets d'infrastructure par semaine pour le provisionnement de bases de données, avec des temps d'attente moyens de 4 heures
• **Tâche :** Vous avez proposé un système de provisionnement de bases de données en libre-service via le portail de la plateforme, mais les équipes d'ingénierie étaient sceptiques quant à la sécurité et la fiabilité
• **Action :** Vous avez mené des entretiens avec les développeurs pour comprendre leurs préoccupations, construit un pilote avec une équipe volontaire, démontré que les bases de données provisionnées respectaient les mêmes standards de sécurité que celles créées manuellement, et publié les métriques d'adoption après le pilote
• **Résultat :** L'adoption est passée de 1 équipe à 12 équipes en 3 mois. Les tickets d'infrastructure ont diminué de 67 %. La satisfaction des développeurs concernant le provisionnement est passée de 3,2/10 à 8,4/10

2. Parlez-moi de l'incident de production le plus complexe que vous avez géré en tant que commandant d'incident. Quelle était la cause racine et quelles mesures préventives avez-vous mises en place ?

**Pourquoi cette question est posée :** Les Platform Engineers sont responsables de la fiabilité en production. Cela teste le leadership en gestion d'incidents, la profondeur du débogage technique et le suivi en prévention.

**Cadre de réponse STAR solide :**

• **Situation :** Panne réseau multi-cluster causant des erreurs intermittentes de communication service à service sur 3 clusters EKS pendant les heures de pointe
• **Tâche :** Commandant d'incident responsable du diagnostic, de l'atténuation et de la communication auprès de plus de 200 ingénieurs affectés
• **Action :** Corrélation des journaux d'erreur du proxy Istio avec les changements de Calico NetworkPolicy déployés 2 heures auparavant, identification d'une politique bloquant le trafic entre namespaces, annulation du changement de politique et implémentation d'un framework de test des politiques réseau avant le déploiement
• **Résultat :** MTTR de 23 minutes (dans le SLO). Post-incident : implémentation d'une politique OPA qui valide les changements de NetworkPolicy contre une matrice de test avant le déploiement, réduisant les incidents liés aux politiques réseau de 4 par trimestre à 0 sur 6 mois

3. Décrivez une situation où deux équipes produit avaient des exigences conflictuelles pour la plateforme. Comment avez-vous résolu le problème ?

**Pourquoi cette question est posée :** Les Platform Engineers servent simultanément plusieurs clients internes. Cela teste la priorisation, la gestion des parties prenantes et la pensée produit.

**Cadre de réponse solide :** Une équipe avait besoin de pools de nœuds GPU pour les charges de travail ML ; une autre avait besoin du même budget pour de la capacité de calcul général supplémentaire. Vous avez analysé les modèles d'utilisation, proposé un pool de nœuds GPU partagé avec des instances préemptibles et une planification basée sur des files d'attente qui répondait aux deux besoins à 60 % du coût combiné, et établi un cadre de gouvernance des ressources pour les conflits futurs.

4. Parlez-moi d'une situation où vous avez dû convaincre la direction de l'ingénierie d'investir dans l'infrastructure de la plateforme plutôt que dans le développement de fonctionnalités.

**Pourquoi cette question est posée :** Le travail sur la plateforme est en concurrence avec les fonctionnalités produit pour l'investissement en ingénierie. Cela teste votre capacité à communiquer la valeur de l'infrastructure en termes business.

**Cadre de réponse solide :** Quantifiez le coût de ne pas investir : heures développeur perdues en provisionnement manuel, fréquence des incidents due à la dérive de configuration, temps d'intégration pour les nouveaux ingénieurs. Présentez l'investissement dans la plateforme comme un multiplicateur de force : « Un investissement de 400 000 $ dans la plateforme élimine 8 000 heures-développeur de travail répétitif d'infrastructure par an, soit l'équivalent de 4 ingénieurs à temps plein. »

5. Décrivez comment vous avez mesuré le succès d'une plateforme que vous avez construite. Quelles métriques avez-vous suivies ?

**Pourquoi cette question est posée :** La pensée produit nécessite de la mesure. Cette question révèle si vous traitez les plateformes comme des produits avec des KPIs ou simplement comme une infrastructure qui fonctionne.

**Cadre de réponse solide :** Suivez les métriques DORA (fréquence de déploiement, délai de livraison, taux d'échec des changements, MTTR), les enquêtes de satisfaction des développeurs (NPS ou CSAT trimestriels), les taux d'adoption du libre-service, le temps jusqu'au premier déploiement pour les nouveaux ingénieurs, les SLOs de disponibilité de la plateforme et le coût d'infrastructure par déploiement.

6. Parlez-moi d'une décision technique que vous avez prise pour la plateforme et dont vous avez ensuite réalisé qu'elle était erronée. Qu'avez-vous fait ?

**Pourquoi cette question est posée :** Teste l'honnêteté intellectuelle, l'orientation vers l'apprentissage et la capacité à corriger le cap à l'échelle de l'infrastructure.

**Cadre de réponse solide :** Exemple : vous avez choisi Helm pour toute la gestion de configuration, puis réalisé que Kustomize était mieux adapté pour les superpositions d'environnements. Quantifiez l'impact de l'erreur, décrivez le plan de migration, expliquez ce que vous avez appris sur les critères d'évaluation et décrivez comment vous avez modifié votre processus de prise de décision (par exemple, implémentation d'ADR avec des critères d'évaluation explicites).

Questions techniques

1. Guidez-moi à travers ce qui se passe quand un pod est planifié dans Kubernetes, du moment où vous appliquez un manifeste Deployment jusqu'à ce que le conteneur soit en cours d'exécution.

**Ce qui est évalué :** La profondeur de la connaissance des mécanismes internes de Kubernetes. Réponse superficielle : « kubectl l'envoie au serveur API et ça tourne. » La réponse approfondie retrace : kubectl → serveur API (authentification, autorisation, admission controllers) → persistance etcd → scheduler (filtrage, scoring, binding) → kubelet sur le nœud sélectionné → appel CRI au runtime de conteneurs (containerd) → plugin CNI pour le réseau → probe de readiness réussie → enregistrement de l'endpoint. Mentionnez la préemption, l'impact des resource requests/limits sur la planification et les topology spread constraints pour des points bonus.

2. Vous devez concevoir une stratégie de modules Terraform pour une organisation de 15 équipes produit. Comment structurez-vous les modules, l'état et les permissions ?

**Ce qui est évalué :** La réflexion architecturale IaC, pas seulement la connaissance de la syntaxe. Couvrez : la composition des modules (modules de base pour les primitives, modules composites pour les patterns), l'isolation de l'état (par équipe, par environnement ou par service), la configuration du backend distant (S3 + DynamoDB locking), le RBAC via IAM et les workspaces Terraform Cloud/Spacelift, le versionnement des modules et le workflow de release, et la stratégie de détection de drift.

3. Expliquez comment vous implémenteriez des mises à jour Kubernetes sans interruption de service pour un cluster exécutant plus de 500 pods répartis sur 30 namespaces.

**Ce qui est évalué :** La maturité opérationnelle. Couvrez : les PodDisruptionBudgets pour toutes les charges de travail critiques, les mises à jour progressives des pools de nœuds (cordon, drain, remplacement), la politique de décalage de version du serveur API (le kubelet peut être une version mineure en retard), la validation pré-mise à jour (vérifications des API obsolètes avec kubent ou pluto), la stratégie de cluster canary (mettre à jour d'abord le hors-production, puis un cluster de production avant le déploiement sur toute la flotte), la surveillance pendant la mise à jour (taux de redémarrage des pods, taux d'erreur, latence de scheduling) et les procédures de rollback.

4. Comment concevriez-vous une stack d'observabilité pour une plateforme servant 50 microservices ? Guidez-moi à travers les métriques, les logs et les traces.

**Ce qui est évalué :** L'architecture d'observabilité. Couvrez : la couche de métriques (Prometheus avec fédération ou Thanos pour le stockage long terme, recording rules pour les SLOs), les logs (Fluent Bit DaemonSet → Loki avec des politiques de rétention appropriées, standards de logging structuré), les traces (instrumentation SDK OpenTelemetry → collector → Tempo/Jaeger), la corrélation (exemplars liant les métriques aux traces, trace IDs dans les logs), les alertes (alertes d'error budget basées sur les SLO plutôt que des alertes par seuil) et le libre-service (Grafana avec des dashboards à portée d'équipe et des templates avec variables).

5. Un développeur signale que son déploiement prend 45 minutes. Comment diagnostiquez-vous et optimisez-vous cela ?

**Ce qui est évalué :** Le débogage systématique et l'optimisation. Tracez le pipeline : temps de checkout du code, installation des dépendances (stratégies de cache), temps de build (builds Docker multi-étapes, cache de build, optimisation des couches), exécution des tests (runners de test parallèles, découpage des tests), temps de push de l'image (proximité du registry, déduplication des couches), temps de sync ArgoCD (sync waves, resource hooks) et temps de scheduling des pods (image pull, init containers, readiness probes). Identifiez le goulot d'étranglement avant d'optimiser — demandez quelle est la répartition actuelle.

6. Expliquez la différence entre Kyverno et OPA/Gatekeeper. Quand choisiriez-vous l'un ou l'autre ?

**Ce qui est évalué :** La profondeur en outillage de sécurité. OPA/Gatekeeper utilise le langage de politiques Rego (puissant mais courbe d'apprentissage abrupte), fonctionne comme webhook d'admission et excelle pour les politiques complexes inter-ressources. Kyverno utilise des politiques YAML natives Kubernetes (courbe d'apprentissage plus douce), prend en charge les politiques de validation, mutation et génération, et s'intègre plus naturellement aux concepts Kubernetes. Choisissez Gatekeeper pour les organisations avec une expertise Rego existante ou des exigences de politiques complexes. Choisissez Kyverno pour les équipes qui souhaitent une gestion de politiques native Kubernetes avec une friction d'adoption moindre.

7. Comment fonctionne la réconciliation d'ArgoCD, et comment la configureriez-vous pour un environnement multi-cluster avec plus de 200 applications ?

**Ce qui est évalué :** La profondeur en GitOps. Couvrez : ArgoCD interroge les repos git à intervalles configurables (3 minutes par défaut), compare l'état souhaité (git) à l'état en direct (cluster) et réconcilie les différences. Pour la mise à l'échelle : ApplicationSets avec générateurs (git, cluster, matrix), pattern App of Apps pour la gestion hiérarchique, RBAC au niveau projet pour le contrôle d'accès multi-tenant, exclusion de ressources pour les ressources bruyantes et fenêtres de sync pour le contrôle des changements en production. Discutez des déclencheurs de sync basés sur les webhooks pour une réconciliation plus rapide si nécessaire.

Questions situationnelles

1. Votre équipe plateforme de 5 personnes reçoit simultanément des demandes de 8 équipes produit. Comment priorisez-vous ?

**Ce qui est évalué :** Les compétences en gestion de produit et de parties prenantes. Cadre : catégorisez par impact (nombre de développeurs affectés × sévérité du problème), urgence (bloque les déploiements vs. souhaitable) et alignement stratégique (soutient les initiatives à l'échelle de l'entreprise vs. besoins d'une seule équipe). Établissez un processus d'intake transparent : réunion hebdomadaire de priorisation avec les responsables d'équipe, feuille de route plateforme publiée, SLAs clairs pour les différents types de demandes (problèmes bloquants P0 : le jour même ; demandes de fonctionnalités : planification de sprint).

2. Un nouveau CTO veut migrer toute l'infrastructure d'AWS vers GCP en 6 mois. Comment évaluez-vous et planifiez-vous cela ?

**Ce qui est évalué :** La réflexion stratégique sous pression. Commencez par l'évaluation d'impact : inventaire de tous les services AWS utilisés, identification des équivalents GCP, estimation des coûts de transfert de données et du calendrier. Évaluez le risque : identifiez les services sans équivalent propre sur GCP (par ex., des services managés spécifiques). Proposez une approche par phases : d'abord abstraire l'infrastructure via des modules Terraform (réduisant le couplage spécifique au cloud), migrer les services non critiques en preuve de concept, puis les services de production avec capacité de rollback. Contestez le délai de 6 mois avec des preuves si irréaliste.

3. Votre cluster Kubernetes connaît des évictions de pods intermittentes pendant les heures de bureau. Guidez-moi à travers votre investigation.

**Ce qui est évalué :** La résolution systématique de problèmes. Vérifiez la pression de ressources au niveau du nœud (mémoire, disque, limites PID) via kubectl describe node et recherchez les événements d'éviction du Kubelet. Examinez les resource requests vs. l'utilisation réelle — les pods sans requests sont les premiers évincés. Vérifiez les effets de voisin bruyant (un pod consommant des ressources excessives sur des nœuds partagés). Consultez les logs Karpenter/Cluster Autoscaler pour les retards de mise à l'échelle. Vérifiez les conflits de ressources DaemonSet. Implémentez des Resource Quotas et LimitRanges pour prévenir le sur-provisionnement futur.

4. Vous découvrez que 40 % de vos fichiers d'état Terraform n'ont pas été appliqués depuis 6 mois et que de la dérive s'est accumulée. Quel est votre plan de remédiation ?

**Ce qui est évalué :** La discipline opérationnelle IaC. N'exécutez pas terraform apply aveuglément — cela détruit des ressources dont des gens peuvent dépendre. Commencez par terraform plan pour chaque fichier d'état, catégorisez la dérive en : (1) changements intentionnels faits hors Terraform (à importer ou à mettre à jour dans le code), (2) dérive non intentionnelle (à appliquer), (3) ressources abandonnées (à nettoyer). Implémentez une détection continue de la dérive (Spacelift, Atlantis ou exécutions de plan programmées) pour prévenir la récurrence. Établissez une politique de gouvernance : tous les changements d'infrastructure doivent passer par des PR Terraform.

5. Un VP ingénierie vous demande de donner à son équipe un accès direct aux clusters Kubernetes de production pour le débogage. Comment gérez-vous cela ?

**Ce qui est évalué :** Le jugement en matière de sécurité et la communication avec les parties prenantes. L'accès direct au cluster crée des risques de sécurité et d'audit. Proposez des alternatives : accès kubectl en lecture seule limité à leur namespace via RBAC, dashboards Grafana avec observabilité au niveau des pods, un workflow de conteneurs de débogage (ephemeral containers) qui fournit un accès shell sans modifier les pods en cours d'exécution, et l'agrégation de logs qui offre de la visibilité sans identifiants de cluster. S'ils insistent, implémentez un accès à durée limitée avec journalisation d'audit (Teleport, Boundary) et révocation automatique.

Critères d'évaluation utilisés par les intervieweurs

**Profondeur technique (40 %) :** Pouvez-vous expliquer comment les systèmes fonctionnent au niveau des composants, pas seulement les configurer ? Les questions sur la planification des pods et l'architecture Terraform testent cela.

**Conception de systèmes (25 %) :** Pouvez-vous concevoir des composants de plateforme qui servent plusieurs équipes à grande échelle ? Les questions sur la stack d'observabilité et ArgoCD multi-cluster testent cela.

**Produit et communication (20 %) :** Pouvez-vous expliquer des décisions d'infrastructure en termes business ? Pouvez-vous prioriser des demandes concurrentes ? Les questions comportementales et le scénario de priorisation testent cela.

**Incidents et opérations (15 %) :** Pouvez-vous diagnostiquer systématiquement des problèmes de production et prévenir leur récurrence ? La question sur le commandant d'incident et le scénario d'éviction de pods testent cela.

Exemples de méthode STAR pour le Platform Engineering

**Modèle :**

• **Situation :** Établissez le contexte avec des données spécifiques (taille de l'entreprise, taille de l'équipe, échelle de l'infrastructure)
• **Tâche :** Définissez votre responsabilité spécifique (pas celle de l'équipe)
• **Action :** Décrivez les étapes concrètes que vous avez prises (outils, décisions, communication)
• **Résultat :** Quantifiez le résultat (métriques, taux d'adoption, économies de coûts, gain de temps)

**Exemple : Construction d'une plateforme en libre-service**

• **S :** Chez [Entreprise] (300 ingénieurs, 40 microservices), les développeurs attendaient en moyenne 3 jours pour le provisionnement d'infrastructure, créant plus de 200 tickets par mois
• **T :** J'ai été chargé de concevoir un catalogue d'infrastructure en libre-service pour éliminer les goulots d'étranglement de provisionnement
• **A :** J'ai construit un catalogue basé sur Crossplane avec 12 modèles de ressources gérées (bases de données, caches, files d'attente, buckets de stockage), intégré avec Backstage pour une interface conviviale pour les développeurs, implémenté des workflows d'approbation pour les ressources de production et créé une documentation complète avec des tutoriels vidéo
• **R :** Le temps de provisionnement est passé de 3 jours à 15 minutes. Les tickets mensuels d'infrastructure ont diminué de 78 %. La satisfaction des développeurs concernant le provisionnement s'est améliorée de 2,8/10 à 8,6/10. Le catalogue a traité plus de 150 demandes de provisionnement au premier trimestre sans aucune mauvaise configuration

Questions à poser à l'intervieweur

1. **« Comment l'équipe plateforme mesure-t-elle le succès ? Quels KPIs ou SLOs suivez-vous ? »** — Teste s'ils ont une mentalité produit ou fonctionnent comme un support réactif.
2. **« Quel est le point de friction actuel de l'expérience développeur que l'équipe plateforme priorise ? »** — Montre que vous pensez aux besoins des développeurs et révèle le travail réel que vous feriez.
3. **« Comment l'équipe plateforme est-elle structurée par rapport aux équipes produit ? Suivez-vous un modèle Team Topologies ? »** — Démontre une conscience organisationnelle et vous aide à évaluer l'autonomie de l'équipe.
4. **« Quelle est votre fréquence de déploiement actuelle et où se situe le goulot d'étranglement ? »** — Signale que vous pensez en métriques DORA et que vous êtes concentré sur l'amélioration mesurable.
5. **« Quelle est la décision d'infrastructure la plus controversée que l'équipe ait prise récemment ? »** — Révèle la culture de prise de décision, la conscience de la dette technique et l'ouverture à la discussion.
6. **« Comment se passe l'astreinte pour l'équipe plateforme ? À quelle fréquence les ingénieurs sont-ils alertés et quelle est la sévérité moyenne des incidents ? »** — Question pratique qui révèle la maturité opérationnelle et l'équilibre vie professionnelle-vie personnelle.
7. **« Existe-t-il un processus de revue d'architecture ou de RFC pour les changements significatifs de la plateforme ? »** — Montre que vous valorisez la prise de décision délibérée et la culture de documentation.

Conclusions finales

Les entretiens en Platform Engineering évaluent trois dimensions : la profondeur technique en Kubernetes, IaC et infrastructure cloud ; la pensée produit concernant l'expérience développeur et l'adoption de la plateforme ; et la maturité opérationnelle en réponse aux incidents et diagnostic de systèmes. Préparez-vous en construisant des récits STAR autour de résultats mesurables de plateforme (pas seulement l'utilisation d'outils), en pratiquant les questions de conception de systèmes couvrant plusieurs composants d'infrastructure, et en recherchant les défis d'infrastructure spécifiques de l'entreprise via leur blog d'ingénierie, leurs repos open source et leurs interventions en conférence. Les candidats qui se démarquent expliquent non seulement ce qu'ils ont construit, mais pourquoi ils l'ont construit, comment ils ont mesuré son succès et ce qu'ils feraient différemment la prochaine fois.

Questions fréquemment posées

Combien de tours d'entretien dois-je m'attendre pour un poste de Platform Engineer ?

En général 4 à 5 tours : filtrage recruteur (30 min), entretien comportemental avec le responsable du recrutement (45–60 min), approfondissement technique avec un ingénieur senior (60–90 min), conception de systèmes avec un ingénieur staff+ (60 min), et panel équipe/adéquation culturelle (45–60 min). Certaines entreprises ajoutent un exercice à faire chez soi (conception de module Terraform, scénario de résolution de problèmes Kubernetes) comme pré-sélection ou alternative au tour technique en direct. Durée totale du processus : 2 à 4 semaines du premier contact à l'offre.

Dois-je me préparer différemment pour une startup par rapport à une grande entreprise ?

Oui. Les startups mettent l'accent sur la polyvalence et la rapidité — elles veulent des ingénieurs capables de construire une plateforme de zéro dans plusieurs domaines (CI/CD, observabilité, Kubernetes, sécurité) sans attendre des membres d'équipe spécialisés. Les grandes entreprises mettent l'accent sur la profondeur dans des domaines spécifiques et la capacité à travailler dans des patterns établis à grande échelle. Les entretiens en startup incluent souvent des exercices pratiques (construire/réparer quelque chose) ; les entretiens en grande entreprise penchent vers des sessions de conception de systèmes au tableau blanc.

Quelle est l'importance de la programmation en Go dans les entretiens de Platform Engineering ?

De plus en plus importante à partir du niveau intermédiaire. Si l'entreprise construit des opérateurs Kubernetes personnalisés, des providers Terraform ou des outils CLI, Go est effectivement requis. Les candidats juniors peuvent démontrer leur maîtrise de Python et Bash comme point de départ. Quand des questions Go apparaissent, elles se concentrent typiquement sur la compréhension de la bibliothèque client-go de Kubernetes, l'écriture de boucles de réconciliation et la compréhension des patterns de concurrence Go pertinents pour l'outillage d'infrastructure.

Et si je n'ai pas d'expérience avec les outils spécifiques utilisés par l'entreprise ?

Concentrez-vous sur les concepts transférables. Si vous connaissez ArgoCD mais qu'ils utilisent Flux, expliquez les principes GitOps et les patterns de réconciliation — les concepts sont identiques. Si vous connaissez AWS mais qu'ils utilisent GCP, discutez de Kubernetes (agnostique du fournisseur) et des patterns de conception de modules Terraform. Les intervieweurs dans les entreprises bien gérées évaluent la compréhension conceptuelle plutôt que l'expérience spécifique aux outils, car les outils changent plus vite que les principes.

**Citations :** [1] DORA / Google Cloud, "2024 Accelerate State of DevOps Report," dora.dev, 2024.