Júnior, pleno ou sênior: a pergunta de entrevista que separa os três

Três candidatos entram na mesma sala virtual, recebem exatamente a mesma demanda e têm o mesmo tempo para responder. Nenhum deles precisa escrever uma linha de código para que eu saiba, em menos de cinco minutos, em que nível cada um está. Este artigo é sobre o que acontece nesses cinco minutos.

Existe uma crença muito difundida — e muito confortável — de que senioridade é um inventário: quantas linguagens você sabe, quantos frameworks você já usou, quantos certificados estão pendurados no LinkedIn. É confortável porque é acionável: basta estudar mais uma ferramenta e subir um degrau.

O problema é que não funciona assim. Já entrevistei gente com quinze tecnologias no currículo que travou na primeira pergunta ambígua, e gente com uma stack modesta que dissecou o problema como cirurgião. A diferença nunca esteve no inventário. Esteve na vivência — na quantidade de vezes que a pessoa já viu algo dar errado e aprendeu a farejar isso antes de acontecer.

Preciso começar por aqui porque é a confusão mais cara do mercado brasileiro.

Você não é desenvolvedor júnior porque terminou um bootcamp. Você não é júnior porque fez três projetos no GitHub, porque concluiu a graduação ou porque assistiu a 200 horas de curso. Enquanto ninguém te contratou para exercer a função, você é estudante — e isso não é ofensa nenhuma, é apenas a descrição correta do estágio.

Júnior é um cargo. Existe a partir do momento em que uma empresa assina um contrato, coloca você dentro de um time, te dá acesso ao repositório de produção e passa a depender de você para entregar valor. Antes disso existe estudo, existe portfólio, existe potencial — mas não existe senioridade, porque senioridade se mede em situações reais, e situações reais só acontecem em produção.

E o inverso também vale: um júnior contratado é um profissional, não um estagiário glorificado. Ele entra em sprint, tem demanda com prazo, participa de code review, quebra produção e conserta produção. A diferença entre ele e o pleno não é “um trabalha e o outro aprende” — os dois trabalham e os dois aprendem. A diferença é o raio de autonomia: o tamanho do problema que a pessoa consegue receber, cortar em pedaços e resolver sem que alguém precise cortar por ela.

Eu entro na sala vestindo o chapéu de PO. Não sou o entrevistador técnico neste momento — sou o cara que acabou de sair de uma reunião com o cliente e trouxe um pedido. E o pedido é este:

É isso. Uma frase. Vaga de propósito, mas não injusta — é exatamente o nível de detalhe que uma demanda real chega na sua mesa numa terça-feira qualquer.

Repare no verbo que eu uso: planeja. Não pedi para implementar. Não pedi pseudocódigo. Pedi um plano. E a primeira coisa que observo é se a pessoa percebeu isso.

Agora, os três candidatos.

O candidato A não hesita. É quase admirável a velocidade. Em quinze segundos ele já está descrevendo a solução:

“Tranquilo. Eu faço uma div de 10 por 10 com CSS, pego a data atual com new Date(), calculo o dia do ano, e uso isso como índice num array de cores. Se você quiser eu já escrevo aqui.”

E ele escreve. E o código funciona. Roda no navegador, mostra um quadradinho colorido, muda de cor quando você mexe o relógio da máquina. Tecnicamente correto:

const cores = ["#e63946", "#457b9d", "#2a9d8f" /* ... 365 cores ... */];

const inicioDoAno = new Date(new Date().getFullYear(), 0, 1);
const diferenca = new Date() - inicioDoAno;
const diaDoAno = Math.floor(diferenca / 86400000);

document.querySelector("#box").style.background = cores[diaDoAno];

Não há nada de burro nesse código. É a solução óbvia, direta, entregue rápido. O júnior fez exatamente o que foi pedido — e é justamente esse o ponto.

O que ele não fez: não perguntou nada. Aceitou a demanda como especificação completa. Assumiu, sem verbalizar, que:

• a cor pode ser diferente para cada usuário (está no cliente);
• a cor pode mudar entre um ano e outro;
• todo ano tem 365 dias;
• o dia do usuário é o dia do relógio da máquina dele;
• um dia tem sempre exatamente 86.400.000 milissegundos.

Cada uma dessas cinco suposições é uma decisão de produto disfarçada de detalhe técnico. Ele tomou todas as cinco sozinho, em silêncio, e nenhuma delas foi validada com quem trouxe a demanda.

O candidato B fica em silêncio por uns segundos. Depois vira a mesa:

