Assisti, quadro a quadro, à gravação de uma entrevista técnica real conduzida por uma plataforma de IA, feita por um dos meus mentorados para uma vaga internacional. A sessão é reveladora porque expõe o formato exato que empresas americanas e europeias estão adotando, e mostra onde candidatos competentes perdem a vaga por razões que não têm relação com conhecimento técnico.
Este ensaio documenta o que observei, com as respostas concretas que apareceram na tela e as correções que orientei.
Como funciona o formato de entrevista conduzida por IA
O primeiro ponto que precisa ser entendido é operacional. A plataforma não grava a sua tela. A permissão solicitada pelo navegador é de câmera e microfone, não de captura de navegação.
"Eu acabei de checar aqui nas permissões do navegador. Não tem nenhuma permissão que concede acesso à gravação de tela."
Isso muda a estratégia. Sem risco de captura de tela, a divisão da tela passa a ser uma decisão de ergonomia: uma janela à esquerda, outra à direita, imitando o cenário de dois monitores. A própria banca assume que o candidato usa ferramentas de apoio, porque isso já está incorporado à prática diária de trabalho.
"Eles te dão um tempinho para ler o script. Na prática, eles sabem que a gente vai usar o GPT. O GPT já existe há três anos. Hoje isso não é vantagem nenhuma."
A estrutura das perguntas é cronometrada, com cerca de vinte segundos para leitura e alguns minutos para resposta. A empresa que assessora a contratação gera um relatório automatizado a partir das respostas, o que reduz a subjetividade e torna o conteúdo da fala ainda mais decisivo.
O verbo que define a avaliação: explicar
Explicar vem do latim explicare, desdobrar o que estava dobrado, estender uma superfície para que todos vejam o interior. É exatamente isso que a banca quer testemunhar: o desdobramento ordenado do seu raciocínio.
Os candidatos aprovados compartilham uma anatomia comum de resposta:
- Contextualizam as restrições: volumetria, tolerância a latência, consistência eventual.
- Definem as variáveis técnicas: custo de processamento, manutenibilidade, limites de escala.
- Apresentam o resultado: a solução implementada e as métricas obtidas em produção.
Quem apenas cita termos decorados revela ausência de vivência. A autoridade sênior aparece quando o candidato abre as camadas do problema com naturalidade metódica.
Três respostas concretas que apareceram na sessão
GraphQL contra REST
A primeira pergunta difícil envolveu economia de tráfego entre microsserviços. A resposta ingênua é criar endpoints sob medida para cada consumidor. O problema é que isso não escala: se um serviço precisa de dez campos, outro de cinco e outro de um, você cria três endpoints e mantém três códigos.
O GraphQL resolve isso de outra forma.
"O GraphQL resolve isso com a query, que funciona como um select, só que na API. Ele retorna segmentado com n variações, sem necessidade de novas implementações."
A conclusão técnica é que, quando o objetivo é economia de tráfego e latência, o GraphQL tende a ser superior. O motivo é físico: trafegar poucos kilobytes é mais rápido do que trafegar megabytes, e em escala essa diferença se multiplica.
"Quando você coloca um volume gigantesco de requisições, coisas pequenas se tornam grandes. Um kilobyte vira gigas, dependendo do caso."
A parte mais interessante foi a observação sobre adoção. A solução superior existe, é testada, e ainda assim muitas equipes continuam na abordagem antiga porque a voz da cabeça de um tech lead ou gerente prevalece sobre os fatos.
Merge hell e a complexidade do Git Flow
Outra pergunta pediu um exemplo de conflito de merge e seu impacto no fluxo de entrega. A resposta precisa de um termo técnico consolidado: merge hell.
"O Git Flow é complexo. Quando é complexo, as pessoas implementam errado. Se você quer que as pessoas implementem corretamente, dê algo simples."
É o mesmo raciocínio que vale para Arquitetura Limpa e Hexagonal: quanto mais complexo, maior a chance de implementação incorreta. A resposta forte descreve as mitigações concretas, canal dedicado para avisar quem vai iniciar uma feature, commits pequenos e frequentes, testes automatizados na pipeline como gate de merge e revisão obrigatória de outro desenvolvedor. Essas restrições reduzem atrasos e retrabalho.
Diagnóstico de performance: onde está o gargalo?
A terceira pergunta foi sobre identificação de problemas de performance. A resposta superficial aponta uma causa genérica. A resposta sênior decompõe o problema em três origens possíveis:
- Banco de dados: consultas sem índice, volume de acesso, N+1.
- Tráfego entre serviços: payloads grandes, chamadas redundantes, falta de granularidade.
- Algoritmo específico: cálculos pesados executados no fluxo da aplicação.
Um exemplo real que citei na sessão veio de um projeto anterior, com um cálculo demográfico que cruzava dados do IBGE com bases de geolocalização e só era acionado em algumas requisições. A lentidão não estava no banco nem no tráfego, estava no algoritmo. A abordagem de correção muda conforme a origem, e é isso que a banca quer ouvir.
O complemento essencial é o processo de diagnóstico. Para identificar, é preciso ter instrumentação: DataDog, New Relic, Dynatrace ou uma stack de OpenTelemetry com Grafana bem configurada. E a correção deve ser reproduzida em ambiente controlado antes de produção.
"É importante enfatizar esse fluxo, porque tem gente que testa solução de bug direto em produção. E aí é desastre."
Vale a leitura honesta sobre a causa. Quando desenvolvedores testam em produção, muitas vezes não é negligência: é porque o ambiente de QA não replica produção, então o teste ali não garante nada.
"A culpa não é do dev. A culpa é da gestão, que permitiu que o ambiente de QA fosse totalmente diferente de produção."
O que a banca realmente avalia
A dissecação da sessão permitiu fixar quatro conclusões diretas:
- A previsibilidade das perguntas é matemática. A maioria das perguntas comportamentais e de arquitetura segue roteiros mapeáveis. Concorrência, índices de banco e trade-offs de microsserviços são temas recorrentes.
- A naturalidade da fala é treinável. O mentorado leu uma resposta apoiada e, mesmo assim, conseguiu construir um tom natural. A meta é a mesma resposta na ponta da língua, sem apoio.
- O português técnico não se traduz sozinho. Termos canônicos da computação têm equivalente exato em inglês, e substituí-los por explicações genéricas reduz a densidade da comunicação.
- Erros pontuais exigem correção imediata. Corrigir o rumo em voz alta, com maturidade, preserva o restante da avaliação.
Conclusão
A entrevista técnica internacional feita por IA não é um obstáculo intransponível. É um formato com regras claras, avaliado por critérios estáveis e sustentado por um punhado de temas recorrentes. Quem entende o formato, domina o vocabulário técnico em inglês e treina respostas estruturadas transforma a ansiedade em previsibilidade.
Sobre o autor. Robson Cassiano é engenheiro de software sênior com quase uma década de atuação em backend Java e Kotlin. Conduz a mentoria Descomplica DEV Na Gringa, onde analisa entrevistas técnicas reais de mentorados e prepara engenheiros brasileiros para processos seletivos internacionais. A sessão analisada neste ensaio é uma gravação real de um de seus mentorados.