Um candidato mid-level, numa entrevista remota, responde a "Qual é a diferença entre switchMap e mergeMap?" com uma definição perfeita, depois de uma pausa de três segundos. Duas perguntas depois, perguntas-lhe qual dos dois usaria numa barra de pesquisa, e porquê. Silêncio. A primeira pergunta mediu a rapidez com que consulta um assistente de IA; a segunda mediu o que realmente precisavas de saber.
Já estive dos dois lados da mesa de entrevista, e a pergunta que me faço cada vez mais é simples: hoje, com um assistente de IA em cada editor, as perguntas clássicas de entrevista ainda fazem sentido?
O que mudou realmente
As perguntas "de manual" — definições, diferenças entre dois conceitos, listas de características — sempre foram uma aproximação: assumia-se que quem conhece a teoria também a sabe aplicar. Era uma aproximação aceitável quando lembrar custava esforço. Hoje lembrar não custa nada: qualquer definição está à distância de um prompt, durante a entrevista e sobretudo depois, no trabalho real.
E é exatamente esse o ponto: o programador que contratas vai trabalhar com IA. O que conta já não é o que sabe de cor, mas três coisas que a IA não faz por ele:
- Discernimento: escolher entre duas soluções corretas consoante o contexto.
- Verificação: perceber quando o código gerado está errado, mesmo que compile.
- Contexto: compreender o problema real antes de escrever uma linha.
Mid e sénior: as perguntas clássicas já não chegam
Para um perfil mid ou sénior, perguntas teóricas isoladas são quase inúteis: um bom candidato passa, mas um medíocre com um segundo ecrã também. Não devem desaparecer por completo — devem ser usadas como ponto de partida para aprofundar. Eis cinco formatos que funcionam.
1. Code review de código gerado por IA
Dá ao candidato um excerto plausível, como os que um assistente produz todos os dias, e pede-lhe que o reveja como faria com o pull request de um colega:
// Product search bar
this.results$ = this.query$.pipe(
debounceTime(300),
mergeMap(q => this.api.search(q))
);O código funciona quase sempre. Um sénior deve reparar que, com mergeMap, uma resposta lenta para "ang" pode chegar depois da de "angular" e substituir os resultados corretos: é preciso switchMap, que cancela o pedido anterior. Pontos extra se perguntar o que acontece com uma string vazia ou com um erro HTTP, que aqui fecharia o stream para sempre.
O mesmo exercício funciona no backend:
async function getOrders(userIds) {
const result = [];
for (const id of userIds) {
result.push(await db.orders.find({ userId: id }));
}
return result;
}Aqui procuram-se as N queries sequenciais, a falta de paginação e a proposta de uma única query com $in. Não há definição para recitar: ou vês o problema ou não vês.
2. Cenários em vez de definições
Em vez de "O que é change detection?" pergunta: "Uma tabela com 5.000 linhas fica lenta quando o utilizador escreve no filtro. Aqui está o profiler: por onde começas?". Em vez de "O que é o Redis?": "Temos uma cache em memória e passamos de uma para três instâncias do backend. O que deixa de funcionar?". As respostas mostram logo se o candidato resolveu problemas semelhantes ou apenas leu sobre eles.
3. A história de um problema real
"Conta-me o bug mais difícil que resolveste em produção" continua a ser uma das melhores perguntas, desde que aprofundes com perguntas de seguimento: como deste por ele? Que hipótese descartaste primeiro? O que mudaste para que não voltasse a acontecer? Uma experiência vivida aguenta cinco níveis de "porquê"; uma história ensaiada cai ao segundo.
4. Pair programming com IA permitida
Em vez de proibir as ferramentas, permite-as e observa como são usadas. Uma tarefa de 30-40 minutos num pequeno repositório real, com o assistente de IA ativo. Não estás a avaliar o resultado, mas o processo: o candidato lê o código antes de perguntar? Escreve prompts precisos ou genéricos? Rejeita uma sugestão errada ou aceita-a porque compila? Acrescenta um teste?
5. Compromissos e decisões
Num sénior conta a capacidade de decidir sob restrições: "Temos duas semanas e uma equipa de três pessoas: reescrevemos o módulo ou protegemo-lo com testes?". Não há resposta certa: há um raciocínio que pesa risco, custo e reversibilidade, e é exatamente isso que queres ouvir.
Júnior: como deve decorrer a entrevista
Com os juniores o problema é o oposto. Não têm experiência para contar, e um code review complexo penalizá-los-ia injustamente. Mas é precisamente para eles que o risco da IA é maior: é fácil produzir código que funciona sem o compreender. A entrevista deve por isso medir compreensão e capacidade de aprender, não a quantidade de conhecimentos.
Um esquema de 60 minutos que uso e recomendo:
| Tempo | Atividade | O que avalia |
|---|---|---|
| 10 min | Um projeto pessoal ou universitário: o que fizeste tu, o que farias de forma diferente | Consciência, honestidade |
| 15 min | Ler um código curto e prever o output, linha a linha | Fundamentos reais |
| 20 min | Pequena tarefa com IA permitida, depois perguntas sobre cada linha escrita | Compreensão, verificação |
| 10 min | Documentação de uma API nunca vista: usá-la num caso simples | Capacidade de aprender |
| 5 min | Perguntas do candidato | Curiosidade, interesse |
Um exemplo de exercício de leitura, perfeito para um júnior de JavaScript:
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0);
}
// O que imprime? E se usarmos let em vez de var?Não importa que o júnior saiba a resposta de cor (3 3 3, depois 0 1 2): importa que, com alguma orientação, consiga explicar porquê — o scope da variável e a execução assíncrona. É uma pergunta clássica, mas usada para pôr a raciocinar, não para verificar uma memória.
Na parte com IA, a pergunta-chave vem depois do código: "O que acontece se o array estiver vazio? E se chegar null?". Um júnior que percebeu raciocina sobre isso, mesmo que erre; um que apenas colou a resposta não sabe por onde começar. Em ambos os casos ficas com uma informação valiosa.
Pergunta clássica → versão atualizada
| Pergunta clássica | Versão atualizada |
|---|---|
| O que é uma closure? | Este código tem um memory leak: onde, e porquê? |
| Diferença entre SQL e NoSQL? | Para este caso de uso qual escolhes, e o que perdes? |
| Quais são os princípios SOLID? | Esta classe é difícil de testar: como a reestruturas? |
| O que é lazy loading? | O bundle inicial pesa 4 MB: o que verificas primeiro? |
| Como funciona um JWT? | Um token roubado continua válido 30 dias: o que mudas? |
O que eliminar (ou quase)
- Definições decoradas como única prova: medem a pesquisa, não a competência.
- Exercícios para casa de 8 horas: uma IA resolve-os em meia hora, e penalizam quem tem menos tempo livre.
- Live coding sem internet nem ferramentas: avalia uma situação que não existe no trabalho real.
- Proibir a IA na entrevista e exigi-la desde o primeiro dia: é incoerente, e os melhores candidatos reparam.
Em resumo
As perguntas clássicas não morreram, mas sozinhas já não medem o que importa. Para mid e sénior são precisos code reviews, cenários reais e decisões sob restrições, de preferência com a IA em cima da mesa para ver como a gerem. Para juniores são precisos exercícios de leitura de código, perguntas sobre o "porquê" e uma prova de aprendizagem: não quanto já sabem, mas quão rápida e honestamente aprendem. Num mundo em que o código se gera em segundos, o verdadeiro talento é perceber quando esse código está errado. Se te estás a preparar do outro lado da mesa, encontras as perguntas técnicas organizadas por nível no guia das 25 perguntas de entrevista frontend/Angular.