Checklist ATS de currículum para ingenieros de software (2026)

Los consejos genéricos sobre ATS se pierden las trampas específicas de ingeniería. El currículum de un marketer rara vez tiene un stack técnico de cinco líneas. El de un ingeniero sí, y ese bloque es donde la mayoría de parsers ATS o sacan una lista limpia de palabras clave o tiran la mitad de la señal al suelo. Lo mismo pasa con los enlaces a GitHub, las viñetas con mucho código, las menciones a Leetcode y las contribuciones OSS. Nada de eso aparece en una guía típica de ATS porque la guía típica está escrita para todo el mundo.

Esta es la versión para ti. Una checklist práctica y consciente del rol que un ingeniero de backend, frontend, SRE o ML puede pasar por cada candidatura antes de darle a enviar.

Por qué los ATS se comportan distinto con currículums de ingeniería

Los reclutadores de empresas tecnológicas grandes reciben entre 200 y 500 candidaturas para un solo rol de ingeniería de mid-level. Su ATS está configurado para extraer una superficie concreta: años en cada lenguaje, frameworks listados literalmente, plataformas cloud y los nombres exactos de las herramientas que aparecen en la oferta. Si tu currículum entierra esas señales dentro de viñetas narrativas, el parser las pierde y el algoritmo de ranking te pone por debajo de candidatos cuyas habilidades aparecen listadas con limpieza.

El segundo matiz: las ofertas de ingeniería suelen listar entre 12 y 25 requisitos técnicos. Alguien que no es ingeniero podría coger los 5-6 que reconoce y escribir en general sobre el resto. Un ingeniero necesita confirmar cada uno como una palabra clave discreta y, o bien hacerla coincidir, o bien dejarla fuera a sabiendas. No hay un buen punto medio donde digas “he construido sistemas de backend” y esperes que cubra “Go”, “gRPC” y “PostgreSQL”. El parser no infiere.

Para la base de cómo los sistemas ATS leen currículums, consulta nuestra guía de optimización ATS. Este post pone la capa específica de ingeniería encima.

Formato seguro para parsers en currículums con mucho código

La mayoría de ingenieros cae por defecto en uno de dos modos de fallo de formato: demasiado ingenioso (iconos, diagramas, dos columnas que rompen el parsing) o demasiado denso (un único párrafo de 4 líneas con tecnologías separadas por comas que el parser no puede tokenizar limpio).

Las reglas:

• Una sola columna. Los diseños a dos columnas se reorganizan de forma impredecible. El bloque de habilidades que pones en la columna derecha suele acabar al final del texto parseado, lo que hunde su peso.
• Encabezados de sección estándar: Experiencia, Formación, Habilidades, Proyectos. Evita sustituciones creativas como Tech Stack o Engineering Toolkit. El parser hace coincidencia con un diccionario finito de cabeceras.
• Sin tablas, sin cuadros de texto, sin iconos SVG al lado de las viñetas. Se descartan.
• Una tipografía, cuerpo 10-11pt. Los PDFs se renderizan bien; .docx es más seguro si no estás seguro.
• Sin foto. Tu código es la foto.
• Formato de fecha: Mes AAAA - Mes AAAA (p. ej., Ene 2023 - Mar 2026). “Presente” funciona para roles actuales. Las fechas numéricas (01/2023) parsean pero pierden legibilidad.
• Nombre de archivo: nombre-apellido-cv.pdf, no Resume_v17_FINAL_FINAL.pdf. Algunos ATS muestran el nombre del archivo al reclutador.

Si quieres un punto de partida que siga estas reglas, nuestra plantilla de currículum ATS-friendly es el formato que sobrevive el parsing en los principales sistemas.

Dónde poner los enlaces a GitHub, portafolio y Stack Overflow

Los currículums de ingeniería tienen más enlaces de alta señal que otros roles. Ponlos en dos sitios:

1. Bloque de cabecera, arriba del todo: github.com/tunombre y el dominio de tu portafolio, en la misma línea que el correo y la ciudad. El ATS lo extrae como dato de contacto y los reclutadores lo cliquean.
2. Dentro de la viñeta de proyecto correspondiente: cuando una viñeta describe un side project o una contribución OSS, pon el enlace al final de la propia viñeta. Eso es lo que se cliquea durante la revisión humana.

