Internamente, todos consideram job description como um artefato de RH, mas a verdade é que ela já funciona como primeiro filtro técnico do processo e como o primeiro sinal público sobre a visão do time sobre o conceito de competência. Já vi essa dupla função ser ignorada dezenas de vezes pelos responsáveis da contratação quando da aprovação do texto, perdendo a chance de entregar mais do que um documento de campos obrigatórios do ATS (sistema de rastreamento de candidatos). Isto resulta em uma calibração enviesada pela comparação com vagas anteriores do próprio time e validado apenas contra a percepção do que se "parece uma vaga de sênior". Esta passividade cobra a conta em três meses, quando a empresa percebe que o funil entregou candidatos que correspondem perfeitamente ao anúncio, mas não ao trabalho real. Ainda pior, os candidatos que teriam correspondido nunca chegam sequer a se candidatar porque o texto sinaliza que o time não os reconheceria.
Na consultoria eu costumo identificar processos de escrita de job descriptions em três camadas separadas, que tendem a ser aglutinadas no texto original: o trabalho a ser feito, as condições operacionais e as competências que tornam alguém capaz de executá-lo. Esta fusão produz formulações como "5 anos de Kotlin em ambiente de microsserviços com Kafka e Kubernetes", que mistura stack, contexto e senioridade numa única string. O candidato que lê o requisito não consegue identificar o que é negociável. Candidatos com repertório transferível, ou seja, com competência conceitual e estrutural, não necessariamente vinculada a uma ou outra tecnologia, simplemente assumem que a stack pedida não é negociável e se removem voluntariamente do processo, enquanto candidatos com correspondência literal, mas muitas vezes sem fit real, se candidatam e avançam.
Se pretende capturar os verdadeiros talentos alinhados à posição, suas descrições do trabalho precisam ser concretas e verificáveis. Em vez de "desenvolver e manter microsserviços", o texto deve descrever o estado atual do sistema e a próxima transição: "o time opera uma plataforma de pagamentos processando cerca de 2 mil transações por segundo, distribuída em 12 serviços, e está migrando o núcleo transacional pra um modelo de event sourcing ao longo dos próximos dezoito meses". Essa formulação dá ao candidato informação suficiente pra avaliar se o problema é interessante e se a direção técnica se encaixa na sua experiência. Mais do que isso, candidatos sêniores lêem este parágrafo como um teste inverso: se o hiring manager consegue descrever o sistema com precisão, o time provavelmente sabe o que está fazendo.
Outra orientação costumeira na consultoria é que as competências também não devem ser descritas pela stack, mas pelo comportamento observável. "Experiência construindo sistemas distribuídos com garantias de consistência explícitas" é uma formulação que captura o que o time precisa sem amarrar a contratação a um ecossistema específico. Candidatos vindos de Erlang, Java, Go, C# ou Rust se reconhecem nessa descrição. Claro que a avaliação real do fit continua acontecendo na entrevista, que é o único lugar onde essa avaliação pode escalar sem degradação. Não se deve ceder ao impulso de tentar substituir a entrevista por um filtro de palavras-chave. É uma tentativa de otimizar o custo errado, porque apesar de reduzir o custo de triagem, em troca estaríamos abrindo mão da qualidade do funil. E o grande problema desta troca é que a redução de qualidade só aparece doze meses depois, refletida na métrica de retenção.
Além das questões estritamente técnicas, as condições de trabalho também precisam ser explícitas porque determinam quem consegue executar. A composição do time, a maturidade do tooling, a expectativa de on-call, o modelo de revisão de código e a superfície de decisão do cargo precisam estar claros. Um Principal Engineer que entra num time sem autoridade de arquitetura não consegue entregar mais do que valor marginal. Um sênior que entra esperando mentoria num time sem Principal vai se frustrar. A descrição de trabalho que omite essas condições está empurrando pra entrevista uma calibragem que deveria ter acontecido no anúncio da vaga. Isto aumenta o ruído no funil, o que reflete diretamente no custo.
De maneira geral, job descriptions mais genéricas geram mais candidaturas, o que aumenta o custo de triagem humana. Times que optam por esse caminho precisam investir em etapas adicionais para reduzir este impacto. Minha sugestão é geralmente uma triagem técnica leve (screening de trinta minutos focado em raciocínio, não em sintaxe) que sirva como substituto do filtro de palavras-chave. O retorno deste investimento é um funil com mais candidatos dotados de repertório transferível (conceito e estrutura), e a entrevista final passa a escolher entre perfis genuinamente competentes ao contrário daqueles que apenas correspondem literalmente às stacks citadas.
Por fim, trago uma consequência de segunda ordem que raramente é discutida, mas que considero importante. Mecanismos de busca e modelos generativos vão indexar suas descrições listadas publicamente, o que significa que ela vai contribuir para o branding de engenharia da empresa ao longo do tempo. Publicar descrições concretas de sistemas e usar uma formulação de competências por comportamento são atitudes lidas pelo mercado como domínio do problema, indicando que seu time sabe o que está construindo. Descrições genéricas, principalmente aquelas copiadas de concorrentes e amarradas a stack, evidenciam times que delegaram a definição de competência ao ATS. Essa leitura reflete na escolha de quem se candidata espontaneamente e quem aceita ser abordado por recrutador.
Reescrever job descriptions é um processo barato, e seu efeito composto sobre dezenas de contratações ao longo de anos define a composição técnica do time. Na minha opinião, equipes de recrutamento que tratam a definição da descrição como um decisão de engenharia estão fazendo a única escolha com retorno mensurável sobre a qualidade do time no longo prazo.