Como avaliar um desenvolvedor para promoção: o que muda de júnior para pleno e sênior
A diferença entre níveis em tecnologia está no escopo do problema que a pessoa resolve sozinha. Veja critérios observáveis por nível e como avaliar sem viés.
Por Emily Leodino ·
A diferença entre júnior, pleno e sênior está no escopo do problema que a pessoa resolve sozinha, não nos anos de carreira. O júnior entrega tarefas bem definidas com apoio, o pleno entrega uma feature completa com autonomia e o sênior resolve problemas mal definidos e eleva o time.
Por que tempo de casa não define nível
O mercado brasileiro tem uma convenção informal de tempo: júnior até cerca de dois anos, pleno entre três e cinco, sênior acima de cinco. Essa referência aparece em vagas e em conversas de carreira, mas tempo é correlação, não causa.
Duas pessoas com cinco anos de carreira podem estar em níveis diferentes. Uma tomou decisões de arquitetura, atravessou incidentes em produção e ensinou o time. A outra repetiu por cinco anos o mesmo tipo de tarefa, com o mesmo apoio. A primeira é sênior. A segunda é provavelmente uma pessoa plena com tempo de casa.
Se o critério principal é o tempo, a promoção vira disputa de calendário. Quem entrou antes se sente no direito de subir antes, sem que o trabalho no nível seguinte tenha sido demonstrado.
O que muda de júnior para pleno e sênior
O jeito mais prático de avaliar é perguntar: qual o tamanho do problema que essa pessoa resolve sem supervisão? A tabela abaixo organiza a resposta em critérios que dão para observar no dia a dia.
| Critério | Júnior | Pleno | Sênior |
|---|---|---|---|
| Autonomia | Executa com apoio próximo | Trabalha sem supervisão e sabe quando pedir ajuda | Define o que precisa ser feito e assume a decisão |
| Escopo | Tarefas bem delimitadas | Uma feature completa, do requisito ao deploy | Uma área do sistema e os impactos de longo prazo |
| Ambiguidade | Problema claro, com critério de pronto | Requisito a interpretar, com alguma dúvida | Problema mal definido, com impacto de negócio |
| Incidentes | Participa e aprende | Resolve problemas conhecidos com método | Lidera a resolução e decide o caminho |
| Time | Pergunta e absorve retorno | Colabora e ajuda quem tem menos experiência | Mentora e eleva o padrão técnico do grupo |
| Erro | Corrige com apoio | Evita e corrige sozinho | Antecipa, previne e transforma o erro em aprendizado |
Repare que a diferença não está na ferramenta nem na linguagem. Está na quantidade de ambiguidade que a pessoa consegue resolver sozinha. Esse é o teste mais direto para um gestor.
Como escrever critérios observáveis de tecnologia
Um critério bom descreve um comportamento ou uma entrega que outra pessoa consegue verificar. Escreva com verbo de ação e resultado.
- Em vez de "sabe React", escreva "entrega uma tela completa com os estados de erro e vazio, sem acompanhamento".
- Em vez de "é referência técnica", escreva "define a solução de um problema do time e documenta a decisão para os outros consultarem".
- Em vez de "tem boa comunicação", escreva "apresenta o trade-off técnico para uma pessoa de produto e chega a um acordo".
O guia critérios de promoção objetivos tem mais exemplos de critério vago reescrito e explica como ligar cada critério a uma evidência.
Evite listar dez itens por nível. Poucos critérios bem escritos são mais fáceis de avaliar e de cumprir do que uma lista longa que ninguém usa.
Como avaliar sem cair no viés de visibilidade
O maior problema da avaliação em tecnologia é confundir presença com desempenho. Quem fala mais nas reuniões, quem pega os projetos de maior destaque e quem tem acesso informal à liderança tende a parecer mais pronto. Isso não mede o trabalho no nível seguinte.
Três cuidados ajudam.
- Troque a pergunta "essa pessoa parece sênior?" por "quais decisões de arquitetura ela tomou nos últimos meses e com que resultado?".
- Peça evidência distribuída ao longo do período, não só do último mês. O erro de recência favorece quem teve um projeto visível no fim do ciclo.
- Avalie a mesma competência para todo mundo. Se um sênior precisa mentorar, verifique quem mentorou, com que frequência e com que retorno.
Registrar as evidências ao longo do tempo reduz a dependência da memória e torna a conversa mais justa.
Promover o melhor técnico a gestor: cuidado
A promoção mais comum em tecnologia também é a mais problemática: o melhor desenvolvedor vira tech lead ou gestor porque é o melhor desenvolvedor. Gestão e desenvolvimento técnico são trabalhos diferentes. Uma pessoa excelente em código pode não querer ou não conseguir liderar pessoas.
A saída não é nunca promover técnicos para gestão. É preparar antes. Dê oportunidades menores, como liderar uma iniciativa, conduzir o planejamento de uma sprint ou mentorar alguém, antes de formalizar o cargo. Assim a pessoa testa o trabalho novo e a empresa observa o comportamento.
Erros comuns ao avaliar desenvolvedores
- Usar anos de carreira como prova. Tempo pode ser requisito mínimo, não demonstração do nível seguinte.
- Calibrar pelo título da empresa anterior. O que era sênior em uma startup de dez pessoas pode ser pleno em uma empresa com carreira estruturada. Compare comportamento, não rótulo.
- Avaliar só o que é visível. Projeto de destaque e presença em reunião não medem o trabalho de base, como manter um sistema estável ou revisar código com cuidado.
- Não documentar o que cada nível significa. Se a diferença existe só na cabeça do gestor, cada promoção vira negociação subjetiva e gera desconfiança.
- Tratar sênior como pleno mais caro. Se você dá ao sênior as mesmas tarefas, com um pouco mais de complexidade, ele se desmotiva. Sênior precisa de problema com julgamento e amplitude.
Exemplo de uma avaliação
Na Codificar, empresa fictícia de 22 pessoas, um desenvolvedor pleno queria virar sênior. A liderança achava que ele "ainda não tinha perfil". Na conversa, ficou claro que o critério usado era a participação nas reuniões de arquitetura, algo que ele nunca tinha sido convidado a fazer.
A empresa reescreveu o critério de sênior em comportamento observável: propor a solução de um problema do time e documentar a decisão. Nos dois meses seguintes, ele fez isso em dois casos. A avaliação passou a ter evidência, e não impressão. Esse exemplo é escrito para ilustrar o processo e não representa um cliente nem um resultado medido.
O que fazer amanhã
Pegue o nível que você mais avalia e escreva de cinco a sete comportamentos observáveis para ele, usando a tabela deste artigo como referência. Depois, escolha uma pessoa do time e anote, para cada comportamento, a evidência mais recente dos últimos meses. O que não tiver evidência não conta a favor nem contra; é lacuna de registro, não de desempenho.
Ferramentas como o Prisma Times organizam funções, níveis e critérios, e deixam as evidências ligadas a cada critério com histórico da avaliação. A liderança avalia com comentário, e o bloqueio externo fica separado para não pesar contra a pessoa. Se quiser ver o fluxo funcionando, o teste do Ilimitado serve como ponto de partida.
PDI: como fazer um plano de desenvolvimento individual que não vira papel
O PDI parte de uma lacuna real, tem ações com prazo e responsável e é revisado no ciclo. Veja um roteiro e um modelo de tabela para o RH.
Como avaliar uma equipe operacional, com critérios e evidências
Quem trabalha em turno e nem sempre usa computador também precisa saber o que se espera. Veja como avaliar operação com critério, celular e contexto.