Una lista larga de lenguajes de programación, frameworks y herramientas se lee como un muro de texto cuando ocupa una sola línea ininterrumpida, y la solución no es acortar la lista sino agruparla: dividir las mismas habilidades en unas pocas categorías cortas y claramente etiquetadas, como Lenguajes, Frameworks y Cloud, para que quien recorra la página con la vista encuentre en segundos los dos o tres elementos que le importan, en lugar de leer toda la línea de principio a fin.
Por qué una sola línea larga sin ordenar es difícil de leer de un vistazo
Una línea de habilidades con veinte elementos separados por comas te pide hacer dos cosas a la vez: encontrar los elementos relevantes para el puesto que se busca cubrir, y descartar mentalmente el resto mientras lo haces. La mayoría de quienes contratan dedican muy poco tiempo a la primera lectura de un currículum, y una lista plana no les da ningún punto de apoyo salvo lo que por casualidad esté cerca del principio o del final de la línea. Una lista agrupada elimina ese trabajo de clasificación para el lector: una etiqueta de categoría como Cloud o Bases de datos le indica exactamente dónde mirar, y puede saltarse las categorías que no importan para ese puesto concreto sin leer cada elemento que contienen.
Agrupar también ayuda a quien sí le interesa la lista completa, no solo una parte. Una línea larga sin estructura interna obliga incluso a un lector cuidadoso a retener toda la lista en la cabeza para notar patrones, por ejemplo si los lenguajes se inclinan más hacia el backend o el frontend, o si la experiencia en cloud es amplia o limitada. Una vez que esas mismas habilidades quedan bajo encabezados, esos patrones se ven de un vistazo en lugar de tener que reconstruirlos.
Agrupar las mismas habilidades, no añadir otras nuevas
Agrupar es un cambio de formato, no de contenido: el conjunto de habilidades subyacente permanece exactamente igual, y el trabajo consiste en decidir a qué categoría pertenece cada una y elegir una etiqueta corta y precisa para esa categoría. Una división inicial habitual es Lenguajes, Frameworks, Datos y Cloud, con una categoría Herramientas como cajón general para editores, herramientas de build y control de versiones, aunque las categorías adecuadas dependen por completo de lo que realmente contenga la lista. Una lista corta de solo seis o siete elementos rara vez se beneficia de dividirse en cuatro categorías separadas; agrupar merece la pena cuando la lista es lo bastante larga como para que el lector tenga que saltarse elementos que no le interesan para encontrar lo que busca.
Vale la pena resistir la tentación de rellenar cada categoría una vez creada. Una categoría con un único elemento potente sigue mereciendo estar separada si ese elemento es realmente de otra naturaleza que los demás, en lugar de fundirlo en una categoría más amplia y vaga solo para evitar una lista corta. Una categoría que acaba con uno o dos elementos no es un problema; una categoría inventada solo para parecer más completa de lo que es suele leerse como relleno en cuanto el lector nota el patrón.
Elegir etiquetas de categoría que realmente signifiquen algo
Una etiqueta de categoría funciona cuando le dice al lector qué tipo de habilidad hay debajo antes de que lea un solo elemento, en lugar de un encabezado vago como Habilidades técnicas u Otras que podría describir casi cualquier cosa. Lenguajes, Frameworks, Bases de datos, Cloud e infraestructura y Herramientas son opciones habituales y autoexplicativas para un apartado de habilidades técnicas, y un lector familiarizado con el campo reconoce cada una al instante. A veces una etiqueta más específica merece su lugar frente a una genérica: Testing como categoría propia, separada de Frameworks, tiene sentido para alguien cuya experiencia en pruebas es un punto fuerte real que merece mencionarse por separado, en lugar de perderse en una línea de frameworks más larga y menos legible.
Las etiquetas también deben mantenerse coherentes con la forma en que el resto del currículum habla de esas mismas habilidades. Si el apartado de experiencia describe un proyecto construido con un framework concreto, el agrupamiento del apartado de habilidades debería usar ese mismo nombre en lugar de una variante más larga o más corta, para que el lector, o un sistema automatizado que lea el mismo documento, vea un vocabulario coherente en lugar de dos versiones del mismo dato.
Ejemplo ilustrativo: una línea sin ordenar convertida en categorías
Antes, como una línea sin ordenar: «JavaScript, TypeScript, Python, React, Next.js, Node.js, PostgreSQL, MongoDB, Docker, AWS, Git, Figma».
Después, agrupada en categorías:
- Lenguajes: JavaScript, TypeScript, Python
- Frameworks: React, Next.js, Node.js
- Datos: PostgreSQL, MongoDB
- Cloud y herramientas: AWS, Docker, Git, Figma
La lista subyacente de doce elementos no ha cambiado en absoluto, pero quien busca específicamente experiencia en bases de datos backend ahora puede ir directamente a la línea de Datos, en lugar de leer cada elemento de la frase original para encontrar PostgreSQL y MongoDB enterrados en medio.
Agrupar sin perjudicar cómo un sistema analiza el apartado
Una preocupación razonable sobre agrupar una lista de habilidades es si eso dificulta el trabajo de un sistema de seguimiento de candidaturas que escanea el documento buscando palabras clave concretas. Agrupar no elimina ninguno de los términos originales, solo añade una etiqueta de categoría corta encima de un subconjunto de ellos, de modo que cada habilidad nombrada en la lista plana original sigue presente en la versión agrupada y sigue siendo localizable por cualquier búsqueda de palabras clave que se ejecute sobre el documento. La guía cómo escribir un currículum compatible con sistemas de seguimiento de candidaturas trata las decisiones de maquetación que sí afectan de verdad al análisis automático, como las maquetas a varias columnas o el texto incrustado en imágenes, y agrupar habilidades en texto plano dentro de categorías etiquetadas no es una de ellas.
Construir un apartado de habilidades agrupado
La plantilla Classic de CVBuilderKit agrupa automáticamente un apartado de habilidades en categorías etiquetadas como parte de su maquetación, en lugar de dejar por completo en manos de quien la rellena la decisión de cómo dividir la lista, lo cual es una forma inicial razonable de copiar incluso en una plantilla que no lo impone. Al partir de una lista en blanco, conviene clasificar primero los elementos en categorías sobre papel o en un archivo de notas, comprobar que cada etiqueta se entiende con claridad para alguien ajeno al equipo directo, y luego empezar a construir el apartado cuando la forma parezca adecuada, manteniendo los términos exactos de la lista plana original en lugar de reformular ninguno de ellos en el proceso.