CV de Programador y Desarrollador: Plantilla Gratis para Descargar y Modificar

Un CV de programador funciona cuando, en una sola pantalla, deja claras tres cosas: qué construyes, con qué tecnologías y qué pasó gracias a ello. Todo lo demás (el diseño, la foto, la lista de aficiones) es secundario. La plantilla que descargas arriba te da la estructura montada; lo que decide si te llaman es lo que escribes dentro de ella, y a eso dedicamos el resto de la página.

Qué es exactamente el archivo que te descargas

Conviene decirlo antes que nada, porque en el sector abundan las páginas que prometen «quince diseños exclusivos» y entregan el mismo documento con quince nombres. Lo que hay detrás del botón es un único archivo, cv-programador.docx, redactado para un perfil de desarrollo: el titular pone «Programador/a · Desarrollador/a de software», el perfil profesional deja el hueco para elegir entre frontend, backend o full-stack, las viñetas de experiencia hablan de API, módulos, revisiones de código, CI/CD y despliegues en cloud, y las competencias vienen agrupadas en lenguajes, frameworks, bases de datos y herramientas.

No es una maqueta gráfica con columnas de color ni un diseño de agencia. Es una base sobria, en una sola columna, pensada para que la rellenes en diez minutos, se lea bien impresa y se deje analizar sin problemas por el software que usan las empresas para recibir candidaturas. Si buscabas un diseño más vistoso, tienes otras opciones en la categoría: plantillas de CV en Canva si te interesa la parte visual, o la plantilla de CV en Word genérica si prefieres partir de cero.

Una plantilla no consigue entrevistas. Lo que consigue entrevistas es que alguien lea tu experiencia y entienda, sin esforzarse, qué problema sabes resolver. La plantilla solo se encarga de que ese texto no se lea mal.

Qué busca de verdad quien selecciona perfiles técnicos

En un proceso de desarrollo hay normalmente dos filtros con criterios distintos, y el CV tiene que sobrevivir a los dos. El primero lo hace alguien de selección que no programa: busca señales reconocibles y comprobables. ¿Cuántos años lleva en esto? ¿Ha trabajado con la tecnología que pide la oferta? ¿Ha estado en empresas parecidas a la nuestra? ¿Los saltos de empresa tienen sentido? ¿Vive donde necesitamos o el puesto es remoto? Esa lectura dura poco y se hace en diagonal, así que lo que no está en el primer tercio de la primera página casi no existe.

El segundo filtro lo hace alguien del equipo técnico, y ahí cambian las preguntas. ¿Este perfil ha construido cosas o ha tocado cosas? ¿Sabe de qué habla cuando dice «arquitectura de microservicios» o lo ha copiado de la oferta? ¿Hay algún indicio de que se preocupe por las pruebas, por el rendimiento, por la mantenibilidad? ¿Aparece algún número que no sea el año de contratación? Un CV que aguanta esta segunda lectura es un CV con verbos concretos y resultados, no con adjetivos.

De ahí sale la regla que ordena todo lo demás: cada línea del currículum tiene que ser defendible en una entrevista técnica. Si has puesto Kubernetes porque desplegaste una vez con un manifiesto que te dieron hecho, lo vas a pasar mal en la primera pregunta. Si has puesto que redujiste el tiempo de carga de una pantalla, prepárate para explicar cómo lo mediste. Es un filtro sencillo y aplicarlo antes de enviar el archivo ahorra sustos.

La diferencia entre «tareas» y «resultados»

Casi todos los CV de desarrollo que se descartan comparten el mismo defecto: describen el puesto en lugar de describir a la persona. «Desarrollo de aplicaciones web con React» es la descripción del puesto; la ha escrito recursos humanos en la oferta de trabajo original y no aporta nada. «Reescribí el buscador de producto en React reduciendo el tiempo de respuesta percibido y bajando las incidencias de soporte del módulo» describe a la persona. Cuesta más redactarlo, pero es la diferencia entre un archivo que se lee y uno que se archiva.

Estructura del CV, bloque a bloque

El orden de la plantilla no es caprichoso. Responde a cómo se lee un documento en pantalla: de arriba abajo y con la atención cayendo en picado a partir del primer tercio. Estos son los bloques y qué debe ir en cada uno.

