AuroraJobs

Problema y contexto

Los universitarios que buscan su primer trabajo y las empresas que contratan perfiles junior rara vez se encuentran en un sitio pensado para esa etapa: los portales generalistas tratan a ambos como un caso más. AuroraJobs montó empleo, formación y contenido alrededor de ese momento concreto.

Para quiénUniversitarios en sus primeros pasos, empresas que contratan perfiles junior y los servicios de orientación de las universidades.

Mi responsabilidad

Construí la aplicación de punta a punta y lideré el desarrollo de producto: modelado, backend, frontend, pruebas y despliegues, además del reparto de trabajo, las pull requests y el mentoring de los otros dos developers.

Decisiones

1. 01

   Un monolito Rails en lugar de servicios

   Situación

   Éramos pocos y había que montar perfiles, ofertas, matching, candidaturas, contenido y analítica casi en paralelo.

   Qué decidí

   Mantenerlo todo en un monolito Ruby on Rails, con Sidekiq para el trabajo asíncrono.

   Por qué

   Con ese tamaño de equipo, separar en servicios añadía despliegues, contratos entre partes y depuración repartida sin resolver ningún problema que tuviéramos entonces.

   Qué cambió

   Modelo de datos e interfaz se tocaban en el mismo cambio, y una funcionalidad completa entraba en un ciclo corto.

2. 02

   Hacer configurable lo que cambiaba cada semana

   Situación

   Los filtros, los formularios del estudiante y los criterios de priorización cambiaban con cada conversación de producto. Cada ajuste era una tarea de desarrollo y un despliegue.

   Qué decidí

   Llevarlos al dashboard interno y dejar que el equipo los configurase desde ahí.

   Por qué

   Lo que cambia por criterio de negocio no debería tener que pasar por mí para cambiar.

   Qué cambió

   Producto ajustaba filtros y formularios sin esperar a desarrollo, y dejaron de llegarme tickets que eran decisiones de negocio disfrazadas de trabajo técnico.

3. 03

   Repartir y revisar en lugar de construirlo todo

   Situación

   El producto crecía más rápido de lo que yo podía escribir y entraron dos developers al equipo.

   Qué decidí

   Repartir el trabajo por áreas, revisar sus pull requests y hacer pairing cuando hacía falta, en vez de quedarme con las partes difíciles.

   Por qué

   Si concentraba lo complicado, el equipo no llegaba a conocer el dominio y yo acababa siendo el cuello de botella.

   Qué cambió

   Los tres developers podíamos avanzar en paralelo, con áreas propias y decisiones de arquitectura discutidas en revisión. El producto dejó de depender de una sola persona para las partes difíciles.

Resultado

• Producto podía cambiar filtros y formularios sin abrir una tarea de desarrollo ni esperar a un despliegue.

  EvidenciaEl dashboard interno guardaba la configuración que consumían el producto de estudiantes y el portal de empresas.

• El monolito acortó los ciclos de producto porque modelado, backend e interfaz podían cambiar en la misma entrega.

  EvidenciaEl mismo Rails cubría desde los datos y la lógica de negocio hasta la interfaz y producción.

• Los tres developers trabajábamos en paralelo y el producto dependía menos de una sola persona.

  EvidenciaReparto por áreas, pull requests, pairing y decisiones de arquitectura compartidas en revisión.

• Lideré técnicamente el desarrollo y entregué funcionalidades completas desde el modelado hasta producción.

  EvidenciaRepartía el trabajo, revisaba las pull requests y mentoricé a los otros dos developers mientras seguía implementando.

Sobre las cifrasLas cifras de usuarios, la financiación y el alcance exacto de la infraestructura son de la empresa y no se publican aquí.