Entrevista técnica em inglês: como se sair bem sem ser fluente
Você resolve o problema em dez segundos e passa cinco minutos sem conseguir explicar. Frases fixas para cada fase liberam a sua cabeça para o que importa.
Tem uma situação específica que humilha gente boa: você olha o problema, enxerga a solução em dez segundos, e passa os cinco minutos seguintes sem conseguir explicar em inglês o que você acabou de enxergar. Você resolveria isso em produção numa tarde. Na entrevista, você parece perdido.
O que está acontecendo não é falta de inglês nem falta de técnica. É que a entrevista técnica pede que você pense e narre ao mesmo tempo, e narrar em segunda língua consome a atenção que você usaria para pensar. Este guia é sobre baratear a narração, para sobrar cabeça para o problema.
O que a entrevista técnica em inglês realmente avalia
Quem entrevista quer saber se você resolve o problema e se dá para trabalhar com você. Inglês entra como um pré-requisito de trabalho, não como uma matéria sendo corrigida.
Na prática, quem conduz está anotando três coisas:
- Você entendeu o problema antes de sair codando? Quem pergunta antes de começar sobe de nota, em qualquer idioma.
- Dá para acompanhar o seu raciocínio? Não se a sua gramática está perfeita. Se a pessoa consegue seguir você.
- Você reage bem quando algo dá errado? Bug no meio, caso que você não previu, dica que contradiz o seu plano.
Nada disso exige fluência. Exige previsibilidade: que quem ouve saiba sempre em que ponto do processo você está. E isso se consegue com um punhado de frases fixas.
A ideia central: frases fixas para o processo, cabeça livre para o problema
Uma entrevista técnica tem sempre as mesmas cinco fases. O que muda é o problema, não o percurso. Se você tiver duas ou três frases decoradas para anunciar cada fase, a narração vira automática e você gasta o inglês só onde ele é insubstituível: explicando a sua ideia.
É a mesma lógica da moldura que funciona na apresentação pessoal, no guia sobre responder “tell me about yourself” em inglês. Decorar a estrutura, nunca o conteúdo.
As cinco fases e o que dizer em cada uma
1. Reformular o problema
Antes de qualquer coisa, repita o problema com as suas palavras. Isso confirma entendimento, compra trinta segundos de pensamento e já pontua.
“Let me make sure I understand the problem.”
“So we get [entrada] and we need to return [saída]. Is that right?”
“Can I ask a couple of questions before I start?”
2. Perguntar sobre os limites
Perguntar não é fraqueza, é o comportamento esperado. E cada pergunta é tempo pensando com a boca ocupada.
“How big can the input get?”
“Can the input be empty, or contain duplicates?”
“Should I optimize for time or for memory here?”
“Do I need to handle invalid input, or can I assume it's valid?”
3. Propor a abordagem antes de escrever código
Diga o plano em voz alta e espere a reação. Se a abordagem estiver errada, você descobre agora, e não depois de vinte linhas.
“My first idea is the brute force approach: [ideia]. That would be O(n²).”
“I think we can do better using [estrutura de dados].”
“Let me start with the simple version, and then improve it. Does that work for you?”
Aquele “does that work for you?” no fim é uma das frases mais úteis da entrevista inteira. Ela transforma monólogo em conversa e faz quem entrevista te ajudar.
4. Escrever o código narrando
Aqui é onde o silêncio pesa. Você não precisa narrar cada caractere, mas precisa marcar as decisões.
“I'm going to use a hash map here so the lookup is constant time.”
“I'll handle the edge case first, to get it out of the way.”
“Let me give this a better name.”
“I'll come back to this part, let me get the main flow working first.”
5. Testar e falar de complexidade
Muita gente entrega o código e para. Testar em voz alta é metade da nota, e é a parte mais fácil de fazer com frase pronta.
“Let me walk through an example to check it.”
“If the input is [exemplo], then the first iteration gives us [valor]...”
“Time complexity is O(n), and space is O(n) because of the map.”
“If I had more time, I would [melhoria].”
Quando você não sabe a resposta
Vai acontecer, e não é uma reprovação automática. O que reprova é fingir. Existem duas saídas honestas, e as duas soam melhor do que silêncio.
Você sabe o conceito mas não o detalhe:
“I know this can be solved with a graph traversal, but I don't remember the exact algorithm. Can I work through it from first principles?”
Você não conhece o assunto:
“I haven't worked with that directly. What I do know is [assunto vizinho], and I'd approach it by [abordagem]. Is that the right direction?”
As duas mostram o que a vaga quer de verdade: alguém que sabe o tamanho da própria ignorância e continua andando mesmo assim.
Como pedir ajuda sem parecer que desistiu
Pedir dica na entrevista técnica é permitido e, em muitos processos, esperado. O que muda tudo é como você pede. Compare:
| Soa como desistência | Soa como colaboração |
|---|---|
| “I don't know.” | “I'm stuck between two approaches. Can I talk them through?” |
| “Can you give me the answer?” | “Am I on the right track, or should I step back?” |
| Silêncio longo | “Let me think out loud for a second.” |
| “Sorry, my English...” | “Let me rephrase that.” |
A coluna da direita não é mais difícil em inglês. É só mais preparada. São quatro frases, e elas cabem num papel do lado do teclado.
Se a etapa for arquitetura, o inglês pesa mais
Entrevista de desenho de sistema é quase inteiramente falada, com pouco código para se esconder atrás. Ali o inglês pesa mais, e vale preparar o vocabulário de estrutura da conversa:
- para começar amplo: “let me start with the high-level picture”
- para dividir: “I'll break this into three parts: [a], [b] and [c]”
- para justificar: “the trade-off here is [x] versus [y]”
- para adiar: “I'll assume [premissa] for now, and revisit it later”
- para fechar: “to summarize, the main components are...”
Marcar essas transições em voz alta faz mais pela clareza do que qualquer melhora de pronúncia. Quem ouve consegue te seguir mesmo perdendo uma palavra ou outra.
Quatro erros que custam caro
- Ficar em silêncio pensando. Em inglês a tentação é maior, porque falar dá trabalho. Mas silêncio de trinta segundos é lido como “travou”, e quem entrevista não tem como saber que você estava resolvendo.
- Sair codando sem perguntar. Derruba nota mesmo com o código certo, e é o hábito mais fácil de corrigir da lista.
- Traduzir termo técnico. Fila, ponteiro, vazamento de memória: use o termo em inglês, que você já conhece de documentação. Traduzir cria confusão onde não havia.
- Tratar o entrevistador como examinador. Ele está simulando um colega de time. Perguntar, discordar com educação e mudar de ideia contam a favor.
Como treinar
- Resolva problemas fáceis narrando em inglês. O objetivo não é o problema, é a narração. Problema difícil ocupa a cabeça e você volta a resolver em silêncio.
- Grave dez minutos de você narrando. Escutar é desconfortável e é o que mais acelera.
- Decore as frases de transição. Umas quinze resolvem quase toda entrevista.
- Treine com interrupção. Narrar sozinho é fácil; a dificuldade real aparece quando alguém corta no meio com uma pergunta e você precisa retomar o fio.
Esse último ponto é o que não dá para ensaiar sozinho, e é para ele que o Aprovaga existe. Você cola o link da vaga, escolhe a etapa técnica, e a entrevista acontece em inglês, com a regra de que resposta em português é recusada e o assunto continua aberto. No fim vem a nota, o que faltou em cada resposta e uma versão melhor da sua própria resposta, tudo em português.
A primeira entrevista é grátis, sem cartão.
Perguntas frequentes
Meu inglês é intermediário. Vale a pena tentar vaga internacional?
Vale. A maioria das vagas para pessoas desenvolvedoras pede inglês funcional, não fluência de nativo. O que costuma eliminar candidato não é sotaque nem erro de gramática, é não conseguir explicar o próprio raciocínio nem pedir esclarecimento quando não entendeu.
Posso pedir para o entrevistador falar mais devagar?
Pode, e é bem recebido. “Could you speak a little slower, please?” é um pedido normal em time distribuído, onde metade das pessoas não é nativa. Melhor pedir uma vez do que responder a pergunta errada.
Devo escrever comentários em inglês no código durante a entrevista?
Sim, e nomes de variáveis também. Código em português numa entrevista em inglês obriga quem avalia a traduzir enquanto lê, e trabalha contra você sem necessidade.
E se eu travar no meio de uma explicação?
Diga “let me rephrase that” e recomece a frase de outro jeito, mais curto. Travar é normal e passa despercebido quando você retoma rápido; o que fica marcado é o silêncio longo depois do travamento. Tem um guia só sobre isso: o que fazer quando você trava.
Devo avisar antes que meu inglês não é fluente?
Não abra com isso. Se o assunto vier, responda de forma factual e sem se diminuir: “I work in English every day with my team, and I'm comfortable in technical discussions.” Desculpa antecipada só direciona a atenção para o que você não quer que seja avaliado.
O resumo, para levar
- A entrevista técnica avalia raciocínio e colaboração, não gramática.
- Cinco fases sempre iguais: reformular, perguntar, propor, codar narrando, testar.
- Frases fixas para o processo liberam a cabeça para o problema.
- Não saber é aceitável; fingir não é. Existem duas saídas honestas e as duas pontuam.
- Silêncio longo é o erro mais caro, e o mais fácil de evitar.
Escolha um problema fácil hoje e resolva narrando em inglês, gravando. Depois treine com a vaga real e com alguém interrompendo, que é onde a preparação sozinha acaba. Se quiser continuar lendo, veja os outros guias.