1. Encabezado y datos de contacto

Nombre en grande, y justo debajo el puesto al que te presentas, no el que tienes ahora. Si la oferta busca «Backend Developer» y tu cargo interno es «Analista Programador II», escribe «Desarrollador backend». No estás mintiendo: estás traduciendo. Debajo, una sola línea con ciudad, teléfono, correo y enlaces. La ciudad basta; la calle y el número no pintan nada en un currículum y añaden un dato personal que nadie necesita para valorarte.

El correo, con tu nombre. Si arrastras una cuenta de la adolescencia, abre una nueva: es gratis y evita empezar con mal pie. Los enlaces (LinkedIn, GitHub, portfolio) van escritos completos si el CV se va a imprimir, y como hipervínculo si va en PDF. Y ojo con un detalle que se pasa por alto: si exportas mal el PDF, los enlaces dejan de funcionar y quien lee no puede llegar a tu repositorio. Compruébalo abriendo el PDF final y haciendo clic.

Nacionalidad, estado civil, fecha de nacimiento y número de documento no van en el CV. Ni siquiera son útiles: son datos personales que no aportan a la valoración profesional y que, una vez enviados, quedan almacenados en el sistema de la empresa. Si el proceso los necesita, ya te los pedirán en la fase de contratación.

2. Extracto o perfil profesional

Tres o cuatro líneas, no más. Es el único párrafo del documento que se lee entero, así que tiene que contener lo que quieres que recuerden: especialidad, años, tipo de producto y una nota diferencial. «Desarrolladora backend con seis años construyendo APIs de alto tráfico para comercio electrónico. Trabajo sobre todo con Python y PostgreSQL, y me ocupa especialmente que el sistema siga siendo comprensible dentro de dos años.» Eso, adaptado a ti, hace más que media página de habilidades genéricas.

Lo que no funciona: «profesional proactivo, dinámico y con alta capacidad de trabajo en equipo». Nadie escribe lo contrario, así que esas palabras no distinguen a nadie. Si quieres transmitir que trabajas bien en equipo, demuéstralo en la experiencia contando que llevabas las revisiones de código o que hiciste de mentor de dos incorporaciones.

El extracto se reescribe para cada tipo de oferta. No para cada oferta, que es inviable si envías veinte al mes, pero sí para cada familia: una versión backend, una versión full-stack, una versión de datos. Con tres versiones guardadas cubres casi todo.

3. Stack tecnológico

En un CV de desarrollo este bloque puede ir antes o después de la experiencia. Antes, si tu argumento principal es la tecnología (perfiles junior, cambios de stack, ofertas muy específicas). Después, si tu argumento principal es la trayectoria (perfiles senior con producto reconocible). La plantilla lo coloca detrás de la formación, pero moverlo es cuestión de cortar y pegar el bloque entero.

La organización que mejor funciona es por familias y en orden de dominio real: lenguajes, frameworks y librerías, bases de datos, infraestructura y entrega, y herramientas de trabajo. Dentro de cada familia, primero lo que dominas. Quien lee escanea la primera palabra de cada línea, y si la primera es la que buscaba, sigue leyendo.

4. Experiencia profesional

Orden cronológico inverso, siempre. Cada entrada con puesto, empresa, ciudad y periodo en mes y año. Si hubo un hueco entre empleos, mejor que se vea y esté explicado en una línea (formación, proyecto propio, excedencia) que dejar al lector calculando. Debajo, entre dos y cuatro viñetas. Nunca un párrafo corrido: en un bloque de texto denso no se distingue lo importante.

Si has estado mucho tiempo en la misma empresa con distintos cargos, agrupa bajo el nombre de la empresa y detalla las etapas. Muestra progresión, que es una señal que quien selecciona valora mucho. Y si vienes de consultoría con veinte clientes, no listes veinte: agrupa por tipo de proyecto y destaca tres o cuatro que tengan que ver con la oferta.

5. Proyectos y repositorio

Este bloque es el que más diferencia un CV técnico de uno genérico, y el que peor se aprovecha. Dos o tres proyectos, cada uno con una línea de qué es, una de con qué está hecho y una de qué resolvía o qué aprendiste. Con enlace directo al repositorio o a la demo, no al perfil general.

