¿Qué hacen los ingenieros de software de herramientas e infraestructura en Google? ¿Es difícil pasar de un puesto de Herramientas e Infraestructura a un ingeniero de software de producto? ¿Qué trayectoria profesional puede tener un ingeniero de Herramientas e Infraestructura en Google?

He sido un antiguo becario de SWE (SETI) en Google India.
Al igual que todos los demás, tampoco sabía la diferencia entre los roles de SWE y SETI.
Me asignaron un equipo SETI y tuve que trabajar con ellos.
Por lo tanto, antes de unirme allí, busqué la descripción del trabajo del rol de SETI, que decía algo así como "Diseñar y construir marcos avanzados de pruebas automatizadas". Esta línea en sí me hizo pensar que era un papel de pruebas, pero fui consolado por mis amigos que podrían ser sólo la construcción de marcos de pruebas, que más tarde sería utilizado por los probadores AKA Ingenieros de Pruebas (TEs).

(Hay que señalar que había aplicado, entrevistado y fue seleccionado para una pasantía SWE solamente. Solo durante la fase de emparejamiento del equipo (aproximadamente 1 mes antes de la fecha de incorporación a las prácticas), me enteré de que mi función iba a ser SETI, no SWE. Pero, no había nada que pudiera cambiar tan tarde. También tenía otra oferta de prácticas de SWE que competía, pero que dejé pasar por la marca Google.)

Antes de las prácticas, tuve una reunión con mis futuros anfitriones, en la que sólo me dijeron el nombre del equipo, pero no me contaron nada sobre el trabajo (debido a la NDA y al tema de SETI). (Nadie le diría a un futuro becario de Google que se uniría a un equipo de pruebas, ¿verdad?)

Además, empecé a trabajar con el equipo, y observé cuidadosamente las reuniones semanales regulares y el tipo de proyectos en los que trabajaban. Pruebas de rendimiento (carga) e integración entre un servicio X* orientado al cliente que mi equipo gestionaba y una base de datos interna.
2. Encontrar manualmente código muerto en el código de producción existente (escrito por otros equipos) y eliminarlo. (Apenas hicieron herramientas automatizadas para ello, siempre que el trabajo manual funcionara)
3. Rotaciones de guardia para el producto X y manejo de interrupciones.
4. Construcción de algunas herramientas internas para construir y probar, que muestran las latencias de varias llamadas a funciones / RPCs y su frecuencia de ser llamado.
Y cosas como estas.

Mi equipo trabajó estrechamente con otro equipo de SWE adecuado, que construyó un producto X de cara al cliente, que mi equipo gestionó. Básicamente, la mayor parte del desarrollo de las características de X fue realizado por el otro equipo, y mi equipo hizo las pruebas y la guardia para ello. (Lo estoy llamando X para mi privacidad.)

Con todo, me di cuenta de que era un papel de pruebas adecuado, con sólo una máscara de ingeniero de software. En los equipos de productividad de ingeniería, hay ingenieros de pruebas (TE) y SETI.
Me enteré de que el nombre de la función cambió de -
Ingeniero de Software en Pruebas (SET) -> SETI (Ingeniero de Software, herramientas e infraestructura) -> SWE, ingeniería de productividad, como se llama ahora.
Creo que los cambios de nombre de la función también reflejan su menor popularidad en Google, y los reclutadores encuentran difícil conseguir y retener a la gente como SETI.

Pila de tecnología:
Todavía estaba un poco feliz de que mi proyecto de prácticas no estaba orientado a las pruebas, y tenía algo de trabajo de desarrollo. Al menos, pensé que podría quedar bien sobre el papel.

Ahora, como recién graduado, me preocupaba cómo iba a poner esto en mi currículum. Ya que mi trabajo no era propiamente de back-end ni de front-end, ni de Android, ni de machine learning ni de ningún título bien definido. Trabajé en la construcción de un portal interno utilizando únicamente las herramientas internas de Google, que no se utilizan ni se conocen fuera de Google.

Mis amigos que hicieron prácticas en otras empresas similares tenían una pila tecnológica y un trabajo mucho mejor. Mis amigos que trabajaron en equipos de backend en otras buenas empresas usaron cosas como - node.js, django, AWS/Azure, Hadoop, Spark, Kafka, Golang etc. Algunos consiguieron trabajos de Android, iOS o machine learning. Yo no utilicé ninguna de ellas durante mis prácticas en SETI.

Otros becarios de Google, que estaban en mejores equipos también no utilizaron apenas ninguna de las herramientas geniales que he mencionado anteriormente.

Otro problema bien conocido es el de Google con la nivelación y los ascensos. Como mi equipo hacía sobre todo pruebas y muy poco trabajo de desarrollo, les resultaba difícil mostrar un impacto medible, que es fundamental para los ascensos en Google. Conocí a algunas personas de mi equipo que llevaban más de 10 años en Google y todavía estaban en la categoría L4 (SWE 3), que es sólo un nivel por encima del nivel de entrada (L3) en Google. Para comparar, puedes ver Google vs Facebook vs Microsoft: Comparación de Niveles y Salarios y Rango Salarial y Tablas de Compensación | Niveles.fyi

Respecto a la parte del cambio, no sé la respuesta, pero supongo que no debe ser muy difícil. Sólo tienes que presentarte a una vacante interna, y si el jefe que tiene la vacante acepta tomarte, puedes cambiarte fácilmente. (La norma es que tienes que pasar al menos un año en tu equipo actual, antes de poder cambiar de equipo.)

En cuanto a la trayectoria profesional, simplemente siguen progresando como los SWE normales. Sin embargo, si se promocionan o no es una cuestión difícil.

En general, SETI es un papel de pruebas de mierda. No lo aceptes a menos que no consigas un papel de desarrollo en otras buenas empresas.
- Un ex pasante frustrado.