Há uma cena que se repete em entrevistas técnicas: uma pessoa com muitos anos de experiência encontra dificuldade para explicar um conceito que alguém com menos tempo de carreira consegue descrever com clareza. Isso não significa que experiência não tenha valor. Significa que tempo de trabalho, por si só, não garante compreensão.
É possível passar anos entregando funcionalidades, corrigindo bugs e participando de projetos sem ter espaço para investigar o que acontece por trás das ferramentas usadas todos os dias. O código funciona, a entrega segue para produção e a próxima demanda já está na fila. Nesse ritmo, aprender a usar uma tecnologia pode acabar ocupando todo o espaço que seria necessário para entender como ela funciona.
Em entrevistas de .NET, essa diferença aparece com frequência. Muita gente sabe escrever async e await, mas hesita quando precisa explicar o que significa aguardar uma operação. Usa injeção de dependência, mas resume sua justificativa a “baixo acoplamento”. Constrói APIs, mas não consegue descrever o caminho de uma requisição HTTP desde a chegada ao servidor até a resposta.
Saber aplicar uma ferramenta resolve a tarefa de hoje. Saber explicar o que ela faz ajuda a tomar decisões quando o contexto muda.
Usar não é o mesmo que compreender
Uma palavra-chave como await pode parecer simples no código. Mas, para explicar o comportamento, é preciso falar sobre operações assíncronas, tarefas representadas por Task, suspensão e retomada do fluxo, além do trabalho que continua enquanto a operação aguarda. Não é necessário recitar detalhes internos do compilador em toda conversa. É necessário entender o suficiente para distinguir uma operação de I/O aguardada de trabalho pesado que continua consumindo CPU.
Essa distinção muda decisões práticas. Tornar um método async não faz automaticamente uma operação lenta ficar mais rápida. Usar .Result ou .Wait() pode bloquear uma thread enquanto o resultado não chega. E criar tarefas sem entender quem as aguarda pode tornar erros e cancelamentos mais difíceis de acompanhar. A teoria dá nomes e relações para investigar esses efeitos; a prática mostra quando eles aparecem no sistema.
O mesmo vale para injeção de dependência. “Baixo acoplamento” é um começo, não uma explicação completa. Um contêiner pode construir objetos e fornecer suas dependências, mas a aplicação ainda precisa definir os limites entre responsabilidades, escolher os tempos de vida adequados e entender quem controla a criação de cada serviço. Se uma dependência com estado compartilhado for registrada com um tempo de vida inadequado, a solução familiar pode introduzir bugs difíceis de reproduzir.
Uma API também não é apenas um método de controller. Entre o cliente e a resposta há uma conexão, processamento HTTP, middleware, roteamento, autenticação e execução da aplicação. Conhecer esse percurso ajuda a localizar problemas: uma resposta inesperada pode nascer antes de o controller ser executado; um erro de autorização pode ocorrer numa etapa diferente de uma falha de validação; e o tempo de resposta pode incluir espera por banco de dados ou outro serviço.
Por que a entrevista expõe essas lacunas
Uma entrevista técnica não mede toda a competência de alguém. O formato tem limites, e uma resposta hesitante não apaga entregas reais. Ainda assim, perguntas sobre fundamentos ajudam a revelar como a pessoa raciocina quando não há um exemplo pronto para copiar.
No trabalho, é comum encontrar uma solução conhecida, consultar documentação ou pedir ajuda ao time. Em uma conversa técnica, pode ser necessário explicar por que uma abordagem funciona, quais custos ela traz e em que situação deixaria de ser adequada. A resposta não precisa ser uma aula perfeita. Precisa mostrar entendimento, capacidade de organizar ideias e disposição para reconhecer o que ainda não se sabe.
Anos de experiência podem abrir a porta de uma entrevista, mas não substituem a clareza sobre as decisões tomadas. Quando a explicação fica apenas no nome de uma ferramenta ou em frases decoradas, torna-se difícil avaliar se a pessoa conseguiria adaptar a solução a um problema diferente.
Explicar é uma forma de testar o próprio entendimento
Tentar ensinar um conceito com as próprias palavras é um teste útil porque obriga a conectar as peças. Se, ao explicar injeção de dependência, você só consegue repetir “baixo acoplamento”, vale perguntar: o que cria o objeto? Quem conhece suas dependências? O que muda entre os tempos de vida Transient, Scoped e Singleton? Que problema cada escolha pode causar?
Com async e await, tente explicar o que está sendo aguardado, o que a thread pode fazer enquanto isso e onde as exceções são observadas. Para uma requisição ASP.NET Core, descreva as etapas principais e identifique onde middleware, roteamento e autenticação entram no caminho. Desenhar o fluxo em uma folha ou explicar o conceito para outra pessoa ajuda a revelar saltos no raciocínio.
Isso não transforma todo desenvolvedor em palestrante. A meta é comunicar o bastante para que outra pessoa acompanhe seu raciocínio, fazer perguntas melhores e escolher uma solução com consciência dos seus efeitos.
Estude a partir das lacunas, não de listas aleatórias
Resolver perguntas de entrevista pode ser útil, mas uma coleção de respostas decoradas oferece uma sensação frágil de preparo. Uma pergunta que você nunca viu pode desmontar essa confiança. O estudo fica mais sólido quando começa pelo que você ainda não consegue explicar.
Escolha um conceito que aparece no seu trabalho. Primeiro, escreva uma explicação curta sem consultar material. Marque os pontos em que você recorreu a frases vagas, confundiu conceitos ou não soube responder “por quê?”. Depois, consulte documentação confiável, leia exemplos pequenos e observe o comportamento na prática. Por fim, tente explicar de novo, agora incluindo quando aquela abordagem ajuda e quais são seus limites.
Esse ciclo conecta teoria e experiência. A documentação organiza o comportamento esperado; a experimentação mostra como ele se manifesta; e a explicação verifica se você realmente entendeu as relações entre as partes. Se surgir uma dúvida nova, ela vira o próximo tópico de estudo — não um motivo para decorar outra resposta pronta.
A pergunta útil não é apenas “qual resposta devo dar?”. É “o que preciso entender para conseguir responder com minhas palavras?”.
Conhecer os fundamentos não serve apenas para passar em entrevistas. Ajuda a depurar problemas, revisar decisões, conversar com o time e reconhecer quando uma prática conhecida não se encaixa no cenário atual. A experiência ganha profundidade quando cada entrega também deixa uma compreensão mais clara do sistema.
Não é preciso saber tudo para demonstrar maturidade técnica. É preciso reconhecer os limites do próprio conhecimento, investigar o que falta e conseguir explicar, com clareza, o que já foi aprendido. No próximo desafio do seu dia, além de perguntar como implementar, pergunte o que acontece por trás da solução — e tente contar essa história com suas próprias palavras.