6. Formación

Titulación, centro y año. En desarrollo, la formación pierde peso a medida que ganas experiencia: con ocho años trabajando, la carrera es una línea al final. Con dos años, la formación sube y se detalla algo más. El bootcamp se pone con su nombre y su duración real, sin disfrazarlo: quien selecciona en tecnología conoce los bootcamps y no le molestan, lo que le molesta es la ambigüedad.

Las certificaciones van aquí o en un bloque propio si son varias. Pon la fecha de obtención y, si caducan, la de vencimiento. Y modera la lista: veinte cursos de plataforma en línea no suman, restan, porque diluyen las dos certificaciones que sí importan.

7. Idiomas

En desarrollo, el inglés es el idioma de trabajo aunque la empresa sea española: la documentación, los mensajes de error y la mitad de las reuniones con proveedores están en inglés. Indica el nivel con el marco europeo (B2, C1) o con una descripción funcional honesta del tipo «lectura técnica fluida, conversación de trabajo con soltura». Lo que no conviene es inflarlo: si pones C1 y la entrevista da un giro al inglés a los cinco minutos, el problema es tuyo.

Cómo describir la experiencia sin inflarla

La fórmula que mejor aguanta la lectura técnica tiene tres piezas: verbo de acción, qué construiste con qué, y qué cambió. Las tres en una línea de no más de dos renglones. Verbos que funcionan: desarrollé, migré, rediseñé, automaticé, reduje, integré, refactoricé, documenté, desplegué, instrumenté. Verbos que no dicen nada: participé, colaboré, apoyé, me encargué de, formé parte de.

El «qué cambió» es la parte difícil, porque no siempre tienes un número. Si lo tienes, úsalo con precisión: no «mejoré el rendimiento un 60 %» a ojo, sino «bajé el tiempo de respuesta del endpoint de checkout de dos segundos a menos de medio en el percentil 95». Si no lo tienes, hay alternativas honestas: el alcance («servicio usado por los 40 comerciales de la red»), el efecto cualitativo («eliminé el despliegue manual de los viernes, que era la fuente habitual de incidencias») o el aprendizaje, cuando eres junior.

Inventar cifras es un mal negocio. En la entrevista técnica te van a preguntar cómo lo mediste, con qué herramienta y sobre qué carga, y una cifra inventada se desmonta en dos preguntas. Un CV sin números pero con alcance real se defiende. Uno con números inventados, no.

Regla práctica antes de enviar: lee cada viñeta en voz alta y pregúntate «¿y qué?». Si la respuesta no aparece en la propia línea, esa línea está incompleta.

Antes y después, con ejemplos

El stack tecnológico: cómo ordenarlo y qué dejar fuera

La lista interminable de tecnologías es el vicio más extendido en los CV de desarrollo. Treinta y cinco nombres separados por comas, mezclando un lenguaje que dominas con una herramienta que abriste una tarde. El efecto es el contrario del buscado: quien lee no puede distinguir qué sabes de verdad y termina asumiendo que nada del todo.

Hay un criterio simple para decidir qué entra: entra lo que sabrías usar mañana en un proyecto real sin volver al tutorial. Todo lo demás se queda fuera o, si de verdad importa para la oferta, se marca como «en aprendizaje» y se acompaña de un proyecto que lo demuestre. Ser explícito sobre el nivel es una señal de madurez profesional, no una debilidad.

Sobre las barras de porcentaje y las estrellitas: no aportan información. Un 80 % en Python no significa nada, porque no hay escala. Si necesitas indicar nivel, hazlo con palabras: «uso diario», «proyectos en producción», «nivel de mantenimiento», «he trabajado con ello puntualmente». Además, esas barras son gráficos y en muchos analizadores desaparecen sin dejar rastro, con lo que pierdes la información dos veces.

Una forma de agrupar que se lee bien

Portfolio, GitHub y lo que se abre de verdad

Un enlace al repositorio en el encabezado es casi obligado en desarrollo, con una condición: que haya algo detrás. Un perfil con tres repositorios abandonados de un curso, sin descripción y sin README, resta puntos respecto a no poner nada. Antes de enlazarlo, entra como si fueras un desconocido y mira qué se ve en los primeros diez segundos.

