J'étais un ancien stagiaire SWE (SETI) chez Google Inde.
Comme tout le monde, je ne connaissais pas non plus beaucoup de différence entre les rôles SWE et SETI.
On m'a attribué une équipe SETI et j'ai dû travailler avec elle.
Hence, avant de m'y joindre, j'ai regardé la description de poste du rôle SETI, qui disait quelque chose comme "Concevoir et construire des cadres de tests automatisés avancés." Cette ligne elle-même m'a fait penser qu'il s'agissait d'un rôle de test, mais j'ai été consolé par mes amis qu'ils pourraient simplement construire des cadres de test, qui seraient ensuite utilisés par les testeurs AKA Test Engineers (TEs).
(Il convient de noter que j'avais postulé, passé un entretien et été sélectionné pour un stage SWE uniquement. Ce n'est que pendant la phase d'appariement des équipes (environ 1 mois avant la date de début du stage) que j'ai appris que mon rôle serait SETI, et non SWE. Mais je n'ai rien pu changer à ce moment-là. J'avais également une autre offre de stage SWE concurrente, que j'avais laissée tomber à cause de la marque Google.)
Avant le stage, j'ai eu une réunion hangout avec mes futurs hôtes, dans laquelle ils ont juste dit le nom de l'équipe, mais ne m'ont rien dit sur le travail (en raison à la fois du NDA et de la chose SETI). (Personne ne dirait à un futur stagiaire de Google qu'il rejoindrait une équipe de test, n'est-ce pas ?)
En avant vers le stage -
J'ai commencé à travailler avec l'équipe, et j'ai observé attentivement les réunions hebdomadaires régulières et le type de projets sur lesquels ils travaillaient.
Ils allaient de :
1. Tests de performance (charge) et d'intégration entre un service X* orienté client que mon équipe gérait et une base de données interne.
2. Trouver le code mort dans le code de production existant (écrit par d'autres équipes) manuellement et l'éliminer. (Ils n'ont pratiquement pas fait d'outillage automatisé pour cela, tant que le travail manuel fonctionnait.)
3. Les rotations d'astreinte pour le produit X et la gestion des pannes.
4. La construction de quelques outils internes pour la construction et le test, qui montrent les latences de divers appels de fonction/ RPC et leur fréquence d'être appelés.
Et des choses comme celles-ci.
Mon équipe a travaillé en étroite collaboration avec une autre équipe SWE appropriée, qui a construit un produit X orienté client, que mon équipe a géré. Fondamentalement, la plupart du développement des fonctionnalités de X a été fait par l'autre équipe, et mon équipe a fait des tests et des appels pour elle. (Je l'appelle X pour ma vie privée.)
Tout compte fait, j'ai réalisé que c'était un rôle de test approprié, avec juste un masque d'ingénieur logiciel. Dans les équipes de productivité de l'ingénierie, il y a des ingénieurs de test (TE) et des SETI.
J'ai appris là que le nom du rôle a changé de -
Software Engineer in Test (SET) -> SETI (Software engineer, tools and infrastructure) -> SWE, engineering productivity, comme on l'appelle maintenant.
Je crois que les changements de nom du rôle reflètent aussi sa moindre popularité chez Google, et les recruteurs trouvant difficile d'obtenir et de retenir des personnes en tant que SETI.
Tech stack:
J'étais quand même un peu content que mon projet de stage ne soit pas orienté vers les tests, et qu'il comporte des travaux de développement. Au moins, je pensais que cela pourrait avoir l'air bien sur le papier.
Maintenant, en tant que jeune diplômé, je m'inquiétais de la façon dont j'allais mettre cela sur mon CV. Puisque mon travail n'était ni proprement back-end ni front-end, ni Android, ni apprentissage automatique ou tout autre titre bien défini. J'ai travaillé à la construction d'un portail interne en utilisant uniquement les outils internes de Google, qui ne sont pas utilisés ni connus en dehors de Google.
Mes amis qui ont fait un stage dans d'autres entreprises similaires avaient une pile technologique et un travail bien meilleurs. Mes amis qui ont travaillé dans des équipes backend dans d'autres bonnes entreprises ont utilisé des choses comme - node.js, django, AWS/Azure, Hadoop, Spark, Kafka, Golang etc. Certains ont travaillé sur Android, iOS ou l'apprentissage automatique. Je n'ai utilisé aucun de ces outils pendant mon stage à SETI.
D'autres stagiaires de Google, qui étaient dans de meilleures équipes, n'ont également pratiquement pas utilisé les outils cool que j'ai mentionnés ci-dessus.
Un autre problème bien connu est que Google est sur le nivellement et les promotions. Comme mon équipe faisait surtout des tests et très peu de travail de développement, ils ont eu du mal à montrer un impact mesurable, ce qui est essentiel pour les promotions chez Google. J'ai rencontré quelques personnes dans mon équipe qui avaient plus de 10 ans d'ancienneté chez Google et qui étaient toujours au niveau L4 (SWE 3), soit juste un niveau au-dessus du niveau d'entrée (L3) chez Google. Pour une comparaison, vous pouvez consulter Google, Facebook et Microsoft : Comparez les niveaux et les salaires et Salary Range and Compensation Charts | Levels.fyi
En ce qui concerne la partie de commutation, je ne connais pas la réponse, mais je suppose que cela ne doit pas être très difficile. Il suffit de postuler à une offre d'emploi interne, et si le manager qui a l'ouverture accepte de vous prendre, vous pouvez facilement bouger. (La règle est que vous devez passer au moins un an dans votre équipe actuelle, avant de pouvoir changer d'équipe.)
Pour ce qui est du parcours de carrière, ils continuent simplement à progresser comme des ETS normaux. Cependant, qu'ils soient promus ou non est une question difficile.
Dans l'ensemble, SETI est un rôle de test merdique. Ne le prenez pas à moins que vous n'obteniez pas un rôle de dév dans d'autres bonnes entreprises.
- Un ancien stagiaire frustré.