O filtro de IA no recrutamento de devs está testando a coisa errada
Recrutadores já perguntam, em entrevista, como o candidato usa inteligência artificial no trabalho. O problema não é a pergunta existir: é que ela costuma parar na palavra certa, não na competência de verdade.
- Leitura
- 4 min
- Tabelas
- 1
- Fontes
- 1
Recrutadores já perguntam, em entrevista, como o candidato usa inteligência artificial↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → no trabalho. O problema não é a pergunta existir: é que ela costuma parar na palavra certa, não na competência de verdade.
Uma reportagem da Exame publicada em 1º de novembro de 2026 confirma algo que quem está em processo seletivo técnico já sentia na pele: recrutadores estão perguntando, em entrevista, como o candidato usa ferramentas como ChatGPT, Microsoft Copilot e Gemini no dia a dia. A reportagem é cuidadosa em dizer que não existe um filtro universal de currículos baseado nisso, e que a exigência varia por cargo e maturidade da empresa.
Concordo com o fato. Discordo do critério que está sendo usado na prática. O problema não é perguntar sobre IA. É perguntar errado: tratar "sabe usar IA" como se fosse uma linha isolada de competência, quando é uma ferramenta embutida no trabalho de programar, igual Git, igual terminal, igual debugger.
Citar a ferramenta no currículo não diz nada
A própria Exame nota que sistemas de triagem identificam palavras-chave, mas que a ausência do termo "IA" não implica exclusão automática. Isso é verdade e é também o ponto fraco do filtro: se a presença da palavra pouco diz sobre competência real, por que ela continua pesando na pré-seleção?
Para quem programa, escrever "ChatGPT" ou "GitHub Copilot" na lista de skills tem o mesmo valor que escrever "Google" tinha em 2012. É esperado, é quase universal entre devs ativos, e não diferencia ninguém. O que diferencia é o relato de uso: qual tarefa, qual ferramenta, qual decisão de quando confiar e quando revisar.
O que separa fluência real de verniz, pra quem constrói software
A Exame recomenda substituir descrições vagas por experiências verificáveis: plataforma usada, atividade, finalidade e, se possível, resultado mensurável. Isso vale em dobro pra dev, porque dá pra verificar de um jeito que recrutador de outras áreas não tem: pedindo o código, o pull request, o changelog.
Esse é o tipo de dado que sustenta uma frase de currículo: resultado mensurável, não claim genérico. "Usei Copilot para gerar testes unitários de um módulo legado e reduzi o tempo de cobertura de X para Y" diz infinitamente mais do que "fluente em IA generativa".
Em resumo: fluência não é ter usado a ferramenta. É saber nomear, com precisão, o que ela fez por você e o que você teve que corrigir nela.
O risco que quase ninguém pergunta na entrevista de dev
A reportagem da Exame cita, com razão, que conhecer as limitações da IA importa tanto quanto saber operá-la: respostas incorretas, exposição de dados confidenciais, interpretações equivocadas. Para engenharia de software, esse risco tem um nome técnico: código inseguro gerado sem revisão.
Código sugerido por um assistente de IA pode conter vulnerabilidades que passam despercebidas quando aceito sem revisão cuidadosa. Some a isso o risco de colar trecho de código proprietário num LLM público sem política de retenção de dados clara, e você tem um problema de governança, não só de produtividade.
Nenhuma entrevista que eu vi relatada até aqui pergunta isso. Pergunta-se "você usa IA?". Raramente se pergunta "o que você faz quando o modelo sugere uma dependência que não existe, ou um trecho que parece certo mas abre uma falha?". Essa é a pergunta que separa quem usa IA como atalho de quem usa IA como ferramenta de engenharia.
| Sinal no currículo | O que realmente mede |
|---|---|
| "Fluente em ChatGPT/Copilot" | Nada verificável |
| Tarefa + ferramenta + resultado numérico | Aplicação real, comprovável |
| Menção a revisão de código gerado | Consciência de risco |
| Silêncio total sobre limitações | Alerta, não desqualificação automática |
O contra-argumento que eu levo a sério
Reconheço o lado do recrutador. Quando uma vaga recebe centenas de candidaturas, é preciso algum proxy pra triagem em escala, e "menciona ferramenta de IA" é mais barato de processar do que ler relato de projeto de cada um. A própria Exame lembra que o funcionamento desses filtros depende da configuração adotada por cada empresa.
O ponto não é abolir o filtro. É que empresa que usa só a palavra-chave está otimizando pra ruído, porque junior que copiou a frase de um modelo de currículo e sênior que debuga output de agente todo dia passam pelo mesmo crivo. Um board que pede relatório de produtividade de squads que adotaram IA generativa não aceitaria essa mesma rasteza de critério; contratação técnica não devia aceitar também.
O que muda pra quem está se candidatando agora
Se você programa e está no mercado, a mudança prática é pequena de escrever e grande de efeito:
- Troque "conhecimento em IA generativa" por uma frase com ferramenta, tarefa e resultado, do jeito que a própria Exame recomenda.
- Prepare um exemplo onde o modelo errou e você percebeu, não só onde ele acertou. Isso prova julgamento, que é o que falta em quem só "usa" a ferramenta.
- Tenha pronta uma resposta sobre dado sensível: já colou código da empresa anterior num LLM público? Por que sim ou por que não?
- Se você nunca usou nenhuma dessas ferramentas no trabalho, diga isso e mostre que aprendeu rápido outras coisas antes. Curva de aprendizado documentável vale mais do que menção vazia.
A fluência que interessa não é saber o nome do produto. É saber onde ele erra, e o que você faz com isso.
Fonte: Exame
Highlights
- Recrutadores perguntam sobre IA em entrevistas, mas testam a palavra errada, não competência real
- Escrever 'ChatGPT' no currículo vale tanto quanto escrever 'Google' em 2012: universal, não diferencia
- GitHub Copilot acelerou tarefas de programação 55% em 2022, mas saber o resultado concreto importa mais que mencionar a ferramenta
- Pesquisa de 2021 encontrou código vulnerável em 40% dos casos com assistentes de código, risco quase nunca perguntado em entrevistas
- Fluência real é saber nomear o que a ferramenta fez, o que você corrigiu e quando não confiar nela
Este artigo foi escrito por Vanessa Guerra. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Por que um time técnico que nunca discorda do fundador é motivo de alerta
Pesquisas da McKinsey e da Bain mostram que líderes superestimam a própria mesa de decisão. Para founders de tecnologia, confundir silêncio com alinhamento custa decisões técnicas erradas e caras.











