Si vous aimez coder et travailler sur de grands projets logiciels, vous devriez choisir SWE plutôt que SRE.
Les SRE écrivent certes du code, mais ils ont tendance à consacrer au moins autant de temps au travail opérationnel. Officiellement, lorsque le service est considéré comme "sain", les SRE sont censés consacrer jusqu'à 50 % de leur temps au travail opérationnel. Pour les services qui ne sont pas si sains, cela peut être encore plus.
Le travail opérationnel est tout ce que vous faites pour maintenir la santé de votre service qui ne construit pas de logiciels. Cela inclut un travail hautement qualifié et engageant comme le dépannage des pannes en temps réel, et la réponse aux problèmes détectés par les systèmes de surveillance pour prévenir les pannes avant qu'elles ne se produisent.
Cela inclut également un travail moins qualifié et fastidieux comme la préparation d'une maintenance planifiée, l'ajustement de la taille ou de l'emplacement de votre service pour gérer des utilisateurs supplémentaires, le déploiement de nouvelles versions du code, le déploiement de changements de configuration, la configuration de tests A/B pour vérifier le nouveau code et les nouvelles configurations avant leur déploiement, l'attente de la fin des déploiements, la vérification des déploiements pour voir pourquoi ils ne sont pas encore terminés, et le dépôt de tickets auprès d'autres équipes dont les bugs empêchent vos déploiements de se terminer.
Lorsque vous écrirez du code en tant que SRE, il ne s'agira probablement pas de grands projets. Il s'agira de remanier des configurations, d'automatiser une partie de ce travail opérationnel fastidieux et de peaufiner des outils que vous utilisez fréquemment. La plupart d'entre eux ne seront visibles pour personne en dehors de votre équipe, et aucun d'entre eux ne sera visible pour quiconque en dehors de Google.
Votre implication dans les grandes applications en contact avec les utilisateurs prendra principalement la forme d'un examen des nouvelles conceptions (et parfois du code) avec un œil sur la fiabilité. Occasionnellement, vous pourriez creuser dans le code de votre service pour traquer un bogue, mais il est plus probable que vous remettiez cela aux développeurs une fois que vous soupçonnez l'existence du bogue.
Si vous rejoignez SRE, suivez le conseil de Mark Shieh et assurez-vous d'être embauché en tant que SRE-SWE. Cela facilitera le transfert vers SWE, car vous n'aurez pas à repasser par l'entretien SWE, mais ce ne sera pas nécessairement facile. Le processus de transfert de Google est conçu pour retenir ses employés vedettes, et non pour aider les nouveaux venus à trouver leurs marques. Les transferts dépendent de vos évaluations de performance, donc si vous demandez un transfert après avoir réalisé que SRE ne fonctionne pas pour vous, il est peut-être déjà trop tard.