Backend Product Engineer

Symmetry es la app número 1 de Salud y Bienestar en varios mercados, con más de 3 millones de descargas. Detrás de cada entreno, cada progreso y cada suscripción hay un backend. Buscamos a la persona que va a ser su dueña.

No buscamos a alguien que cierre tickets. Buscamos a un/a ingeniero/a que sabe por qué existe cada endpoint, qué número mueve y qué pasa a las tres de la mañana cuando falla. Que diseña el sistema, lo lanza, lo mide y lo mejora sin que nadie se lo pida.

El listón es muy alto a propósito: preferimos tardar más en contratar que contratar a alguien normal.

A quién buscamos

Contratamos por lo que has construido y lo que puedes demostrar, no por años en el CV ni por el logo de tu última empresa.

• Has tenido sistemas en producción que eran tuyos. No "participé en": diseñaste la arquitectura, te comiste los incidentes y decidiste qué se rehacía. Puedes contarnos qué falló y por qué.
• Piensas en producto. Antes de diseñar una tabla te preguntas qué decisión del usuario va a guardar y qué métrica va a mover: activación, retención o ingresos.
• Te gustan los problemas duros. Colas, reintentos, idempotencia, concurrencia, datos que no cuadran. Lo que a otros les da pereza a ti te engancha.
• Sigues construyendo con tus manos. Da igual tu seniority: hoy escribes código, y se nota.
• Dejas rastro. Un proyecto con usuarios reales, una competición, un ascenso antes de tiempo, un bug bounty, algo que montaste de adolescente y usaban otros. La gente excelente deja miguitas, y nos fijamos en ellas.
• No buscas un trabajo corporativo. Ni comités, ni tres capas de aprobación, ni esperar a que alguien te escriba la spec.

El rol

Serás dueño/a de los sistemas que mueven Symmetry: las APIs que consume la app de Flutter, los modelos de datos, los jobs en background, las integraciones y los flujos de datos que deciden si un usuario se activa, vuelve mañana y paga.

Aquí no hay squads de backend ni arquitectos que diseñan para que otros implementen. Hay un único equipo de desarrollo y tú llevas el backend de punta a punta: entiendes el problema con Producto, diseñas la solución, la lanzas detrás de un flag, miras los datos y decides el siguiente paso.

Esto no es mantenimiento. El producto cambia cada semana, con varios experimentos A/B a la vez, y el backend tiene que ir a ese ritmo sin romperse. Velocidad y calidad no son un tradeoff: son el trabajo.

Qué harás

• Diseñar y construir las APIs y los modelos de datos de cada funcionalidad nueva, desde la primera migración hasta el despliegue.
• Hacer que el backend aguante el crecimiento: rendimiento, colas, caché, jobs en background y una base de datos que no se cae cuando un vídeo se hace viral.
• Llevar los experimentos desde el servidor: feature flags, variantes, asignación de cohortes y los eventos de analítica que permiten leer cada test con honestidad.
• Ser dueño/a de los datos que importan: usuarios, entrenos, progreso y suscripciones. Que cuadren, que se puedan consultar y que nadie tenga que pedir un export a mano.
• Trabajar codo con codo con Producto, Diseño y mobile para que lo que se define salga exactamente como se pensó.
• Fiabilidad y observabilidad: si algo se rompe, te enteras tú antes que el usuario, y lo arreglas en la causa, no en el síntoma.
• Usar IA como herramienta por defecto: Claude, Cursor, agentes. Si algo te lleva un día y un agente puede hacerlo en una hora, esperamos que lo veas tú solo.

Requisitos

No negociable

• Backend en producción de verdad: diseño de APIs, bases de datos relacionales y modelado de datos con volumen real.
• Ownership de principio a fin de problemas ambiguos. Si la spec no existe, la escribes tú.
• Velocidad con código mantenible. Lanzas rápido, y lo que dejas se entiende, se testea y se puede tocar dentro de seis meses.
• Criterio de producto. Sabes decir que no a algo técnicamente bonito que no mueve nada.
• Impacto que puedes probar. Un número, un enlace o una persona que lo confirme. "Mejoré el rendimiento" no cuenta; "bajé el p95 de 900 a 120 ms" sí.
• Comunicación escrita clara y directa. En remoto, escribir bien es parte del trabajo.

Lo que más suma

• Nuestro stack: Python, Django/DRF, PostgreSQL, Redis y Celery.
• Haber escalado una app de consumo de miles a millones de usuarios.
• Suscripciones y pagos: App Store, Google Play, webhooks, trials y todo lo que se rompe entre medias.
• Analítica y experimentación, CI/CD y Docker.
• Apps de fitness, salud o bienestar.

Qué es tener éxito aquí

• En dos meses llevas el backend de punta a punta sin que nadie te tenga que guiar.
• De la idea a producción en días, no en semanas.
• Cada incidente tiene su causa raíz y un cambio que evita toda esa familia de fallos.
• Los experimentos se leen sin discutir si los datos están bien.
• Al final de tu primer año el backend es más simple, más rápido y más barato que cuando llegaste.

Este rol no es para ti si…

• Necesitas tickets muy especificados antes de empezar.
• Te importa más la elegancia técnica que lo que le pasa al usuario.
• «En mi máquina funciona» te parece una respuesta.
• Lo tuyo es implementar lo que otro ha diseñado y pasar al siguiente proyecto.
• El feedback directo o el listón alto te incomodan.
• Buscas un nueve a cinco sin presión ni sentido de urgencia.

Compensación y beneficios

• Salario competitivo más bonificación trimestral del 25 % al 50 % ligada a resultados. No fijamos cifra por el puesto: nos adaptamos a tu experiencia y a tu situación actual.
• Equity: participación directa en el crecimiento de Symmetry.
• 100 % remoto, sin horarios fijos y con casi ninguna reunión.
• Impacto real: lo que despliegas por la mañana lo usan miles de personas esa misma tarde.
• Crecimiento acelerado: trabajas directamente con el CEO y el equipo directivo.

El proceso

• Aplicas en unos minutos. Lo que más pesa no es el CV: lo más impresionante que has hecho, tus indicadores de competencia y el problema técnico más difícil que has resuelto. Solo cuenta lo que puedas probar con un número, un enlace o una persona.
• Llamada de 30 minutos. Bajamos al detalle de lo que contaste en el formulario: ten a mano los números y los enlaces.
• Prueba técnica de unas 3 horas: un repo real, tu PR y tu criterio. La empiezas cuando tengas el bloque libre.
• Decisión rápida. Sin semanas de silencio.

Respondemos a todo el mundo, avances o no.