Uma lista longa de linguagens de programação, frameworks e ferramentas lê-se como uma parede de texto quando ocupa uma única linha contínua, e a solução não é encurtar a lista mas sim agrupá-la: dividir as mesmas competências em algumas categorias curtas e claramente identificadas, como Linguagens, Frameworks e Cloud, para que quem percorre a página com o olhar encontre em poucos segundos os dois ou três elementos que lhe interessam, em vez de ter de ler a linha toda.
Porque é que uma única linha longa e sem ordem é difícil de percorrer
Uma linha de competências com vinte elementos separados por vírgulas pede ao leitor que faça duas coisas ao mesmo tempo: encontrar os elementos relevantes para a função a que se candidata, e ir separando mentalmente tudo o resto enquanto o faz. A maioria dos recrutadores dedica muito pouco tempo à primeira leitura de um currículo, e uma lista plana não lhes dá nenhum ponto de apoio, além do que estiver, por acaso, perto do início ou do fim da linha. Uma lista agrupada retira esse trabalho de organização ao leitor: um rótulo de categoria como Cloud ou Bases de Dados indica-lhe exatamente onde olhar, e permite saltar as categorias que não importam para aquela função sem ter de ler cada elemento lá dentro.
Agrupar também ajuda quem está genuinamente interessado na lista inteira, não apenas numa parte dela. Uma linha longa sem estrutura interna obriga até um leitor atento a reter a lista inteira na memória para notar padrões, por exemplo se as linguagens pendem mais para o backend ou o frontend, ou se a experiência em cloud é ampla ou limitada. Quando as mesmas competências passam a estar sob títulos, esses padrões tornam-se visíveis de imediato, em vez de terem de ser reconstruídos pelo próprio leitor.
Agrupar as mesmas competências, sem acrescentar novas
Agrupar é uma alteração de formatação, não de conteúdo: o conjunto de competências subjacente mantém-se exatamente o mesmo, e o trabalho consiste em decidir a que categoria pertence cada uma e escolher um rótulo curto e preciso para essa categoria. Uma divisão inicial comum é Linguagens, Frameworks, Dados e Cloud, com uma categoria Ferramentas a funcionar como saco onde cabem editores, ferramentas de build e controlo de versões, embora as categorias certas dependam inteiramente do que a lista contém de facto. Uma lista curta de apenas seis ou sete elementos raramente beneficia de ser dividida em quatro categorias separadas; agrupar só compensa quando a lista é suficientemente longa para que o leitor, de outra forma, tivesse de passar por elementos irrelevantes até encontrar o que procura.
Vale a pena resistir à tentação de encher cada categoria depois de criada. Uma categoria com apenas um elemento forte continua a merecer ficar separada se esse elemento for genuinamente de natureza diferente dos restantes, em vez de o juntar a uma categoria maior e mais vaga só para evitar uma lista curta. Uma categoria que acaba com um ou dois elementos não é um problema; uma categoria inventada apenas para parecer mais preenchida do que na realidade é tende a ler-se como enchimento assim que o leitor repara no padrão.
Escolher rótulos de categoria que realmente signifiquem algo
Um rótulo de categoria funciona quando diz ao leitor que tipo de competência está por baixo antes de este ler um único elemento, em vez de um título vago como Competências Técnicas ou Outras, que poderia descrever quase tudo. Linguagens, Frameworks, Bases de Dados, Cloud e Infraestrutura e Ferramentas são escolhas comuns e autoexplicativas para uma secção de competências técnicas, e um leitor familiarizado com a área reconhece cada uma delas de imediato. Por vezes um rótulo mais específico merece o seu lugar em vez de um genérico: Testes como categoria própria, separada de Frameworks, faz sentido para um candidato cuja experiência em testes seja uma força genuína que valha a pena destacar sozinha, em vez de se perder numa linha de frameworks mais longa e menos legível.
Os rótulos também devem manter-se coerentes com a forma como o resto do currículo fala das mesmas competências. Se a secção de experiência descreve um projeto construído com um framework específico, o agrupamento na secção de competências deve usar o mesmo nome em vez de uma variante mais longa ou mais curta, para que o leitor, ou um sistema automatizado que leia o mesmo documento, veja um vocabulário coerente em vez de duas versões do mesmo facto.
Exemplo ilustrativo: uma linha sem ordem transformada em categorias
Antes, como uma linha sem ordem: "JavaScript, TypeScript, Python, React, Next.js, Node.js, PostgreSQL, MongoDB, Docker, AWS, Git, Figma."
Depois, agrupada em categorias:
- Linguagens: JavaScript, TypeScript, Python
- Frameworks: React, Next.js, Node.js
- Dados: PostgreSQL, MongoDB
- Cloud e ferramentas: AWS, Docker, Git, Figma
A lista subjacente de doze elementos não mudou em nada, mas um leitor à procura especificamente de experiência em bases de dados de backend consegue agora ir diretamente à linha Dados, em vez de ler cada elemento da frase original para encontrar o PostgreSQL e o MongoDB enterrados a meio dela.
Agrupar sem prejudicar a forma como um sistema analisa a secção
Uma preocupação razoável sobre agrupar uma lista de competências é saber se isso dificulta o trabalho de um sistema de seguimento de candidaturas que analisa o documento à procura de palavras-chave específicas. Agrupar não remove nenhum dos termos originais, apenas acrescenta um rótulo de categoria curto acima de um subconjunto deles, pelo que cada competência mencionada na lista plana original continua presente na versão agrupada e continua localizável por qualquer pesquisa de palavras-chave feita sobre o documento. O guia escrever um currículo compatível com sistemas ATS aborda as opções de layout que realmente afetam a análise automática, como layouts em várias colunas ou texto incorporado em imagens, e agrupar competências em texto simples dentro de categorias identificadas não é uma delas.
Construir uma secção de competências agrupada
O modelo Classic da CVBuilderKit agrupa automaticamente uma secção de competências em categorias identificadas como parte do seu layout, em vez de deixar inteiramente a quem o preenche a decisão de como dividir a lista, o que é uma forma inicial razoável a seguir mesmo num modelo que não o impõe. Ao partir de uma lista em branco, vale a pena ordenar primeiro os elementos por categorias em papel ou num ficheiro de notas, verificar se cada rótulo fica claro para alguém fora da equipa direta, e só depois começar a construir a secção quando a forma parecer adequada, mantendo exatamente os termos da lista plana original em vez de os reformular no processo.