“Antes de pensar em código, tenho duas dúvidas. Primeira: a cor precisa ser a mesma para todos os usuários? Se sim, essa definição tem que sair do servidor, porque se eu gerar no cliente cada navegador pode chegar num resultado diferente. Segunda: em 15 de março do ano que vem, a cor tem que ser a mesma de 15 de março deste ano? Se sim, isso não é um cálculo, é um dado — precisa estar persistido em algum lugar.”

Estas duas perguntas não são detalhes. Elas decidem a arquitetura inteira antes de qualquer linha ser escrita:

O pleno entendeu a coisa mais importante da profissão: ambiguidade na demanda não é problema do PO, é risco do time. Ele não devolveu a demanda; ele a refinou. Fez as perguntas cujas respostas ele sabia que mudariam o desenho.

O que ele ainda não fez: olhou para as bordas do calendário e do planeta.

O candidato C começa exatamente igual ao pleno. Faz as mesmas duas perguntas, na mesma ordem, quase com as mesmas palavras. E aí continua.

“E o ano bissexto? Se a paleta tem 365 cores e o índice é o dia do ano, em 2028 tudo depois de 29 de fevereiro anda uma casa. O 1º de março passa a exibir a cor que era do dia 28. E o dia 29 em si — ele tem cor própria, ou herda alguma?”

“E fuso horário? Dois usuários podem abrir a página exatamente no mesmo instante e estarem em dias diferentes. Alguém em Auckland às 10h da manhã e alguém no Havaí no mesmo segundo estão separados por um dia inteiro de calendário. Qual dos dois está ‘certo’? A cor é do dia do servidor, do dia do usuário, ou do dia de um fuso de referência do negócio?”

“Se a resposta for ‘fuso do usuário’, então não posso cachear essa página numa CDN sem cuidado — o HTML gerado às 23h59 em Lisboa está errado para quem abre às 00h01. Se for ‘fuso do servidor’, preciso escrever isso na UI, porque senão vou ter ticket de suporte de gente dizendo que a cor não mudou à meia-noite.”

Aqui está a diferença que não cabe em currículo. O sênior não sabe mais JavaScript que o pleno. Ele já levou porrada de ano bissexto, de horário de verão, de cache que serviu conteúdo de ontem, de bug que só reproduzia entre 21h e 00h para usuário do Acre.

E tem mais uma coisa que ele viu, e que quase ninguém verbaliza:

// O bug silencioso do candidato A:
const diaDoAno = Math.floor(diferenca / 86400000);

Nem todo dia tem 86.400.000 milissegundos. Em países com horário de verão — Irlanda, Portugal, boa parte da Europa — existe um dia por ano com 23 horas e outro com 25. O desvio que isso introduz é de exatamente uma hora, 3.600.000 milissegundos: nada de dramático em si. O problema é o Math.floor. Uma hora de defasagem é suficiente para o índice cair na casa anterior, e o efeito não é uma hora de erro — é um dia inteiro de cor errada. Na Irlanda, entre o último domingo de março e o último de outubro, quem abrir a página entre meia-noite e 1h da manhã continua vendo a cor de ontem. É o tipo de bug que só existe numa janela de 60 minutos, some sozinho quando o relógio volta, e ninguém consegue reproduzir às 15h de uma quarta-feira.

A versão do sênior troca aritmética por calendário:

// Chave de calendário explícita, no fuso que o negócio decidiu.
function chaveDoDia(instante, fuso) {
  return new Intl.DateTimeFormat("en-CA", {
    timeZone: fuso,
    year: "numeric",
    month: "2-digit",
    day: "2-digit",
  }).format(instante); // -> "2028-02-29"
}

const chave = chaveDoDia(new Date(), "Europe/Dublin").slice(5); // -> "02-29"
const cor = paleta[chave] ?? paleta["02-28"]; // fallback explícito para bissexto

Repare no que mudou conceitualmente: o índice deixou de ser um número sequencial e passou a ser uma chave de calendário. Com isso, 29 de fevereiro deixa de deslocar o resto do ano, o horário de verão deixa de importar, e o comportamento do dia extra vira uma decisão explícita e visível no código — não um acidente.

Colocando os três caminhos lado a lado, o padrão fica visível. Não é que um pense “melhor” — é que cada um para em um ponto diferente antes de começar a executar.

O júnior tem quatro etapas e chega ao código na terceira. O sênior tem seis e só chega ao código na última. Isso não significa que o sênior é mais lento — significa que ele gasta o tempo antes, e não depois, quando o custo do erro já multiplicou.

Toda demanda tem camadas. A superfície é o que foi pedido; embaixo dela existem regras de negócio, estado, tempo, entrega e manutenção. Senioridade, na prática, é a profundidade média que a pessoa alcança sozinha, sem que alguém puxe.

