Pra mim, anúncios pedindo cinco anos de experiência numa linguagem que tem quatro anos de vida não são erros de redação. Vejo o mesmo padrão em vagas que cobram sete anos num framework cuja primeira versão estável saiu há cinco, e em descrições que exigem "senior-level" em Kotlin pra uma base de código de três anos. São o subproduto de um processo de contratação que transferiu a avaliação de competência pro filtro de keyword, usando "anos de experiência em X" como proxy barato pra algo que ninguém quer medir de verdade.
Entre o segundo trimestre de 2022 e o mesmo período de 2025, a fatia de vagas de tecnologia pedindo cinco anos ou mais subiu de 37% pra 42%, segundo levantamento do Indeed Hiring Lab, enquanto a faixa de "2 a 4 anos" encolheu. O movimento começou no início de 2023, logo após a popularização de LLMs, e se correlaciona mais com a tentativa de proteger a senioridade do time contra a percepção de commoditização do que com qualquer mudança real na natureza do trabalho. A vaga continua pedindo que alguém resolva o mesmo problema. O filtro subiu porque o recrutador precisa de um critério que reduza volume, e anos numa stack específica é o critério mais fácil de aplicar sem envolver alguém tecnicamente competente na triagem.
Recrutadores operam sob pressão de volume: mais de 99% usam filtros de keyword em ATS, e 44% filtram explicitamente por anos de experiência. A stack entra como "knockout requirement": quem não tem a string exata no currículo é removido antes de qualquer leitura humana. Isso produz um funil em que o candidato que passou dez anos em Java e dois em Kotlin é tratado como menos qualificado do que quem passou cinco anos só em Kotlin, mesmo quando os dois resolveriam o mesmo problema com diferença de semanas. O filtro mede permanência num ecossistema específico, uma variável diferente de competência e frequentemente inversamente correlacionada com capacidade de transferência.
O efeito colateral é previsível. Engenheiros com histórico poliglota são removidos desproporcionalmente, porque seu tempo acumulado em cada linguagem individual é menor, mesmo que o tempo total de engenharia seja maior. Quem fez carreira migrando entre Java, Go, Python e Rust em contextos diferentes aparece no filtro como "2 anos de Go", enquanto quem nunca saiu de Go aparece como "6 anos de Go". O primeiro traz repertório arquitetural e calibragem sobre quando a linguagem importa e quando é detalhe; o segundo traz profundidade numa convenção local. A job description, como está escrita, prefere o segundo. O time descobre o custo dessa preferência meses depois, quando precisa tomar uma decisão que o ecossistema local não oferece precedente, e não há ninguém no time com o repertório pra enquadrar a decisão como um problema conhecido em outro contexto.
Na minha avaliação, o trade-off existe e precisa ser nomeado. Exigir familiaridade com a stack reduz ramp-up inicial: um engenheiro que já escreve Kotlin idiomático entrega PRs na primeira semana, enquanto alguém vindo de outra linguagem precisa de três a oito semanas pra calibrar convenções, tooling e padrões do time. Pra posições curtas ou times pequenos sem banda pra onboarding, o ganho é real. Mas o cálculo muda em horizontes de seis meses ou mais. O ramp-up se dilui, e o que permanece é a capacidade de resolver problemas que o time ainda não encontrou, capacidade que correlaciona mais com amplitude de repertório do que com profundidade numa sintaxe.
Vi recentemente um time contratar uma engenheira com background em Haskell pra uma posição em Go. Na terceira semana ela escrevia Go idiomático; no terceiro mês havia refatorado o sistema de tipos de um domínio crítico de um modo que ninguém com "experiência em Go" havia proposto, porque o repertório dela em tipos algébricos tornava óbvias decisões que o time tratava como restrição fixa da linguagem. O filtro original teria removido essa candidata.
Há uma consequência de segunda ordem. A job description funciona como sinal público sobre como o time pensa sobre competência técnica. Uma vaga que exige cinco anos numa linguagem específica comunica que o time define senioridade por permanência num ecossistema fechado. Candidatos seniores leem esse sinal. Os que têm repertório poliglota se auto-selecionam pra fora, porque reconhecem que o time provavelmente também define promoção, code review e arquitetura pelos mesmos critérios rasos. O resultado é um pool enviesado em direção ao perfil que o filtro descreve. Esse viés reforça a monocultura do time, que torna a próxima job description ainda mais restritiva. O ciclo se fecha, e o time gradualmente perde a capacidade de reconhecer que perdeu alguma coisa.
Na minha análise, a correção passa por reescrever a job description. Em vez de "5 anos de experiência em Kotlin", a formulação que descreve o trabalho real é algo como "experiência construindo e operando sistemas em produção numa linguagem com tipagem estática e runtime de JVM ou similar". Isso captura o que o time precisa, familiaridade com sistemas de tipos e garbage collection e o debugging que esses ambientes exigem, sem amarrar a contratação a uma string específica. Candidatos vindos de Scala, Java, C#, Swift e até TypeScript passam a ser legíveis pelo filtro. O time precisa então avaliar raciocínio em entrevista, que é exatamente o trabalho que o filtro de keyword tentava evitar. É mais caro, e é o único processo que escala sem degradar a composição do time ao longo do tempo.