A forma de encaixar anos de trabalho de engenharia numa página não é reduzir cada projeto a um fragmento ilegível. É escolher os três ou quatro projetos que melhor apoiam o cargo a que se candidata, agrupar o resto numa única linha perto do final, e escrever cada projeto que sobrevive como uma linha compacta em vez de um parágrafo. Uma página que tenta conter doze projetos com o mesmo peso acaba por não apresentar bem nenhum deles; uma página que mantém quatro com todo o seu peso, com o resto apenas mencionado de passagem, lê-se como um currículo mais forte, mesmo dizendo tecnicamente menos.
Decidir que projetos merecem um lugar
Comece por ordenar os projetos consoante a sua adequação ao cargo específico, não consoante o orgulho que sente por cada um. Um projeto que usou a mesma tecnologia do cargo pretendido, resolveu um problema semelhante, ou mostra responsabilidade sobre um sistema inteiro em vez de uma pequena parte, merece um lugar à frente de um projeto tecnicamente impressionante mas afastado daquilo que o cargo realmente precisa. A atualidade também importa, embora menos do que a relevância: um projeto mais antigo mas muito alinhado com o cargo pretendido costuma vencer um recente que não está. Três ou quatro projetos costumam bastar para uma página quando também há entradas de experiência; um currículo composto sobretudo por projetos, com pouca experiência remunerada ainda, pode alargar-se a cinco ou seis antes de a página começar a parecer sobrecarregada.
Um erro comum é ordenar pelo esforço em vez de pela relevância: um projeto que levou seis meses de fins de semana pode parecer merecer o primeiro lugar só pelo tempo investido, mesmo quando um projeto mais pequeno de duas semanas corresponde de forma muito mais direta ao que o cargo pretendido faz realmente no dia a dia. O esforço é invisível para um leitor que apenas vê a linha final na página, por isso vale a pena deixá-lo deliberadamente de lado e reordenar apenas pela adequação antes de fechar quais os quatro projetos escolhidos.
Agrupar os mais pequenos numa única linha
Um projeto que não entra no grupo de destaque não tem de desaparecer. Uma única linha perto do final da secção de projetos, algo como "Também construído: um bot de notificações para Slack, uma pequena CLI para pesquisa de logs, e dois scripts de ferramentas internas", mantém-nos visíveis sem lhes dar o mesmo espaço das entradas em destaque. Esta linha desempenha um papel real: sinaliza que os projetos em destaque foram escolhidos deliberadamente e não são tudo o que alguma vez construiu, e dá a um leitor interessado um ponto de partida para perguntar sobre eles numa conversa, sem obrigar cada projeto a passar pela mesma descrição completa.
Escrever uma entrada de projeto numa linha
Uma entrada de projeto numa linha ainda precisa de responder ao que é, com que foi construído, e o que resultou disso, apenas comprimido numa linha em vez de três. "Painel de métricas - React e uma pequena API Node a extrair de um fluxo de eventos interno, substituiu três folhas de cálculo separadas que a equipa usava para seguir manualmente os mesmos números" cabe confortavelmente numa linha e ainda assim diz algo concreto ao leitor. Reduzir um projeto a um título nu sem contexto, pelo contrário, poupa espaço mas não conserva nenhuma das informações que faziam a linha valer a pena incluir à partida. O objetivo é densidade, não brevidade pela brevidade: uma linha que diz menos com menos palavras não é automaticamente uma linha melhor.
Exemplo ilustrativo: uma lista de projetos reduzida
Exemplo ilustrativo. Um candidato tem nove projetos pessoais e ligados ao trabalho construídos ao longo de vários anos. Antes da redução, cada um tem a sua própria entrada de duas linhas, e só a secção de projetos ocupa quase uma página inteira. Depois da redução: quatro projetos são mantidos com todo o detalhe, escolhidos por corresponderem mais de perto à tecnologia e ao âmbito do cargo pretendido, cada um escrito numa linha que indica o que é, o que usou e o que mudou por causa dele. Os cinco restantes são reunidos numa única linha final que os nomeia brevemente. A secção de projetos ocupa agora cerca de um terço do espaço de antes, e as quatro entradas em destaque leem-se com mais atenção porque deixaram de competir com outras cinco pela mesma atenção.
Manter a página legível ao reduzir
Fazer caber mais numa página reduzindo o tamanho da letra ou as margens para além de um nível confortável de leitura troca um problema por outro pior: uma página que tecnicamente contém tudo mas é desconfortável de ler perde mais do que uma página que honestamente precisava de um formato um pouco mais longo. A redução deve vir da escolha do que incluir, não de tornar o próprio texto mais difícil de ler. Se quatro entradas de projeto completas mais uma linha agrupada ainda não couberem a um tamanho de leitura normal, isso costuma ser sinal para cortar um quinto projeto em vez de encolher mais o texto, ou sinal de que este currículo em particular justifica honestamente uma segunda página.
Quando projetos e experiência competem pela mesma página
Para um engenheiro com vários anos de experiência remunerada e uma longa lista de projetos pessoais, as duas secções competem pelo mesmo espaço limitado, e a experiência deve normalmente vencer essa competição primeiro. Um leitor que avalia um engenheiro em meio de carreira geralmente valoriza mais o trabalho remunerado e com responsabilidade do que um projeto pessoal, pelo que reduzir a secção de projetos às suas poucas entradas em destaque, em vez de reduzir as entradas de experiência para abrir espaço a mais projetos, costuma ser o lugar mais seguro para encontrar o espaço extra de que um currículo de uma página precisa.
Construa o seu
Escolha um modelo pensado para trabalho de engenharia, como o modelo Developer, e percorra a sua própria lista de projetos com o mesmo filtro: que poucos projetos apoiam mais diretamente o cargo, e quais podem ser nomeados numa única linha final em vez disso. Para a questão mais geral de quanto deve medir um currículo antes de os projetos sequer entrarem em jogo, quanto deve medir um currículo cobre esses compromissos mais amplos, e apresentar projetos pessoais num currículo de engenheiro de software aprofunda como escrever uma única entrada de projeto assim que souber quais sobreviveram ao corte. Comece a reduzir e a reconstruir no gerador.