Lo que hace que un repositorio sume: un README que explique en cinco líneas qué hace el proyecto, cómo se levanta y qué decisiones técnicas tomaste; el código organizado; algo de pruebas, aunque sean cuatro; y un historial de commits con mensajes legibles. No hace falta un proyecto enorme. Una utilidad pequeña, terminada y bien documentada demuestra más criterio que un clon de una red social a medio hacer.

Si trabajas en proyectos cerrados y no puedes publicar nada, dilo. «Código de cliente sujeto a confidencialidad» es una frase que todo el mundo entiende, y puedes compensar describiendo la arquitectura y las decisiones sin exponer implementación. También puedes fijar en el perfil una prueba técnica antigua ya entregada, si el proceso terminó y no hay restricción.

Sobre el portfolio web: en desarrollo backend es opcional; en frontend y en interfaz de usuario, casi imprescindible, porque el trabajo se ve. Si lo montas, que cargue rápido y funcione en móvil, que es lo primero que va a comprobar cualquiera del oficio. Un portfolio de frontend lento es un argumento en tu contra.

CV de junior sin experiencia frente a CV de senior

Los dos usan la misma plantilla pero con el peso repartido de forma distinta. El error del junior es intentar parecer senior rellenando con paja; el error del senior es seguir escribiendo como cuando buscaba su primer empleo, con listas de cursos y descripciones de tareas rutinarias.

Si estás en el primer caso, la página de CV para primer empleo desarrolla cómo montar el documento cuando la experiencia laboral todavía no existe. Y si vienes de otro sector y has hecho un bootcamp, tu argumento no es «he estudiado programación», sino lo que aportas por venir de donde vienes: si eras contable y ahora haces backend en una fintech, conoces el dominio mejor que la mayoría del equipo.

Adaptar el CV a tu especialidad

«Programador» es una etiqueta demasiado ancha. La misma plantilla sirve para todas las ramas, pero lo que se pone en el extracto, en el stack y en las viñetas de experiencia cambia bastante según a qué te dediques.

Frontend

Aquí el trabajo se ve, así que el portfolio pesa más que en ninguna otra rama. Habla de accesibilidad, de rendimiento percibido, de diseño adaptable y de sistemas de componentes. Si has trabajado con métricas de experiencia de carga, menciónalo con el nombre de la métrica y cómo la medías. Y si colaboras bien con diseño, cuéntalo: es una habilidad escasa y muy buscada.

Backend

El argumento es la fiabilidad. Diseño de API, modelado de datos, colas y procesos asíncronos, control de errores, idempotencia, migraciones sin cortar servicio. Si has tocado sistemas con carga real, di el orden de magnitud del tráfico o del volumen de datos; no hace falta precisión de informe, basta con que se entienda la escala.

Móvil

Indica si trabajas en nativo, en multiplataforma o en ambos, y menciona las aplicaciones publicadas con enlace a la tienda si son públicas. Los detalles que interesan aquí son el ciclo de publicación, la gestión de versiones antiguas, el trabajo sin conexión y el consumo de batería y datos, que es donde se separa a quien ha publicado de quien ha hecho prototipos.

Datos e inteligencia artificial

Diferencia con claridad si haces ingeniería de datos, análisis o modelos, porque son oficios distintos con el mismo nombre comercial. Menciona el tamaño y la naturaleza de los datos, las herramientas de orquestación y qué decisiones de negocio se tomaron con tu trabajo. Un modelo que nunca llegó a producción vale mucho menos que uno mediocre que sí llegó, y quien selecciona lo sabe.

DevOps y plataforma

Aquí importa el antes y el después: tiempos de despliegue, frecuencia de entrega, tiempo de recuperación ante incidencias, coste de infraestructura. Menciona la infraestructura como código, la observabilidad y las guardias si las has hecho. Y si has reducido la factura de la nube, dilo en porcentaje o en orden de magnitud, que es un argumento que abre puertas.

Calidad y pruebas

Distingue entre pruebas manuales y automatizadas, y nombra el nivel en el que trabajas: unitarias, de integración, de extremo a extremo, de carga. Cuenta qué encontraste y qué se evitó gracias a ello. Un perfil de calidad que sabe programar sus propias pruebas y montar el pipeline es muy demandado, así que si es tu caso, que se vea en el extracto y no enterrado en la tercera viñeta.

