Entretien blanc SRE — pratique avec l'IA

Les entretiens SRE sont le loop où la profondeur DevOps rencontre la rigueur du software engineering — et les candidats qui décrochent des offres sont ceux qui savent passer d'un triage de panne de cinq minutes à une conversation de design de SLO de trente minutes sans perdre leur auditoire. La plupart des candidats perdent l'offre non pas sur la trivia Linux, mais à l'instant où on leur demande « quel est votre error budget pour ce trimestre et comment y êtes-vous arrivé ». Ce guide explique comment utiliser les entretiens blancs IA pour répéter spécifiquement le loop SRE.

Les tours d'entretien typiques pour les SRE

Le loop SRE est le plus long en infra — généralement 5 à 6 tours. Screening recruteur ; un phone screen de fondamentaux (internals Linux, networking, bases des systèmes distribués) ; un entretien de coding (Python ou Go, généralement parser des logs ou construire un petit CLI, parfois léger en structures de données) ; un tour de gestion d'incident ou de troubleshooting (« la production est tombée — pilotez l'appel ») ; un tour de system design (« concevez un load balancer global avec 99,99 % de disponibilité ») ; et un tour behavioral avec le hiring manager. Les loops senior et staff ajoutent un tour SLO/stratégie de fiabilité où vous argumentez des compromis au niveau de l'organisation.

Le tour de gestion d'incident et le tour de stratégie de fiabilité sont ceux où les entretiens blancs IA rapportent énormément. Tous deux sont des conversations ouvertes sous pression temporelle, tous deux récompensent la pensée structurée, tous deux punissent les réponses génériques. L'entretien blanc IA reproduit le format de la panne qui se déroule presque à l'identique : un énoncé vague, des relances qui montent, une notation sur votre façon de réduire l'espace de recherche. Le tour de system design s'y prête aussi bien — le design SRE a sa propre saveur (disponibilité, blast radius, dependency graphs) que l'entretien blanc peut piloter spécifiquement.

Les principaux sujets techniques

SLO et error budgets

Le vocabulaire du livre SRE de Google est la base. Soyez prêt : SLI vs SLO vs SLA, choisir des SLI qui comptent vraiment pour les clients (taux de succès des requêtes, latence p99, fraîcheur — pas l'utilisation CPU), le calcul de l'error budget (un SLO mensuel à 99,9 % vous donne 43 minutes de budget), la politique d'error budget (ce que vous faites quand vous le grillez — gel des releases, dépriorisation des features, postmortem obligatoire). Une question favorite : « l'équipe a 99,95 % de disponibilité mais les clients se plaignent — où est le problème ? » Les bonnes réponses interrogent la définition du SLI, la fenêtre d'agrégation et l'expérience par client.

Gestion d'incidents

L'entretien blanc le simulera directement. Soyez prêt pour le rythme de triage structuré : évaluer d'abord le blast radius (qui est affecté, combien), puis stabiliser (rollback, traffic shed, scaling de capacité), puis diagnostiquer (logs, traces, changements récents), et seulement ensuite vous engager sur un correctif de long terme. Le rôle d'IC (incident commander) est une compétence distincte — soyez prêt à expliquer comment vous coordonnez quand trois personnes tapent en même temps. La culture du postmortem : blameless, action items avec owners, et la différence entre root cause et facteurs contributifs.

Linux et internals OS

Soyez prêt : le modèle de processus, les signaux, les file descriptors, l'OOM killer et comment prédire ce qu'il choisit, les cgroups et namespaces, /proc et /sys pour l'introspection en direct, les syscalls et strace, eBPF pour le tracing en production sans redémarrer les services, et le networking Linux (iptables, conntrack, netfilter). Une question favorite : « le load average est à 200 mais le CPU est à 30 %. Où est le problème ? » Les bonnes réponses séparent les processus runnable des processus sleeping et pointent vers l'IO wait, la contention de locks ou les threads.

Networking

Les loops SRE senior sondent en profondeur. Soyez prêt : le handshake TCP, le slow start et le congestion control, la différence entre latence et débit dans une même conversation, le DNS (et pourquoi le DNS représente la moitié des pannes du monde), les handshakes TLS et l'OCSP stapling, les bases de BGP pour l'infra globale, le routing anycast vs unicast, les types de load balancer (L4 vs L7, hardware vs software, sticky vs round-robin). Un scénario favori : « la latence d'EU vers US-East a doublé à 3h du matin, sans déploiement. Déroulez-moi votre raisonnement. »

Systèmes distribués

Les tours de design SRE en raffolent. Soyez prêt : CAP et PACELC, les modèles de consistance (strong, eventual, causal, read-your-writes), le consensus (Raft, esquisse de Paxos), l'élection de leader, les stratégies de sharding et le rebalancing, les topologies de réplication (sync vs async, dangers du multi-leader), les transactions distribuées (saga, two-phase commit et pourquoi personne ne l'utilise), les idempotency tokens, et la sémantique des queues (at-most-once vs at-least-once vs exactly-once et ce que signifie réellement exactly-once en pratique).