Tres errores frecuentes:

• Hipervínculos detrás de texto como “GitHub” o “ver proyecto”. La mitad de los parsers descarta la URL y se queda solo con el texto del ancla. Escribe la URL real.
• Enlazar a un GitHub vacío o desactualizado. Si tus repos pinned son forks de 2019 y un trabajo de un curso, ese enlace te resta. O lo pueblas o lo quitas.
• Poner enlaces de Stack Overflow por encima de GitHub en cualquier rol que no sea muy senior. La reputación en SO es buena señal pero más débil que el código actual. GitHub va primero.

La URL de LinkedIn también va aquí. El parser normalmente la extrae. Asegúrate de que el perfil de LinkedIn refleje exactamente los títulos de puesto y las fechas del currículum. Los desajustes en esta capa son la razón más común para que un reclutador marque un currículum como “inconsistente”.

Las 20 palabras clave que de verdad mueven la aguja, por stack

La mayoría de ofertas se agrupa en un set reconocible por familia de rol. Estas son las palabras clave que, cuando están, suben tu match score de forma significativa y, cuando faltan, suelen ser imprescindibles de la oferta que no te puedes permitir perder.

Backend (Go / Java / Python / Node.js): distributed systems, microservices, REST, gRPC, message queues (Kafka, SQS, RabbitMQ), PostgreSQL o MySQL, Redis, Docker, Kubernetes, AWS o GCP, CI/CD, observabilidad, system design, code review, on-call.

Frontend (React / TypeScript / Next.js): React, TypeScript, Next.js, accesibilidad (a11y), Core Web Vitals o web performance, consumo de GraphQL o REST, design system, librería de componentes, testing (Jest, React Testing Library, Playwright), diseño responsive, compatibilidad entre navegadores.

SRE / Infraestructura: AWS / GCP / Azure, Terraform, Kubernetes, observabilidad (Prometheus, Grafana, Datadog), respuesta a incidentes, SLO / SLI / error budget, runbooks, rotación de on-call, optimización de costes, networking, Linux, buenas prácticas de seguridad.

Ingeniería ML / AI: PyTorch, TensorFlow, transformers, LLM, RAG, base de datos vectorial (pgvector, Pinecone, Weaviate), prompt engineering, evaluación de modelos, fine-tuning, AWS Bedrock o Azure OpenAI, MLOps, data pipelines.

Replica la fraseología exacta de la oferta, no un sinónimo. “Kubernetes” y “k8s” no son intercambiables para un parser aunque sí lo sean para un humano. Si la oferta usa “k8s” tres veces, tu currículum también. Si usa “Kubernetes”, usa eso. Ante la duda, lista los dos.

Para más sobre cómo los reclutadores y los motores de ATS ponderan los tipos de habilidad, consulta hard skills vs soft skills.

Cómo deberían aparecer Leetcode y las contribuciones OSS (o no)

Para roles de inicio de carrera hasta mid-level: una mención breve funciona si es real y reciente. Ejemplos válidos:

• “Top 5% en Leetcode (rating 1.800, 600+ problemas resueltos)” si es cierto y actual.
• “OSS: 14 PRs mergeados a [proyecto], incluyendo [funcionalidad concreta]” si es específico y verificable.

Ejemplos que te perjudican:

• “Activo en Leetcode” sin métrica. Suena a relleno.
• “Contribuí a open source” sin nombre del proyecto. Igual.
• Cualquier mención a Leetcode en un currículum senior+. A ese nivel está por debajo del umbral de ruido de lo que les importa a los hiring managers.

Para los side projects, lidera con el resultado, no con el stack. “Construí X que llegó a Y usuarios / procesó Z requests / ahorró $W” es muchísimo más fuerte que “Construí X usando React, Node, MongoDB, Docker, AWS”. El stack va entre paréntesis al final. Los reclutadores escanean el resultado; el parser pilla el stack de todos modos.

Para más sobre cómo enmarcar proyectos cuando estás cambiando de rumbo, consulta currículum para cambio de carrera.

Patrones de cuantificación específicos para ingenieros

El consejo genérico dice “cuantifica tus viñetas”. Es correcto pero incompleto. Los ingenieros tienen dimensiones específicas con las que los hiring managers de verdad comparan:

• Latencia / rendimiento: “Reduje la latencia p95 de 800ms a 120ms” gana a “Mejoré significativamente el rendimiento”.
• Throughput / escala: “El servicio maneja 12k RPS en pico” o “procesó 4.500M de eventos/día”.
• Coste: “Bajé el gasto en AWS un 38% (14k$/mes) migrando cron jobs a Lambda”.
• Fiabilidad: “Subí el SLO del 99,5% al 99,95% en dos trimestres”.
• Code review / mentoría: “Revisé una media de 35 PRs/semana; mentoricé a 3 ingenieros junior hasta mid-level”.
• Cadencia de entrega: “Lideré 6 lanzamientos en 12 meses; 5 dieron en la fecha comprometida”.

Si no sabes el número exacto, da un rango. “Reduje el tiempo de query unas 4x” vale. Lo que hay que evitar es “Mejoré el rendimiento de las queries”, que no transmite nada.

La checklist de 60 segundos antes de enviar

Pasa esta lista por cada candidatura de ingeniería antes de pulsar enviar:

• [ ] Arriba del currículum: github.com/tunombre y URL del portafolio escritas (no detrás de un ancla), más URL de LinkedIn.
• [ ] Sección de Habilidades: 12-18 habilidades, todas coincidiendo exactamente con la fraseología de la oferta, listadas con limpieza (sin iconos, sin barras de progreso).
• [ ] Tecnologías mencionadas en la oferta: cada tecnología imprescindible aparece al menos una vez en tu currículum, idealmente en Habilidades y en una viñeta.
• [ ] Las 3 viñetas top de tu rol más reciente atacan los 3 requisitos top de la oferta, en orden.
• [ ] Cuantificación: al menos el 60% de las viñetas tiene un número (latencia, escala, coste, RPS, %).
• [ ] Side projects: lidera con el resultado, stack entre paréntesis al final. Cada proyecto tiene un enlace funcional y poblado.
• [ ] Sin formato roto: abre el .pdf en un visor distinto al que usaste para guardarlo. Si la maquetación cambia, vuelve a guardar o pásate a .docx.
• [ ] Nombre de archivo: nombre-apellido-cv.pdf.
• [ ] Match score: 75%+ de coincidencia de palabras clave contra la oferta.

El último ítem es el más fácil de manipular y el que de forma más consistente predice las tasas de respuesta. Tailor te da ese score en 60 segundos más las palabras clave faltantes exactas y en qué viñeta deberían aterrizar.

Cuando seguir la checklist se vuelve en tu contra

Tres situaciones donde la optimización ATS para ingeniería necesita relajarse:

1. Roles muy senior (Staff+ / Principal): a este nivel, el currículum lo leen más los humanos que el ATS, y los criterios de cribado se desplazan hacia alcance, liderazgo técnico y criterio de diseño. La densidad de palabras clave todavía importa, pero la narrativa importa más.
2. Research / FAANG L5+ donde la oferta es genérica: cuando una oferta dice “sólidos fundamentos de CS, disposición para trabajar en problemas difíciles”, no hay nada con lo que hacer match de palabras clave. Optimiza por claridad e impacto.
3. Founding engineer / startups muy tempranas: las leen los fundadores, no los reclutadores, y quieren explícitamente versatilidad. Generalista pulido > especialista estrecho en el currículum.

Para todo lo demás, la checklist se sostiene. Pásala una vez, guarda los patrones y aplícala en 5 minutos por candidatura en lugar de 30. El retorno compuesto de adaptar un currículum de ingeniería es mayor que en cualquier otra familia de roles porque la densidad de palabras clave por oferta es más alta.

El panorama mayor

La optimización ATS es el suelo, no el techo. Pasar el parser es necesario, no suficiente. Una vez superado el filtro, el currículum todavía tiene que leerse como el de un ingeniero que construyó cosas, asumió resultados y dejó mejor los sistemas que tocó. La checklist te lleva a través de la puerta. Las viñetas que escribes dentro del currículum son las que te consiguen la entrevista.

Las dos habilidades son separables, y la mayoría de ingenieros las pondera mal: 80% del esfuerzo en pulir viñetas, 20% en higiene de parser. Dale la vuelta para la primera versión y luego itera.