Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

Nossos recrutadores agora entregam software

Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.

By Vadim SoloveyJul 28, 20268 min read
Vadim Solovey

About Vadim Solovey

Founded DoiT in 2011 and have been here ever since — in every flavor of CTO, co-CEO, and now CEO. I started my career in 1999 building data centers before anyone called it "the cloud," and I've spent the two decades since trying to deliver on what the cloud was actually supposed to be. I still write code most weeks.

My personal page

Um ano atrás, careers.doit.com era uma página do HubSpot com filtros que não funcionavam. Se você clicasse na categoria "Customer Experience", veria talvez um terço das vagas abertas, porque as vagas no Greenhouse são marcadas com os subdepartamentos e o site nunca percorria a hierarquia. Os candidatos se inscreviam por um iframe incorporado que parecia ter sido projetado em 2014 — porque tinha sido.

Hoje, o mesmo time que costumava abrir tickets sobre aquela página é dono de uma aplicação Next.js em produção rodando no Google Cloud Run. Ela serve o site público de carreiras e, atrás de um login, roda um criador de descrições de vagas com IA, uma ferramenta de sourcing de candidatos, uma ferramenta de triagem de inscrições, um fluxo de revisão de remuneração com aprovações, um editor de blog para histórias de funcionários e um bot do Slack que anuncia novas vagas. O time de aquisição de talentos não contratou uma agência. Não ficou esperando no backlog de engenharia. Eles construíram tudo, com um engenheiro e muito Claude.

Quero compartilhar como isso funciona, porque acredito que o modelo é replicável e a maioria das empresas está complicando demais.

PerfectScale™ for Kubernetes

Ready to optimize?

Get your free Kubernetes savings analysis

O Applied AI engineer

O centro de tudo é uma função que chamamos de Applied AI engineer. É um engenheiro de software cujo trabalho em tempo integral é atuar dentro de um único time de negócio. Não um consultor que recebe requisitos e some por um trimestre, nem um time de plataforma construindo "AI enablement" para todos e para ninguém. Um engenheiro, um time (o nosso time de People Ops, neste caso), participando das reuniões deles, sentindo as dores deles.

Nosso time de aquisição de talentos, que faz parte da área de People, ganhou um. A missão do engenheiro era simples: automatizar o que é chato, construir o que falta e ensinar o time a fazer cada vez mais sozinho ao longo do tempo.

Essa última parte é a que mais importa. Medimos o engenheiro pelo quanto o time consegue entregar sem ele, não pelo que ele mesmo produz.

As specs acabaram sendo o trabalho de verdade

A reconstrução do site de carreiras começou com um documento, não com código. Escrevemos uma spec longa em markdown descrevendo tudo: a hierarquia de departamentos do Greenhouse e exatamente como os filtros devem percorrê-la, os campos do formulário de inscrição, os redirecionamentos das URLs antigas, o padrão de acessibilidade e até os erros do site antigo que não podiam se repetir. Esse arquivo foi para o repositório como CLAUDE.md, e o Claude Code construiu o site com base nele.

O que eu não esperava era que os recrutadores conseguissem ler a spec. Eles a corrigiram. "A entrevista com o recrutador dura 30 minutos, não 45." "As vagas são marcadas com o subdepartamento, é por isso que os filtros quebram." Conhecimento de domínio que normalmente se perderia num telefone sem fio entre um PM e um contratado foi direto para a fonte da verdade.

Agora escrevemos uma spec assim para cada ferramenta interna. A spec do JD Builder tem cerca de dez páginas e inclui os prompts exatos, os critérios de pontuação e perguntas em aberto para os stakeholders. Escrevê-la levou dias. A ferramenta funcionando levou menos tempo do que a spec. Essa proporção ainda me parece estranha, e já parei de esperar que ela se inverta.

O que eles realmente construíram

O site público é a parte visível: um formulário de inscrição customizado falando diretamente com a API do Greenhouse, um mapa de contratações, alertas de vagas, SEO e AEO bem feitos e um e-mail de confirmação com a nossa marca no momento em que você se inscreve. Legal, mas isso é só o básico.

As ferramentas internas foram o que realmente mudou a semana do time:

JD Builder. Qualquer pessoa na DoiT pode gerar ou reescrever uma descrição de vaga. A IA escreve no nosso tom de voz e, enquanto você edita, a IA também recalcula a pontuação do rascunho mais ou menos a cada segundo em cinco dimensões: inclusão, tom, completude, legibilidade e se um candidato forte realmente pararia de rolar a tela. Importe uma vaga aberta do Greenhouse, corrija e envie de volta. A meta que definimos: de "preciso de uma JD" até a publicação em menos de 15 minutos, com pontuação de inclusão de 85 ou mais. Os gestores de contratação pararam de mandar rascunhos para o time de TA reescrever. Agora eles mesmos resolvem.

JD Builder

Nosso sistema interno de criação de descrições de vagas

Candidate Sourcing. Um recrutador escolhe uma vaga aberta e a ferramenta lê a descrição, pede à IA que escreva uma query de busca com critérios de verificação e entrega tudo a uma API de pesquisa na web que encontra cerca de 250 pessoas compatíveis e localiza seus e-mails profissionais. Os critérios codificam o que aprendemos sobre quem prospera aqui, como candidatos vindos de empresas que vendem para times de plataforma e DevOps. O contato acontece na mesma tela, via LinkedIn e e-mail, com leads favoritados, anotações e rastreamento de contatos. Os sourcers pararam de fazer malabarismo com abas do navegador e planilhas.

