Currículum de arquitecto/a de software: ejemplos y guía para redactarlo

Este ejemplo es el de una arquitecta que viene de la ingeniería de backend y hoy define una plataforma que usan nueve equipos de producto. Los nombres de las empresas son inventados. Fíjate en que cada decisión de arquitectura de la página va acompañada de su consecuencia.

Contratar a un arquitecto es valorar su criterio, y el criterio es difícil de demostrar sobre el papel. Hay cuatro señales que hacen el trabajo.

• Escala y forma de lo que has diseñado. Usuarios, servicios, volumen de datos, equipos, ingenieros. Una herramienta interna de tres equipos y una plataforma multitenant de 60 servicios son trabajos distintos.
• Decisiones con motivos y consecuencias. Nombrar lo que elegiste, lo que descartaste y lo que pasó después es la prueba más clara de pensamiento arquitectónico en un currículum.
• Si sigues construyendo. La mayoría de las empresas quiere un arquitecto que programe y revise pull requests, no uno que solo dibuje diagramas. Di qué has puesto en producción recientemente.
• Influencia sin autoridad jerárquica. Los arquitectos rara vez dirigen a los equipos que implementan sus diseños. Los registros de decisiones, los procesos de revisión, la mentoría y las cifras de adopción demuestran que eres capaz de mover una organización.

“Enséñame una decisión que tomaste y resultó ser errónea, y qué hiciste al respecto. Todos los arquitectos en los que confío tienen una. Un currículum lleno de patrones de éxito y sin compromisos me dice que tuviste suerte o que en realidad no eras quien tomaba las decisiones.”

Cuatro líneas como máximo. Años, sector, escala, el mayor cambio que impulsaste y cuántos ingenieros trabajan sobre tu trabajo.

El fallo más habitual en un currículum de arquitecto/a es una lista de tecnologías elegidas sin explicar qué cambió.

Divídelas en diseño, tecnología y competencias organizativas. El tercer grupo es lo que distingue a un arquitecto de un ingeniero muy sénior.

• Diseño: compromisos en sistemas distribuidos, diseño guiado por el dominio y contextos delimitados, patrones orientados a eventos y de petición-respuesta, modelado de datos y elección del modelo de consistencia, diseño y versionado de API, caché e idempotencia, modos de fallo y degradación.
• Requisitos no funcionales: presupuestos de rendimiento, objetivos de disponibilidad, arquitectura de seguridad y modelado de amenazas, conservación de datos y privacidad (RGPD), recuperación ante desastres, modelado de costes y restricciones normativas de tu sector.
• Profundidad tecnológica: al menos un lenguaje que sigas escribiendo bien, una nube a fondo, orquestación de contenedores, al menos dos motores de base de datos y cuándo usar cada uno, y una plataforma de mensajería o streaming.
• Documentación y comunicación: registros de decisiones de arquitectura, C4 u otros modelos de diagramas similares, procesos RFC, análisis escrito de compromisos, presentaciones a la dirección y a ingenieros escépticos.
• Organización: moderación de revisiones de diseño, mentoría, planificación de migraciones, trabajo con proveedores y equipos de plataforma, saber decir que no con argumentos, secuenciar los cambios para que los equipos sigan entregando.
• Marcos que merece la pena nombrar si los usas: TOGAF en entornos corporativos, el modelo C4 para diagramas y las revisiones well-architected para cargas de trabajo en la nube.

A nivel de arquitecto/a, las pruebas de criterio pesan más que las acreditaciones. Aun así, los certificados tienen su papel en entornos corporativos y de consultoría, donde los clientes los piden.

• Los certificados de arquitectura cloud son los que más peso práctico tienen: AWS Certified Solutions Architect – Professional, Microsoft Certified: Azure Solutions Architect Expert y Google Professional Cloud Architect.
• La certificación TOGAF de The Open Group es habitual en arquitectura empresarial y en consultoras. Importa mucho más en grandes corporaciones y en proyectos para el sector público que en empresas de producto.
• Los certificados de Kubernetes y de seguridad ayudan si tu trabajo de arquitectura tiene mucho de plataforma o de seguridad.
• Titulaciones: lo habitual es un grado o una ingeniería en informática, pero no es imprescindible. Muchos arquitectos llegan desde la ingeniería sin título universitario, y a este nivel nadie queda descartado solo por la formación.
• Mejor que cualquier certificado: un artículo público sobre un diseño del que fuiste responsable, una charla en una conferencia, un proyecto open source o un registro de decisión anonimizado que puedas enseñar en una entrevista.

Dos páginas es lo normal para un/a arquitecto/a. La primera media página tiene que dejar claros la escala y el nivel de experiencia, porque es todo lo que lee un responsable de contratación con prisa antes de decidir.

• Empieza con un perfil profesional con cifras de escala. Usuarios, servicios, equipos, ingenieros, volumen de datos. Todo lo demás puede esperar.
• Usa el mismo título que la oferta: arquitecto/a de software, technical architect, arquitecto/a de aplicaciones, arquitecto/a de soluciones, principal engineer. Las empresas los usan para puestos que se solapan y los filtros son literales.
• Mantén un bloque sencillo de competencias para que coincidan las palabras clave, pero que no se coma la página. La credibilidad la aportan los logros.
• Una sola columna, sin diagramas dentro del currículum y sin fecha de nacimiento; la foto es opcional en España. Si quieres enseñar un diagrama, enlaza a un artículo.
• Para puestos corporativos y de consultoría, añade una línea breve por proyecto con el sector, el tamaño del equipo y la duración, porque en esos puestos se valora la variedad de contextos.