Un reclutador dedica unos siete segundos a la primera pasada de un CV de desarrollador. Los que pasan ese filtro ya conocen el formato. Los que no, suelen caer por las mismas razones: una lista de frameworks sin contexto, un resumen que parece copiado del «Acerca de» de LinkedIn y viñetas que parafrasean el puesto en vez de contar lo que la persona realmente entregó.

Esta es la versión del CV que escribiría hoy para un puesto backend o full-stack en una empresa mediana. Funciona también para roles senior: la estructura no cambia, lo que cambia son las pruebas.

Empieza por lo que entregaste, no por lo que usaste

La parte de arriba del CV debe contestar una sola pregunta: qué construyó esta persona y si alguien lo usa. «Construyó un pipeline Kafka» no es un logro. «Construyó un pipeline Kafka que reemplazó un batch nocturno y bajó la latencia del estado de pedido de 20 minutos a menos de 30 segundos» sí lo es.

Tres reglas que aplico a cada viñeta:

1. Empezar con el verbo, no con la tecnología.
2. Incluir un número: usuarios, latencia, tasa de error, coste, lo que sea medible.
3. Cortar todo lo que solo reformule el título del puesto.

Las tecnologías van más abajo. Los reclutadores las repasan rápido, pero los managers técnicos leen primero las viñetas para decidir si sabes pensar.

Una estructura que funciona en 2026

Un CV de ingeniería de software en 2026 se parece a esto, de arriba abajo:

• Nombre, puesto buscado, ciudad, GitHub, portfolio, email. Sin foto.
• Un resumen breve: tres líneas máximo, escrito para el puesto al que aplicas.
• Experiencia en orden cronológico inverso, cuatro a seis viñetas por puesto.
• Proyectos seleccionados, solo si son públicos y recientes.
• Habilidades agrupadas (lenguajes, infra, herramientas).
• Formación y certificaciones, abajo.

Una página si tienes menos de cinco años de experiencia. Dos si eres senior o has lanzado productos que de verdad lo justifican. Tres páginas son para CVs académicos, no de ingeniería.

El resumen es la parte más difícil

La mayoría de los resúmenes de desarrolladores no dicen nada («desarrollador full-stack apasionado y con gran atención al detalle») o repiten cada tecnología dos veces. Un buen resumen se parece más a un posicionamiento: quién eres, qué has construido y qué buscas ahora.

Ingeniero backend con siete años en sistemas de pagos y contabilidad en fintech y marketplaces. Cómodo llevando un servicio de punta a punta, del esquema de base de datos hasta la guardia. Busco un puesto senior en un equipo pequeño, sobre una base de código que no sea un museo.

Es lo bastante específico para que el reclutador decida si sigue leyendo. Los resúmenes genéricos se saltan, incluso cuando la experiencia debajo es sólida.

Stack técnico: lista lo que entregarías el lunes

La sección de habilidades es donde más CVs de desarrolladores pierden credibilidad. Listar veinte lenguajes y cuarenta frameworks le dice al reclutador que no sabes cuáles usas en realidad. Lista el stack con el que estarías cómodo abriendo un pull request mañana. El resto, en una línea pequeña de «familiar con», si de verdad necesitas mencionarlo.

Agrúpalo para que un manager técnico escanee en dos segundos:

• Lenguajes: TypeScript, Go, Python
• Infra: AWS (ECS, Lambda, RDS), Terraform, Postgres, Kafka
• Herramientas: Datadog, Sentry, GitHub Actions

Nada de puntuaciones («Python ★★★★☆»). Nada de años por habilidad. Las dos cosas señalan falta de confianza.

Open source y proyectos personales

Un solo enlace a un repo de GitHub con un README limpio vale más que un párrafo sobre contribuciones open source. Si tienes un proyecto que demuestra ingeniería real, nivel producción, con tests, desplegado, pon el enlace y escribe una viñeta sobre qué hace y qué fue lo difícil. Olvídate de los diecisiete forks de tutoriales.

La misma vara para los proyectos personales: lo usa alguien que no eres tú, o te enseñó algo que no podías aprender en el trabajo. Si no, es ruido.

La realidad ATS para un CV de desarrollador

Casi todos los equipos de ingeniería usan un ATS, incluso los que dicen que no. El CV tiene que sobrevivir al parser antes de que lo lea un humano. En la práctica:

• PDF de salida, pero generado desde texto (no imágenes escaneadas).
• Una sola columna. Dos columnas confunden a la mayoría de parsers.
• Encabezados estándar (Experiencia, Habilidades), sin variantes creativas.
• Las palabras clave de la oferta dentro de tu experiencia real, no metidas en un pie de página.

Si vienes de pasar un perfil de LinkedIn a CV, Postulit se ocupa de la estructura y la capa ATS para que tú te centres en reescribir las viñetas.

Qué cortar

Una lista corta de cosas que ocupan espacio sin generar entrevistas:

• Los hobbies, salvo que sean directamente relevantes (mantienes una librería conocida, organizas un meetup).
• La foto. Es estándar en algunos mercados europeos, pero añade sesgo y ruido para el ATS.
• «Referencias disponibles a petición.» Se sobreentiende.
• La lista de todas las certificaciones que has hecho. Quédate con dos.
• Las soft skills como sección aparte. Demuéstralas en las viñetas.

El objetivo del CV es llegar a la llamada inicial, no comprimir toda una carrera en una hoja. Todo lo que no acerque al lector a agendar esa llamada está ocupando un sitio que otra cosa podría usar.