Fiz engenharia reversa de sistemas ATS e descobri por que seu currículo nunca passa da triagem automática
Fiz engenharia reversa de sistemas ATS e documentei tudo em 33 páginas — por que seu currículo nunca passa da triagem
Você aplica pra 50 vagas, tem a stack perfeita, mas recebe silêncio absoluto.
O problema não é seu código. É o parser que lê seu currículo antes de qualquer humano ver.
O problema
Sistemas como Gupy, Workday, Greenhouse e Lever não leem currículos como pessoas. Eles fazem parsing do arquivo, extraem entidades (nome, datas, skills) e atribuem um score baseado em densidade de keywords, vetores semânticos e heurísticas estatísticas.
Seu currículo é tratado como um payload que precisa ser perfeitamente interpretado pelo pipeline de triagem.
E a maioria falha silenciosamente.
O que descobri
Passei as últimas semanas estudando como esses sistemas funcionam. Não li artigos de coach — li código-fonte.
OpenCATS (open source), documentação de APIs, testes com parsers reais, análise de NLP (BERT, Word2Vec), regex patterns, tokenização.
Bugs que eliminam candidatos qualificados:
1. UTF-8 BOM quebra parsers silenciosamente
ERROR: Unable to parse candidate resume
TOKEN: undefined
Se você salvou o .docx com BOM (Byte Order Mark), alguns parsers legados simplesmente falham. Sem erro. Sem log. Você nem sabe que foi rejeitado.
2. "React" ≠ "ReactJS" ≠ "React.js"
São 3 tokens diferentes para sistemas baseados em regex. Se a vaga pede "React" e você escreveu "ReactJS", pode ser match zero em ATS legados.
3. Layout de duas colunas causa text interleaving
O parser lê linha por linha, da esquerda pra direita. Se você tem sidebar, o texto das duas colunas é concatenado de forma alternada:
"Desenvolvedor Python Telefone: (11) 99999-9999
com 5 anos Email: [email protected] de experiência..."
O NLP não entende nada disso.
4. PDF com fontes não-embarcadas falha em OCR
Se a fonte não está embarcada, o sistema usa uma fallback. Resultado: caracteres trocados, texto corrompido, keywords perdidas.
5. A última linha do resumo "vaza" pra experiência
Parsers baseados em regex cortam seções procurando padrões tipo \b(Experience|Experiência)\b. Se a keyword que você precisa está na transição entre seções, ela pode ser associada ao bloco errado.
Você pode explorar isso (context bleed).
6. Metadados vazios no core.xml
O parser lê os metadados do .docx antes do corpo do texto. Se dc:title, dc:keywords e dc:description estão vazios, você perde peso algorítmico logo na primeira fase.
Stack de análise
- Parsers open-source: OpenCATS (Ruby + regex)
- NLP: spaCy, NLTK para Named Entity Recognition
- Embeddings: gensim (Word2Vec), similaridade cosseno entre termos
- Análise de tokens: normalização UTF-8, regex patterns
- Plataformas testadas: Gupy, Workday, Greenhouse (via documentação de API)
O que eu fiz
Compilei tudo em um manual técnico de 33 páginas.
Não é curso. Não é motivacional. É documentação de engenharia reversa.
Conteúdo:
- Como parsers legacy (regex) vs modernos (NLP) vs híbridos (LLM) funcionam
- Data scraping de keywords: como extrair e rankear termos de 10 vagas reais
- Metadata injection: editando
core.xmldo .docx via terminal - Context bleed: explorando falhas de regex entre seções
- Normalização de tokens e encoding UTF-8 sem BOM
- Fórmula XYZ: estrutura de bullets com impacto quantificável
- Compliance regional: diferenças entre Brasil, EUA e Europa (GDPR, EEO)
- A/B testing de currículos: framework de split testing
Bônus:
-
Prompt Mestre v1.0: Pipeline de 10 fases pra IA (ChatGPT, Claude, Gemini). Cola na IA, passa 10 descrições de vagas + seu currículo atual, e recebe output otimizado em texto + LaTeX + metadados prontos.
-
Template LaTeX profissional: Baseado no awesome-cv, com metadados configuráveis, encoding UTF-8, fontes embarcadas e layout ATS-friendly.
Custos
R$ 0,00
Porque conhecimento técnico não deveria custar R$ 997.
O problema não é falta de curso. É falta de documentação.
E documentação deveria ser open source.
Links
- PDF completo: GitHub Releases
- Repo: github.com/caiquegaspar/ats-engineer
- Site: ats-engineer.pages.dev
O que aprendi
-
ATS não são uma única coisa — Existem 3 categorias: legacy (regex puro), ML-based (NER + embeddings), hybrid (filtro automático + LLM). Sua otimização precisa cobrir os três.
-
Parsing quebra com coisas bobas — Hífen vs en-dash, aspas ASCII vs tipográficas, BOM, fontes não-embarcadas. Detalhes que você nem percebe mas que destroem a extração de texto.
-
Keywords sem contexto valem pouco — Sistemas modernos usam clusterização semântica. "React" isolado vale menos que "Desenvolvedor de SPAs com React integradas a REST APIs em Node.js".
-
O problema não é você, é a API — Candidatos qualificados são eliminados por falhas de parsing, não por falta de skill.
Exemplo prático
Antes de otimizar:
Desenvolvedor Full Stack
Experiência com React, Node, Docker
Depois de aplicar as técnicas:
Desenvolvedor Full Stack | React | Node.js | Docker
RESUMO
Desenvolvedor de Web Applications com React e Node.js, especializado em
arquitetura de microsserviços containerizados com Docker para deploy em AWS.
Tecnologias principais: React, Node.js, TypeScript, Docker, PostgreSQL.
EXPERIÊNCIA
Full Stack Developer | Empresa X | 03/2022 - Presente
• Arquitetei e implementei SPA com React integrada a REST APIs em Node.js,
resultando em redução de 40% no tempo de carregamento (de 2.1s para 1.2s),
utilizando Server-Side Rendering e code splitting.
Diferenças:
- Metadados no título (keywords de alta densidade)
- Última linha do resumo com "context bleed" proposital
- Fórmula XYZ: O quê + Quanto + Como
- Tecnologias em inglês (consistência de tokens)
- Datas no formato MM/AAAA (evita subcálculo de experiência)
Conclusão
Se você é dev, debugga exceções no seu código.
Mas está enviando currículos que lançam NullPointerException no parser do recrutador.
Talvez seja hora de debugar isso também.
v1.0.0 - Initial Release
- ✓ Engenharia reversa completa
- ✓ 33 páginas de documentação técnica
- ✓ Prompt Mestre v1.0 + Template LaTeX
Feedback é bem-vindo nos comentários ou no repo.