Time de contratação contorna o secretary problem reaprovando candidatos

O problema e o contexto

Aditya Athalye relata uma experiência de contratação que, segundo ele, contornou por acidente o chamado "Secretary Problem" - um problema de teoria da parada ótima que modela como escolher o melhor candidato quando não se sabe o tamanho do pool, não há padrão objetivo de qualidade e, sobretudo, quando um candidato rejeitado não pode ser recuperado.

Entre o fim de 2013 e 2014, Athalye e seu colega Mayank contratavam programadores para uma equipe de QA na Helpshift, startup de SaaS escrita em Clojure, em Pune, na Índia. O desafio era duplo: precisavam de pessoas dispostas a aprender Clojure, em um mercado onde o pool de testadores era quase inteiramente composto por profissionais manuais, sem incentivo de carreira para programar. Testes eram considerados trabalho de baixo status, e as pessoas "técnicas" fugiam do rótulo de QA ou testador.

A violação da regra central

A restrição-chave do Secretary Problem é que, uma vez rejeitado, o candidato não pode ser chamado de volta. Os dois contornaram isso de duas formas:

1. Manter explicitamente a porta aberta para novas candidaturas após um período de espera, com um convite real - não o "pinky promise" típico de e-mails de rejeição que, na visão do autor, ninguém nunca cumpre.
2. Oferecer suporte de aprendizado opt-in a quem fosse rejeitado: currículo de estudos e horários semanais fixos de "office hours" com a própria equipe.

A ideia partiu de experiências prévias de Athalye como gerente de negócios, quando viu empresas perderem candidatos com as vivências certas, mas diploma, pedigree ou nota errados. A cultura da empresa já favorecia contratações "não tradicionais", e a ausência de função de RH deixou os dois livres para agir - algo que, em hindsight, ele considera sorte, dado o risco de criar compromissos implícitos de contratação.

Resultados diretos e indiretos

Em cerca de um ano de processo, converteram 5 contratações a partir de cerca de 300 candidaturas. Cada pessoa se tornou produtiva em cerca de um mês; três dominaram Clojure e duas migraram para SDKs mobile. Quando uma reorganização extinguiu a função de QA, todos migraram para outras áreas, como desenvolvimento backend e gestão de produto. Todos se tornaram funcionários de longo prazo, com permanências de quatro a dez anos - retenção considerada boa para startups de alto crescimento. Indiretamente, pelo menos um engenheiro sênior se juntou por causa do boca a boca: ele ficou impressionado com o suporte de aprendizado oferecido à esposa, que havia sido avaliada e rejeitada, mas participou das office hours.

Os "truques" do processo

O autor lista várias práticas que sustentaram o processo:

• SLA de 24 horas: resposta a candidatos em no máximo 24 horas, inspirado pela disciplina de contratação veloz de Paul English, ex-CEO do Kayak, cuja meta era da descoberta do candidato à oferta em sete dias corridos.
• Nunca fantasiar ninguém: um "não" rápido é melhor que meses de enrolação.
• Proteger os próprios ciclos mentais: toda comunicação pelo ATS, com notas imediatas do "porquê" de cada decisão, como boas mensagens de commit; entrevistas síncronas por último e individuais; playbooks para cada ligação.
• Respeitar o tempo do candidato: nenhum exercício de código acima de quinze minutos para o nível da vaga; grandes tarefas têm péssima relação sinal-ruído. A resposta pedida, por padrão, era refatorar a solução com um design totalmente diferente. Copiar era permitido, mas só se declarado - ocultar cópia era critério de demissão.
• Valorizar comunicação escrita: triagem primária por e-mail, exigindo respostas curtas e pensadas; o primeiro e-mail já enumerava possíveis fatores eliminatórios (obrigação de aprender Clojure, queda na hierarquia, orçamento de remuneração, plantões, rigor de code review). O autor lamenta não poder divulgar faixas salariais e acredita que seria boa prática.
• Filtrar iniciativa e curiosidade: portfólios no GitHub e sites pessoais não são sinais automaticamente bons, apenas pontos de partida para investigar o "porquê" do candidato.
• Protocolo assíncrono de decisão: apenas dois votos "sim" avançam; um sim e um não rejeitam; votos registrados em 24 horas, sem necessidade de permissão mútua.
• Falsos negativos por excesso: só avançavam candidatos pelos quais sentiam "sim absolutos"; a porta aberta tornava seguros os "nãos" rápidos para os quase-aprovados.

Conclusão

Athalye defende que a contratação típica é jogada como jogo de soma zero, mesmo sendo um jogo adversarial sem padrão objetivo - e que, nesse cenário, empresas pequenas perdem sempre para as grandes que copiam loops de cinco rodadas estilo FAANG. A proposta dele é que contratação não predatória, com reaplicação, suporte de aprendizado e velocidade, deveria ser o modo padrão de qualquer indústria. Ele reconhece que parte do sucesso pode ter sido sorte, e atribui o crédito maior pelo crescimento e retenção à cultura de engenharia construída por todos os colegas, não apenas ao processo de recrutamento.