carlos@cesaints: ~/projects/hiring-challenges.md — zsh

EN (Ler esta página em inglês)

Comando: cat projects/hiring-challenges.md

projects/hiring-challenges.md · 3,2 KB

Fábrica de desafios técnicos de contratação, com defesa ao vivo e decisão humana

Uma ferramenta interna para criar desafios técnicos de contratação para 22 trilhas em 4 níveis, do estágio ao sênior. Cada desafio sai com enunciado, kit inicial, gabarito, rubrica por comportamento observável, roteiro de defesa ao vivo e testes ocultos, e só pode ser publicado depois de mostrar que não se resolve só com um modelo de linguagem. A avaliação é pseudonimizada, a defesa pesa pelo menos metade da nota e quem decide é sempre uma pessoa. Até setembro de 2026, nenhum candidato real tinha sido avaliado com ela.

abrir demonstraçãosimulação do sistema com dados fictícios · 6 telas

Papel
Autor do método e da ferramenta
Período
set/2026 – set/2026
O que eu fiz

Eu: O método de avaliação, as rubricas por nível, os portões de qualidade, as regras de ética e de LGPD, a ferramenta de linha de comando, a barreira de privacidade na consulta a modelos externos e os scripts de catálogo, empacotamento e expurgo.

Projeto privado, descrito sem identificar cliente, produto ou empresa.

Diagrama

Da ficha à decisão humana, com o gabarito sempre na máquina

Tudo roda numa ferramenta local. As fichas, o método e as rubricas ficam num cofre de notas; modelos de linguagem geram os artefatos, e portões com evidência e data decidem a publicação, com a regra de que quem cria não aprova. Uma barreira de privacidade deixa sair para os modelos externos só o material do candidato. O pacote enviado ao candidato leva só a pasta dele, passada pelo guardião de confidencialidade. A entrega volta pseudonimizada, os avaliadores dão as notas sozinhos, há uma defesa ao vivo, e o parecer apoia uma decisão que é sempre de uma pessoa.

Contexto

Um grupo empresarial precisava estruturar e contratar o seu time de tecnologia. O teste técnico clássico, um take-home isolado, já não separa quem entende de quem só entrega: um modelo de linguagem com execução de código resolve em minutos. Eu queria um processo que medisse como a pessoa pensa e decide, sem vigiar a máquina dela e sem pedir trabalho grátis.

O que eu construí

  • O método. Doze mecanismos que tornam a solução só por IA insuficiente por desenho. Rubricas por comportamento observável em oito dimensões, com pesos por nível, eliminatórias e uma trava de autoria: com nota de autoria 2 ou menor, o parecer não recomenda a pessoa nem para o nível abaixo.
  • A esteira de criação. Portões G0 a G5 com evidência e data, pendências humanas numeradas e um catálogo gerado a partir das fichas. A geração dos artefatos usa modelos de linguagem, sob regras fixas: quem cria não aprova, e as revisões recebem o pacote pronto.
  • A blindagem. Só o material do candidato vai para pelo menos três modelos, com nomes de arquivo neutros. Cada resposta passa pela armadilha e pela suíte oculta e recebe duas notas, só entrega e entrega com defesa. O desafio só é publicado sem nenhum resultado vulnerável e com no máximo um parcial coberto pela parte ao vivo.
  • O envio e a avaliação. Um script empacota só a pasta do candidato, passa o guardião de confidencialidade na cópia e bloqueia o pacote se houver pendência. Na avaliação, a entrega é pseudonimizada antes de qualquer leitura, os avaliadores pontuam sozinhos e com evidência, e uma diferença de dois pontos exige discussão com evidência nova.

Ética e LGPD no desenho

  • Decisão humana. O parecer apoia a decisão e diz isso numa frase obrigatória; quem decide é a pessoa responsável pela vaga (LGPD, art. 20).
  • Pseudônimos. Cada candidato vira um código antes de qualquer leitura, e a tabela que liga código e nome fica fora do repositório.
  • Prazo para apagar. Entregas e notas somem por script em 6 meses, ou 12 com consentimento para banco de talentos.
  • Sem trabalho grátis. Acima de 4 horas de trabalho assíncrono, o desafio é remunerado. Nenhum hardware ou software pago é exigido, e acomodações são oferecidas antes do aceite.
  • Critérios. Nenhum critério discriminatório (Lei 9.029/95), e a equidade é uma das revisões antes da publicação.
  • Transparência. O candidato conhece a política de uso de IA antes de começar e declara no diário onde usou.