Stack d'observabilité

Prometheus, Grafana, Loki, Tempo ou Jaeger, OpenTelemetry. Soyez prêt : la cardinalité des métriques et ce qu'elle coûte, l'alerting sur les symptômes vs les causes, ce qui fait un bon runbook, le sampling des logs à grande échelle (et pourquoi votre facture de logs est le deuxième plus gros coût d'infra), les stratégies de sampling des traces (head-based vs tail-based), et comment concevoir des dashboards pour un on-call qui a 30 secondes avant de devoir prendre une décision.

Questions de scénario courantes

• « La production est tombée. Le dernier déploiement remonte à 4 heures. Pilotez l'appel d'incident. » (Rythme de triage, question du rollback, comms, posture d'IC.)
• « Définissez un SLO pour une API de paiement. Défendez votre chiffre devant un CFO qui veut 100 %. » (Coût des neuf, concept d'error budget, disponibilité perçue par le client.)
• « Concevez un load balancer global avec 99,99 % de disponibilité. » (Routing DNS, anycast, health checks, failover régional, blast radius.)
• « La moitié des requêtes vers un microservice sont lentes mais uniquement à 4h UTC. Investiguez. » (Cron jobs, GC, rotation des logs, fenêtres de backup, sweeps de rétention.)
• « Vous avez grillé l'error budget trimestriel. Le PM veut livrer une grosse feature la semaine prochaine. Que dites-vous ? » (Politique de budget, gel, négociation, chemin d'escalade.)

Axes behavioral — ce que les hiring managers recherchent

Les hiring managers SRE filtrent sur trois traits spécifiques. D'abord, le calme sous pression — savez-vous garder une voix posée quand la situation tourne mal ? L'entretien blanc ne simulera pas le cortisol, mais il testera si votre pensée structurée tient quand l'énoncé devient ambigu. Ensuite, la culture blameless — chaque histoire de postmortem doit se concentrer sur les causes systémiques (nous n'avions pas l'alerte, le runbook était obsolète, l'outil de déploiement a laissé passer ça) et non sur la personne qui a appuyé sur le bouton. Enfin, le jugement business sur la fiabilité — les SRE staff et principal argumentent avec les PM et les dirigeants sur la valeur de la fiabilité. Les bonnes histoires montrent comment vous avez fait cette démonstration avec des chiffres, pas des impressions. Attendez-vous à des questions sur une panne mémorable, une fois où vous avez grillé un SLO, une fois où vous avez dit non à une feature pour des raisons de fiabilité.

Comment utiliser l'entraînement IA pour ce poste

Réglez le type d'entretien sur « Tech Screening » ou « Scénario » selon ce que vous travaillez. Pour la pratique SLO et stratégie de fiabilité, collez la situation actuelle de votre équipe en contexte et faites jouer à l'IA le CFO ou le PM sceptique. Pour la gestion d'incident, basculez en mode « Scénario » et faites piloter à l'IA une panne qui se déroule pendant 15 à 20 minutes. L'entretien blanc note votre façon de réduire l'espace de recherche, pas le fait d'arriver à la « bonne » root cause.

Pour le system design, lancez « System Design » avec des énoncés spécifiques au SRE : concevez un rate limiter global, concevez un failover de base de données multi-région, concevez un control plane qui ne se met pas lui-même à terre. L'IA poussera sur la disponibilité et le blast radius comme le fait un interviewer SRE — pas sur l'UX côté utilisateur.

Un exercice qui rapporte vite : enchaînez cinq scénarios d'incident dans des domaines différents (paiement, streaming vidéo, API interne, inférence ML, stockage de fichiers). La reconnaissance de patterns pour « est-ce un déploiement, une dépendance, un problème de données ou de capacité » est la compétence d'entretien SRE la plus transférable.

Questions fréquentes