Senior DevOps Engineer

Este es un puesto senior y no es un puesto que podamos cubrir con alguien junior: eres el primero, durante un tiempo el único, y la plataforma sobre la que construyen todos los demás es la que pongas tú.

Mainloop AI es una empresa de ingeniería en Barcelona. Somos dueños de lo que construimos y respondemos ante nosotros mismos. Te llevas la parte interesante de una empresa nueva, con un cliente real y productos reales desde el primer día.

Lo que construimos es el software que automatiza el trabajo de los servicios profesionales, en unos quince países, para empresas que se ahogan en procesos. Construimos esos productos y los operamos. Esa segunda mitad es la razón por la que existe este puesto, y no es un formalismo: un equipo que es dueño de cómo se construye su software debería ser dueño de cómo se entrega.

Tú eres quien acaba con eso. Eres nuestro primer ingeniero de DevOps, y durante un tiempo el único.

En qué consiste el trabajo de verdad

No estás heredando una plataforma. La estás escribiendo.

Hoy no hay infraestructura como código en nuestro estado: ni una línea. Tu primer trabajo es hacer que eso deje de ser cierto para siempre: todos los entornos que operamos reproducibles desde un repositorio versionado, desde tu primera semana, antes de que se asiente la costumbre.

En tus primeros meses vas a:

• Construir la plataforma desde código. Máquinas, red, ingress, accesos, entornos: versionado, parametrizado, revisable. Es el momento más barato en que esto se va a hacer nunca, y te toca hacerlo bien en lugar de encajarlo después.
• Hacer que desplegar sea autoservicio. Hoy, publicar una aplicación existente es un git push; levantar una nueva exige permisos de administrador y dos trampas sin documentar. Cerrar ese hueco es tuyo, hasta dejarlo en un solo comando, para que un desarrollador nunca tenga en la mano una credencial de plataforma.
• Gestionar los secretos como es debido. Un gestor de secretos de máquina de verdad y —porque ejecutamos muchos agentes de IA— credenciales intermediadas de forma que un proceso agente solo tenga nunca un marcador de posición, jamás una clave. Si tienes opiniones sobre cómo se impide que un agente con una inyección de prompt filtre una credencial de producción, esta parte te va a gustar; casi nadie llega a diseñarla desde cero.
• Demostrar la restauración. Tenemos un estándar escrito que dice que «alguien lo despliega» no es «alguien ha demostrado que la restauración funciona». Harás el simulacro y escribirás el informe.
• Construir el camino a producción. Del commit a producción, con una barrera de pruebas automática, URLs de vista previa por rama que un stakeholder pueda abrir desde el móvil, y un rollback que todo el equipo haya ensayado antes de necesitarlo.
• Y luego mantenerlo todo en marcha, y hacerlo cada vez más aburrido. Observabilidad, topes de coste, higiene de dependencias, el trabajo sin glamour que decide si un equipo pequeño puede llevar muchos productos.

Y tendrás la autoridad que corresponde. No estás implementando el diseño de plataforma de otro. Cómo se construye esto lo decides tú. Contratamos a nivel senior precisamente para que esas decisiones puedan ser tuyas: la plataforma sobre la que corre aquí cada producto es la que pongas tú, y preferimos incorporar el criterio a supervisarlo.

Nadie está de guardia. Nunca.

Sin turnos, sin busca, sin número de teléfono, sin «échale un ojo este fin de semana». Las alertas se publican en un canal de equipo y esperan ahí. Es una decisión escrita, no un descuido que redescubriremos más adelante, y se aplica a todos los productos que llevamos, sin excepciones.

Te lo decimos de entrada porque no es un extra que esperemos en voz baja que renuncies a usar. Muchos anuncios dicen «cultura de guardias sana» y quieren decir un turno rotativo. Nosotros queremos decir que no hay turno.

Aquí va la otra mitad honesta, y es el trabajo de verdad: solo podemos hacer esa promesa porque nos protegemos con ingeniería en lugar de con las tardes de la gente, y esa ingeniería es para lo que te contratamos. Infraestructura como código, para que una máquina perdida se reconstruya en lugar de resucitarse. Backups con una restauración que hemos probado de verdad. Un rollback de un clic que todo el mundo ha ensayado ya. Alertas que se encolan en vez de llamar, porque no se espera que nadie conteste de noche al otro lado.

Así que el trato es explícito: a ti no te despiertan nunca, y a cambio los sistemas tienen que ser genuinamente recuperables. Si has pasado una carrera recibiendo avisos por cosas que deberían haberse resuelto con ingeniería, esta es la versión del trabajo en la que haces la ingeniería.

En horario laboral es lo contrario de estar al margen. El PO, los desarrolladores y el ingeniero de DevOps asignados a un producto responden de las incidencias de ese producto: el soporte no se despacha a un equipo aparte, es parte de ser dueño de la cosa, y es lo que mantiene a todo el mundo honesto sobre la calidad.

