Un currículum de desarrollador se lee dos veces: primero por un reclutador que comprueba el stack, la antigüedad y los nombres de empresa, y después por un lead técnico que busca pruebas de impacto real: latencia reducida, incidentes evitados, costes de infraestructura recortados. El ejemplo de abajo está construido para sobrevivir a ambas lecturas: cada viñeta nombra una tecnología concreta y un resultado medido.
La trampa clásica del currículum de desarrollador es la lista de responsabilidades («desarrollo y mantenimiento de APIs») que describe a todos los desarrolladores del mercado. La estructura correcta: verbo, tecnología, escala, resultado. «Migración de RabbitMQ a Kafka en un pipeline de 40 millones de peticiones al día, latencia p99 reducida un 38 %» dice en una línea lo que diez líneas de responsabilidades no dirán nunca.
En cuanto a la forma, quédese en una sola columna y con apartados estándar: las plataformas de selección tech analizan el currículum automáticamente antes de que lo lea un humano, y las maquetaciones con columnas o iconos pierden información en la extracción. Puede comprobar lo que un programa de filtrado extrae de su currículum con nuestro análisis ATS.
Nombre sus tecnologías en su forma literal. Los filtros buscan «Go», «Kafka», «Terraform», «PostgreSQL»: escriba los nombres exactos, agrupados por familias (lenguajes, infraestructura, prácticas), y mantenga la lista honesta: cada tecnología listada debe ser defendible en la entrevista. Un proyecto open source con tracción real (estrellas, usuarios, contribuciones) vale tanto como una experiencia: dele una entrada dedicada con las mismas viñetas cuantificadas.
Adapte el currículum a cada oferta en diez minutos. Reordene los grupos de competencias para que el stack pedido aparezca primero, ajuste la primera frase del resumen y compruebe que sus tres primeras viñetas cubren lo que la oferta lista en primer lugar. Los reclutadores tech españoles leen también los títulos en inglés (backend, DevOps, data): conserve los términos técnicos ingleses habituales, nadie busca «macrodatos».
Cuantifique según el tipo de empresa, porque cada entorno valora una escala distinta. En una startup o scaleup, cuentan la amplitud y la velocidad: funcionalidades entregadas de punta a punta, decisiones tomadas con poca supervisión, sistemas montados desde cero. En una empresa de producto consolidada, mandan la escala y la fiabilidad: tráfico, disponibilidad, incidentes, coste de infraestructura. En una consultora o en servicios, pesan la variedad de contextos, la relación con el cliente y la capacidad de entrar rápido en código ajeno. Y en banca o sectores regulados, la trazabilidad y los tests. El mismo trabajo se presenta con métricas distintas: elija las del entorno al que aspira, no las del que deja.
Evite los errores típicos del currículum de desarrollador. La nube de veinte tecnologías sin nivel ni contexto, que diluye las cinco que domina de verdad; las responsabilidades sin resultado («desarrollo de nuevas funcionalidades»), que describen el contrato y no el desempeño; las métricas sin base («optimicé el rendimiento») que un lead técnico descarta igual que un porcentaje sin denominador; el proyecto open source enterrado al final cuando es su mejor prueba; y la experiencia contada por herramientas en lugar de por problemas resueltos. Un error más caro de lo que parece: listar una tecnología que no podría defender en entrevista, porque en tech la entrevista técnica verifica el currículum línea a línea.
La carta de presentación en tech: corta o inexistente, pero nunca genérica. Muchos procesos tech prescinden de ella; cuando se pide, o cuando escribe directamente a un CTO o a un lead, el formato que funciona es el de un mensaje técnico: tres frases sobre por qué ese producto o ese problema le interesa (con una observación específica que demuestre que miró de verdad), dos líneas con su logro más pertinente para su stack, y una propuesta de siguiente paso. El modelo entusiasta y genérico se descarta en segundos; la nota corta y específica consigue respuestas incluso sin oferta publicada. Si la empresa trabaja en inglés, escríbala en inglés.
El currículum evoluciona con la carrera, y las variantes de resumen de más abajo recorren los tres niveles. Al principio, venda los proyectos con código consultable, las prácticas con impacto medido y la base técnica (grado, ciclo de FP de desarrollo de aplicaciones o bootcamp con proyectos serios). En mitad de carrera, mandan la escala de los sistemas operados y los resultados de producción. En el nivel sénior, lo que diferencia es el efecto multiplicador: arquitecturas que otros equipos adoptan, mentoría con resultados, decisiones técnicas argumentadas por escrito, incidentes mayores gestionados. Ese material es el que abre las entrevistas de staff engineer o de lead.
Use esta página de forma activa. El botón «Usar este ejemplo» abre el currículum completo en nuestro editor para sustituir stack, escala y logros por los suyos; el banco de viñetas da estructuras probadas para los impactos difíciles de formular; la lista de palabras clave se compara con cada oferta antes del envío; y las preguntas del final tratan los casos reales (GitHub, reconversión, inglés, huecos) que deciden las candidaturas tech.
Preguntas frecuentes
- ¿Hay que poner el GitHub en un currículum de desarrollador?
- Sí, si el perfil muestra algo: un proyecto con tracción, contribuciones regulares o código representativo de su nivel. Un enlace a un perfil vacío perjudica más de lo que ayuda. Si tiene un proyecto open source significativo, dele una entrada dedicada en el currículum con viñetas cuantificadas (estrellas, usuarios, problema resuelto): suele ser la línea de la que el lead técnico habla primero en la entrevista.
- ¿Un currículum de desarrollador debe caber en una página?
- Una página sigue siendo el objetivo hasta los 8 o 10 años de experiencia: los reclutadores tech leen rápido y un currículum denso de una página se compara favorablemente con dos páginas diluidas. Cuando falte espacio, reduzca los puestos antiguos a una línea, conserve 4 o 5 viñetas en el puesto actual y 3 en el anterior, y elimine las tecnologías que ya no quiera practicar: cada tecnología listada es una invitación a que le pregunten por ella.
- ¿Cómo presentar una reconversión hacia el desarrollo?
- Empiece por lo verificable: formación (grado, bootcamp, ciclo de FP de desarrollo de aplicaciones, autoformación estructurada), proyectos reales con código consultable y, si es posible, una primera experiencia aunque sea corta (prácticas, contrato de formación, freelance). Suba el apartado de proyectos por encima de la experiencia no técnica y conecte su antiguo oficio con el nuevo cuando tenga sentido: un excontable que automatiza conciliaciones en Python cuenta una historia coherente. El resumen debe anunciar la reconversión en una frase en lugar de dejar que se adivine.
- ¿Conviene redactar el currículum en español o en inglés?
- Siga el idioma de la oferta. Una oferta redactada en inglés, incluso para un puesto en España, espera generalmente un currículum en inglés; una oferta en español espera un currículum en español con los términos técnicos habituales en inglés. Si aspira a ambos mercados, mantenga las dos versiones al día: nuestro editor permite duplicar un currículum y cambiarle el idioma sin empezar de cero.
- ¿Cómo presentar un hueco en la trayectoria en un currículum de desarrollador?
- Con una línea fechada en su lugar cronológico y, si es posible, con código que la respalde. La tech es de los pocos sectores donde una pausa puede documentarse con trabajo verificable: un repositorio activo durante el periodo, una migración de stack completada, contribuciones open source fechadas. «2023-2024: cuidado familiar; transición de Java a Go con un proyecto de replicación de datos publicado» convierte el hueco en una prueba de iniciativa. Si la pausa fue total, no la disfrace: una línea honesta genera menos dudas que un silencio que el lector rellenará solo. En la entrevista, dos frases serenas bastan; después devuelva la conversación a sus sistemas en producción, que es donde se decide la contratación.
- ¿Merecen la pena las certificaciones (AWS, Kubernetes) en el currículum?
- Depende de lo que compensen. Una certificación pesa cuando cubre un hueco de experiencia demostrable: el desarrollador de consultora que aspira a un puesto cloud sin haber operado AWS en producción gana credibilidad con una certificación de arquitecto; el que ya opera Kubernetes a diario no necesita el certificado para demostrarlo, sus viñetas lo hacen mejor. Si las lista, hágalo con el nombre oficial completo y el año («AWS Certified Solutions Architect Associate, 2025»), porque los filtros buscan la denominación literal. Y colóquelas después de la experiencia, nunca antes: en tech, la producción real manda sobre cualquier credencial, y un currículum que abre con certificaciones sugiere lo contrario.
- ¿Cómo presentar la experiencia freelance o los proyectos propios?
- Como experiencia de pleno derecho, con las mismas viñetas cuantificadas que un puesto asalariado. Un periodo freelance se titula con el rol y el marco («Desarrollador backend freelance, 2023-2025») y se cuenta por resultados de cliente: sistemas entregados, escala alcanzada, mantenimiento asumido. Un proyecto propio con tracción real merece una entrada dedicada: usuarios, peticiones diarias, estrellas si son significativas, y el problema que resuelve en una frase. Lo que debe evitar: la lista de diez proyectos de fin de semana sin usuarios, que diluye el que sí importa. Uno o dos proyectos vivos y medibles valen más que un portafolio extenso de demos, y son de lo primero que un lead técnico abre antes de la entrevista.
- ¿Cuántas tecnologías conviene listar y cómo indicar el nivel?
- Las que pueda defender en una entrevista técnica, agrupadas por familias y ordenadas por dominio real: lenguajes, después infraestructura, después prácticas. Entre ocho y quince entradas suele ser el equilibrio correcto; a partir de veinte, la lista deja de informar y empieza a diluir. Para el nivel, evite las barras de progreso y los porcentajes, que los programas de extracción pierden y los lead técnicos no se creen: el nivel se demuestra por la posición en la lista y por las viñetas de experiencia que usan cada tecnología. Si quiere marcar una distinción, sepárela con palabras («uso diario», «en producción desde 2022») en lugar de gráficos. Y retire las tecnologías que ya no quiera practicar: cada línea del apartado es una invitación a preguntar por ella.
- ¿Se puede conseguir un puesto de desarrollador sin título universitario?
- Sí, y el mercado español lo confirma cada año: el ciclo superior de FP en Desarrollo de Aplicaciones (DAM o DAW), los bootcamps con proyectos serios y la autoformación documentada colocan desarrolladores en empresas de producto y consultoras. Lo que cambia sin el grado es la carga de la prueba: el currículum debe abrir con código consultable y resultados medidos, no con la formación. Suba el apartado de proyectos por encima del de estudios, cuantifique todo lo que pueda (usuarios, peticiones, cobertura de tests) y prepare las entrevistas técnicas con más margen, porque serán su verdadero título. Algunas grandes empresas y organismos públicos mantienen el requisito formal; las startups y las scaleups, que concentran la mayor parte de las ofertas backend, casi nunca.