Estado

É uma ferramenta interna, local e sem deploy. O catálogo tem cinco desafios, quatro em rascunho e um pronto para publicar, parado em pendências que só pessoas resolvem. Nenhum desafio foi aplicado, nenhum candidato real foi avaliado e nenhuma contratação saiu dela até setembro de 2026. As telas de avaliação da demonstração mostram os modelos preenchidos com um candidato fictício.

O que eu faria diferente

Aplicaria o primeiro desafio a uma pessoa real antes de escrever o quinto. Toda a calibração até aqui vem de candidatos simulados e de modelos, e só uma aplicação de verdade vai dizer se sessenta minutos de defesa bastam para avaliar um pleno.

Restrições

  • Um take-home isolado é resolvido por um modelo de linguagem em minutos; o processo precisa medir o que a pessoa entende e decide.
  • Nada de software de vigilância na máquina do candidato.
  • Material da banca e entregas com identidade nunca saem para um serviço externo.
  • Decisão sempre humana, sem critério discriminatório, e dado pessoal com prazo para ser apagado.
  • Nenhum trabalho grátis além de 4 horas assíncronas.

Decisões

A defesa ao vivo pesa pelo menos metade da nota

Contexto
No primeiro ciclo de revisão, um take-home isolado foi resolvido por um modelo de linguagem com execução de código, com nota simulada acima da faixa de recomendar só com a entrega.
Escolha
Nota final igual a 40% da menor entre entrega e defesa mais 60% da defesa. Se a nota só com a entrega de algum modelo passar de 3,0 na blindagem, o peso ao vivo fica em pelo menos 50% e a autoria vira eliminatória.
Ganhos
  • Entregar bem sem entender não passa.
  • A defesa mede o que a pessoa decide e sabe explicar, e não só o código entregue.
Custos
  • Cada candidato custa uma hora de banca ao vivo, o que limita a escala do processo.

Contra a solução só por IA, por desenho e não por vigilância

Contexto
Monitorar a tela ou a câmera do candidato é invasivo e fácil de contornar, e proibir IA não reflete o trabalho real.
Escolha
Doze mecanismos de desenho, entre eles armadilha plausível, revelação em etapas, "explique esta linha", falha injetada, PR plantado e testes ocultos. Pelo menos 7 por desafio, e 9 em pleno e sênior. O candidato pode usar IA no take-home e declara onde usou.
Ganhos
  • Nenhum software de monitoramento na máquina de ninguém.
  • A política de uso de IA é conhecida antes do aceite.
Custos
  • Cada desafio fica mais caro de desenhar e de calibrar.

Quem cria não aprova

Contexto
Quem escreveu um desafio não enxerga as próprias brechas.
Escolha
Portões G0 a G5 com evidência e data. A geração dos artefatos usa modelos de linguagem, e as revisões de blindagem, candidato simulado, equidade, confidencialidade e crítica final recebem o pacote pronto, sem o raciocínio de quem criou. Nada é publicado com pendência humana aberta.
Ganhos
  • Brecha de enunciado aparece antes de qualquer candidato.
  • Cada aprovação deixa uma evidência que dá para conferir depois.
Custos
  • Um desafio leva vários ciclos; nenhum dos quatro do primeiro ciclo passou na revisão de design sem ajuste.

Barreira de privacidade na consulta a modelos externos

Contexto
A blindagem manda o desafio para vários modelos de linguagem, e o gabarito, a base de conhecimento e as entregas com identidade não podem sair da máquina.
Escolha
Só o material do candidato sai, com nomes de arquivo neutros. O resto é recusado antes da chamada, cada processo recebe só a própria credencial, os caminhos ficam confinados à pasta do projeto e o texto vai por entrada padrão, com argumentos fixos.
Ganhos
  • Um erro de operação não manda o gabarito para fora.
