Retrospectiva — Tu evolución y preparación para FlashRoute

### De junior asustado a mid engineer con criterio

Hace diez meses estabas en FreshMart, nervioso porque María te pasaba un CSV con formatos raros y no sabías ni por dónde empezar. Hoy acabas de resolver un incidente de producción a las 3AM en un banco regulado por el Banco de España, has diseñado una arquitectura de feature store que un VP ha aprobado, y has escrito un proceso de supresión de datos que afecta a 2.1 millones de personas reales.

La progresión no ha sido lineal en el tiempo: los seis primeros meses te dieron diez puntos de autonomía, y la última semana te ha dado quince. Lo que se acelera no son los años, es lo que sacas de cada uno:

• ▹FreshMart (retail, meses 1-6): Aprendiste a trabajar con datos reales que siempre vienen sucios. A comunicarte con negocio sin jerga técnica. A que un CSV "final_v3_BUENO" es la norma, no la excepción.
• ▹TaskFlow (SaaS, meses 7-9): Aprendiste a pensar en eventos, cohortes y métricas de producto. A que los datos cuentan historias de comportamiento si sabes preguntarles. A lidiar con tracking roto.
• ▹AdPulse (marketing, mes 10): Aprendiste a integrar múltiples fuentes, reconciliar discrepancias y presentar a clientes exigentes. A que "los datos cuadran" es una decisión de ingeniería, no un hecho.
• ▹NeoBank (fintech, semana 1): Aprendiste streaming real-time, regulación, incident management y feature engineering para ML. A que los datos tienen consecuencias legales y financieras reales.

### Lo que NeoBank te enseñó que no está en ningún tutorial

• ▹Los ADRs son tu memoria institucional. Sin ellos, cada decisión se re-debate cada 3 meses con personas que no estuvieron en la reunión original.
• ▹GDPR no es un checkbox en un formulario — es un proceso de ingeniería real con consecuencias millonarias si lo haces mal.
• ▹Los incidentes no son fracasos — son oportunidades de aprendizaje Y de conseguir presupuesto para hacer las cosas bien.
• ▹Un feature store no es solo Redis + queries. Es arquitectura, governance, monitoring y un serving API con SLAs definidos.
• ▹Streaming no es "batch más rápido". Es un paradigma diferente con problemas propios: watermarks, exactly-once, data skew, late data.
• ▹Los stakeholders regulatorios (Sara) no son enemigos ni burócratas — son aliados que te mantienen fuera de problemas legales de millones.
• ▹La demo de sprint es tan importante como el código. Comunicar bien es una habilidad técnica que multiplica el impacto de tu trabajo.
• ▹Diseñar para el caso malo (skew, picos, bugs de terceros) es más importante que optimizar para el caso normal.

### Los cuatro niveles de «lo sé hacer»

Antes de escribir nada en un currículum o en un perfil, pásale a cada línea esta pregunta: ¿en qué nivel lo tengo?

1. 01.Lo he leído. Sabes que existe y para qué sirve. Vale para una conversación, no para una entrevista técnica. No va en el currículum.
2. 02.Lo he hecho una vez. Lo has implementado, funcionó, y podrías repetirlo mirando tus notas. Va en el currículum, y si te preguntan dices exactamente eso: «lo implementé una vez, en este contexto».
3. 03.Lo he operado. Ha estado corriendo en producción y has tenido que arreglarlo cuando se ha roto. Aquí es donde empiezas a tener opiniones propias, y las opiniones son lo que separa a un mid de un junior.
4. 04.Lo he enseñado. Se lo has explicado a alguien que después lo ha hecho solo. Es el nivel en el que descubres los agujeros de lo que creías saber.

### Skills técnicas adquiridas en NeoBank

• ▹Spark Structured Streaming: micro-batch, watermarks, exactly-once con checkpoints, ventanas deslizantes
• ▹Data skew: diagnóstico con datos reales, salting en dos fases (implementado)
• ▹Prevención de skew: circuit breaker por merchant y alertas de volumen (diseñado, pendiente de implementar — son dos de tus acciones del post-mortem)
• ▹GDPR/RGPD: inventario PII, anonimización irreversible, SHA-256 + salt efímero, compliance reports
• ▹Feature Store: arquitectura hot/warm/cold, Redis como serving layer, feature registry
• ▹ADRs: evaluar opciones con scoring, documentar trade-offs, defender ante ARB
• ▹Incident Management: PagerDuty, hotfix vs solución permanente, post-mortem blameless
• ▹Kafka: consumo de un topic con Spark, monitorización de consumer lag, deduplicación en el consumidor (no exactly-once del productor: eso es otra cosa)

### Preparación para FlashRoute

NeoBank te hizo sólido técnicamente. Sabes resolver problemas en producción con calma bajo presión, tomar decisiones de arquitectura justificadas con datos, y comunicarte con compliance sin que parezca una conversación de sordos. Pero hay algo que NeoBank no te dio: OWNERSHIP completo de un dominio.

Marcos, CTO de FlashRoute, te contactó por LinkedIn. FlashRoute es una empresa de logística de última milla — 1.000 repartidores, 100K envíos al día, datos GPS en real-time. Marcos te ofrece algo que NeoBank no puede: "Serás el owner del dominio de datos de tracking. No un contribuidor — EL responsable. Diseñas, implementas, operas, y decides la tecnología. Si funciona, es mérito tuyo. Si se cae, es tu problema."

Es el siguiente paso natural: de hacer bien lo que te piden (NeoBank) a decidir QUÉ se hace (FlashRoute). El reto ya no es "¿puedo implementar esto?" sino "¿qué debemos construir y por qué?". NeoBank te dio la base técnica. FlashRoute te dará la base de liderazgo técnico.