Olhe para dez vagas de "full stack developer" e você vai notar um padrão que não tem nada a ver com amplitude técnica. A maioria pede para uma única pessoa ser dona do frontend, do backend, do banco de dados, às vezes da infraestrutura, tudo pelo orçamento de um único salário de nível médio. "Full stack" em muitas dessas vagas não descreve um conjunto de habilidades. Descreve um problema de headcount que a empresa decidiu resolver pedindo um generalista em vez de contratar um time.
Isso não é o que full stack significa quando você já faz isso há uma década, e fingir o contrário é de onde vem boa parte da confusão, e boa parte do cinismo do mercado sobre o termo.
A versão junior: amplitude sem profundidade, e está tudo bem nessa fase
No começo de carreira, "full stack" geralmente só significa "já usou React e já usou uma API REST", e não tem nada de errado nisso. Amplitude é como você descobre no que realmente quer se especializar. Você constrói um app CRUD de ponta a ponta, aprende que frontend e backend têm modos de falha completamente diferentes e modelos mentais completamente diferentes, e sai do outro lado com um mapa aproximado de todo o território, mesmo que ainda não conheça bem nenhuma região específica.
O problema não é essa versão de full stack existir. O problema é que muitas empresas contratam para essa versão e depois esperam que ela venha com o critério de um senior, porque o título da vaga soa igual independente de a pessoa por trás ter dois anos de experiência ou doze.
A versão senior: profundidade em mais de uma camada, mais o critério para saber qual importa agora
Um full stack developer senior não é alguém que sabe um pouco de tudo. É alguém que se aprofundou o suficiente em pelo menos duas camadas do stack para tomar decisões arquiteturais reais em cada uma, e que desenvolveu o critério para saber, diante de um problema concreto, qual camada merece essa profundidade agora e qual só precisa funcionar.
Esse critério é a parte que não aparece num bullet point do currículo. É a diferença entre "eu sei escrever um componente React" e "eu sei que esse problema específico de gerenciamento de estado pertence ao servidor, porque levar isso pro cliente vai criar um bug de sincronização no momento em que alguém abrir duas abas ao mesmo tempo". É a diferença entre "eu sei escrever uma query SQL" e "eu sei que essa query vai quebrar com dez vezes o volume de dados atual, e sei exatamente qual índice resolve isso em vez de tentar adivinhar". Nenhuma das duas vem da amplitude. Vêm de ter se queimado com a decisão errada pelo menos uma vez em cada camada, e de ter internalizado a lição.
Por que "full stack" é tratado como um rebaixamento da especialização, e por que isso está ao contrário
Existe uma narrativa em partes da indústria de que full stack é o que você aceita quando não é bom o suficiente para se especializar, que a profundidade real mora com o especialista em backend ou o especialista em frontend que passou anos em exatamente uma camada. Essa narrativa inverte a causalidade para um tipo específico de engenheiro.
Algumas das melhores decisões arquiteturais vêm de alguém que entende os dois lados de uma fronteira bem o suficiente para ver onde um problema está sendo resolvido do lado errado. Um especialista em backend pode construir uma API lindamente normalizada que obriga o frontend a fazer três viagens de rede para renderizar uma única tela. Um especialista em frontend pode construir uma interface lindamente responsiva que esconde um padrão de queries caro em silêncio em cada carregamento de página. O engenheiro que passou tempo real nas duas camadas é quem detecta esse descompasso antes de ir para produção, não porque tenha mais talento do que qualquer um dos dois especialistas, mas porque consegue ver a costura que nenhum dos dois está olhando.
Isso não significa que full stack seja superior à especialização. Muitos problemas realmente precisam de alguém que passou cinco anos exclusivamente em sistemas distribuídos ou exclusivamente em performance de renderização, e nenhuma quantidade de amplitude substitui isso. Significa que o enquadramento de "full stack é o caminho superficial" está errado com frequência suficiente para não ser tratado como uma suposição padrão.
O sinal que separa um full stack developer senior de uma lista de desejos de vaga
Se a ideia de full stack de uma empresa é "faz o trabalho de um engenheiro de frontend, um de backend e um de DevOps por um único salário", isso não é um requisito de habilidade, é uma decisão de orçamento disfarçada de título de vaga. O sinal geralmente está em como o cargo é definido: se não há espaço para dizer "essa peça específica de infraestrutura precisa de alguém que realmente se especialize nisso", e a expectativa é que uma única pessoa seja dona de literalmente tudo com profundidade senior, a vaga não está descrevendo um full stack developer. Está descrevendo três empregos na esperança de que uma pessoa muito cansada os cubra todos.
Um cargo de full stack genuinamente senior parece diferente. Ele vem com o reconhecimento de que a profundidade é finita mesmo para quem tem mais de uma especialidade, e a expectativa não é onisciência, é o critério para saber quando ir a fundo, quando uma solução superficial realmente basta, e quando dizer "isso precisa de alguém que viva nessa camada em tempo integral, e esse alguém não vai ser eu nos próximos três meses".
O que realmente constrói isso, já que não acontece com tutoriais
Ninguém se torna full stack developer senior seguindo um currículo que cobre frontend, backend e infraestrutura em sequência. Isso acontece por ser dono de uma funcionalidade de ponta a ponta vezes suficientes para sentir pessoalmente o custo de uma decisão ruim tomada numa camada aparecendo como bug em outra. Você aprende indexação de banco de dados não num curso, mas com uma query que derrubou uma página em produção. Você aprende gerenciamento de estado no frontend não num tutorial, mas com um relatório de bug sobre dados desatualizados entre duas abas abertas que levou quatro horas para reproduzir.
Esse tipo de aprendizado é mais lento do que ler uma ementa que promete "full stack em doze semanas", e também é a única versão que realmente produz o critério que o título sugere. Não existe atalho para ter errado nas duas camadas vezes suficientes para saber onde o risco real costuma se esconder.
Como isso aparece numa entrevista técnica, e por que a maioria das entrevistas não detecta
A maioria das entrevistas de full stack testa amplitude passando por uma lista de perguntas: uma sobre estado em React, uma sobre um join em SQL, uma de system design básico, cada uma superficial o suficiente para caber em quinze minutos. Esse formato recompensa quem memorizou a superfície de cada camada e não diz quase nada sobre se o candidato tem o critério descrito acima, porque critério não aparece em fragmentos isolados de quinze minutos.
Um sinal melhor vem de um único problema que atravessa camadas e força um tradeoff entre elas: onde essa validação deveria viver, por que mover esse cálculo do cliente para o servidor muda o modo de falha, o que quebra primeiro se essa funcionalidade tiver sucesso além da escala para a qual foi construída. Essas perguntas não têm uma rubrica limpa, e é exatamente por isso que a maioria dos processos de entrevista as evita em favor do formato de lista. Mas elas são o único formato que realmente distingue quem tocou em cada camada de quem raciocinou através de todas elas sob pressão.
Se você é quem está sendo entrevistado e o processo é só lista e nenhum tradeoff entre camadas, vale a pena notar. Não é necessariamente um alerta por si só, mas é um sinal de se o time que está te avaliando realmente entende para o que está contratando, ou se está usando "full stack" como abreviação de "sabe um pouco de tudo" sem ter pensado muito além disso.
O rótulo não é o problema. A desvalorização dele é.
Nada disso é um argumento para aposentar o termo. Full stack é uma descrição real e útil de um tipo real de engenheiro, alguém que consegue se mover por todo o sistema e ver as costuras que especialistas de cada lado às vezes deixam passar. O problema é que o termo foi estirado para cobrir tanto esse engenheiro quanto o atalho de contratação de uma empresa, e os dois acabam misturados sob as mesmas duas palavras numa vaga.
Se você é senior e full stack, o movimento útil não é rejeitar o rótulo. É ser explícito, nas entrevistas e em como você fala do seu próprio trabalho, sobre qual das duas versões você é: a que tem profundidade real em mais de uma camada e o critério para saber onde ela importa, não a que estão pedindo para ser quatro cargos pelo preço de um.
