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

Un currículum para un desarrollador con unos siete años de experiencia, escrito como lo leen los responsables técnicos: el stack arriba y después qué puso en producción en cada empleo y a qué escala. El nombre y las empresas son inventados; las cifras son del tipo que puedes sacar de tus propios paneles y de tu historial de pull requests.

Un currículum de desarrollador lo leen dos personas, y cada una lo lee de forma distinta. Quien selecciona busca coincidencias de palabras. El responsable técnico valora el alcance. Tienes unos 15 segundos con cada una.

• Que el stack coincida, a la primera. Quien selecciona busca los lenguajes y frameworks de la oferta. Si el puesto pide React, TypeScript y AWS y en tu primera pantalla aparecen Angular y Azure, quedas fuera. Pon las competencias cerca del principio.
• Alcance: ¿qué tamaño tenía lo que hacías? Usuarios, peticiones por segundo, volumen de datos, número de servicios, tamaño del equipo. «Desarrollé API» no dice nada. «Desarrollé la API de ingesta que gestiona 2 millones de eventos al día» le dice a un responsable técnico qué nivel tienes.
• Pruebas de que pusiste cosas en producción. Un producto en funcionamiento, una ficha en una tienda de apps o un perfil de GitHub con commits reales. Los responsables técnicos hacen clic. Un enlace a GitHub con tres repositorios vacíos es peor que no poner enlace.
• Actualidad y trayectoria. ¿Tus mejores logros son de 2025 o de 2017? ¿Pasaste de desarrollador a ingeniero II y a sénior, o cambiaste de empresa cada 9 meses? Las estancias cortas necesitan una explicación de una palabra (contrato por proyecto, adquisición, despido).

“En diez segundos sé si alguien ha trabajado en un sistema real en producción. Está en las cifras: latencia, disponibilidad, usuarios, guardias. Los currículums que solo enumeran tecnologías parecen el temario de un bootcamp.”

La sección de competencias de un currículum de desarrollador es una tabla de consulta, no una lista para presumir. Agrupa por categorías para que quien selecciona encuentre React en un segundo, y pon solo aquello sobre lo que podrían entrevistarte hoy. Entre catorce y veinte elementos son más que suficientes.

• Escribe los nombres como los escribe la oferta: «Node.js», no «NodeJS»; «PostgreSQL», no «Postgres». La comparación del ATS suele ser literal.
• Quita lo que usaste una vez en 2018. Todo lo que aparece en el currículum puede salir en la entrevista.
• Nada de estrellas, barras ni porcentajes. Los responsables técnicos los ignoran y los ATS no los leen.
• Las competencias transversales van en los logros, como pruebas, no en la lista de competencias.

El patrón de un logro de desarrollador: qué construiste o cambiaste, la tecnología y una cifra que muestre el efecto (velocidad, fiabilidad, coste, adopción, productividad del equipo). Siete reescrituras a partir de trabajo típico de desarrollo:

Con dos o más años de experiencia profesional, la sección de proyectos es opcional y el enlace a GitHub solo merece la pena si el perfil está activo. Para estudiantes, recién titulados, personas que salen de un bootcamp o que cambian de carrera, la sección de proyectos es la sección de experiencia. Trátala como tal.

1. 1Elige dos o tres proyectos que funcionen de principio a fin y que puedas enseñar. Una URL desplegada vale más que un repositorio.
2. 2Escribe cada entrada como un empleo: nombre, descripción de una línea, el stack entre paréntesis y dos o tres logros con cifras (usuarios, registros, pruebas, tiempo de carga, estrellas).
3. 3Haz que el repositorio sea presentable: un README con una captura y los pasos de instalación, un historial de commits limpio y pruebas que se ejecuten. Los responsables técnicos leen primero el README.
4. 4Fija esos repositorios en tu perfil de GitHub y archiva los clones de tutoriales abandonados.
5. 5En contribuciones open source, enlaza la pull request aceptada, no solo el proyecto.

