Currículums por puesto
Currículum software: stack en Skills, prueba en Experiencia
Pon el stack bajo un título Skills que Greenhouse pueda mapear. Escribe las viñetas de experiencia como trabajo enviado: sistema, usuarios y un cambio que puedas defender. Repite un lenguaje solo donde lo usaste. Luego comprueba el parseo antes de subir a Greenhouse o al Workday de la empresa.
Redactado por EnhanceCV Editorial Team·Revisión editorial: CPRW
Publicado 27 de agosto de 2026·Última actualización 27 de agosto de 2026
Puntos clave
- · Lenguajes, frameworks y almacenes van bajo Skills en texto real — no como pastillas de color en una barra que Greenhouse no mapea.
- · Las viñetas son trabajo enviado: quién lo usó, qué cambió, qué sistema. Un stack separado por comas en cada línea es ruido.
- · Copia los sustantivos de la oferta que puedes defender: Go, Postgres, Kafka, React — no un pie con cada librería de node_modules.
- · Los perfiles staff abren con alcance (guardia, RFCs, migraciones). Los junior, con un proyecto que de verdad corrió.
- · Exporta texto seleccionable y comprueba el parseo antes de Apply en Greenhouse o Workday.
Pon el stack bajo Skills, no en cada viñeta
Punto clave: Los hiring managers buscan sistemas enviados. Greenhouse busca nombres de lenguaje y almacén. Si el stack vive solo en un gráfico de nubes, no existes.
Un currículum de ingeniería de software no es un volcado de cada librería que hayas importado. El hiring manager se hace tres preguntas antes de la primera viñeta: ¿Has enviado en este lenguaje? ¿Has operado un sistema como el nuestro? ¿Te encontramos en Greenhouse al buscar “Go Postgres Kafka”? Workday en un banco o un retailer hace la misma búsqueda con un parseo un poco peor. Si el stack está en pastillas de color en una barra, la extracción vuelve sin Go y no apareces en el filtro de lenguaje.
Escribe un encabezado Skills en texto claro. Agrupa: lenguajes, frameworks, almacenes, infra, prácticas. Ejemplo: “Go, TypeScript; Postgres, Redis; Kafka; Terraform, Kubernetes; CI en GitHub Actions.” Ese bloque es para la búsqueda. Las viñetas de experiencia son para la prueba. Repetir el stack entero en cada línea gasta el único espacio que un staff tiene para mostrar una migración, un incidente o un RFC. Un sustantivo de la oferta en una viñeta basta si Skills ya sostiene el resto.
Alinea el título solo si es verdad. Si la oferta dice “Backend Engineer” y tu placa decía “Software Engineer III”, puedes escribir “Software Engineer III (Backend).” No inventes alcance staff que no tuviste. GitHub y porfolio van en la línea de contacto como texto, no como iconos. Workday suele tirar una URL de encabezado; un https completo en el cuerpo sobrevive más. Secuencia: cómo hacer un currículum y adaptar a la oferta. Esta página se queda en stack frente a prueba.
Qué copiar de una oferta de ingeniería — y qué no
- Copia sustantivos: Go, Java, TypeScript, Postgres, DynamoDB, Kafka, gRPC, Kubernetes, Terraform, Datadog, LaunchDarkly.
- Copia el tono de seniority: “dueño de la guardia”, “escribir el RFC”, “migrar”, no adjetivos vacíos.
- No pegues el párrafo entero de requisitos. El parser no te premia y el hiring manager lo nota.
- No listes un lenguaje que no puedas escribir en una prueba. Greenhouse no te salva en el pairing.
Dale a Greenhouse y Workday un layout que puedan mapear
Punto clave: Los tableros Greenhouse de producto y el Workday corporativo cuelgan nombre, email, empleadores, fechas y un blob de skills. Las plantillas de dos columnas “porfolio dev” revuelven el stack.
Greenhouse es el default en muchas product companies. Workday aparece en bancos, retail y healthtech. Ninguno “ve” el currículum como tú en el visor. Extraen texto y lo cuelgan en campos: nombre, email, teléfono, empleador, cargo, fechas, formación, skills. Si el email vive en un encabezado, o Go solo en un gráfico de pastillas, la extracción puede volver vacía. Luego buscan “TypeScript Postgres” y no estás en el conjunto.
Una columna. Alineado a la izquierda. Encabezados que el parser ya mapea: Experiencia laboral, Formación, Skills, opcionalmente Proyectos seleccionados. “Tech stack”, “Lo que construyo” e hileras de iconos son bonitos y no mapean. Fechas junto a la empresa: “mar 2022 – actualidad.” Contrato más cliente en el mismo bloque — “SWE contratada, ThoughtWorks / Cliente: API de pagos, Go.”
Contacto en el cuerpo. Teléfono, email, ciudad/región, GitHub o LinkedIn como URL completa. Sin foto en pipelines Greenhouse y Workday de EE. UU. Reglas visuales: formato y currículum ATS. Campo a campo: formato Workday. Colocación de skills no exclusiva de ingeniería: skills del currículum.
Tipo de archivo, fuentes y la línea de GitHub
- .docx o PDF con texto seleccionable. Una captura de VS Code es un ladrillo.
- Calibri, Arial, Georgia o la fuente de Enhance CV. Cuerpo 10,5–12 pt. Monoespacio en toda la página cuesta más en el móvil.
- Una URL de GitHub o porfolio en contacto. Cinco iconos de badge en el encabezado suelen desaparecer en Workday.
- Sin barras de skills ni gráficos de contribuciones como imagen. Greenhouse no puntúa los cuadrados verdes.
Prueba el archivo como el ATS. Selecciona todo. Si no puedes marcar “Postgres” o el email, Greenhouse tampoco. Luego el comprobador ATS contra la oferta. Un currículum ATS de ingeniería sigue siendo un argumento de sistemas — solo que aún contiene Go después del parseo.
Reescribe líneas flojas: tres transformaciones antes/después
Punto clave: Un dump técnico describe la caja de herramientas. El trabajo enviado te describe a ti. Si la viñeta podría ir en cualquier currículum backend con ese cargo, no está lista.
Los hiring managers escanean un verbo, un sistema y un usuario o escala que reconozcan. “Responsable de desarrollar features” esconde los tres. Tres reescrituras: backend, full-stack e intern. Copia el patrón, no los hechos. Si no hay una latencia limpia, usa alcance: servicios a cargo, deploys semanales, tamaño de equipo, regiones, rotación de guardia. No inventes p99 que no puedas explicar en la pizarra.
Antes
Responsable de desarrollar nuevas funcionalidades y trabajar con stakeholders en todo el stack.
Después
Envié la exportación CSV de facturación en Go y Postgres usada por 40 personas de finanzas; bajé la consulta de cierre de mes de 12 minutos a 90 segundos al añadir un índice cubriente.
Antes
Trabajé en frontend y backend para mejorar el checkout.
Después
Monté el flujo de checkout React para IVA de la UE en TypeScript; lo gatedé con LaunchDarkly para que legal pudiera apagarlo sin un deploy.
Antes
Mejoré la calidad del código y colaboré en varios servicios en un entorno de ritmo alto.
Después
Saqué la autenticación de sesión del monolito Rails a una librería Go; el p95 de login bajó de 800 ms a 220 ms al quitar un round trip extra a Redis.
Tres a cinco viñetas en el puesto actual. Los antiguos, dos. Un volcado de dos páginas de cada ticket es cómo el hiring manager no llega a la línea que te habría dado la entrevista. Patrones de línea: viñetas y verbos. El relleno de keywords sin contexto: keywords. No cueles ejemplos clínicos ni de aula en este archivo.
Los side projects van bajo Proyectos seleccionados solo si corrieron para alguien más: un bot de un club, un parche open source mergeado, un trabajo de curso con un dataset real. “Todo app en React” es más débil que una viñeta de intern con un deploy en producción. Reconversión bootcamp: mantén cronología y pon la prueba de ingeniería primero — cambio de carrera.
Un playbook de 12 pasos para una oferta de ingeniería
Punto clave: En este orden. Saltar a una plantilla de dos columnas “dev” es cómo se envía un archivo bonito que Greenhouse guarda sin email.
Reserva dos horas. Ten la oferta, tu último currículum y notas de sistemas que de verdad enviaste. Si quieres un layout que el parser ya entiende, empieza en el editor Enhance CV. El resumen, al final.
- Guarda la oferta. Rodea el título, cinco lenguajes o almacenes, infra y cualquier forma de seniority (guardia, RFC, mentorship).
- Archivo nuevo. Nombre, ciudad/región, teléfono, email, URL de GitHub en el cuerpo — no en un cuadro del encabezado.
- Deja el resumen de 3–4 líneas en blanco hasta que existan las viñetas.
- Puestos en cronología inversa. Empresa, cargo, ciudad, fechas con mes y año. Agencia más cliente en un bloque si fuiste contratada.
- Bajo el puesto más relevante, ocho viñetas sucias de lo que enviaste: migraciones, incidentes, features, RFCs.
- Borra lo que no ayude. Las librerías que sobren, al maestro, no a un pie de keywords.
- Reescribe: verbo + sistema + usuario o número. Léelas en voz alta. Si no lo dirías en el standup, el verbo es falso.
- Encabezado Skills con sustantivos de la oferta que puedes defender. Grupos: lenguajes, almacenes, infra. Sin estrellas ni barras.
- Formación: título, escuela, año. Quita la nota media salvo junior y si suma. Curso relevante solo si te falta un segundo empleo.
- Proyectos seleccionados solo si cambian la decisión. Un enlace GitHub en contacto basta; no pegues un README.
- Exporta texto seleccionable. Ábrelo en el móvil. Email táctil y fechas legibles sin zoom.
- Pega currículum y oferta en el comprobador ATS. Corrige contacto y stack, luego sube a Greenhouse o Workday.
La gente invierte el paso 3. Escriben “ingeniera orientada a resultados apasionada por el scale” y el resto es una lista de librerías. Primero la prueba. El resumen debe sonar como un hiring manager repitiéndote a otro: cargo, años, dominio, stack, una prueba — “Backend, 6 años, Go y Postgres, exportaciones de facturación para un equipo de finanzas de 40.”
Si te atascas con el resumen, sáltalo y vuelve tras las viñetas. Estructura, no frases, de ejemplos de perfil. No pegues el p95 de otra persona. La latencia inventada es la vía más rápida de perder un loop con el último tech lead.
Haz esto, evita aquello
Punto clave: Casi todas las plantillas “tech” optimizan parecer developer. Parsers y hiring managers optimizan campos de stack y prueba enviada.
Úsalo como filtro. Si la duda no está en la tabla: ¿Greenhouse lo guardará y un hiring manager lo entenderá en el móvil a las 7:15 antes del standup?
Decisiones amigables vs. hostiles para archivos de ingeniería
| Tema | Haz | Evita |
|---|---|---|
| Skills | Encabezado en texto con lenguajes y almacenes que puedes defender. | Pastillas de color, barras o un pie con cada paquete npm. |
| Viñetas | Trabajo enviado: sistema, usuarios, cambio. | El mismo stack repetido en cada línea sin resultado. |
| Encabezados | Experiencia, Formación, Skills — palabras que el ATS ya mapea. | “Lo que construyo”, “Viaje tech”, iconos en lugar de palabras. |
| Enlaces | Una URL de GitHub o porfolio en el cuerpo. | Cinco iconos de cabecera que Workday tira, o un QR. |
| Fechas | Mes + año junto a cada puesto. Contrato + cliente juntos. | Solo años para esconder un hueco que un contrato de una línea llenaría. |
| Archivo | PDF seleccionable o .docx NombreApellido_Backend.pdf. | Un PNG del currículum, o CurriculumFinalFINAL3.pdf. |
Los currículums funcionales que esconden fechas bajo “Lenguajes” siguen saliendo en consejos de bootcamp. Greenhouse puede parsear una nube; las personas desconfían. Mantén cronología. Si cambias de campo, cambio de carrera y sigue fechando el último empleador. Huecos: una línea clara — hueco laboral. Longitud mid-career: longitud del currículum.
Junior, staff, bootcamp: el mismo método, distinta prueba primero
Punto clave: Solo cambia qué prueba enviada va en las primeras cinco líneas y cómo etiquetas prácticas y contratos.
Junior y newly graduated. Abre con las prácticas o el proyecto que de verdad corrió: usuarios, deploy, lenguaje. Los volcados de “asignaturas: estructuras de datos” son débiles. “Load-testé un servicio Go usado por un club de 12 personas” es una viñeta. Combina con sin experiencia y estudiante si aún no hay empleo pagado de ingeniería. No inventes producción si la app no salió de localhost.
Staff y senior. Abre con alcance: servicios a cargo, guardia, RFCs, migraciones, gente a la que desbloqueaste. Corta viñetas junior que gritan “sigo listando proyectos de intern.” Dos páginas están bien cuando la segunda sigue teniendo prueba para esta oferta — migraciones, guardia, sistemas — no cuando el espacio en blanco te asusta. Ver mid-career y longitud.
Bootcamp o reconversión. Mantén cronología inversa. Las prácticas o el apprenticeship de ingeniería primero, luego comprime la carrera previa a fechas, empleador y una línea transferible — no un currículum de retail completo. Dos archivos si sigues postulando al campo antiguo. LinkedIn puede ser más ancho; el upload de Greenhouse no.
Contratos y agencias. Cada engagement es un puesto: firma, cliente, stack, fechas. Fusionar tres contratos Go en “Freelance 2022–2025” esconde los clientes que pedirá el background check y parece un hueco en el grafo de Workday. Contratos antiguos en una línea si pasas de dos páginas; no borres los nombres de cliente si puedes nombrarlos.
Qué hacer hoy: una oferta, los 12 pasos, puntúa. Si el checker marca un email ausente o un encabezado que Greenhouse no mapea, arréglalo antes de otro framework. El título Skills es lo primero a probar. Luego arma en Enhance CV si el layout sigue siendo una plantilla de dos columnas “porfolio dev”.
Preguntas frecuentes
¿Dónde van los lenguajes en un currículum de ingeniería de software?
Bajo un título Skills en texto, agrupados con almacenes e infra, para que Greenhouse y Workday los mapeen. Repite un lenguaje dentro de una viñeta solo donde enviaste con él. Una fila de pastillas de color en una barra es la razón habitual de que Go no llegue a la base.
¿Cada viñeta debe listar el stack completo?
No. Skills sostiene el stack. Las viñetas, el trabajo enviado. Repetir “React, Node, Postgres, Docker, AWS” en cada línea tapa el único hecho que el hiring manager preguntará en la entrevista. Un sustantivo por viñeta basta si Skills está completo.
¿Basta un enlace a GitHub en lugar de viñetas de proyectos?
Una URL en contacto ayuda a una persona. No sustituye Experiencia. Greenhouse no rastrea tus repos. Pon el trabajo enviado en texto. Un proyecto seleccionado sirve si te falta un segundo empleo; cinco README pegados no.
¿Se puede usar una plantilla de dos columnas “developer” en Greenhouse?
Puedes subirla. No deberías fiarte. Greenhouse y Workday leen a menudo las columnas en un orden raro y desaparecen emails y Skills. Una columna con un título Skills es la opción fiable; deja el diseño decorativo para un porfolio.
¿Cuánto debe medir un currículum de ingeniería de software?
Una página basta para la mayoría con menos de unos ocho años relevantes. Dos páginas están bien cuando la segunda sigue teniendo prueba para este puesto — migraciones, guardia, sistemas — no un dump de librerías. Casi nadie termina un dos páginas hinchado en el móvil. Ver longitud.
¿Cómo listan las contratistas varios clientes?
Un bloque por engagement: firma, cliente si puedes nombrarlo, cargo, stack en Skills, fechas con mes. Los antiguos pueden ir en una línea. Un único blob “Freelance Engineer” sin clientes parece un hueco y retrasa el background check.
¿Hace falta un objetivo en un currículum de ingeniería en 2026?
Casi nunca si ya tienes trabajo enviado. Un resumen de tres líneas con cargo, dominio, stack y una prueba hace el mismo trabajo con menos relleno. Usa objetivo solo si cambias de campo y debes explicar el giro en una frase.
¿Cómo comprobar el currículum de ingeniería antes de Greenhouse?
Selecciona todo en el PDF. Si lenguajes y email no se marcan, corrige. Luego el comprobador ATS de Enhance CV contra la oferta: contacto, fechas, título Skills y huecos de stack. Corrige y sube. No esperes a un tablero en silencio para descubrir que Postgres no parseó.
Escribe el siguiente borrador en un layout que el parser ya entiende
Abre el editor de Enhance CV, conserva stack y hechos enviados, y aprieta las líneas que aún suenan a descripción de puesto. Luego puntúa el archivo contra la oferta.