Tempo de casa não faz ninguém sênior. Nem a faixa salarial, nem o título que a última empresa distribuiu com facilidade. O rótulo de sênior é aplicado de forma inconsistente no mercado, e as empresas pagam por isso quando contratam olhando os anos acumulados em vez do que esses anos produziram.
Depois de alocar centenas de profissionais em empresas americanas, aprendemos isto: a distância entre um dev pleno e um dev sênior de verdade não é principalmente técnica. A parte técnica é a mais fácil de medir. A diferença real está no resto.
O problema do título
Em algumas empresas, a pessoa vira "sênior" depois de três anos. Em outras, leva dez. Em muitas startups, o primeiro dev contratado já é sênior por padrão. O título não vale a mesma coisa em todo lugar.
Isso importa porque quem contrata costuma usar título e anos de experiência como atalho para capacidade. Se alguém se apresenta como dev sênior há cinco anos, a suposição natural é que mereceu. Às vezes a suposição se confirma. Muitas vezes, não.
A pergunta certa não é "há quanto tempo você faz isso?". É "o que você fez com esse tempo?".
Profundidade técnica: a base
Um dev sênior conhece a fundo a stack dele. Não só o caminho feliz. Sabe o que quebra sob carga, o que o framework faz por baixo dos panos e onde o comportamento documentado diverge do que acontece em produção.
Ele também domina mais de uma linguagem ou framework. Não porque pula de uma para outra, mas porque já trabalhou em contextos suficientes para entender que a maioria dos problemas de arquitetura não depende da linguagem. A ferramenta certa para cada trabalho é uma decisão que ele toma pela experiência, não por preferência.
Na prática: um dev pleno pergunta "como eu implemento isso?". Um dev sênior pergunta "a gente deveria implementar isso? E, se sim, qual abordagem tem menos formas de falhar?".
Proficiência técnica no nível sênior não é saber mais sintaxe. É ter contexto suficiente para tomar decisões melhores com a mesma sintaxe que todo mundo tem.
Pensamento sistêmico
Devs júnior e pleno escrevem código. Devs seniores desenham sistemas.
Isso não diminui quem escreve código. Descreve o escopo. Um dev sênior pensa em como a funcionalidade que está construindo se encaixa no resto da arquitetura. Considera o que acontece quando o banco de dados dobrar de tamanho, quando dois times precisarem mexer no mesmo serviço, quando uma dependência externa for descontinuada.
Isso aparece nas perguntas que ele faz antes de escrever uma linha de código. Quais são os modos de falha? Como vai estar o modelo de dados daqui a três anos? Estamos criando uma dependência da qual vamos nos arrepender?
A maioria dos devs júnior não faz essas perguntas porque nunca viu o que acontece quando ninguém faz. Os seniores já viram. As cicatrizes orientam as perguntas.
Depuração e decomposição de problemas
Todo dev depura. Devs seniores depuram de outro jeito.
A diferença não é a velocidade, embora ela costume vir junto. É o método. Diante de um bug complexo, um dev sênior formula uma hipótese, testa, elimina possibilidades e atualiza o modelo mental conforme as evidências aparecem. Documenta o que encontra enquanto avança. Consegue explicar o raciocínio para outra pessoa antes mesmo de achar a resposta.
Ele também decompõe problemas de outro jeito. Um dev júnior vê um pedido de funcionalidade como uma tarefa de código. Um dev sênior vê o mesmo pedido como um conjunto de decisões: arquitetura, modelo de dados, casos de borda, estratégia de testes e forma de lançar. Ele quebra o problema em partes antes de escrever código, não depois.
No trabalho remoto, isso pesa mais do que muita gente imagina. Quando a depuração acontece de forma assíncrona, a capacidade de explicar um problema com clareza, sem uma call de duas horas, é a diferença entre uma correção de um dia e uma thread de quatro.
Senso de dono: o maior diferencial
Se fosse para escolher uma única característica que separa os devs seniores de verdade dos que são tecnicamente capazes mas não chegam lá, seria o senso de dono.
Senso de dono quer dizer: o problema é meu até ser resolvido. Não "fiz a minha parte", não "esperei o card ser atribuído", não "comentei na daily e achei que alguém ia resolver".
Um dev com senso de dono vê um bug em produção às 16h de sexta-feira e fica até resolver, ou passa o bastão com clareza para quem vai resolver. Ele percebe coisas que não são responsabilidade dele e resolve ou diz "vi isso aqui, vale a gente tratar?". Não deixa a ambiguidade virar desculpa para não agir.
Essa característica é mais difícil de avaliar do que a habilidade técnica, mas prevê melhor o desempenho do time. Um dev com boa base técnica e muito senso de dono quase sempre vale mais do que um com técnica excepcional e pouco senso de dono.
Na EnzRossi, senso de dono é uma das cinco dimensões que avaliamos em todo candidato. Não dá para verificar num teste de código. A gente procura no jeito como a pessoa descreve os projetos anteriores: ela fala do que o time fez ou do que ela, especificamente, conduziu? Assume os fracassos com a mesma clareza que assume as vitórias?
Comunicação e mentoria
Devs seniores escrevem código que outras pessoas conseguem ler. Um código que funciona e que deixa clara a intenção para quem ler daqui a seis meses, inclusive eles mesmos.
Eles também comunicam as decisões. Quando fazem uma escolha de arquitetura, registram o porquê. Não o que escolheram, mas por quê: o que consideraram, o que descartaram, que trade-offs aceitaram. Esse registro evita que o time rediscuta a mesma decisão doze meses depois.
Além do próprio trabalho, devs seniores melhoram o time. Isso não exige um programa formal de mentoria. Aparece em code reviews que ensinam em vez de só corrigir, em explicações que passam o modelo mental em vez de só a resposta, na paciência de deixar um dev júnior se debater com um problema enquanto continua disponível se ele travar de verdade.
Um dev sênior num time de quatro não entrega só a parte dele. Quando faz isso bem, a presença dele aumenta a entrega dos outros três. Times com bons seniores entregam mais, cometem menos erros caros e perdem menos gente por frustração.
Alinhamento com o negócio
Essa é a característica que separa devs seniores de tech leads e engenheiros principais, e vale dizer com todas as letras: devs seniores entendem por que aquilo que estão construindo importa.
Eles conseguem equilibrar o ideal técnico e as restrições do negócio sem tratar cada concessão como um fracasso pessoal. Sabem quando questionar uma decisão de produto e quando aceitar e entregar. Conseguem explicar para alguém de fora da área por que uma coisa vai levar três semanas em vez de uma, em termos que essa pessoa realmente se importa.
Não se trata de virar gestor ou pessoa de negócios. Se trata de entender que software não existe isolado. Uma solução tecnicamente perfeita que chega seis semanas atrasada, para uma funcionalidade que a empresa precisava no mês passado, não é uma vitória.
Os profissionais que alocamos e que recebem o melhor feedback dos clientes quase sempre são os que tratam o resultado do negócio como parte do trabalho, não como preocupação de outra pessoa. Perguntam sobre prazos e por que eles importam. Entendem o produto a ponto de perceber quando um requisito não faz sentido. Se importam com o resultado, não só com o código.
Aprendizado contínuo
Isso é repetido tantas vezes que quase não chama mais atenção, mas é real: a tecnologia muda rápido o bastante para que parar de aprender seja uma escolha com consequências.
Devs seniores se mantêm atualizados. Não correm atrás de todo framework novo, mas sabem o que está acontecendo na área deles. Quando uma ferramenta nova vira padrão, não estão aprendendo do zero dois anos depois de todo mundo.
Eles também adotam ferramentas novas com critério. Saber que uma tecnologia existe e saber se faz sentido usá-la no seu contexto são habilidades diferentes. Devs seniores têm as duas. Conseguem avaliar uma ferramenta nova considerando a stack atual, a familiaridade do time, o custo de manutenção e o problema real a resolver.
Isso inclui as ferramentas de IA. Um dev sênior hoje tem uma opinião formada sobre quais ferramentas de IA para código combinam com o fluxo de trabalho dele e quais não combinam. Não evita por teimosia nem usa sem senso crítico. Testou, formou uma opinião e ajustou o processo.
Como a gente avalia isso
Na EnzRossi, avaliamos cinco dimensões em todo profissional que alocamos: profundidade técnica, comunicação, fluência em ferramentas de IA, senso de dono e alinhamento cultural. Um bom currículo e um teste de código aprovado não bastam para passar no nosso processo.
O senso de dono aparece no jeito como o candidato descreve o trabalho anterior. A comunicação aparece na entrevista comportamental e na clareza com que ele explica por escrito uma decisão técnica que tomou. O alinhamento cultural aparece no jeito como ele descreve os times em que trabalhou e o que o frustrava neles.
Aprovamos cerca de 5% dos candidatos. Não porque os outros 95% não têm capacidade técnica. Alguns são tecnicamente excelentes. Ficam de fora porque capacidade técnica sozinha não prevê se alguém vai render num time remoto, num projeto com risco e prazo reais.
Se você está montando um time e tentando separar quem se diz sênior de quem é sênior de verdade, olhe além do currículo. Pergunte qual sistema a pessoa mais se orgulha de ter construído e, em seguida, o que ela faria diferente se construísse de novo. Pergunte de uma vez em que ela discordou de uma decisão técnica e o que aconteceu depois. Peça que ela explique como aborda um bug desconhecido num código que nunca viu.
As respostas vão dizer mais do que os anos de experiência.
Se você quer uma shortlist de profissionais que já passaram por essa régua, fale com a gente. Primeiros perfis em 3 dias.
