Cómo escribir un CV para un trabajo tecnológico (ingenieros de software, desarrolladores, data)

El CV tech se lee de forma diferente — qué cambia

Antes de las tácticas, la diferencia estructural. Los CVs tech se evalúan a través de un lente diferente que los CVs corporativos, y la diferencia moldea cada sección:

• El hiring manager de ingeniería lee el CV junto con (o después de) un escaneo rápido de tu GitHub, tu sitio personal si lo tienes y tu LinkedIn. El CV no es la única señal; es una señal en una evaluación multi-fuente
• La sección de habilidades técnicas es leída primero tanto por reclutadores como por ingenieros, pero buscan cosas diferentes. Los reclutadores escanean coincidencias de keywords contra el JD; los ingenieros escanean si la profundidad y amplitud coinciden con la seniority del rol
• Los proyectos a menudo importan más que el historial de trabajo a los niveles junior y mid. Un proyecto auto-impulsado que lanzó algo real señaliza iniciativa y ejecución de una forma que un internship o primer trabajo no pueden
• El historial de trabajo se lee por scope, impacto y seniority del contexto — no solo por nombres de empresa. Trabajar en el equipo de auth en una startup de 50 personas es diferente de trabajar en el equipo de auth en una empresa de 50.000 personas; el CV debe hacer el scope legible
• La presencia en GitHub es verificada. Un candidato con un perfil GitHub activo (commits reales, múltiples repositorios, gráfico de contribuciones mostrando actividad reciente) es tratado como ingeniero más creíble que uno sin — incluso si la habilidad subyacente es idéntica
• El CV es de una página hasta que no puede serlo. Dos páginas son aceptables para ingenieros con 8+ años de experiencia, pero la segunda página debe contener sustancia real, no relleno
• La educación importa a nivel junior (especialmente para nuevos graduados), se vuelve menos importante a nivel mid y se vuelve casi irrelevante a nivel senior+. Ajusta la prominencia en consecuencia
• Las certificaciones importan para roles cloud específicos (AWS, GCP, Azure) y especialidades específicas (seguridad, networking) pero son en gran parte irrelevantes para roles generales de ingeniería de software

El resto de esta guía está construida alrededor de estos hechos estructurales. Cada sección aborda qué escribir, cómo organizarlo, qué enfatizar y qué cortar — calibrado específicamente para roles de ingeniería en lugar de roles corporativos genéricos.

La sección de habilidades técnicas — cómo organizarla

La sección de habilidades técnicas es la sección más escaneada en un CV tech. Tanto reclutadores como ingenieros la miran primero. Cómo está organizada determina si transmite competencia o ruido:

• Organiza por categoría, no como una sola lista plana. Lenguajes, frameworks, bases de datos, infraestructura/cloud, herramientas, metodologías — cada uno como su propio grupo. Una pared de 40 tecnologías separadas por comas se lee como un volcado de buzzwords; las mismas 40 organizadas por categoría se leen como un mapa estructurado de competencias
• Lista tecnologías que puedes discutir con confianza en una entrevista técnica. El entrevistador elegirá de esta sección para diseñar preguntas técnicas; si listas Rust porque lo usaste para un tutorial hace tres años, fallarás la entrevista
• Ordena cada categoría por proficiencia genuina, no por lo que desearías que fuera verdad. Si eres más fuerte en Python y más débil en Go, pon Python primero — el orden se lee como señal de confianza
• Evita etiquetas de nivel de habilidad (Principiante / Intermedio / Experto / 8 de 10). Son subjetivas, a menudo inexactas y crean preguntas incómodas en entrevistas. O lista una tecnología porque puedes discutirla con confianza, o déjala fuera
• Empata el vocabulario técnico en la descripción del trabajo. Si el JD dice 'React, Node.js, PostgreSQL, AWS', usa esos términos exactos — no 'frameworks JavaScript, servidores web, bases de datos relacionales, plataformas cloud'. El ATS keyword matching es literal
• Lista versiones o dialectos específicos cuando sea relevante: 'Python 3.x', 'PostgreSQL 14+', 'React 18 con hooks'. La especificidad señaliza profundidad
• Salta los básicos que se asume que todos tienen. Listar 'HTML, CSS, Git, línea de comandos' en un CV de senior engineer es relleno que desplaza señal real
• Si tienes expertise especializado (compiladores, sistemas distribuidos, infraestructura ML, sistemas en tiempo real), crea una línea separada 'especialidades' o 'dominios' que lo saque a la superficie. La especialización es más valiosa que la amplitud a nivel senior