Note uma coisa importante: as camadas 1 e 2 são idênticas para os três. O código do júnior não é pior. É que ele só existe nas duas primeiras camadas — e as quatro de baixo continuam lá, esperando alguém.

Aqui está o ponto central do artigo, e vou ser direto: nenhuma das perguntas do sênior exige conhecimento de framework.

Ano bissexto é ensinado no ensino fundamental. Fuso horário é ensinado no ensino fundamental. Intl.DateTimeFormat está na documentação. Nada disso é conhecimento raro.

O que é raro é lembrar de perguntar. E você não lembra porque leu — você lembra porque um dia às 2h da manhã de um domingo de outubro o relatório de fechamento saiu duplicado, e você passou seis horas descobrindo que o servidor tinha vivido a mesma hora duas vezes.

A matriz que prova isso sozinha

A matriz de competências da Talabat avalia 27 temas distribuídos em cinco áreas: habilidades técnicas, entrega, feedback e comunicação, liderança e impacto estratégico. Cada tema tem uma descrição própria para cada um dos seis níveis, de IC1 a IC6.

Com uma exceção. Exatamente um dos 27 temas para de evoluir depois do sênior. Nos três níveis acima — Staff, Principal, Senior Principal — a célula não traz um texto novo. Traz duas palavras: “see IC3”.

Isso é a tese deste artigo escrita por um departamento de RH, com carimbo. Se escrever código para de diferenciar no sênior, então tudo que vem depois — e boa parte do que vem antes — é outra coisa.

E o gráfico acima mostra que outra coisa é essa. A matriz define, para cada nível, um horizonte de planejamento: por quanto tempo à frente aquela pessoa responde. Cinco dias no júnior. Um mês no pleno. Um trimestre no sênior. Dois anos no topo. O crescimento não é uniforme: o salto é brutal no começo — cerca de 5× de júnior para pleno e 3× de pleno para sênior — e depois se estabiliza em 2× a cada degrau. Do IC1 ao IC6 o horizonte cresce quase 150 vezes.

É por isso que um dev que passou cinco anos numa única stack, mas mantendo um produto vivo com usuários reais, costuma ser mais sênior do que alguém que passou cinco anos pulando de projeto greenfield em greenfield. Quem nunca manteve o próprio código não viu a consequência das próprias decisões — e é exatamente esse feedback loop que constrói a intuição.

Se senioridade se constrói com vivência, a pergunta óbvia é: quantos anos?

A resposta honesta é que depende brutalmente do tipo de empresa. O gráfico abaixo não mede quanto tempo você fica em cada nível — mede em que ponto da carreira o título costuma chegar. É essa leitura que expõe a distorção: a barra de “sênior” da coluna de retenção cai exatamente em cima da barra de “pleno” da big tech.

Um framework que publica os números

Quase toda empresa trata a matriz de promoção como documento interno. O Dropbox publicou a dele, e isso dá uma âncora rara — números oficiais, não crowdsourced:

Somando as faixas, uma pessoa entra no L3 com 3,5 a 5 anos de carreira e no L4 com 5,5 a 9 anos. Compare com a régua da seção anterior: L3 é o degrau de sênior, L4 é o de especialista. Os números batem quase exatamente com as faixas de big tech do gráfico — o que é um bom sinal, já que vieram de fontes independentes.

O padrão das grandes empresas

Em empresas grandes, com trilha de carreira formalizada e comitê de calibração, os números são razoavelmente estáveis. No Google, o nível de entrada (L3) costuma durar entre um ano e meio e dois anos — ficar muito além disso é lido internamente como sinal de baixa performance. O L4, o degrau seguinte, corresponde grosso modo a algo entre um e cinco anos de mercado, e o título de Senior Software Engineer (L5) normalmente é associado a uma faixa de seis a nove anos de experiência. Meta, Amazon e Microsoft operam com trilhas diferentes no nome, mas com ordens de grandeza muito parecidas.

Traduzindo para a nomenclatura brasileira:

Repare que a coluna que importa não é a do meio. É a da direita. Os anos são proxy da autonomia, não a causa dela.

O padrão das empresas pequenas — e a armadilha

Agora a parte que ninguém coloca no material institucional.

Em empresas pequenas, consultorias de body shop e lugares que pagam abaixo do mercado, existe um padrão muito consistente: promoção rápida com aumento pequeno. A pessoa entra como júnior e, com menos de um ano de carreira, já é “pleno”. Antes de completar três, tem cartão de visita de sênior — no mesmo ponto da linha do tempo em que uma multinacional ainda estaria assinando a promoção para pleno.

Isso raramente é generosidade. É retenção barata, e a matemática — com os números arredondados a título de ilustração — é simples:

Como diferenciar uma promoção real de uma promoção de retenção? Pelo que mudou além do título:

Até aqui eu tratei a carreira como uma escada única. Ela não é. Júnior, pleno e sênior formam um tronco comum, mas no topo desse tronco existe uma bifurcação — e muita gente descobre isso tarde demais, já tendo aceitado virar gestor por falta de alternativa visível.

Três leituras importam nesse desenho:

Trilha IC — o especialista

Em vez de inventar uma régua, vale olhar escadas reais: a da Artsy (aberta no GitHub), a do Yahoo (reconstruída por ex-funcionários em fóruns), a do Google (mapeada publicamente por ex-recrutadores) e a da Talabat, que eu conheço de dentro — trabalhei lá entre 2021 e 2023, e a matriz de competências deles é o documento mais bem construído que já vi sobre isso. Elas discordam entre si de um jeito muito instrutivo:

O Dropbox ficou de fora dessa tabela justamente por não usar numeração IC — a escada dele é L1 a L4, e já apareceu na seção anterior. Vale citá-lo aqui por outro motivo: enquanto as quatro empresas acima esticam a escada até sete ou oito degraus, o Dropbox comprime tudo em quatro, e trata o L4 como nível terminal. A documentação diz que se espera que todo engenheiro alcance o impacto de L4 e possa ficar lá o resto da carreira, sem pressão de subir. Duas filosofias opostas sobre a mesma pergunta: escada longa com muitos degraus, ou escada curta em que a maioria chega ao topo e fica.

A regra “Staff vem antes de Principal” vale no Google (L6 → L8), na Meta (E6 → E7), na Artsy (IC6 → IC8) e na Talabat (IC4 → IC5). Não vale no Yahoo nem na Amazon, que não têm degrau de Staff. E repare na coluna da Talabat: júnior IC1, pleno IC2, sênior IC3, Staff IC4, Principal IC5 — é a escada mais próxima da intuição brasileira que eu conheço, e existe de verdade. A régua “óbvia” não é errada; ela só não é universal.

Trilha de gestão

A Artsy é útil aqui porque publica o pareamento entre as duas trilhas — coisa que quase nenhuma empresa mostra:

Duas coisas nessa tabela merecem atenção, e as duas contrariam o senso comum brasileiro.

A primeira: gestão não é um atalho. A Artsy escreve na documentação que a trilha de gestão só está disponível para quem já chegou a Senior Engineer 2. O Dropbox chega ao mesmo lugar por outro caminho: registra que o tempo de um gestor em L3 é mais curto que o de um IC justamente porque quem migra para gestão já cresceu através de boa parte do L3 como IC. Ou seja, nos dois frameworks a gestão começa depois do sênior, não em paralelo a ele.

A segunda: o par lateral não é onde eu disse. Eu havia afirmado que Staff e Engineering Manager sentam na mesma faixa. Na Artsy, o EM1 pareia com Senior Engineer 1, e é o Senior Engineering Manager que pareia com Staff. O EM1 lá é explicitamente transitório e interno — eles não contratam ninguém direto nesse nível, e esperam que a pessoa chegue a EM2 em uns 18 meses. A ideia de “mesma faixa” continua certa; o degrau exato, não. Varia por empresa, e é por isso que a tabela existe.

"Júnior" é um termo brasileiro?

Essa é uma observação que eu carrego há anos, e vale separar o que os dados sustentam do que não sustentam.

Ou seja: sua percepção estava mais certa do que errada, só apontando para a palavra vizinha. O que não se traduz não é “júnior” — é “pleno”. E isso tem uma consequência prática desagradável: quem se descreve como “pleno” num currículo em inglês está usando um rótulo que o recrutador do outro lado não consegue mapear. O termo que ele espera ler é o título do nível, não a escala.

Volto à sala de entrevista. Quando o cenário do quadradinho colorido termina, eu não preenchi nenhum campo chamado “sabe JavaScript”. Preenchi estes:

Traduzindo cada linha em pergunta concreta que eu me faço:

Não inventei esses seis critérios. Eles são a versão informal de eixos que aparecem nos frameworks formais. A Artsy avalia IC em quatro dimensões, e a tradução é quase direta:

O quarto eixo é o mais revelador, e é exatamente o que o cenário do quadradinho mede. “Natureza da orientação recebida” é outra forma de perguntar: quanto do problema alguém precisou recortar por você antes de te entregar? O júnior recebe a tarefa já cortada. O sênior recebe a frase crua e faz o próprio corte — e ainda devolve as decisões documentadas para quem pediu.

Vivência acumula sozinha com o tempo, mas dá para acelerar bastante. Algumas coisas que funcionam: