Préparation entretien Site Reliability Engineer, ce qui vous attend

C'est la transition SRE la plus courante en France, et le piège est toujours le même : le round de coding. Beaucoup de profils admin sys / DevOps arrivent en pensant « SRE = bash + Terraform + Kubernetes » et se font filtrer au coding screen, qui est bien plus proche de la barre SWE que du scripting d'ops. Votre force, c'est l'infra : Ansible, GitLab CI, l'astreinte, vous connaissez. Votre angle mort, c'est l'algo. Comptez 6 à 10 semaines de prep : 50+ LeetCode mediums centrés sur hashmaps, graphes et manipulation de flux (le scripting de log que vous faites déjà aide pour cette partie). En parallèle, structurez le vocabulaire qui vous manque côté méthode SRE : SLO, error budget, blast radius, le Google SRE Book est fait pour ça et il est cité directement en entretien. Côté system design, vous partez avec un avantage réel : vous avez vu de la prod, des pannes, des migrations. Présentez-le, mais reformulez en langage fiabilité plutôt qu'en langage exploitation pure.

C'est une idée reçue qui coûte des offres. Sur la plupart des loops SRE sérieux (filiales FAANG en France, Datadog, Criteo, scale-ups bien financées), le coding round est au niveau LeetCode-medium, parfois doublé d'une question systèmes du type « parse ce format de log et calcule un taux d'erreur en fenêtre glissante ». Ce n'est pas un quiz bash. La nuance, c'est qu'on attend du code propre et raisonné, pas la résolution de problèmes algos exotiques façon concours, mais un profil ops qui n'a jamais ouvert LeetCode se fait quand même filtrer. Si vos missions actuelles sont à 70 % de la config et du YAML, comptez large, 10 semaines et plus. Drillez en priorité les structures de données que le scripting de log mobilise naturellement (hashmaps, files, tableaux), puis élargissez. Et entraînez-vous à coder en parlant à voix haute : sur un round SRE comme SWE, le raisonnement narré compte autant que la réponse.

En France, l'astreinte est encadrée par le Code du travail et la convention collective (souvent Syntec) : elle est en principe indemnisée, et les interventions de nuit ou de week-end comptent comme du temps de travail. Concrètement, attendez-vous à un roulement (par exemple une semaine sur quatre ou cinq selon la taille de l'équipe), un pager, et des objectifs de temps de réponse. En entretien, le hiring manager veut surtout savoir si vous avez déjà vécu une vraie nuit d'astreinte : une alerte à 2h, un diagnostic sous pression, une mitigation, un postmortem le lendemain. Préparez 2 ou 3 récits d'incident avec des chiffres précis (heure de l'alerte, temps de diagnostic, temps de mitigation, périmètre touché). C'est aussi le bon moment, côté candidat, pour poser vos propres questions : fréquence du roulement, volume d'alertes par semaine, politique sur le toil. Une équipe SRE saine sait répondre sans gêne ; une équipe qui élude le sujet vous dit quelque chose.

Non, et vous partez même avec une bonne moitié du chemin faite. La transition SWE vers SRE a le profil inverse de la transition ops vers SRE : vous tenez le coding round sans souci, mais vous devez construire l'intuition fiabilité et opérationnelle. Les intervieweurs vont chercher ça précisément. Avant le loop, ancrez le vocabulaire et les réflexes : SLO et error budget (le Google SRE Book, chapitres 3 et 4), modes de défaillance, blast radius, le déroulé détection / diagnostic / mitigation / postmortem. Côté pratique, montez une stack Prometheus + Grafana en local, cassez votre propre service exprès et entraînez-vous à lire les métriques sous contrainte de temps : c'est exactement le round de debugging. Pour le behavioral, même sans astreinte formelle, vous avez sûrement géré des bugs en prod, des déploiements ratés, des rollbacks : reformulez ces histoires en langage incident. Et apprenez un outil d'IaC à fond (Terraform) plus Kubernetes au niveau manifests, c'est l'autre attendu où un backend pur peut être un peu juste.

Lisez d'abord le guide Software Engineer. Les entreprises calibrent les candidats L4 / IC3 contre la barre L4 / IC3, en ciblant clairement l'écart de scope, elles veulent voir où vous êtes aujourd'hui, puis creuser le gap jusqu'au L4 / IC3. Lisez ce guide APRÈS avoir compris la baseline L4 / IC3, comme ça vous saurez exactement quels signaux démontrer pour le step-up.

Le process prend 4 à 6 semaines du pré-screen à l'offre. Ajoutez 6 à 8 semaines de prep : LeetCode mediums, le Google SRE Book et un deep-dive observabilité sont les plus rentables. Ne sous-estimez surtout pas le round de coding.

Sous-investir le round de coding. Beaucoup de profils venus de l'admin sys / DevOps ont d'excellentes compétences infra mais se font filtrer au coding screen parce qu'ils ont cru que SRE = bash + Terraform. La barre coding est plus proche du SWE que du DevOps : drillez les LeetCode mediums pendant 4 semaines au minimum.

L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.

Ce guide couvre la barre générale au niveau L4 / IC3. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.