Software Engineer - XP / TDD / Continuous Delivery Mindset

Nuestro cliente es una startup que construye sistemas de gestión de riesgo y alertamiento temprano para eventos hidrometeorológicos y desastres naturales. Su software procesa información en tiempo real, integra sensores físicos, distribuye alertas y ayuda a instituciones y organizaciones a reaccionar ante eventos críticos.

No estamos buscando solo Backend...Estamos buscando engineers que:

• No trabajan como una software factory tradicional.
• No creen en releases gigantes,
• QA como cuello de botella,
• tickets eternos,
• “ya quedó en mi ambiente”,
• ceremonias ágiles vacías,
• ni arquitecturas complejas solo porque “así lo hace Big Tech”.

Sí creemos en:

• XP (Extreme Programming),
• TDD real,
• refactor continuo,
• feedback loops cortos,
• trunk-based development,
• entrega continua,
• YAGNI,
• diseño incremental,
• colaboración constante,
• y software simple que evoluciona rápido.

Qué hacemos realmente

Construimos software para:

• ingestión de datos en tiempo real,
• procesamiento de eventos,
• alertamiento temprano,
• sistemas operativos críticos,
• continuidad operativa,
• monitoreo,
• observabilidad,
• y automatización de flujos de riesgo.

Trabajamos principalmente con:

• AWS,
• arquitecturas event-driven,
• TypeScript end-to-end,
• servicios cloud-native,
• sistemas distribuidos,
• y releases frecuentes en producción.

Stack actual

Backend

TypeScript, Node.js, Serverless, Event-driven Architecture

Cloud / Infraestructura

AWS Lambda, EventBridge, SNS, SQS, CloudWatch, DynamoDB, Fargate

Frontend

TypeScript, React

Mobile

React Native

Otros

Docker, CI/CD, Testing, Observability, Cloud-native tooling

Cómo trabajamos

El objetivo NO es escribir la arquitectura “perfecta”.

El objetivo es:

• entregar valor rápido,
• obtener feedback temprano,
• reducir fricción,
• mantener el sistema fácil de cambiar,
• y evolucionarlo continuamente.

Aquí:

• hacemos releases frecuentes,
• trabajamos con ownership compartido,
• revisamos diseño constantemente,
• hacemos refactor continuo,
• y buscamos reducir el tiempo entre:

  “escribí código”

  y

  “sé si realmente funciona”.

Cómo colaboramos

Trabajamos de manera altamente colaborativa.

Eso significa que:

• compartimos contexto constantemente,
• revisamos ideas temprano,
• hacemos pairing,
• discutimos diseño,
• y damos feedback técnico frecuente.

Para nosotros, pair programming NO significa:
“dividir tareas y cada quien trabajar por su lado”.

Significa:

• resolver problemas juntos,
• reducir incertidumbre temprano,
• compartir ownership,
• detectar errores antes de producción,
• y mejorar continuamente cómo construimos software.

Si disfrutas trabajar completamente aislado o prefieres ownership individual rígido sobre partes del sistema, probablemente este entorno no te resulte cómodo.

Lo que probablemente NO disfrutarás aquí

Este rol probablemente NO es para ti si:

• prefieres procesos rígidos y altamente estructurados,
• necesitas tickets extremadamente detallados para avanzar,
• haces testing solo al final,
• trabajas mejor aislado,
• te incomoda recibir feedback técnico frecuente,
• piensas que TDD = “hacer pruebas después”,
• buscas equipos donde cada quien toca únicamente “su microservicio”,
• o si tu definición de seniority es únicamente años de experiencia o conocimiento de frameworks.

Qué valoramos realmente

Más allá del stack, buscamos personas que:

• sepan reducir complejidad,
• puedan entregar incrementalmente,
• entiendan trade-offs,
• detecten fricción en procesos,
• colaboren activamente,
• tengan criterio técnico,
• y sean capaces de aprender rápido.

No esperamos perfección.

Sí esperamos curiosidad técnica genuina.

Antes de aplicar

trabajamos bajo principios inspirados en:

• Extreme Programming (XP)
• TDD
• Continuous Delivery
• YAGNI
• Refactor continuo
• Feedback-driven development

Si estos conceptos te son familiares, probablemente tengas ventaja en el proceso.

Si no los conoces pero este tipo de cultura te interesa, te recomendamos muchísimo explorar:

Extreme Programming Explained — Kent Beck

No necesitas convertirte en experto para aplicar.
Pero sí queremos personas con curiosidad real por mejorar cómo se construye software.

Proceso

1. Conversación inicial (mindset + experiencia real)
2. Sesión técnica práctica
3. Conversación final con el equipo

No hacemos:

• LeetCode
• acertijos algorítmicos irreales
• entrevistas teatrales

Sí evaluamos:

• cómo piensas,
• cómo colaboras,
• cómo diseñas,
• cómo abordas problemas,
• cómo reaccionas al feedback técnico,
• y cómo trabajas bajo incertidumbre real.

Requirements

Nota importante

Si sientes que tu CV NO refleja completamente este tipo de mindset técnico-cultural, pero esta forma de trabajar te entusiasma genuinamente:
aplica de todos modos.

Nos interesa mucho más:

• cómo piensas,
• cómo aprendes,
• cómo colaboras,
• y cómo reaccionas al feedback,
  más que una lista perfecta de buzzwords.
  
  Responde a detalle todas las preguntas de prefiltro (ATS), esto será importante para el prefiltro.

• Más allá de tu CV, queremos entender cómo piensas y cómo trabajas.

• No buscamos respuestas “correctas”.
• Buscamos honestidad, criterio y claridad técnica.

Benefits

🚀 Integración a marcas globales y startups disruptivas.

🏡 Trabajo remoto/Home office.

📍 En caso de requerir modalidad híbrida o presencial, serás informado desde la primera sesión.
⏳ Horario ajustado a la célula de trabajo/proyecto asignado.
📅 Trabajo de lunes a viernes.
🎉 Día off en tu cumpleaños.
🏥 Seguro de gastos médicos mayores (aplica para México).
🛡️ Seguro de vida (aplica para México).
🌎 Equipos de trabajo multiculturales.
🎓 Acceso a cursos y certificaciones.
📢 Meetups con invitados especiales del área de IT.
📡 Eventos virtuales de integración y grupos de interés.
📢 Clases de inglés.
🏆 Oportunidades dentro de nuestras diferentes líneas de negocio.
🏅 Orgullosamente certificados como Great Place to Work.