Custos
  • A barreira precisa acompanhar cada nova fonte de dados.
  • Um achado real mostrou que o caminho de um anexo entregava a resposta, e só o nome-base do arquivo passou a ser exposto.

Pseudônimo antes de qualquer leitura, e expurgo com data

Contexto
Nome, idade ou escola num arquivo influenciam quem avalia, e dado de candidato não pode ficar guardado para sempre.
Escolha
Código por candidato, remoção do autor nos metadados de git da entrega, tabela de identidade fora do repositório, parecer com a frase obrigatória de decisão humana e expurgo por script em 6 meses, ou 12 com consentimento para banco de talentos.
Ganhos
  • Quem avalia não sabe quem é.
  • O dado tem prazo para sumir, e o prazo está no parecer.
Custos
  • A devolutiva exige reidentificar pela tabela externa, um passo manual a mais.

Stack e por quê

Node.js em scripts sem dependências
Catálogo, status dos portões, validação, empacotamento e expurgo rodam na linha de comando.
Cofre de notas em Markdown (Obsidian)
Metodologia, matriz de cargos, fichas, modelos de avaliação e o catálogo gerado, legíveis por quem não programa.
Mermaid
Fluxos e diagramas versionados junto com as notas.
CLI e servidor MCP para modelos de linguagem
Blindagem contra vários modelos, com barreira de privacidade e caminhos confinados.
Painel local em Node
Acompanhar a esteira por stream de eventos, só em localhost.

Resultados

  • Matriz de 22 trilhas em 4 níveis (88 cargos), com âncoras gerais, formato e duração máxima por nível.

    repositório privado auditadoMatriz de cargos do projeto(Auditoria do repositório privado, set/2026)

  • 12 mecanismos contra a solução só por IA, com mínimo de 7 por desafio e de 9 em pleno e sênior.

    repositório privado auditadoMetodologia do projeto(Auditoria do repositório privado, set/2026)

  • Catálogo com 5 desafios: 4 em rascunho e 1 pronto para publicar, parado em pendências humanas como um canal real de contato. Nenhum publicado, nenhum candidato real avaliado e nenhuma contratação feita com a ferramenta até setembro de 2026.

    repositório privado auditadoCatálogo gerado e fichas(Auditoria do repositório privado, set/2026)

  • No primeiro ciclo, um take-home isolado resolvido por um modelo de linguagem teve nota simulada de 3,3 a 3,8 só com a entrega, que caiu para cerca de 2,45 com a defesa; a regra de publicação mudou por isso.

    declaradoRegistro de aprendizados do projeto

Ângulo de segurança

Superfície de ataque

  • Material da banca (gabarito, rubrica e testes ocultos) que não pode chegar ao candidato nem a um serviço externo.
  • Entregas de candidatos, com dados pessoais.
  • Consulta a modelos de linguagem externos pela linha de comando.
  • O pacote enviado ao candidato.
  • O painel local de eventos.

Controles implementados

  • Barreira de privacidade que recusa material da banca, base de conhecimento e entregas não pseudonimizadas antes da chamada.
  • Caminhos confinados, com recusa de .., de outro drive, de caminho de rede e de junção para fora da pasta.
  • Credencial separada por processo, argumentos fixos e texto por entrada padrão.
  • Guardião de confidencialidade que procura segredos, dados pessoais e trechos da banca no pacote, sem imprimir os valores.
  • Empacotamento que copia só a pasta do candidato, bloqueia pendência de publicação e gera o arquivo com código neutro.
  • Pseudonimização da entrega, inclusive do autor nos metadados de git, e expurgo por script.
  • Painel só em localhost, com checagem de origem, teto de corpo e rotação de log.

O que eu testaria hoje

  • Um anexo com link simbólico apontando para o material da banca.
  • Instruções escondidas no enunciado ou na entrega, tentando fazer um modelo ler outros arquivos.
  • Metadados de documentos e imagens dentro do pacote enviado ao candidato.

Evidências

  • repositório privado auditadoPasta privada auditada (ferramenta local, sem deploy)(Auditoria do repositório privado, set/2026)