Cómo construimos: deliberadamente aburrido, y tú tienes voz

Tenemos un stack asentado y es el mismo en casi todos los repositorios a propósito: un andamiaje, paquetes compartidos, push para desplegar. La recompensa es que un equipo de dos personas puede coger un producto que no ha visto nunca y ser útil el mismo día, que es la única razón por la que un equipo de este tamaño puede llevar tantos productos.

Construimos la plataforma más simple que cumpla el requisito, y somos estrictos con cuál es el requisito de verdad. Aquí la complejidad tiene que ganarse su sitio: cada capacidad que operamos es una cosa más que un solo equipo tiene que entender, parchear y ser capaz de reconstruir.

Un ejemplo concreto, porque dice mucho de nosotros: no usamos Kubernetes, y fue una decisión y no un olvido. Lo miramos bien, dos veces —la última porque nos preocupaba habernos equivocado— y las dos veces la respuesta fue que una cartera pequeña con tráfico predecible no necesita planificación multinodo ni autoescalado lo bastante como para pagarlos con el único ingeniero de infraestructura que tenemos. Escribimos las condiciones concretas bajo las que cambiaríamos de opinión, y cuando se cumpla una, cambiaremos.

Que es justo por lo que pedimos a alguien que haya llevado Kubernetes en producción y sepa decirnos cuándo no es la respuesta. Si tu idea de una buena semana es afinar un clúster, este es el trabajo equivocado y preferimos que lo sepas ahora. Si tu idea de una buena plataforma es una que un equipo pequeño pueda entender del todo, reconstruir desde un repositorio y entregar a alguien nuevo en una tarde, y tienes cicatrices suficientes para saber dónde eso deja de bastar, ese criterio es casi todo lo que estamos contratando.

Es un valor por defecto, no una camisa de fuerza. Algunas cosas necesitan genuinamente otra solución, y cuando es así nos adaptamos a propósito, con el razonamiento escrito. Lo que no hacemos es volver a decidir las mismas cinco preguntas en cada repositorio nuevo por costumbre.

Y tienes voz en cuál es el estándar. Cualquiera puede proponer un cambio: algo nuevo que sea genuinamente mejor, algo a lo que deberíamos actualizarnos, algo en lo que nos equivocamos. Una propuesta se investiga como es debido frente a las alternativas, recibe una respuesta, y si la respuesta es no te llevas el razonamiento. En infraestructura no eres una voz entre muchas: eres quien decide, dentro de un presupuesto que ayudas a fijar.

Vas a llegar a ser muy bueno construyendo con agentes de IA

Somos un equipo de ingeniería nativo en IA de verdad, no un equipo que ha añadido una licencia de Copilot. Cada ingeniero tiene su propia suscripción a Claude Max y un orquestador de escritorio que ejecuta varios agentes de código en paralelo, cada uno en su rama. Contigo también: una gran parte del trabajo de infraestructura hoy se especifica más que se teclea, y llegarás a manejar eso muy bien: dónde funciona, dónde falla, y cómo leer un diff y decidir si de verdad está bien.

También hace tu trabajo más interesante que el mismo título en otro sitio, porque la ingeniería agéntica crea problemas de infraestructura que casi ningún equipo tiene todavía:

• Los agentes instalan paquetes en código que está al lado de datos de cliente. La higiene de la cadena de suministro deja de ser una casilla de cumplimiento y pasa a ser un control vivo del que respondes tú.
• Los agentes tienen credenciales, o mejor dicho, no deben tenerlas. Intermediar la identidad de máquina para que el agente nunca toque la clave real es un problema de diseño, y es tuyo.
• Los agentes cuestan dinero de una forma invisible hasta que llega la factura. Presupuestos por proyecto, topes duros y una alerta que salte antes del tope, no después.
• Los agentes pueden desplegar. Lo que significa que las barreras entre «un agente ha propuesto esto» y «esto está en producción» son infraestructura, no política.

Si llevas tiempo ejecutando agentes en serio y tienes opiniones sobre dónde se rompen, queremos oírlas. Si tienes curiosidad pero aún no estás metido a fondo, también vale: enseñar esto bien es algo por lo que pretendemos ser conocidos.

Cosas que conviene saber de entrada

• Este es un puesto presencial en Barcelona. Más que las otras plazas de aquí, y por una razón real: estás levantando infraestructura y accesos casi físicos para un equipo que se está montando a tu alrededor, en su primer año, y casi todo eso va más rápido en una sala.
• Eres el único ingeniero de DevOps durante un tiempo. Eso es autoridad, y también es un factor bus, que es por lo que «nada existe solo en la cabeza de una persona» está escrito en el puesto en vez de ser un deseo. Todo lo que construyes queda documentado y reproducible sobre la marcha, no después.

Si te mudarías a Barcelona por esto

No esperamos que asumas el coste de mudarte, y preferimos decir qué cubrimos a dejar que lo preguntes.

