Uma pessoa com nove anos de React entrou em uma entrevista técnica e saiu com a sensação de que tinha sido avaliada menos pelo trabalho que sabe fazer do que pela capacidade de recitar nomes. No relato publicado no devBR, ela conta que explicou como usa tipos utilitários, organização de CSS, performance e componentes no dia a dia. Ainda assim, bastava não lembrar o rótulo exato para a conversa virar uma aula dada em tom de correção.
O caso não prova que toda entrevista técnica funciona assim. Mas acerta numa dor bem reconhecível: quando o processo confunde vocabulário com domínio, ele deixa de testar como alguém trabalha e passa a testar a memória sob pressão.
O relato: quando a pergunta parece mais difícil que o problema
Segundo o autor do post, a entrevista começou com perguntas sobre recursos que ele já usa, como Partial, Record e Exclude. O problema não era admitir que existem outros tipos utilitários; era a expectativa de que a lista inteira estivesse pronta na cabeça. Quando ele disse que pesquisaria o recurso certo para uma necessidade específica, a resposta teria sido que, sem saber naquele instante, ele não conseguiria usar.
O mesmo padrão apareceu com BEM, controlled components e termos de Angular que ele não usa havia anos. Em mais de um ponto, o autor diz que entendia a prática, mas hesitava porque a formulação da pergunta soava como se houvesse um conceito muito mais sofisticado escondido ali.
Essa diferença é importante. A documentação do React, por exemplo, usa “controlado” para explicar de onde vem a informação que define o comportamento de um componente: de props ou de estado local. É uma linguagem útil para discutir arquitetura. Mas reconhecer ou não o rótulo, isoladamente, não mostra se a pessoa sabe escolher uma fonte de verdade, organizar estado ou corrigir um fluxo quebrado.
Conhecer o nome ajuda. Transformar nome em prova de competência, não.
Termos técnicos existem por uma razão: eles encurtam conversas entre pessoas que já compartilham contexto. Saber o nome de um padrão facilita busca, documentação, revisão de código e comunicação com o time. Ninguém está defendendo ignorância como virtude.
O salto errado acontece quando a entrevista trata o termo como fim da investigação. Um candidato pode decorar uma lista de padrões e travar diante de um bug real. Outro pode não lembrar o nome formal, mas explicar o problema, propor um teste, consultar documentação e justificar uma solução. O segundo comportamento é muito mais próximo do trabalho cotidiano.
Em TI, pesquisar não é cola. É método. A questão profissional é saber o que pesquisar, avaliar se a fonte é confiável, adaptar a resposta ao código existente e verificar se a mudança resolveu o problema sem criar outro.
O que uma entrevista mais útil deveria procurar
Uma boa conversa técnica não precisa abandonar fundamentos. Ela só precisa sair do formato “defina X” como regra única. Algumas perguntas revelam mais sobre trabalho real:
- Peça para o candidato explicar uma decisão que tomou e o trade-off envolvido.
- Mostre um trecho pequeno de código e pergunte como ele investigaria um comportamento estranho.
- Apresente uma mudança de requisito e observe como ele organiza as perguntas antes de sair alterando tudo.
- Pergunte como valida uma resposta encontrada na documentação ou sugerida por IA.
- Use conceitos como gancho, mas deixe espaço para a pessoa raciocinar em voz alta.
Isso não torna a avaliação “fácil”. Pelo contrário: exige entrevistador que saiba escutar, aprofundar e distinguir um raciocínio incompleto de um raciocínio inexistente. Só que produz um sinal melhor do que transformar a entrevista em campeonato de glossário.
Como responder quando a pergunta vem com um rótulo que você não lembra
Para quem está do outro lado, fingir que sabe costuma piorar a situação. Uma saída melhor é separar nome e entendimento: “Não estou lembrando o termo exato, mas se você está falando de X, eu costumo resolver assim…” Depois explique o cenário, as decisões e o que validaria.
Se realmente não conhece o assunto, vale dizer isso sem floreio e mostrar o próximo passo: onde buscaria a referência, como testaria em um projeto pequeno e que impacto esperaria encontrar. Não é uma resposta mágica para uma entrevista hostil, mas devolve a conversa para competência verificável.
O relato do devBR também deixa um recado para empresas. Um seletivo que humilha, interrompe e comemora cada lacuna pode até filtrar gente. Só não garante que está filtrando quem resolve problemas melhor. Pode estar apenas selecionando quem treinou melhor para aquele jogo.
