Vale esclarecer um ponto importante aqui.

Quando eu falo em “engenharia reversa”, não é acesso a código interno nem a API proprietária de Gupy, Workday ou Greenhouse. Isso obviamente não existe.

É engenharia reversa no sentido clássico de engenharia de software: observar comportamento do sistema, padrões de entrada/saída, erros recorrentes, documentação pública, casos open-source e literatura técnica que esses próprios sistemas usam como base.

ATS não é caixa mágica.
Ele usa parsing (regex), NLP, embeddings, heurísticas de scoring e pipelines híbridos — isso é amplamente documentado e, em parte, reproduzível.

O objetivo do material não é prometer que “vai funcionar” sempre.
Nenhum sistema probabilístico funciona assim.

A proposta é reduzir falsos negativos que acontecem por motivos bem conhecidos:
layout quebrando extração,
tokenização ruim,
metadados ausentes,
datas ambíguas,
encoding errado,
etc.

Muita gente é eliminada não por falta de experiência, mas porque o sistema não conseguiu extrair o que já estava lá.

O documento não é um curso, nem um milagre, nem uma promessa de aprovação.
É documentação técnica aplicada pra quem quer entender o sistema e diminuir o ruído.

Quem espera garantia tá procurando marketing.
Quem quer entender o problema, engenharia.