Compatibilidad con los sistemas de recepción de candidaturas

Cuando envías el CV a través del portal de empleo de una empresa mediana o grande, lo más probable es que el archivo aterrice en un ATS, que es el software con el que la empresa recibe, ordena y busca entre las candidaturas. Herramientas como Workday, SAP SuccessFactors, Greenhouse o Teamtailor hacen básicamente lo mismo: extraen el texto de tu archivo y lo reparten en campos estructurados.

Conviene desmontar aquí un mito muy repetido. Circulan por internet cifras del tipo «el 75 % de los currículums se descarta automáticamente antes de que los vea una persona». Esas cifras no tienen una fuente comprobable y se repiten de artículo en artículo sin que nadie llegue al estudio original. Lo que sí es comprobable es más aburrido y más útil: si el análisis del archivo sale mal, el perfil queda incompleto en el sistema, y un perfil incompleto pierde contra uno completo cuando alguien busca por tecnología. El objetivo no es engañar a una máquina, es que tu texto llegue entero.

Lo que hace bien un archivo analizable

• Texto seleccionable. Abre tu PDF y prueba a seleccionar el nombre con el ratón. Si no puedes, es una imagen y no hay nada que analizar.
• Encabezados con nombres reconocibles. «Experiencia profesional», «Formación», «Competencias». Los títulos creativos del tipo «Mi viaje» obligan al sistema a adivinar.
• Una sola columna, o dos hechas con tabla. Las columnas construidas con cuadros de texto flotantes se leen en un orden impredecible.
• Nada importante en la cabecera o el pie de página. Es el lugar donde más a menudo se pierden el teléfono y el correo.
• Fuentes estándar. Arial, Calibri, Helvetica, Times, Georgia. Las fuentes decorativas descargadas se sustituyen y descolocan la página.
• Sin iconos como sustituto del texto. Un icono de sobre no dice «correo electrónico»; pon la palabra o, al menos, que el dato esté escrito al lado.
• Fechas en formato consistente. «03/2022 – 06/2024» en todas las entradas, sin mezclar «marzo 2022» con «2022-03».
• Nombre de archivo limpio. Sin acentos, sin espacios, sin caracteres extraños. nombre-apellido-cv-backend.pdf.

Sobre las palabras clave: la recomendación sensata es usar el mismo vocabulario que la oferta cuando describe algo que de verdad haces. Si la oferta dice «TypeScript» y tú has escrito «TS», escribe las dos. Si dice «integración continua» y tú has puesto solo «CI/CD», pon ambas la primera vez. Lo que no funciona, y además queda fatal cuando lo ve una persona, es pegar un bloque de palabras clave en blanco sobre blanco al final del documento: los sistemas lo extraen igual y quien lee lo detecta al instante.

Word o PDF, según el destino

Prueba de un minuto antes de enviar: abre tu PDF, selecciona todo el texto, cópialo y pégalo en un bloc de notas. Lo que veas ahí es, más o menos, lo que verá el sistema de la empresa. Si el orden es un caos o falta el teléfono, ya sabes qué arreglar.

La carta de presentación

En desarrollo no siempre se lee, pero cuando el formulario deja un campo de texto libre, dejarlo vacío es desaprovechar el único hueco donde puedes explicar algo que el CV no cuenta. Media página, cuatro párrafos cortos: por qué esa empresa en concreto, qué parte de tu experiencia encaja con lo que piden, un ejemplo breve que lo demuestre y un cierre sin florituras.

La carta es especialmente útil en tres situaciones: cuando cambias de especialidad o de sector y hay que explicar el salto; cuando hay un hueco largo en el currículum; y cuando la empresa te interesa de verdad y puedes demostrar que has mirado su producto. Ese último caso es el que más funciona: mencionar algo concreto de lo que hacen te separa del envío masivo.

Si quieres una base sobre la que escribir, tienes la plantilla de carta de presentación y, para procesos donde toca argumentar la motivación con más espacio, la carta de motivación.

Errores que más se repiten en los CV de desarrollo