• Pagamos por traerte. Vuelos, el alojamiento del primer mes mientras encuentras algo propio, los costes de visado y papeleo, y un gestor que se ocupe de la burocracia —el NIE, la cita del TIE, las apostillas— en lugar de dejarte solo ante la administración española. Clases de español si las quieres.
• Un bonus de reubicación, pagado a la llegada y no a plazos. Solo es reembolsable si te vas en los primeros dieciocho meses, y esa condición es justo lo que nos permite pagarlo por adelantado: mudarse de país cuesta dinero al principio, no en el segundo año.

Tres cosas de aquí valen más de lo que parecen al comparar ofertas, sobre todo frente a una estadounidense:

• Nadie está de guardia. Nunca. Tiene su propia sección más arriba y lo decimos literalmente. Si vienes de un mercado donde se da por hecho que el trabajo de infraestructura y un busca van juntos, lee esa sección dos veces: es la mayor diferencia entre este trabajo y el mismo título en otro sitio, y no es un extra que esperemos en voz baja que renuncies a usar.
• Sanidad sin prima, sin franquicia y sin cuadro médico, desde el primer día y sin quedar atada a seguir en este trabajo.
• Treinta días naturales de vacaciones —es decir, 22 laborables— más catorce festivos, unas siete semanas en total. Es el mínimo legal en España, no un beneficio con el que estemos siendo generosos.

Y lo de presencial se lee distinto según dónde estés. Para alguien que ya vive en Barcelona es una restricción y hemos dicho por qué. Para alguien que se muda es casi todo el atractivo: este es un trabajo en Barcelona, no un trabajo que haces desde Barcelona, un equipo que se sienta junto, en una ciudad en la que merece la pena estar en persona.

Qué buscamos

Lee esto como una descripción del ingeniero que serás aquí, no como una lista con la que tengas que llegar. Casi nadie lo marca todo el primer día, y preferimos contratar a alguien con el instinto y formar lo demás; es buena parte de para qué sirve el certificado.

• Has construido infraestructura desde cero antes, y sobrevivió a que otros la usaran. Una plataforma que te entregaron y mantuviste vale; una plataforma que creaste es lo que pedimos. Esto es lo único innegociable, y es por lo que el puesto es senior: aquí no hay nadie que revise tu trabajo, y la plataforma que pongas es sobre la que construyen todos los demás durante años.
• La infraestructura como código es cómo trabajas, no una herramienta que has usado. Sabes hablar de qué haces cuando la realidad y el repositorio no coinciden, porque siempre acaban por no coincidir.
• Has sido dueño de backups y has restaurado de verdad desde ellos, con prisa, idealmente cuando importaba. Todo el mundo tiene backups. Muchos menos han restaurado.
• Te mueves con soltura operando cosas en servidores propios, no solo en una consola de cloud gestionado. Somos dueños de nuestra infraestructura a propósito, y eso es una habilidad distinta de configurar la de otro.
• Has llevado Kubernetes en producción, y estás igual de cómodo diciendo cuándo no es la respuesta correcta. Hoy no lo usamos. Si lo usaremos y cuándo es una de las decisiones de las que este puesto es dueño, y preferimos que la tome alguien que ha convivido con la cosa antes que alguien que razona sobre ella desde fuera.
• Te automatizas a ti mismo fuera del bucle, y escribes las cosas. La medida de este trabajo es cuán poco de él te necesita a ti en concreto.
• Sabes decirle que no a la complejidad. El mejor ingeniero para esta plaza es el que construye la cosa aburrida que funciona y se resiste a la cosa interesante que no hace falta que exista.
• La seguridad es instinto, no una fase. Secretos, accesos, mínimo privilegio, parcheo: las disciplinas aburridas, sostenidas con constancia.
• Inglés, con fluidez. Es nuestro idioma de trabajo: trabajamos en unos quince países. El español es genuinamente útil en el día a día. El catalán no es un requisito.
• Barcelona. Este es un equipo que se sienta junto, sobre todo en su primer año.

Nos da igual qué estudiaste. Nos importa qué has construido y operado, y si sabes explicarnos las decisiones que hay dentro.

Cómo contratamos: las dos rondas hechas para esta plaza

1. Una conversación de treinta minutos. Qué has construido, cómo trabajas y cómo lo piensas. Te pediremos que nos lleves por algo que hayas construido y que después justifiques una decisión concreta de dentro. No hay forma de preparar eso y no busca pillarte: es como distinguimos entender de estar familiarizado.
2. Un proyecto. Te damos un encargo y un entorno de trabajo donde construirlo, con Claude Code ya montado y conectado a una clave, para que construyas como construimos de verdad en lugar de hablar de ello en una pizarra. Es trabajo real y no un acertijo, lo haces a tu ritmo —sin cogerte una semana, sin vuelos, sin nada que exija que ya estés libre— y después repasamos juntos lo que construiste.

Mainloop · Barcelona. Preséntate con algo que hayas construido y un párrafo sobre una caída que provocaste o heredaste, y qué cambiaste después.