Candidate Sourcing

Interface de sourcing de candidatos

Candidate Screener. É no volume que a contratação derrota os humanos, então essa é a ferramenta que mais importa. Uma vaga recente atraiu cerca de 2.200 inscrições; os próprios filtros do Greenhouse reduziram isso para aproximadamente 1.100 candidatos ativos. O screener puxou do Greenhouse o currículo, as respostas de triagem e o perfil de cada um e pediu à IA que os pontuasse em oito características universais mais os requisitos específicos da vaga. Cada candidato recebe uma avaliação por escrito — e quero dizer cada um deles: um resumo, pontos fortes com evidências citadas do currículo, pontos de atenção que merecem ser explorados na entrevista e pontuações por característica, com um link de volta para o perfil no Greenhouse. Definimos o corte em 96 e chegamos a 61 candidatos fortes. Essa é uma shortlist que um time de contratação realmente consegue sentar e revisar junto — e ainda exportar para CSV quando fizer isso. A vaga em que rodamos isso? Nosso próximo Applied AI engineer. Pareceu apropriado.

Candidate Screener

Triagem de candidatos com classificador de IA

Comp Review. Quando um Doer se inscreve em uma vaga interna no Greenhouse, um webhook monta o rascunho da revisão de remuneração antes que alguém peça: salário atual, bônus, equity e histórico de promoções via API do Rippling (nosso sistema de RH), além de uma faixa salarial calculada a partir dos pares na mesma função e região. Depois, notifica no Slack o recrutador, o gestor, o skip-level, o HRBP e o head do departamento. O que antes era uma semana de arqueologia em planilhas e cobranças por e-mail agora é um fluxo de aprovação com lembretes.

Comp Review

Sistema de revisão de remuneração

Anúncios no Slack. As novas vagas são publicadas no Slack no momento em que abrem, com o recrutador e o gestor de contratação marcados, já com o prazo para inscrições internas. Os Doers ficam sabendo das novas vagas na hora e podem considerar a mobilidade interna se fizer sentido para suas aspirações de carreira.

Slack announcements

Notificações internas no Slack

Nenhuma dessas ferramentas teria prioridade suficiente para entrar no roadmap de engenharia. Juntas, elas mudaram a forma como o time opera.

Your cloud bill shouldn't be a mystery

Optimization, automation, expertise. In one platform.

A parte que merece cautela

A triagem é a aplicação de IA de maior consequência que já fizemos, e quero ser honesto sobre os dois lados disso.

O argumento a favor é forte. O screener lê o candidato número 1.100 com a mesma atenção e os mesmos critérios do candidato número 1. Humanos não conseguem fazer isso. Nós cansamos, ancoramos no último currículo que lemos e, no fim da tarde, estamos reconhecendo padrões nas coisas erradas. Uma pessoa enterrada na posição 900 da pilha recebe da máquina uma leitura justa que nunca receberia de um revisor exausto. Sou um forte defensor da IA exatamente nesse ponto.

Mas a IA carrega seus próprios vieses, e um viés consistente aplicado a 1.100 pessoas de uma vez é um tipo de problema diferente de um viés humano inconsistente. Por isso o screener produz uma shortlist e uma lista de pontos a investigar; pessoas tomam todas as decisões a partir daí. E antes que isso passe de experimento a ferramenta interna consolidada, devemos a nós mesmos uma conversa aberta sobre justiça, transparência e guardrails. Estamos tendo essa conversa agora, abertamente, e eu recomendaria a qualquer empresa que esteja fazendo isso tê-la antes que a ferramenta funcione tão bem que ninguém mais queira conversar.

O que eu diria a outro CEO

Comece por algo quebrado, não por uma estratégia de IA. Não começamos querendo "adotar IA no RH". Começamos querendo consertar um site de carreiras com filtros quebrados. O resto foi se acumulando a partir daí, uma dor de cada vez.

Um repositório, infraestrutura compartilhada. Cada ferramenta vive no repositório do site de carreiras e reutiliza a mesma integração com Greenhouse e Rippling e a mesma autenticação. A segunda ferramenta exigiu uma fração do esforço da primeira. A quinta saiu quase de graça.

Quem não é engenheiro revisa resultados, não código. Nossos recrutadores não sabem ler TypeScript e não precisam. Eles conseguem dizer em segundos se uma JD gerada soa como a gente, e o dashboard de qualidade dá a eles uma linguagem comum para apontar o que está fora do tom. Confie no especialista de domínio para julgar o resultado; deixe o agente e o engenheiro se preocuparem com o diff.

Os custos são o de menos. Um modelo rápido e barato para pontuação em tempo real, um modelo forte para geração, um contêiner que escala para zero quando ninguém está contratando às 3 da manhã. Não é um item de custo relevante. A parte cara é o salário do engenheiro, e um engenheiro por time é justamente a proposta.

A verdade nada glamourosa é que a maior parte do valor veio de uma pessoa que se importava, sentada perto do trabalho, com um agente de código que eliminou a desculpa de "não temos capacidade de engenharia". Essa combinação está disponível para quase qualquer empresa agora mesmo.

E se um lugar onde recrutadores entregam software em produção e o CEO escreve specs parece o seu tipo de lugar, o site de carreiras que o time construiu está em careers.doit.com. Os filtros funcionam agora; eu conferi.