La prueba para la sección de habilidades técnicas: un ingeniero leyéndola debería poder predecir cómo ha sido tu trabajo del día a día. Si la sección es una nube de palabras genérica que podría coincidir con cualquier candidato, está fallando. Si está organizada, calibrada y honesta, hace la mayor parte del trabajo del screening técnico antes de que el screening técnico siquiera ocurra.

Mostrar proyectos — cuándo los proyectos importan más que los trabajos

Los CVs tech a menudo incluyen una sección Proyectos además de Experiencia Laboral. Para algunos candidatos la sección Proyectos es la parte más fuerte del CV. Cuándo incluir una y cómo usarla:

• Ingenieros junior y nuevos graduados: la sección Proyectos es esencial. Con historial laboral limitado, los proyectos son la evidencia primaria de que puedes lanzar código. Coloca esta sección encima o justo después de Educación
• Cambios de carrera entrando a ingeniería: la sección Proyectos es esencial. Es el puente entre tu experiencia previa y tu capacidad de ingeniería — y la única prueba de que realmente has construido algo
• Ingenieros mid-level con historial laboral fuerte: la sección Proyectos es opcional. Inclúyela si tienes proyectos paralelos que demuestran habilidades que tu historial laboral no demuestra (open source, experimentos ML, una librería publicada, una extensión Chrome popular)
• Ingenieros senior y superior: la sección Proyectos es usualmente innecesaria. El historial laboral a este nivel debería cargar el peso. Excepción: mantenimiento notable de open source, trabajo publicado bien conocido o contribuciones significativas a la comunidad
• Cada entrada de proyecto debe tener: nombre del proyecto (con enlace a repo o URL en vivo), descripción de una línea de qué hace, el stack tech usado y 1-2 bullet points sobre qué fue no-trivial al construirlo
• Prefiere 2-4 proyectos fuertes en lugar de 8 débiles. Una app todo siguiendo tutorial no ayuda; un proyecto que resolvió un problema real y que puedes discutir en profundidad sí lo hace
• Si el proyecto es un clon o seguimiento de tutorial, no lo listes como proyecto. Lístalo como 'ejercicio de aprendizaje' si acaso, u omítelo
• Los enlaces en vivo importan más que los enlaces a repo para proyectos orientados al usuario. Un sitio desplegado en el que el hiring manager puede hacer clic es dramáticamente más convincente que un repo que tiene que clonar
• Si el proyecto tuvo colaboradores, nómbralos y tu rol específico. 'Construí API backend y capa de base de datos para proyecto de equipo de 4 personas' es honesto y específico; reclamar autoría única de un proyecto de equipo es el tipo de cosa que se atrapa en la entrevista

El CV tech más fuerte a nivel junior/mid a menudo tiene 2-3 proyectos sustanciales sobre los cuales el candidato puede hablar en profundidad, con demos en vivo. Esto a menudo supera un historial laboral más largo pero menos diferenciado. Construye los proyectos deliberadamente para ser la evidencia más fuerte de tu CV.

GitHub, portfolio y trabajo demostrable

Los enlaces que incluyes en tu CV tech se leen como evidencia de que eres un ingeniero practicante en lugar de un titular de credenciales. Qué enlaces incluir y cómo presentarlos:

• GitHub: incluye para casi todos los roles de ingeniería. Asegúrate de que el perfil al que enlazas es real (commits recientes, múltiples repos, readme de perfil poblado). Un GitHub vacío o estancado enlazado en tu CV es peor que ningún enlace
• Sitio personal: incluye si tienes uno y está actualizado. El sitio no necesita ser elegante; un portfolio simple con enlaces a proyectos, una bio corta e información de contacto es suficiente. Un sitio roto o de la era 2019 es peor que ningún sitio
• LinkedIn: incluye. Aunque pienses que LinkedIn es mayormente ruido, los reclutadores lo verifican y un perfil vacío señaliza falta de profesionalismo
• Perfil Stack Overflow: incluye solo si tienes reputación significativa y respuestas de alta calidad. Un perfil de 50 reputación no señaliza nada; un perfil de 50.000 reputación señaliza expertise real
• Blog personal o escritura técnica: incluye si escribes contenido técnico regularmente. Los posts de blog de ingeniería demuestran capacidad de comunicación, profundidad técnica y un hábito de reflexión — todas señales que los hiring managers valoran
• Charlas en conferencias, podcasts, apariciones en video: incluye si tienes alguna. Funcionan como validación de tercera parte de que puedes comunicar ideas técnicas
• Haz todos los enlaces clicables en el PDF (Word y Google Docs ambos lo soportan cuando 'Insertas hipervínculo'). Los reclutadores harán clic; enlaces rotos o no clicables te cuestan el click-through
• Cura antes de enlazar. Antes de añadir tu enlace de GitHub, mira tu perfil con ojos frescos. Fija tus mejores 4-6 repos al perfil. Asegúrate de que los READMEs de repo están escritos. Elimina o archiva repositorios que existen solo como tutoriales a medio terminar. El hiring manager formará una impresión en 30 segundos de mirar tu perfil — asegúrate de que sea la impresión que quieres

Cada enlace en tu CV tech es una promesa — hacer clic en él revelará más evidencia de tu capacidad de ingeniería. Si hacer clic revela menos de lo que el CV sugirió, la candidatura se debilita. Los enlaces son neto positivos solo si el material subyacente está a la altura de lo que el CV implica.

ATS para roles tech — el keyword matching que importa

La mayoría de las contrataciones tech en grandes empresas todavía pasan por sistemas ATS que filtran por keywords. La dinámica del matching ATS para roles de ingeniería:

• ATS para roles tech a menudo ejecuta matching literal de keywords contra el JD. Si el JD dice 'React' y tu CV dice 'React.js', algunos sistemas no harán match. Usa la ortografía exacta del JD donde sea posible
• Lista tecnologías en múltiples secciones, no solo en la sección Habilidades. Un ingeniero senior que usó Kubernetes en producción en tres empresas diferentes debería tener 'Kubernetes' apareciendo en esas tres descripciones de trabajo más la sección Habilidades — el algoritmo de matching pondera las ocurrencias
• Frameworks y herramientas específicas importan más que categorías generales. 'React, Vue, Angular' es mejor que 'frameworks JavaScript'. 'PostgreSQL, MongoDB, Redis' es mejor que 'bases de datos'
• Acrónimos y formas completas: incluye ambos. 'Machine Learning (ML)' cubre tanto las búsquedas de 'ML' como las de 'machine learning'. 'Continuous Integration (CI/CD)' hace lo mismo
• Variaciones comunes: 'Node.js' y 'Nodejs' y 'Node' son todas la misma tecnología pero los sistemas ATS pueden no saberlo. Si el JD dice 'Node.js', empata esa forma exacta
• Certificaciones y frameworks específicos de industria: incluye si son relevantes. 'PCI DSS', 'HIPAA', 'SOC 2', 'GDPR' si has trabajado con ellos. 'Agile', 'Scrum', 'Kanban' si has ejecutado estos procesos
• Evita el keyword-stuffing que rompe la legibilidad. El CV es leído por humanos después de pasar ATS; si el lector humano ve una pared de nombres de tecnología sin contexto, la candidatura falla en el screening humano aunque haya pasado el screening ATS
• Adapta por aplicación. La lista de keywords que pasa un CV a través del ATS de Google es diferente de la lista de keywords que lo pasa a través del Greenhouse de una startup. Empata el JD específico

El matching ATS es un primer obstáculo necesario para roles tech en la mayoría de grandes empresas. Trátalo como un ejercicio literal de matching: empata el vocabulario del JD, lista tecnologías en contexto (en descripciones de trabajo, no solo en la lista Habilidades) y asume que el matching es tonto. Una vez pasado ATS, el lector humano toma el control y el contenido importa más que la densidad de keywords.

Cuantificar el impacto de ingeniería

Los CVs tech a menudo sufren del mismo problema de afirmaciones genéricas que los CVs corporativos: 'desarrollé features', 'mejoré el rendimiento', 'trabajé en la plataforma'. El impacto específico cuantificado es lo que separa un CV tech fuerte de uno genérico:

• Rendimiento: 'reduje la latencia p99 del API de 850ms a 120ms' supera a 'mejoré el rendimiento del API'. Los números específicos son creíbles; las afirmaciones vagas no lo son
• Escala: 'manejé 50K req/sec en pico' o 'procesé 2B eventos/día' ancla el trabajo en escala real. Sin números, el lector tiene que imaginar; con números, entiende
• Costo: 'reduje el costo de infraestructura AWS en $180K/año a través de optimización de base de datos y tier-rightsizing' es el lenguaje que aterriza con el liderazgo de ingeniería. La reducción de costos es a menudo la métrica de ingeniería de mayor apalancamiento
• Confiabilidad: 'reduje la tasa de incidentes de producción de 8/mes a 1/mes' o 'mejoré el SLO del servicio de 99,5 % a 99,95 %' son métricas concretas de confiabilidad
• Equipo y scope: 'tech lead para equipo de 6 ingenieros' o 'poseí diseño end-to-end e implementación del servicio de pagos' le dice al lector tu scope de responsabilidad. Sin esto, el trabajo podría ser cualquier cosa desde 'escribí una feature' hasta 'diseñé el sistema entero'
• Entrega: 'lancé 12 releases de producción en 18 meses con cero incidentes mayores' o 'entregué proyecto 3 semanas antes del cronograma paralelizando infraestructura y trabajo de feature' cuenta una historia de entrega
• Adopción: 'librería interna usada por 15+ equipos' o 'proyecto open source con 8K estrellas en GitHub' cuantifica el impacto del trabajo que no tiene métricas orientadas al cliente
• Cuando no tienes números específicos, da descripciones específicas. 'Migré el servicio de pagos de monolito a arquitectura event-driven, con cero downtime durante el cutover' es concreto incluso sin un número

El patrón: cada bullet debería responder '¿y qué?' Si un bullet dice 'desarrollé features', el y-qué es invisible. Si dice 'desarrollé flujo de checkout que llevó al aumento de conversión de 2,1 % a 3,2 % durante el experimento de 6 semanas', el y-qué está ahí mismo. Reescribe bullets genéricos hasta que tengan un número o un resultado específico concreto.

Open source, side projects, hackathons

La contratación de ingeniería valora las contribuciones fuera del trabajo pagado como evidencia de compromiso genuino con el oficio. Cómo manejarlas en el CV:

• Contribuciones open source: incluye si son sustantivas. 'Maintainer de X (descripción del proyecto, 8K estrellas)' es señal alta. 'Contribuí bug fix a librería popular Y' es señal media. 'Submití PR al proyecto Z' es señal baja a menos que el PR fuera sustancial
• Lista la naturaleza de la contribución: maintainer, contribuidor regular, contribuidor ocasional, contribuidor de una sola vez. La distinción importa y el enmarque honesto construye credibilidad
• Si has creado una librería o herramienta open source popular, lidera con ella en el CV. Un proyecto open source ampliamente usado es una de las señales más fuertes posibles de capacidad de ingeniería
• Side projects: incluye 2-3 de los más fuertes en una sección Proyectos. Salta side projects que son seguimientos de tutorial, a medio terminar o solo existen como repos privados
• Hackathons: incluye solo si ganaste o quedaste en uno notable. Un 2do lugar en un hackathon universitario o industrial mayor vale la pena listar; participación en un hackathon de universidad no, a menos que seas muy junior
• Proyectos internos de empresa: usualmente no cuentan como 'open source' aunque se discutan públicamente. Inclúyelos bajo experiencia laboral en su lugar
• Involucramiento en comunidad: organizador de meetup, ponente de conferencia, invitado de podcast, escritor técnico — incluye estos si son sustantivos. Señalizan un ingeniero que se involucra con la comunidad más amplia en lugar de solo hacer su trabajo
• Sé honesto sobre el scope. 'Contribuí a React' podría significar 'abrí un issue que fue cerrado sin PR' o 'escribí 30 PRs que fueron lanzados'. La afirmación del CV y la evidencia de GitHub tienen que coincidir

El rol de open source y side projects cambia con la seniority. A nivel junior, son evidencia esencial de ser un ingeniero practicante. A nivel mid, diferencian. A nivel senior, señalizan compromiso continuo con el oficio más allá del trabajo del día. Calibra la prominencia a tu etapa de carrera.

