Junior vs Senior: o que separa os dois não é o que você pensa
Eu já contratei o currículo errado achando que era o certo.
Era um dev com GitHub sólido, portfólio público, domínio de React, Node.js e TypeScript. Passou bem na entrevista técnica. Código limpo, testes escritos, PR aberto no prazo.
Seis meses depois, o sistema estava cheio de N+1 queries que ninguém havia questionado, uma lógica de sessão que explodia sob carga concorrente e uma decisão de arquitetura que faria sentido para um projeto pequeno, não para o volume que atingimos no terceiro mês.
O problema não era o desenvolvedor. Era a minha expectativa sobre o que aquele nível entrega.
⚠️ A diferença entre junior e senior não é o que está no código. É o que o senior impede que entre no código.
O que o junior faz bem (e o que ele não enxerga)
Um junior que recebe o ticket “adicionar autenticação OAuth 2.0” consegue estudar a documentação, implementar o fluxo com Passport.js, fazer os testes passarem e abrir um pull request limpo.
O código funciona.
Mas ninguém perguntou: o que acontece se o token expirar durante uma transferência em andamento? E se o cache de refresh tokens explodir sob carga? E se dois clientes tentarem usar o mesmo token simultaneamente? Que superfície de ataque isso abre em relação à LGPD?
O junior resolveu o ticket. O sistema ainda tem um problema que vai aparecer em produção às 3 da manhã, dois meses depois, num momento em que ninguém vai lembrar desse PR.
Isso não é incompetência. É ausência de contexto acumulado.
💡 O junior estudou documentação. O senior estudou falhas de produção.
O que o senior faz que não aparece no ticket
O mesmo ticket nas mãos de um senior gera um caminho diferente antes de escrever uma linha de código.
Ele vai mapear edge cases de sessão, validar o design contra requisitos de conformidade como PSD2 e LGPD, pensar em fallback se o provedor OAuth ficar indisponível, medir a latência do novo fluxo de autenticação e planejar como fazer rollback sem invalidar sessões ativas.
O código dele leva mais tempo. Mas a diferença é o que não quebra depois.
Essa é a habilidade que não aparece no GitHub. Não tem repositório para “número de decisões ruins que não cheguei a implementar” ou “refatorações que evitei ao questionar o ticket antes de começar”.
A diferença que importa operacionalmente
Um junior vai criar um endpoint porque o ticket pediu um endpoint.
Um senior vai questionar se precisa de um endpoint — ou se um job assíncrono resolve melhor, com menos acoplamento e sem a latência síncrona que vai incomodar o usuário em pico de carga.
Um junior usa PostgreSQL porque é o banco que o time usa.
Um senior pergunta: este caso de uso precisa de ACID? Ou Cassandra entrega melhor para este volume de escrita? E se a resposta for PostgreSQL mesmo, pelo menos a decisão foi consciente.
Isso não é brilhantismo. É ter visto a decisão errada virando dívida técnica num projeto que ele não conseguia mais entregar features sem primeiro refatorar o que a equipe anterior deixou.
⚠️ Um caso concreto: acompanhei uma startup que tinha oito juniors e um desenvolvedor intermediário, numa decisão explícita de “otimizar headcount”. No primeiro trimestre, tudo rodava. No segundo, apareceram N+1 queries em produção. No terceiro, deadlocks inadvertidos em transações concorrentes. No quarto, dois meses de refatoração.
Custo da refatoração: R$ 180 mil em horas. Um salário sênior anual custa entre R$ 120 e R$ 150 mil. O cálculo é chato de fazer, mas ele existe. E o break-even entre um time balanceado e um time só de juniors acontece entre o terceiro e o quinto mês.
O custo invisível da mentoria não estruturada
Equipes com razão de três juniors para um senior têm 40% mais bugs em produção do que equipes balanceadas. Não porque o código individual é pior — é porque o senior gasta tempo interceptando bugs que ainda não aconteceram.
Só que isso tem um custo escondido: quando você não tem senior suficiente, quem faz esse trabalho? Ninguém. O bug passa. Ou o próprio senior fica sobrecarregado fazendo code review de tudo e parando de entregar.
🔑 Um dev com oito anos de experiência não é sênior só porque oito anos passaram. É sênior porque foi mentorado por alguém melhor, errou grande em produção e analisou o erro sem defensividade, trabalhou em domínios diferentes e viu arquitetura falhar de verdade.
Se sua empresa não cria trilhas de crescimento, você está construindo um time que fica junior indefinidamente.
Como estruturar o time sem acumular débito
Depende do tamanho e do momento.
Menos de 5 devs: contrate 1 senior que goste de mentoria. Os outros podem ser juniors com potencial. O senior vai gastar 20% do tempo ensinando e 80% entregando. O sistema não vira um pântano.
Entre 5 e 15 devs: use razão de 1 senior para 3 ou 4 juniors. Crie ciclos de mentoria estruturada: code review, pair programming, design reviews quinzenais. Identifique quem tem potencial de ir para intermediário e invista antes que o mercado faça isso por você.
Acima de 15 devs: comece a diferenciar funções. Alguns seniors focam em arquitetura, outros em mentoria, outros em delivery. Crie trilhas claras de crescimento onde um junior sabe o que precisa fazer para virar intermediário em 18 meses — e isso precisa estar escrito em algum lugar, não só na cabeça do CTO.
Armadilhas comuns
“Vamos contratar só juniors para economizar.”
Você economiza R$ 50 mil no primeiro semestre. No segundo, gasta R$ 200 mil refatorando código que não escala. A estratégia correta é começar com pelo menos 1 senior para cada 5 juniors, depois ajustar a razão conforme o time amadurece.
“Vamos botar um junior em arquitetura de sistema.”
Um junior não entende tradeoffs de design porque nunca viu os tradeoffs quebrarem em produção. Ele vai implementar a primeira coisa que funciona. Você vai descobrir o problema quando o volume triplicar.
“Senior com muitos anos de experiência é senior.”
Quinze anos em COBOL não vale nada em sistemas distribuídos modernos. Sênior não é título acumulado por tempo. É a capacidade de antecipar onde vai dar errado. 📖 Se você quer saber se alguém é realmente senior, pergunte sobre erros. Um sênior real conta histórias detalhadas sobre bugs que causaram downtime, decisões que não escalaram, projetos que falharam e por quê. Quem só tem anos vai responder com generalidades.
O que separa um junior de um senior que nunca foi mentorado
Esse é o ponto que as empresas ignoram mais consistentemente.
Um desenvolvedor que passou cinco anos num time sem arquitetura, sem code review real, sem pair programming, sem exposição a falhas de produção — esse desenvolvedor acumulou tempo, não experiência.
Ele vai para outra empresa com o título de senior, mas o repertório de um intermediário. E isso não é culpa dele. É culpa do ambiente que não o expôs ao que importa.
⚠️ A consequência prática: você contrata alguém como senior, paga salário de senior, e descobre depois que a senioridade era titulada, não real.
A forma mais confiável de evitar isso: pergunte sobre projetos que falharam. Pergunte o que ele teria feito diferente. Pergunte sobre decisões de arquitetura que se provaram erradas depois. A vulnerabilidade honesta é o sinal mais confiável de maturidade técnica real.
Perguntas Frequentes
Um junior pode ser tão produtivo quanto um senior em alguma situação?
Sim. Em tarefas bem-especificadas e repetitivas: formulários CRUD, scripts de migração, refatorações em código já testado. O problema é quando tarefas que parecem repetitivas têm complexidade escondida que só um senior identifica antes de começar.
Como sei se um “sênior” é realmente sênior ou só tem muitos anos de carreira?
Pergunte sobre erros. Um sênior real conta histórias detalhadas sobre bugs que causaram downtime, decisões de arquitetura que não escalaram, projetos que falharam e por quê. Quem só tem anos vai responder com generalidades. A vulnerabilidade honesta é o sinal.
Preciso de um senior em todo projeto?
Depende do risco e da reversibilidade. Dashboard interno com baixo volume e baixo impacto? Pode ser tudo junior com code review ocasional. Sistema de pagamentos, autenticação ou qualquer coisa com dados sensíveis? Um senior participa do design desde o início, sem exceção.
Como um junior evolui para senior de fato?
Trabalhando em três ou quatro domínios diferentes, errando em produção e analisando o erro sem defensividade, mentorando alguém mais júnior e acumulando experiência em sistemas que falharam. Em geral, entre 5 e 7 anos com exposição real a problemas reais.
O que vem depois de senior?
Staff engineer, tech lead ou saem para empreender. Mas as competências que levam alguém a senior são as mesmas que sustentam qualquer um desses caminhos. O senior que nunca mentora dificilmente vai a lugar nenhum.
💬 Para reflexão
Código é commodity. Contexto é o diferenciador. Um junior traz código. Um senior traz o contexto de por que esse código importa, quando ele vai escalar e onde ele vai quebrar. Se você só quer código, automatize. Se quer um negócio que dure, invista em contexto.
1 Comentário