Tres líneas: puesto y años, el stack y el tipo de producto, y un resultado con una cifra. Olvídate del objetivo profesional salvo que no tengas ninguna experiencia profesional, e incluso entonces funciona mejor un perfil como el del primer ejemplo.

Las ofertas de desarrollador junior reciben cientos de candidaturas. Las que consiguen llamada hacen pensar al responsable técnico «esta persona ya ha construido cosas». Eso se demuestra con proyectos, prácticas y cualquier prueba de haber trabajado en el código de otros.

• Orden de la página: cabecera con enlace a GitHub, perfil breve, competencias agrupadas por nivel y después proyectos (dos o tres, con cifras) y prácticas. Si vienes de la universidad o de la FP, pon la formación con la fecha de finalización justo después del perfil; si vienes de un bootcamp o eres autodidacta, ponla cerca del final. Los empleos no tecnológicos, al final, con una o dos líneas cada uno.
• Las prácticas cuentan como experiencia. Indica el tipo de empresa, el equipo, el stack y lo que integraste. «11 pull requests aceptadas» es una cifra en la que un responsable técnico confía.
• Hackatones, concursos de programación y colaboraciones como ayudante docente tienen su sitio en la página, con resultados (puesto, participantes, estudiantes a tu cargo).
• Los empleos no tecnológicos demuestran fiabilidad: «Encargado de turno, cafetería, 2022–2024: formé a 6 nuevas incorporaciones y me encargué del arqueo de caja al cierre». Una o dos líneas.
• Deja fuera: el instituto, cada curso online que empezaste, un objetivo sobre querer «crecer y aprender». La foto es opcional. Una página, sin excepciones.

En los niveles sénior y staff la pregunta pasa de «¿sabes programar?» a «¿de qué fuiste responsable y a quién hiciste mejorar?». El stack sigue importando, pero baja en la página.

• Empieza por la responsabilidad: sistemas que diseñaste o de los que fuiste responsable técnico, con su escala (tráfico, ingresos que pasan por el sistema, equipos que dependen de él).
• Muestra trabajo entre equipos: RFC o documentos de diseño que escribiste, migraciones que dirigiste en varios equipos, decisiones sobre proveedores.
• Muestra tu impacto en las personas: ingenieros a los que has hecho de mentor, procesos de entrevistas que has dirigido, tiempo de incorporación reducido.
• Incluye cifras de coste y fiabilidad: gasto en cloud reducido, disponibilidad, tasa de incidencias, MTTR.
• Dos páginas están bien a partir de 10 años, pero el puesto actual debe seguir ocupando media primera página. Resume en una línea cada uno los puestos de hace más de 10 años.

Muchas empresas tecnológicas gestionan las candidaturas con Greenhouse, Lever, Workday o Ashby, que primero descomponen el currículum en campos. Las plantillas que quedan bien en pantalla a menudo se leen mal, y tu línea de competencias acaba en el campo de la dirección.

• Una página si tienes menos de 10 años de experiencia; dos como máximo a partir de ahí.
• Una sola columna, tipografía estándar, sin iconos, barras de nivel ni cuadros de texto. Las plantillas a dos columnas son la causa más habitual de que el ATS desordene el contenido.
• Nombres de sección estándar: Experiencia, Proyectos, Competencias, Formación.
• PDF con texto real llamado Nombre-Apellido-CV.pdf.
• Copia una vez cada término de la oferta: los nombres exactos de lenguajes y frameworks, «REST», «microservicios», «CI/CD», «pruebas unitarias», el proveedor cloud, «Agile» o «Scrum».
• Sin fecha de nacimiento, DNI, dirección completa (basta con la ciudad) ni «referencias disponibles a petición». La foto es habitual en España, pero opcional; en tecnología no suele aportar nada.

Pega la oferta en el comprobador ATS de cvplex junto con tu currículum. Te muestra qué términos del stack de la oferta faltan, si tu sección de competencias se ha leído como una sola y qué logros no tienen cifra.