Educación y certificaciones — qué importa

Los roles tech ponderan educación y certificaciones muy diferente a otras industrias. El panorama actual:

• Ingenieros junior (0-2 años): la educación importa. Título de Ciencias de la Computación o relacionado de una institución conocida tiene peso. Lista educación prominentemente, cerca de la parte superior del CV
• Ingenieros mid-level (3-7 años): la educación importa menos. El historial laboral es la señal primaria. Mueve educación a la parte inferior del CV a menos que tengas un título particularmente notable (escuela top-tier, título avanzado en campo relevante)
• Ingenieros senior (8+ años): la educación es casi irrelevante para la mayoría de los roles. Una entrada de una línea en la parte inferior es suficiente. La excepción son roles que valoran explícitamente credenciales académicas (research engineering, ciertos roles ML/AI)
• Graduados de bootcamp: lista el bootcamp. El mercado de contratación para graduados de bootcamp ha madurado; bootcamps reputados (Hack Reactor, App Academy, Lambda School históricamente) son reconocidos. Empareja con proyectos fuertes para compensar el tiempo más corto de aprendizaje
• Ingenieros autodidactas sin educación CS formal: lidera con proyectos e historial laboral. Lista el aprendizaje auto-dirigido ('autodidacta, enfocado en desarrollo web full-stack desde 2019') honestamente. No inventes credenciales, pero no te sientas obligado a listar ninguna si no las tienes
• Certificaciones AWS / GCP / Azure: importan para roles enfocados en cloud (DevOps, SRE, cloud architect, ingeniería de infraestructura). Lista el nivel específico de certificación (Associate, Professional, etc.)
• Certificaciones de seguridad (CISSP, OSCP, CEH): importan para roles de seguridad. Lista con fecha obtenida
• Certificaciones generales de software (Oracle Java, Microsoft .NET): en gran parte ignoradas. Listarlas en un CV de senior engineer es relleno
• Completaciones de cursos online (Coursera, Udemy, edX): generalmente no listes. Señalizan que puedes completar un curso, no que puedes hacer el trabajo. Excepción: completar un programa especializado (Stanford ML, especialización de deep learning de Andrew Ng) podría justificar una mención de una sola línea
• PhD: lista en la parte superior si es reciente y relevante; mueve abajo con seniority. PhD es una señal fuerte para roles orientados a investigación y una señal neutra (a veces ligeramente negativa por percepción de 'demasiado académico') para roles de ingeniería de producto

El patrón: la educación es una señal de junior engineer que se desvanece con el tiempo. Las certificaciones son señales de roles especializados que importan cuando son relevantes y son relleno cuando no lo son. Calibra la prominencia de estas secciones a dónde estás en tu carrera.

CV tech remote-friendly — la nueva norma

Una parte significativa de los roles de ingeniería en 2026 son remotos o híbridos. El CV debería señalizar remote-readiness, que ahora es una consideración de contratación en sí misma:

• Si tienes experiencia de trabajo remoto, márcalo: 'Senior Engineer (remoto), Acme Corp, 2022-2025'. Los reclutadores escanean por esto; la experiencia remota es una señal positiva para roles remotos
• Ubicación: incluye ciudad y país actual, pero señaliza flexibilidad si es relevante. 'Madrid, España (abierto a remoto, zonas horarias UE)' o 'San Francisco, CA (abierto a remoto dentro de US)'. 'Abierto a reubicación' vago es más débil que disponibilidad específica
• Zona horaria: lístala si aplicas para roles remotos en una geografía diferente. 'Zona horaria: CET (UTC+1)' hace la programación más clara
• Experiencia con herramientas de comunicación: en un contexto relevante a remoto, mencionar experiencia con Slack, Notion, Linear, Figma, pair programming basado en video y workflows async-first señaliza fit para la cultura de ingeniería remota
• Lenguaje de auto-dirección: 'lideré el proyecto end-to-end desde spec hasta deployment' señaliza la autonomía que requiere el trabajo remoto. 'Trabajé con el equipo para entregar X' es neutro; 'impulsé X de concepto a lanzamiento independientemente' es más fuerte para remoto
• Documentación y escritura: destaca cualquier escritura técnica, autoría de design docs o contribuciones RFC. Los equipos remotos sobre-confían en la comunicación escrita; los ingenieros que escriben bien son más fáciles de contratar remotamente
• Señales de superposición de zona horaria: si has trabajado explícitamente a través de zonas horarias (un ingeniero US trabajando con un equipo en Berlín, o viceversa), menciónalo. La habilidad de colaboración asíncrona es no-trivial
• Evita señalizar inflexibilidad remote-only si estás abierto a onsite. El sesgo todavía existe en algunas empresas; si eres flexible, señaliza flexibilidad