1. El muro de tecnologías. Treinta nombres seguidos. Quien lee no sabe cuáles dominas y deja de intentarlo.
2. Copiar la oferta. Describir el puesto en lugar de describir lo que hiciste dentro de él.
3. Barras de porcentaje. No informan, y muchos analizadores las pierden.
4. Enlazar un repositorio vacío. Peor que no enlazar nada, porque invita a comprobarlo.
5. Diseño por encima del contenido. Una plantilla espectacular con tres líneas de contenido real no engaña a nadie.
6. Datos personales de más. Documento de identidad, estado civil, dirección completa. Ni se piden ni ayudan.
7. El mismo CV para todo. Cambiar el extracto y reordenar el stack según la oferta lleva cinco minutos y se nota.
8. Erratas en los nombres de las tecnologías. «Javascript» con jota minúscula, «MySql», «Github». En un perfil técnico, detalle que se ve.
9. Correos y enlaces rotos. Comprueba cada enlace del PDF final antes de enviarlo.
10. Inflar el nivel de idiomas. Se descubre en los primeros cinco minutos de la primera entrevista.
11. Nombres de archivo descuidados. cv_final_v3_definitivo.pdf llega tal cual a la bandeja de quien selecciona.
12. Enviarlo sin releerlo en frío. Déjalo reposar una noche; las erratas aparecen solas al día siguiente.

Cómo editar y exportar el archivo

El documento es un .docx estándar, así que se abre en Word de escritorio, en Word para la web con una cuenta gratuita de Microsoft, en LibreOffice Writer, en Google Docs y en Pages. Al ser una plantilla de una sola columna y sin formas decorativas, aguanta el cambio de programa mucho mejor que los diseños con columna lateral de color.

La única precaución que merece la pena: edita en un solo programa y exporta el PDF desde ese mismo programa. Cada salto entre suites reinterpreta márgenes e interlineado, y los saltos encadenados acaban descolocando la paginación sin que sepas por qué. Si tienes dudas con la conversión, la guía de la plantilla de CV en Word entra en detalle sobre qué se rompe en cada programa.

Última comprobación antes de enviar: número de páginas (que no se te haya colado una tercera con una línea suelta), el nombre del archivo, que el PDF tenga texto seleccionable y que los enlaces funcionen al pulsarlos. Con eso cubierto, el archivo llegará como lo has escrito.

Preguntas frecuentes

¿Cuántas páginas debe tener el CV de un programador?

Una página si llevas menos de cinco o seis años trabajando, y dos como máximo si tienes una trayectoria larga con varios proyectos relevantes. La segunda página solo se justifica si aporta información que cambia la decisión: proyectos con impacto, publicaciones, contribuciones a proyectos de código abierto. Si la segunda página se llena con cursos de tres horas y aficiones, sobra.

¿Envío el currículum en PDF o en Word?

En PDF salvo que la oferta pida el .docx de forma expresa. El PDF fija la maquetación y viaja igual a cualquier ordenador. Exporta el PDF desde el mismo programa en el que has editado el archivo y comprueba que se puede seleccionar el texto: si no se puede, has generado un PDF de imagen y ningún sistema podrá leerlo.

¿Hay que poner foto en el CV de programador en España?

No es obligatoria y ninguna empresa puede exigirla como requisito para valorar tu candidatura. En perfiles técnicos aporta poco y ocupa espacio que rinde más en el stack o en los proyectos. Si la pones, que sea una foto neutra y reciente. En procesos internacionales lo habitual es enviarlo sin foto.

¿Qué es un ATS y cómo afecta a mi CV?

Un ATS es el software con el que la empresa recibe, almacena y filtra las candidaturas. Extrae el texto de tu archivo y lo coloca en campos: nombre, contacto, experiencia, formación, competencias. Si tu archivo está bien estructurado, esa extracción sale limpia y quien selecciona ve tu perfil completo. Si el texto está dentro de imágenes o de cajas flotantes, se pierde. Los porcentajes de descarte automático que circulan por internet no tienen una fuente verificable, así que no los repetimos: el objetivo práctico es que tu archivo se lea bien, no batir una cifra inventada.

¿Puedo usar un CV a dos columnas siendo programador?

