“Coloca sênior, por segurança.” Essa frase aparece em muitas aberturas de vaga de tecnologia. Parece prudente, mas costuma sair cara: a busca demora mais, o custo sobe e, quando a função não exige esse nível, o profissional se desmotiva em poucos meses. O inverso também acontece. Um pleno colocado para tomar decisões de arquitetura sem apoio vira gargalo e sai desgastado.

O problema é que júnior, pleno e sênior não significam a mesma coisa em empresas diferentes. Tempo de carreira ajuda pouco: há gente com oito anos repetindo o mesmo ano, e gente com quatro que já conduziu migrações inteiras. Para acertar, você precisa descrever o que a função exige e comparar com sinais concretos do candidato.

Quatro dimensões que definem senioridade

Em vez de um rótulo, use quatro perguntas sobre a função.

  • Autonomia: quanto a pessoa precisa de direção para entregar?
  • Escopo: ela trabalha em uma tarefa, em uma funcionalidade inteira ou em um sistema?
  • Influência: o trabalho dela afeta só o próprio código, o time ou outros times?
  • Tipo de decisão: ela escolhe como implementar, o que implementar ou por que implementar?

A matriz na prática

Júnior

  • Autonomia: executa tarefas bem definidas, com revisão próxima e pares disponíveis.
  • Escopo: tarefas e partes de uma funcionalidade.
  • Influência: o próprio código.
  • Decisão: como implementar dentro de um padrão que já existe.

Pleno

  • Autonomia: resolve sozinho problemas conhecidos e sabe quando pedir ajuda nos novos.
  • Escopo: funcionalidades completas, do refinamento à produção.
  • Influência: o time, por meio de revisões e boas práticas.
  • Decisão: como implementar, propondo alternativas quando o pedido não faz sentido.

Sênior

  • Autonomia: recebe problemas, não tarefas. Quebra o trabalho para o time.
  • Escopo: sistemas ou domínios inteiros.
  • Influência: o time e as interfaces com outros times.
  • Decisão: o que construir e com quais trade-offs. Antecipa riscos antes que virem incidentes.

Liderança técnica (tech lead, arquiteto)

  • Autonomia: define a direção técnica e negocia com produto e negócio.
  • Escopo: vários sistemas ou a plataforma.
  • Influência: vários times e a forma como a engenharia trabalha.
  • Decisão: por que e quando: prioridade técnica, padrões, investimento em plataforma.

Escreva no briefing em que linha da matriz a função está em cada dimensão. Muitas vagas ficam no meio: um pleno com escopo de sênior em um domínio pequeno, por exemplo. Tudo bem, desde que esteja escrito. O artigo sobre como descrever o perfil técnico mostra onde isso entra.

Sinais observáveis na entrevista

Currículo e título não mostram senioridade. A conversa mostra, se você souber o que ouvir.

Sinais de maturidade

  • Explica o porquê das decisões, não só o que foi feito.
  • Menciona alternativas descartadas e o que perderia com cada uma.
  • Fala de impacto no negócio ou no usuário, não só na tecnologia.
  • Reconhece erros próprios com clareza e conta o que mudou depois.
  • Faz perguntas sobre o contexto antes de propor solução.

Sinais de que o nível está abaixo do título

  • Descreve só tarefas recebidas, nunca problemas que identificou.
  • Usa “a gente decidiu” sem conseguir explicar a própria contribuição.
  • Responde toda pergunta de desenho com a mesma ferramenta.
  • Não sabe como o sistema dele se comporta em produção.

Uma pergunta que separa bem os níveis: “Conte uma vez em que você discordou de uma decisão técnica. O que fez?”. O júnior costuma aceitar. O pleno argumenta. O sênior traz dados, propõe um teste e aceita o resultado.

Como compor o time com o mix certo

A senioridade de uma vaga depende do time que já existe. A mesma função pede níveis diferentes em contextos diferentes.

  • Time sem nenhum sênior: a primeira contratação precisa tomar decisões técnicas. Aqui, economizar no nível sai caro.
  • Time com liderança técnica forte: plenos ganham velocidade rapidamente, e um júnior bem acompanhado cresce sem sobrecarregar ninguém.
  • Time só de seniores: costuma ter discussão demais e execução de menos. Plenos equilibram o ritmo.
  • Produto novo: peso maior em seniores no começo, porque as decisões iniciais são difíceis de desfazer.
  • Produto em sustentação: plenos com boa autonomia costumam ser a melhor relação entre custo e resultado.

Um ponto de partida comum para um squad de produto é um sênior ou tech lead para cada dois ou três plenos, com espaço para um júnior quando há alguém com tempo para acompanhar. Não é regra: é uma referência para questionar a sua composição atual. Se você está montando um time do zero, veja quando montar um squad.

Erros comuns ao definir senioridade

  • Sênior por segurança. Você paga por decisões que a função não pede, e o profissional percebe.
  • Júnior para economizar em time sem estrutura. Sem ninguém para revisar e orientar, o júnior não cresce e o time não entrega.
  • Anos de experiência como critério único. Mede tempo, não autonomia.
  • Nível diferente para cada entrevistador. Se o tech lead espera um sênior e o gestor espera um pleno, nenhum candidato passa.
  • Esquecer que senioridade é relativa à stack. Um sênior em Java que vai trabalhar em Go começa com autonomia menor. Considere isso no escopo dos primeiros meses.

Como a Devgo trata a senioridade

No deep dive de 30 minutos que abre cada busca, a Devgo pergunta pelas decisões que a pessoa vai tomar, e não só pelo título. A shortlist chega com essa leitura, e o time valida cada nome antes de ele chegar até você. Quando a pergunta é sobre composição, o Squad as a Service já monta o time com o mix de senioridades pensado para a fase do produto.

E quando o que falta é a camada de decisão, a liderança sob demanda aloca arquitetos e tech leads 100% dedicados ao seu time, sem a lógica de consultoria que aparece só para opinar.

Defina a senioridade pelas decisões que a função exige e pelo time que já existe, e não pelo título que parece mais seguro.