El remote-friendliness se ha movido de ser una preferencia del candidato a ser un criterio de contratación. Mostrar en el CV que has trabajado remotamente, comunicado asíncronamente y operado con auto-dirección es ahora parte del trabajo del CV — no solo para roles completamente remotos sino para híbridos e incluso algunos roles onsite donde el remote-readiness es tratado como señal de calidad.

CVs para junior vs mid vs senior vs staff/principal

El énfasis del CV de ingeniería cambia dramáticamente a través de las etapas de carrera. Lo que funciona para un CV junior hundirá un CV staff y viceversa:

La declaración de resumen para roles técnicos

La declaración de resumen en la parte superior de un CV tech es opcional para roles junior y cada vez más importante de mid-level hacia arriba. Cómo escribir una que haga trabajo:

• Longitud: 3-5 líneas. Lo suficientemente larga para enmarcar tu especialidad, lo suficientemente corta para que el lector realmente la lea
• Lidera con años de experiencia y especialidad primaria: 'Ingeniero backend con 7 años de experiencia diseñando sistemas distribuidos de alta escala, principalmente en Go y Python.' Esto es lo primero que ve el lector y debería anclar todo el CV
• Sigue con una oración sobre el tipo de trabajo que haces bien: 'Me enfoco en la frontera entre diseño de API e infraestructura, con experiencia profunda en arquitecturas event-driven e internos de base de datos.'
• Termina con lo que buscas: 'Buscando roles senior+ donde pueda liderar el diseño de un sistema backend crítico y crecer al scope staff en los próximos 2 años.'
• Evita descriptores genéricos: 'apasionado', 'orientado a resultados', 'atento al detalle'. Estos son cero-señal y se leen como relleno
• Evita resumir el resto del CV. El resumen debería añadir información que el lector no puede obtener escaneando el resto — específicamente tu área de especialidad, tu dirección de carrera y qué te hace un candidato coherente
• Adapta por aplicación. El resumen es el lugar más fácil para señalizar que el CV está dirigido a este rol específico. Un resumen escrito para un rol de infraestructura backend en una empresa de bases de datos debería leerse diferente del resumen de la misma persona escrito para un rol de backend de producto en una empresa SaaS
• Salta el resumen completamente si eres un ingeniero junior. En esa etapa de carrera, el resumen arriesga relleno sin añadir señal; deja que tu trabajo hable por sí mismo

La declaración de resumen es real estate de alto apalancamiento en la parte superior del CV. Usada bien, le dice al lector quién eres como ingeniero en 3-5 líneas y enmarca todo lo que sigue. Usada mal (adjetivos genéricos, aspiraciones vagas), es relleno que desplaza señal real.

Elecciones de formato de CV tech — una página vs dos páginas

La pregunta de una página vs dos páginas es más matizada para CVs tech que para otras industrias. El marco:

• Una página: ingenieros junior (0-3 años), la mayoría de ingenieros mid-level (3-7 años) e ingenieros en mercados donde una página es la norma cultural (la mayoría de la industria tech de US)
• Dos páginas: ingenieros senior con experiencia sustancial (8+ años), ingenieros staff/principal con scope significativo a comunicar, ingenieros en mercados donde dos páginas son normales (la mayoría de Europa, especialmente Alemania, Francia, UK)
• Nunca tres páginas. Si no puedes encajar tu CV en dos páginas, el problema es la edición, no el espacio. Corta roles antiguos a resúmenes de una línea, corta detalle de roles de carrera temprana, recorta proyectos menos relevantes
• Si tienes un documento más largo estilo CV (estilo académico, con publicaciones, charlas, patentes), mantenlo separado. El CV es el resumen orientado al reclutador; el documento más largo es para solicitudes de seguimiento
• Formato: una sola columna o dos columnas? Una sola columna es más segura para ATS. Si usas dos columnas (sidebar para habilidades/contacto, columna principal para experiencia), prueba el parsing ejecutando el PDF a través de un resume parser online antes de enviar
• Fuente: quédate con fuentes estándar (Calibri, Helvetica, Arial, Source Sans, Inter). Las fuentes de diseñador pueden romper el parsing de ATS. Texto de cuerpo 10-11pt, headings 12-14pt
• Color: mínimo. Un color de acento para los headings de sección está bien; el diseño en color completo es innecesario y puede romper ATS. El contenido es la señal, no el diseño
• Foto: no en CVs tech de US. En países europeos donde las fotos son normales (Alemania, Francia), incluye un headshot profesional
• Formato de archivo: PDF. Siempre PDF. Los documentos Word se reflujan en máquinas diferentes y se ven rotos; los PDFs renderizan consistentemente. Nombra el archivo consistentemente: 'Nombre-Apellido-CV.pdf' o 'Nombre-Apellido-SeniorEngineer-CV.pdf'

Las decisiones de formato deberían servir al contenido, no distraer de él. Un CV tech que usa fuentes estándar, estructura simple y color modesto es más legible que uno que intenta verse como un portfolio de diseño. La excepción es ingeniería de diseño o roles front-end donde alguna sofisticación visual en el CV mismo es una señal relevante — pero incluso ahí, la moderación se lee como confianza.

Coordinar CV, LinkedIn, GitHub y sitio personal

El CV tech es un documento en una presencia online coordinada. Los hiring managers de ingeniería mirarán múltiples superficies, y la inconsistencia entre ellas es una señal negativa. El playbook de coordinación:

• LinkedIn: debería contar la misma historia que el CV en términos de roles, fechas y scope. El headline puede ser más aspiracional ('Senior Backend Engineer interesado en sistemas distribuidos y developer tooling'), pero la sustancia debería empatar. Un LinkedIn que contradice el CV (fechas diferentes, títulos diferentes, scope diferente) destruye la confianza
• GitHub: debería estar vivo. Commits recientes, readme de perfil poblado, 4-6 repositorios fijados que representan tu mejor trabajo, READMEs de repo limpios. Un GitHub vacío enlazado desde el CV es peor que ningún enlace. Si GitHub es escaso, invierte un fin de semana en limpiarlo antes de enviar el CV
• Sitio personal: opcional pero poderoso cuando se hace bien. Una página simple con una bio de un párrafo, destacados de proyectos, un enlace de descarga de CV e información de contacto es suficiente. Evita Flash, formularios de contacto rotos, enlaces muertos, fechas de última actualización de 2020
• Consistencia de nombre e identidad: usa el mismo nombre y headshot a través de CV, LinkedIn, GitHub, sitio personal. Los reclutadores hacen cross-reference; un 'James Smith' en el CV que es 'Jim Smith' en LinkedIn crea fricción
• Dirección de email: consistente a través de todas las superficies. Usa un email profesional (tunombre@tudominio.com o nombre.apellido@gmail.com), no un email de universidad o un username de 2005
• Número de teléfono, ubicación y zona horaria: consistentes a través de superficies. Señales de ubicación conflictivas se ven como falta de atención
• Si tienes un portfolio de trabajo publicado (posts de blog técnico, charlas, papers), enlaza desde el CV a la fuente canónica — tu sitio personal o un perfil centralizado, en lugar de 10 enlaces separados
• Audita antes de aplicar. Antes de enviar el CV, haz clic en cada enlace en él como si fueras un reclutador. Mira el perfil LinkedIn con ojos frescos. Navega el GitHub. Si encuentras algo que contradice o socava el CV, arréglalo antes de aplicar

El hiring manager construye una sola impresión de ti desde las superficies coordinadas, no impresiones separadas de cada una. El CV que apunta a una presencia online coherente se lee como más creíble que uno con un CV fuerte y un LinkedIn/GitHub débil o contradictorio. Los treinta minutos de limpieza a través de superficies es uno de los usos de mayor apalancamiento del tiempo en una búsqueda de trabajo tech.