Sí, siempre que las columnas estén hechas con una tabla o con columnas reales del procesador y no con cuadros de texto flotantes. Los analizadores modernos manejan bien las dos columnas, pero el orden de lectura puede alterarse. Si te presentas a una empresa grande con un portal de empleo propio, una sola columna es la opción con menos puntos de fallo.

¿Cómo hago el CV si soy junior y no tengo experiencia laboral?

Invierte el orden: extracto, formación, proyectos y después prácticas o trabajos no relacionados. Los proyectos ocupan el lugar de la experiencia, y se describen igual que un trabajo: qué construiste, con qué tecnología, qué problema resolvía y qué aprendiste. Un proyecto con repositorio público y un README decente vale más que una lista de doce cursos.

¿Cuántas tecnologías pongo en el stack?

Las que sabrías defender en una entrevista técnica. Una lista de treinta nombres transmite lo contrario de lo que pretende: que no hay ninguna dominada. Agrupa por familias, ordena de mayor a menor dominio y deja fuera lo que solo has tocado en un tutorial. Si necesitas indicar nivel, hazlo con palabras claras y no con barras de porcentaje.

¿Qué pongo en el CV si mi GitHub está casi vacío?

Si no hay nada que enseñar, no enlaces el perfil: un repositorio vacío resta. Tienes dos caminos: publicar un proyecto pequeño pero terminado, con README, instrucciones de instalación y pruebas, o sustituir el enlace por una descripción de proyectos internos que no puedes publicar por confidencialidad, explicando el problema y la solución sin exponer código de la empresa.

¿Debo poner el salario que pido en el CV?

No en el CV. La expectativa salarial se trata en el formulario de candidatura si lo pide o en la primera conversación. Y antes de dar una cifra, contrástala con fuentes que expliquen su metodología, como las estadísticas salariales oficiales por ocupación o los convenios del sector, en lugar de con rangos que circulan sin fuente. Los datos varían mucho por comunidad autónoma, tamaño de empresa y modalidad de trabajo, así que un número suelto sin contexto no sirve para negociar.

¿Cómo nombro el archivo del CV?

Nombre, apellido y la palabra CV, con guiones y sin acentos ni caracteres raros: por ejemplo, laura-mendez-cv-backend.pdf. Añadir el puesto ayuda cuando envías varias versiones. Evita nombres como cv_final_v3_bueno.pdf, que llegan tal cual a la bandeja de quien selecciona.

¿Hace falta una carta de presentación para un puesto de desarrollo?

No siempre se lee, pero cuando el formulario deja un campo de texto libre conviene rellenarlo. Media página basta: por qué esa empresa y ese producto, qué parte de tu experiencia encaja con lo que piden y qué quieres construir allí. Si vas a cambiar de especialidad o de sector, la carta es el sitio donde se explica el salto.

¿La plantilla que descargo es realmente específica para programadores?

Sí. El archivo cv-programador.docx trae los apartados redactados para un perfil de desarrollo: perfil profesional con hueco para frontend, backend o full-stack, experiencia con líneas orientadas a stack y resultado medible, competencias divididas en lenguajes, frameworks, bases de datos y herramientas, y formación con espacio para bootcamp o certificaciones. Es una base editable con marcadores entre corchetes, no un diseño gráfico cerrado: el trabajo de contenido lo pones tú.

¿Puedo usar la plantilla para una candidatura fuera de España?

La estructura vale, pero traduce el contenido y quita la foto si la habías puesto. En países anglosajones el currículum sin foto y sin datos personales es la norma, y los apartados cambian de nombre. Si la oferta es de una institución europea o pide formato normalizado, revisa la plantilla Europass, que sigue el modelo oficial de la Unión Europea.

Otras plantillas que te pueden servir

Si tu perfil está a caballo entre varias ramas, estas versiones de la misma familia cambian el vocabulario y el orden de los bloques:

• CV de diseñador UX/UI, si trabajas en la frontera entre producto y frontend.
• CV de ingeniero, para perfiles de sistemas, industriales o de telecomunicaciones.
• CV de freelance o autónomo, cuando facturas por proyectos en lugar de tener empleos.
• CV de primer empleo, si aún no tienes experiencia laboral que contar.
• Todas las plantillas de CV gratis, para comparar formatos antes de decidir.