O que separa um Júnior de um Staff numa entrevista

Não é a quantidade de tecnologia que você conhece. É o que você faz com o problema.

Quando comecei a entrevistar, eu tinha dificuldade de avaliar um candidato pelo nível dele. Não conseguia achar critérios objetivos para dizer se era Júnior, Pleno ou Sênior.

Foi assim por anos. Eu tentando encontrar uma métrica, um sistema para olhar para um candidato e cravar o nível. Até que comecei a perceber um padrão nas entrevistas.

O padrão que eu comecei a enxergar

Os que eu considerava Júnior não tinham tanta consciência do problema. Pulavam essa etapa e iam direto para a solução. Algo comum no início de carreira.

O Pleno já tinha consciência do problema, mas trabalhava com uma ou duas possibilidades de solução. Sabia o que precisava resolver e levantava algumas hipóteses sobre como resolver.

O Sênior tinha consciência do porquê. Por que estava resolvendo aquilo e por que cada solução fazia sentido. É o que a O’Reilly resume bem no artigo “Seniors and Juniors” (2025): entender um problema não é achar um algoritmo, é saber quem quer aquilo resolvido, por que quer, quem está pagando e o que já foi tentado antes. Usando arquitetura complexa ou simples, tanto faz: o Sênior tinha clareza do que precisava ser resolvido e da solução certa para aquele prazo, aquele escopo, aquela entrega.

E tinha um nível acima do Sênior, muito claro nas entrevistas: o candidato raciocinava em trade-offs. Sabia o que fazer, como fazer, por que faria e o que estaria perdendo e ganhando ao adotar cada solução. Não por acaso Tomasz Lelek e Jon Skeet dedicaram um livro inteiro a isso, o “Software Mistakes and Tradeoffs” (Manning, 2022): quase toda decisão de engenharia é um equilíbrio entre forças que se opõem, e o custo de escolher errado costuma aparecer só lá na frente.

Como isso virou meu método de entrevista

Depois de enxergar esse padrão, passei a usar isso de forma deliberada.

Júnior. Numa vaga Júnior, eu esperava que o candidato soubesse o que fazer. Um serviço, um banco de dados, uma fila, algo assim. Mesmo sem entender o porquê da escolha. Ele pegava a solução que já tinha em mente e quebrava em componentes, e isso já indicava o nível. Decompor o problema, antes de escolher a solução, é outra história.

Pleno. Aqui eu esperava que ele não só soubesse o que fazer, mas trouxesse mais de uma solução para o mesmo problema. Nesse nível eu não cobrava o porquê nem os trade-offs. Queria ver mais de uma opção na mesa.

Sênior. Eu esperava o que fazer, como fazer, algumas opções e, principalmente, o porquê de escolher uma ou outra. Não necessariamente o que ele ganharia ou perderia, mas os motivos por trás da escolha. Alguns já identificavam trade-offs, mas eu não exigia profundidade sobre ganhos, perdas e impacto no negócio. Saber explicar o porquê já sinalizava o nível.

Especialista/Staff. Aqui estava a grande diferença. O candidato sabia o que fazer, como fazer, por que fazer, e explicava o que ganharia e perderia em cada solução, inclusive pensando no negócio. Will Larson descreve bem esse território no “Staff Engineer” (2021): parte do trabalho staff-plus é lidar com muita ambiguidade e conectar decisão técnica a impacto organizacional, seja como o “Solver” dos problemas mais espinhosos, seja como braço direito da liderança.

E muitas vezes a solução escolhida era a mais simples possível. O problema parecia complexo, mas quando analisado a fundo não exigia nada tão estruturado, tão cheio de tecnologia. Era resolver da forma mais simples que desse. Rich Hickey já tinha dado nome a isso em “Simple Made Easy” (Strange Loop, 2011): a gente confunde o simples com o fácil e acaba pagando em complexidade. O Sênior escolhe o simples mesmo quando o fácil seria empilhar tecnologia.

Quanto mais Sênior o profissional, mais simples tende a ser a solução.

Sênior não é quem sabe menos tecnologia

Uma ressalva importante: isso não significa que Sênior e Especialista precisem conhecer menos de tecnologia. Pelo contrário. Eles conhecem muito mais.

A diferença é que não saem aplicando toda tecnologia ao mesmo tempo, em todo problema. Enxergam o problema, decompõem em partes e decidem onde aplicar determinada tecnologia e onde simplesmente ignorá-la, porque muitas vezes deixar de fora é o que serve melhor ao problema.

Não é à toa que a clássica “Programmer Competency Matrix”, de Sijin Joseph, tem uma linha inteira dedicada à decomposição de problemas: é uma das competências que mais separam os níveis. É também o que o modelo de Dreyfus já apontava em 1980: o novato se apega às regras e às ferramentas, enquanto o especialista opera pelo contexto e por uma intuição treinada. No nível de processo, a mesma lógica aparece nos modelos de maturidade como o CMM do SEI e sua evolução na ISO/IEC 33000, que descrevem a passagem do caótico para o previsível e o otimizado.

No fundo, é uma troca de foco: da tecnologia para o problema, o negócio e o impacto.

Um exemplo. Contrate um Júnior e é comum vê-lo aplicar soluções complexas em problemas pequenos, deixando o sistema difícil de manter e de evoluir. O Especialista, no fim, pergunta outra coisa: essa solução pronta vai custar mais ou menos do que uma solução customizada?

O que trai o Júnior e o Pleno é a tentativa de mostrar que conhece muitas tecnologias, pensando em sistemas complexos, sem olhar para o problema que precisa ser resolvido e para como decompô-lo.

Senioridade é uma relação com o problema

Nada disso é sobre quantas tecnologias a pessoa domina. Um Júnior pode conhecer mais frameworks que um Sênior. O que separa os níveis é a relação de cada um com o problema: o Júnior corre para a solução, o Sênior fica no problema até entender o que ele é de verdade.

Talvez seja por isso que Júnior, Pleno e Sênior queiram dizer coisas tão diferentes de uma empresa para outra. A gente insiste em medir senioridade por tempo de casa, por stack, por título. Numa entrevista, quando você presta atenção, o que aparece é outra coisa.

O nível não está no stack que você cita. Está no problema que você entende.

Referências e leituras

Dreyfus, Stuart E. & Dreyfus, Hubert L. “A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition” (University of California, Berkeley, 1980). Ampliado em Mind Over Machine (1986).
O’Reilly Radar. “Seniors and Juniors” (2025).
Lelek, Tomasz & Skeet, Jon. Software Mistakes and Tradeoffs (Manning, 2022).
Larson, Will. Staff Engineer: Leadership beyond the management track (2021).
Hickey, Rich. “Simple Made Easy” (Strange Loop, 2011; vídeo no InfoQ).
Joseph, Sijin. “Programmer Competency Matrix”.
SEI/CMM (Capability Maturity Model) e ISO/IEC 33000 (modelos de maturidade de processos de software).