As Novas Gerações Estão Bem
Não contratar engenheiros juniores não vai resolver o problema que você acha que tem
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
Eu estava ouvindo um podcast recentemente em que o entrevistador perguntou ao CTO de uma empresa de tecnologia muito grande se eles ainda estavam contratando engenheiros juniores. Não consigo superar o fato de que essa era uma pergunta séria.
Ainda estamos passando pela névoa da mudança que a IA trouxe para a engenharia de software. As empresas estão experimentando, algumas fazendo grandes afirmações e a maioria se sentindo atrasada na adaptação. Essa ansiedade leva a argumentos e decisões simplistas (olá, tokenmaxxing!) enquanto as empresas tentam encontrar apostas simples que esperam que as coloquem à frente da curva.
“Devemos contratar engenheiros juniores?” é uma dessas perguntas. Quem está entrando agora enfrenta uma dificuldade real, com menor crescimento na área de tecnologia e ferramentas capazes de realizar as tarefas que essas pessoas fariam. Não quero minimizar isso. Mas esse enquadramento é prejudicial para os candidatos e, mais importante ainda, para as empresas.
Engenheiros juniores são necessários hoje e continuarão sendo necessários. Se a sua organização tem dúvidas sobre isso, talvez você esteja enfrentando um problema diferente.
Esse não é um tema novo
A motivação para evitar contratar engenheiros menos experientes não é nova. Empresas de tecnologia há muito tempo buscam contratar apenas profissionais mais experientes, com base na teoria de que as pessoas precisam ser donas do próprio trabalho de ponta a ponta, o que tornaria melhor investir em experiência.
Essa era a situação em uma empresa em que trabalhei. Quando entrei, a política era contratar apenas engenheiros seniores ou acima. O argumento era que, devido à complexidade do nosso sistema, engenheiros juniores poderiam ser um risco, entregando mudanças que quebravam as coisas. Uma das consequências visíveis e irônicas dessa decisão era a dificuldade que os gestores enfrentavam para tirar tarefas simples do papel, já que todos se sentiam acima delas.
Mudamos a política, primeiro experimentando contratar algumas pessoas menos experientes e, depois, montando um programa de estágio que se tornou uma porta de entrada para recém-formados. Alguns anos depois, alguns desses estagiários eram engenheiros plenos que superavam pessoas que havíamos contratado como seniores.
A versão dessa discussão com o tempero da IA não é um insight novo. É uma preferência antiga (e equivocada), vestindo roupas novas.
As premissas erradas
A pergunta sobre engenheiros juniores se apoia em algumas premissas, e todas elas são falhas.
A mais óbvia é o problema de retenção de talentos. Você vai perder pessoas por rotatividade. Engenheiros vão ganhar experiência e buscar desafios maiores. Você vai precisar contratar mais gente. Nesse momento, ou você vai ao mercado, pagando em tempo e custo de recrutamento por alguém que precisa de seis meses para aprender os seus sistemas, ou você promove alguém que já os conhece. A IA certamente está impactando o tamanho dos times, mas esse tamanho será maior que zero.
Outra premissa central é a de que a indústria está mudando tanto, e o papel do engenheiro será tão diferente, que contratar alguém que não é experiente agora seria um desperdício, já que essa pessoa talvez não consiga se adaptar à mudança.
Uma história que costumo contar sobre esse tema é que, quando comecei minha carreira como consultor, passávamos a primeira semana de um projeto configurando nossos ambientes. Os clientes pagavam por um time de engenharia completo a taxas muito caras para passar uma semana colocando um repositório de controle de versão e um build de CI para rodar. E isso quando tínhamos a sorte de estar em um lugar onde os computadores não demoravam semanas para ser provisionados. Um trabalho que hoje provavelmente pode ser feito com um prompt e 10 minutos de espera.
Eu sobrevivi, mas minhas habilidades de configurar um repositório subversion não. Se a indústria está mudando tão rápido assim, a experiência é o ativo que se deprecia, e quem argumenta que juniores não conseguem se adaptar é quem tem mais coisa para desaprender.
A última premissa, e provavelmente a mais enraizada, é a de que, se o trabalho do engenheiro se torna criar prompts e gerenciar agentes que executam as tarefas simples (e complexas), o que um engenheiro júnior vai fazer?
O principal problema com esse raciocínio é que ele reduz o trabalho de engenharia à entrega de código. O papel de um engenheiro antes da IA era entregar valor para o cliente construindo software. O papel de um engenheiro depois da IA continua sendo entregar valor para o cliente, agora por meio de agentes que escrevem o código. O objetivo continua o mesmo e o julgamento continua sendo necessário. No momento, o julgamento técnico ainda é uma parte importante do papel. Talvez isso seja minimizado no futuro (assunto para outro post), mas então será substituído pelo julgamento focado em valor. Isso realmente resolve o problema? Essa mudança combina com as funcionalidades que já existem?
Mesmo em um mundo totalmente orientado por IA, o papel do engenheiro continuará sendo entregar valor.
E me parece óbvio que, se o papel de um engenheiro é liderar um projeto sozinho orquestrando múltiplos agentes, o trabalho do engenheiro júnior será liderar projetos simples sozinho orquestrando múltiplos agentes. Independentemente do que o futuro reserve, sempre haverá versões mais simples e mais complexas da tarefa a ser feita.
O problema escondido
As premissas acima mostram como a pergunta sobre engenheiros juniores costuma estar equivocada na conversa atual da indústria de tecnologia. Mas elas também expõem um problema mais profundo: as empresas de tecnologia têm dificuldade de enxergar um lugar para juniores porque insistem em olhar a engenharia como uma disciplina isolada dentro do desenvolvimento de produto.
Estamos em 2026, décadas depois de a indústria ter rejeitado o waterfall como um método produtivo para entregar software, mas continuamos recaindo nele. Times de software ainda costumam se parecer com uma linha de produção, onde requisitos vindos de product managers trabalhando isoladamente são transformados em design por designers trabalhando isoladamente, e então entregues a líderes técnicos que dividem o trabalho em tarefas simples, que são atribuídas aos membros menos experientes do time. Se esse é o processo, então é natural pensar que você pode substituir a última etapa por agentes.
No entanto, o problema aqui não é o papel dos engenheiros juniores. É o sistema. O desenvolvimento de produto deveria ser uma colaboração entre produto, design e engenharia na entrega de valor para o cliente. Engenheiros não estão apenas escrevendo código, eles estão trazendo perspectiva e alternativas sobre como resolver um problema do cliente da forma mais eficaz. Uma tarefa simples não deveria ser Adicionar um endpoint de exportação em CSV, deveria ser Permitir que um cliente exporte seu histórico de cobrança, o que inclui pensar sobre o que deve constar nessa exportação, qual desempenho é aceitável considerando que você tem 10 anos de dados, e como ela se integra com outras funcionalidades de exportação do seu produto.
E se você enquadra o trabalho dessa forma, mesmo em um mundo orientado por IA, haverá problemas de engenharia mais complexos, como entregar uma iniciativa estratégica complexa no contexto tecnológico da sua empresa. E haverá problemas de engenharia mais simples, como o exemplo acima.
Se os engenheiros do seu time estão trabalhando em tarefas técnicas, o problema não é sobre juniores e IA. É sobre a eficácia da sua organização de engenharia. Você vai ter alguns poucos engenheiros gerenciando a complexidade (e virando o gargalo) para os demais, enquanto seus concorrentes vão ter cada membro contribuindo com valor para o cliente. Um time altamente produtivo, agora e no futuro, tem espaço para engenheiros de todos os níveis, juniores incluídos.
Comentários