Ejemplo de CV para Software Engineer
El CV de un software engineer lo leen dos audiencias muy distintas, una tras otra: primero un parser automático de CVs, después un ingeniero senior o un reclutador técnico. Ambos buscan señales muy diferentes en la misma página. El parser quiere coincidencias exactas de palabras clave con la oferta —nombres de lenguajes, de frameworks, los títulos de puesto en el formato correcto. El humano quiere evidencia: el alcance de lo que construiste, la profundidad técnica que exige el rol y resultados que demuestren que tu trabajo importó. Este ejemplo cubre la estructura, la sección de habilidades, los bullets de experiencia, la sección de proyectos y los pequeños detalles que separan un CV de software engineer que consigue entrevistas de uno que queda filtrado. Todo es editable en el builder de Cvida; úsalo como punto de partida y adáptalo a tu stack y nivel de seniority.
Por qué el CV de un software engineer es distinto al de cualquier otro perfil
Empieza por las diferencias, porque explican cada decisión que viene después. La selección en software tiene sus propias convenciones:
- La especificidad técnica lo es todo: 'web developer' es una etiqueta, 'TypeScript / React / Node / PostgreSQL' es una coincidencia real que el parser puede puntuar
- Los proyectos cuentan tanto como los trabajos: una contribución sólida a open-source o un proyecto real en producción se trata como experiencia laboral por los evaluadores senior
- El stack importa más que el título: 'Senior Engineer en una empresa pequeña que nunca has oído mencionar' se juzga por el stack usado y la escala entregada, no por el título
- La cuantificación es técnica, no comercial: latencia reducida, queries-per-second gestionados, MTTR mejorado, frecuencia de deploy, cobertura de tests —no 'aumenté los ingresos'
- El matching de palabras clave en ATS es despiadado en tech: cientos de candidaturas por rol significa que el reclutador escanea literalmente en busca de los frameworks exactos que menciona la oferta
Trata tu CV como un documento técnico. La misma precisión que usarías en un system design doc aplica aquí: nombra las primitivas correctas, muestra la escala a la que operabas, demuéstralo con resultados medibles.
La estructura de CV que funciona para roles de ingeniería
La mayoría de los CVs de software engineer funcionan mejor en este orden —coloca la señal técnica justo donde los evaluadores miran primero:
- Cabecera: nombre, título del rol, ubicación, email, URL de GitHub, URL de LinkedIn, URL de portfolio/web —cada enlace clicable en el PDF
- Resumen (3-4 líneas): años de experiencia, stack principal, una o dos especializaciones de dominio, el tipo de rol que buscas
- Habilidades: skills técnicas agrupadas (lenguajes, frameworks, infraestructura, herramientas) —escaneables en 5 segundos
- Experiencia: puestos en orden cronológico inverso, cada uno con 3-6 bullets centrados en lo que entregaste y el impacto
- Proyectos (especialmente para juniors y mid-level): 2-4 proyectos personales o de open-source con stack técnico y resultado
- Educación: titulación + universidad + año —breve, salvo que seas recién graduado con asignaturas relevantes
- Opcional: certificaciones (AWS, Kubernetes, etc.) e idiomas si son relevantes
Una página para menos de 5 años de experiencia, dos páginas por encima. Los ingenieros staff/principal con un alcance real se merecen la segunda página; el resto debería tratar la página única como la disciplina que les obliga a elegir las señales más potentes.
Los fundamentos de estructura y extensión del CV sobre los que se construye este ejemploEl resumen: el stack técnico primero, los resultados después
Tres o cuatro líneas, en la parte superior. Es la sección más leída después de tu nombre. Debe responder a: quién eres, qué entregas, qué tipo de rol encaja a continuación:
- Línea 1: años de experiencia + especialización principal. Ejemplo: 'Backend engineer con 6 años de experiencia construyendo servicios Go distribuidos en AWS.'
- Línea 2: la escala a la que has operado. Ejemplo: 'He liderado servicios que gestionan 50k requests/segundo; coordiné la respuesta a incidentes en un equipo de plataforma de 12 ingenieros.'
- Línea 3: señal de amplitud técnica. Ejemplo: 'Sólido en Go, Kafka, Postgres; cómodo en TypeScript y Python para trabajo adyacente.'
- Línea 4 (opcional): a qué aspiras a continuación. Ejemplo: 'Busco roles senior o staff construyendo infra de plataforma a escala consumer.'
- Qué eliminar: 'apasionado' / 'jugador de equipo' / 'altamente motivado' —son relleno que trabaja en tu contra. El detalle técnico es el que persuade
Un resumen que nombra un stack real, una escala real y un próximo paso real supera siempre a uno cargado de adjetivos. Si no puedes nombrar un stack concreto que domines, el resumen no está listo —ese vacío saldrá de todas formas en la entrevista.
La sección de habilidades: señales de profundidad, no una pared de buzzwords
Agrupa tus habilidades técnicas por tipo para que un evaluador pueda escanearlas en segundos. Dentro de cada grupo, ordénalas por profundidad real —las que más dominas, primero:
- Lenguajes: Go, TypeScript, Python, Rust (en ese orden aproximado de fluidez)
- Frameworks: React, Next.js, Node/Express, FastAPI, gRPC
- Datos / infraestructura: PostgreSQL, Redis, Kafka, ElasticSearch, Kubernetes, Terraform, AWS (EC2, S3, RDS, Lambda)
- Prácticas: diseño de sistemas distribuidos, observabilidad (Prometheus, Grafana, OpenTelemetry), CI/CD (GitHub Actions, ArgoCD), respuesta a incidentes
- Qué dejar fuera: herramientas que usaste una vez hace 5 años, lenguajes que solo tocaste en un tutorial, 'Microsoft Word' (en serio —los reclutadores pondrán los ojos en blanco)
Sé honesto con la profundidad: si lo listas, te preguntarán sobre ello. Una sección de habilidades breve y precisa supera a una larga llena de señales falsas —que te pillen mintiendo sobre tu experiencia con Kafka en la prueba técnica te cuesta la oferta.
Cómo construir una sección de habilidades creíble y específica, mapeada al rolBullets de experiencia: entregado + escala + impacto, en cada línea
Los bullets de ingeniería más potentes siguen un patrón claro: verbo de acción → qué construiste → la escala o el impacto en números. Compara estos ejemplos:
- Débil: 'Trabajé en el sistema de procesamiento de pagos' —sin stack, sin escala, sin resultado, sin alcance de responsabilidad
- Fuerte: 'Diseñé y entregué un servicio de pagos distribuido en Go que gestiona 12k transacciones/segundo con 99,99% de disponibilidad en 3 regiones de AWS'
- Fuerte: 'Reduje la latencia p99 de la API de 480ms a 90ms sustituyendo la agregación en memoria por una vista materializada en Redis; desplegado tras feature flag durante 6 semanas'
- Fuerte: 'Lideré la migración del equipo de un monolito Rails a 4 servicios Go; reduje el tiempo de deploy de 35 minutos a 6 y el MTTR de incidentes de ~2h a 28 minutos'
- Fuerte: 'Construí la plataforma interna de feature flags usada por 40 ingenieros en 6 equipos; integré SDKs para Go, TypeScript y Python'
- Patrón a aplicar: empieza cada bullet con un verbo de acción (diseñé, entregué, lideré, escalé, asumí, migré, automaticé), nombra la tecnología, nombra la escala o el antes/después
Los números no tienen que ser impresionantes —tienen que ser reales y específicos. 'Gestioné 200 requests/segundo en un checkout de e-commerce pequeño' es un bullet sólido para un ingeniero mid-level; la honestidad sobre la escala es más convincente que las afirmaciones vagas de impacto.
Cómo cuantificar tu trabajo de la forma en que lo puntúan los paneles de selección en ingenieríaLa sección de proyectos: fundamental para juniors, útil para todos
Una buena sección de proyectos responde a la pregunta que los evaluadores siempre tienen sobre candidatos cuyo trabajo diario no muestra todo su rango: ¿qué puedes construir cuando nadie te frena? Tiene un peso real para ingenieros en etapas tempranas y para quienes dan un giro de carrera:
- Elige 2-4 proyectos, cada uno con: nombre, una línea de descripción, stack técnico, URL de GitHub o en producción, y 1-2 bullets sobre lo que tiene de interesante técnicamente
- Las contribuciones a open-source cuentan: 'Contribuí una reescritura del consumidor Kafka en {project} (mergeado, 30k descargas semanales)' es una señal seria
- Los proyectos paralelos con usuarios reales son oro: 'Construí {tool}: un CLI para X usado por ~200 desarrolladores; escrito en Rust, empaquetado vía Homebrew'
- Los proyectos de cursos o bootcamps son los más débiles —inclúyelos solo si no tienes nada más y empieza por lo que era técnicamente no obvio
- Si tienes 5+ años de experiencia laboral sólida, esta sección pasa a ser opcional; sustitúyela por 'Contribuciones seleccionadas a open-source' si las tienes
Mantén vivo cada enlace de proyecto. Un evaluador que hace clic en la URL de GitHub y aterriza en un repositorio real, activo recientemente, con un README limpio, está medio convencido antes de leer tus bullets —ponle la señal delante con un solo clic.
Educación + certificaciones: que sea breve
Para los software engineers, esta sección se gana su espacio solo cuando añade una señal concreta:
- Si tienes titulación, inclúyela: tipo de título, campo, universidad, año. Una sola línea. Omite la nota si no eres recién graduado con una sobresaliente
- Recién graduados (0-2 años): añade asignaturas relevantes o el proyecto de fin de grado, pero solo los que se mapeen al rol que buscas
- Graduados de bootcamp: nombra el bootcamp y el año; lidera con los proyectos y el código en producción que has entregado desde entonces, no el currículo
- Autodidactas: omite la sección de educación por completo; deja que la sección de proyectos y la experiencia hagan el trabajo
- Certificaciones que vale la pena listar: AWS Solutions Architect / Associate, GCP Professional Cloud Architect, CKA (Certified Kubernetes Administrator). Omite 'Codecademy completado' —los reclutadores no lo cuentan
La educación importa cada vez menos cuanto más te alejas de la graduación. A partir del quinto año, una sección sólida de proyectos y experiencia hace que la línea de educación sea casi invisible —que es exactamente lo que quieres. La entrevista girará en torno a tu código, no a tu título.
Optimización ATS: replica la oferta al pie de la letra
Incluso en niveles senior, tu CV se parsea antes de que lo vea un humano. La puntuación ATS en ingeniería es inusualmente literal con los nombres de tecnologías:
- Replica los nombres exactos de los frameworks de la oferta. Si dice 'React.js', escribe 'React.js' (no solo 'React'); si dice 'Node.js', escribe 'Node.js'
- Escribe tanto la abreviatura como el nombre completo donde difieren: 'Kubernetes (K8s)', 'Continuous Integration (CI/CD)' —cubre ambas variantes de palabra clave
- Mantén el formato simple: fuentes estándar, sin maquetación en dos columnas, sin imágenes de texto, sin separadores decorativos. Los parsers ATS destrozan cualquier cosa visualmente ingeniosa
- Guarda como PDF salvo que la oferta pida Word —el layout sobrevive mejor al proceso
- No rellenes una línea oculta de 'habilidades' con palabras clave en texto blanco. Los ATS modernos lo detectan y los reclutadores se ríen —y la prueba técnica descubre la mentira de todas formas
La prueba más sencilla: ¿puedes abrir tu CV en un editor de texto plano y se lee de arriba abajo en un orden lógico? Si es así, el parser también lo hará. Si tus habilidades acaban en medio de la línea de educación, el formato está luchando contra el parser.
La guía completa de ATS para un formato de CV seguro ante el parseoErrores frecuentes que filtran a buenos ingenieros
Incluso los ingenieros técnicamente fuertes pierden entrevistas por errores de CV fáciles de corregir:
- Listar cada lenguaje que hayas tocado alguna vez: diluye las señales reales e invita a preguntas de entrevista en las que tropezarás. Lista solo lo que defenderías con confianza en una entrevista, nada más
- Resúmenes cargados de buzzwords sin stack: 'apasionado full-stack engineer con excelentes habilidades de comunicación' no le dice nada al lector. Nombra un stack y una escala
- Sin enlaces: un CV de software engineer sin URL de GitHub ni portfolio es sospechoso —los evaluadores quieren ver código. Añade la URL aunque tu GitHub sea modesto
- Bullets de texto en bloque: los bullets de más de dos líneas pierden al escáner. Mantenlos ajustados: acción + tecnología + resultado
- Señales de stack obsoletas: dejar 'jQuery' en la lista de lenguajes cuando llevas 5 años escribiendo TypeScript indica que el CV no se ha reescrito en mucho tiempo —y quizás tú tampoco te has actualizado
Aplica el test del reclutador: en 30 segundos, ¿puede un evaluador ocupado ver qué construyes, a qué escala y para qué roles encajas? Si es así, este CV te conseguirá las entrevistas. Si no, las correcciones son casi siempre las mismas —bullets más ajustados, stack nombrado, menos adjetivos, enlaces funcionales.
La guía completa para adaptar un CV a roles tech: mapeo de stack y señales de seniority