Uma contratação sênior errada em engenharia custa muito mais do que o salário pago no período. Uma parte do custo aparece na planilha: recrutamento, salário e encargos, rescisão e um segundo processo seletivo. A outra parte não aparece: tempo da liderança, queda de produtividade do time, moral abalado, limpeza do código e as features que nunca saíram. Em geral, essa segunda parte é a maior.
A história costuma ser assim. Uma empresa contrata um dev. Três meses depois, percebe que não está funcionando. O código dele precisa de revisão constante. Os colegas estão frustrados. A liderança de engenharia passa horas por semana em conversas de feedback que não levam a lugar nenhum.
Seis meses depois, a empresa desliga a pessoa. O custo total não é só o salário. Nem perto disso.
Os custos visíveis
Estes são os números que aparecem na planilha:
Recrutamento: taxa de consultoria ou hunter, horas do time de recrutamento, anúncios de vaga e o tempo de quem entrevista de 5 a 10 candidatos.
Remuneração durante o período: salário, encargos e benefícios de todos os meses em que a pessoa ficou, inclusive os meses em que já estava claro que não ia dar certo.
Desligamento: verbas rescisórias, aviso prévio e, dependendo do caso, custos jurídicos.
Segundo processo seletivo: tudo de novo para preencher a mesma vaga.
Só a parte visível já dói. E ainda piora.
Os custos escondidos (a parte cara)
Tempo da liderança. Do momento em que surgem as primeiras preocupações (normalmente entre o segundo e o terceiro mês) até a saída, a liderança de engenharia gasta de 3 a 5 horas a mais por semana com essa pessoa. Conversas de desempenho, documentação, reuniões de escalonamento, plano de transição. Em 3 ou 4 meses, são de 40 a 80 horas de liderança sênior desviadas do trabalho de engenharia.
Queda de produtividade do time. Um dev que escreve código ruim não atrasa só a si mesmo. Atrasa quem revisa o código dele, quem constrói em cima dele e quem corrige os bugs depois. Pela nossa estimativa, isso significa uma queda de 15% a 25% na produtividade de 2 ou 3 pessoas do time durante o período.
Moral abalado. Profissionais fortes não gostam de trabalhar ao lado de profissionais fracos. Quando o time vê alguém com dificuldade ficar meses sem uma solução, perde a confiança na liderança. Em times remotos, onde os sinais de cultura são mais difíceis de ler, esse efeito aumenta. Já vimos casos em que uma contratação errada levou um bom profissional a começar a procurar outra empresa.
Estrago no código. O código escrito durante o período da contratação errada muitas vezes precisa ser refatorado ou substituído. Se a pessoa trabalhou três meses numa feature crítica, essa feature pode precisar de mais um mês de limpeza depois que ela sai. Às vezes mais.
Custo de oportunidade. O maior custo escondido. Durante os 6 meses da contratação errada, mais os 2 ou 3 meses para repor a vaga, o projeto roda abaixo da capacidade. Features não saem. Prazos escorregam. A concorrência anda mais rápido. É impossível medir esse custo com precisão, mas muitas vezes ele é o maior de todos.
A conta de verdade
Quando você soma os custos escondidos aos visíveis, a conta de uma contratação sênior errada fica muito acima do que a empresa pagou de salário no período. Para empresas menores, isso pode ameaçar o negócio. Para as maiores, continua sendo um freio importante na velocidade.
O pior: o estrago cresce com a senioridade. Uma contratação júnior errada custa tempo. Uma contratação sênior errada custa tempo, confiança do time e decisões de arquitetura que levam meses para desfazer.
Por que contratar com pressa gera contratações erradas
A maioria das contratações erradas não acontece por descuido. Acontece por pressa.
O padrão: o time está desfalcado. O backlog cresce. A diretoria pede para a liderança de engenharia "colocar alguém aqui o quanto antes". A régua baixa. O processo seletivo encolhe. Os sinais de alerta viram justificativa: "Ele pareceu meio quieto, mas o código era bom." "As referências foram mornas, mas a experiência batia."
A pressão por velocidade transforma a contratação em preencher cadeira, não em avaliar qualidade. E quando você coloca a pessoa errada na cadeira, fica mais lento do que se tivesse deixado a cadeira vazia.
Um time de quatro devs fortes entrega mais do que um time de cinco em que um precisa de supervisão constante. Sempre.
Como é uma boa avaliação
Uma boa avaliação é completa, mas não é lenta. Dá para ser rigoroso e rápido ao mesmo tempo se o processo for bem estruturado.
Um processo de avaliação completo inclui:
Avaliação técnica com profundidade, sem pegadinhas. Em vez de desafios de algoritmo cronometrados, avalie como a pessoa aborda problemas reais. Ela consegue ler um código que não conhece? Consegue depurar com informação incompleta? Consegue explicar as decisões de arquitetura que tomou?
Avaliação de comunicação. Uma entrevista comportamental estruturada que avalia como a pessoa explica ideias, lida com discordâncias e reage à ambiguidade. É a etapa que melhor prevê o sucesso em time remoto.
Checagem de referências. Conversamos com pelo menos duas referências profissionais que o candidato indica e, quando possível, vamos além delas: contatamos lideranças e colegas anteriores pela nossa rede. Duas perguntas específicas: "Você contrataria essa pessoa de novo?" e "O que você gostaria que a próxima liderança dela soubesse?"
Checagem de alinhamento cultural. O jeito de trabalhar dessa pessoa combina com o time em que ela vai entrar? Startup que anda rápido ou empresa grande e estruturada. Autonomia ou direção próxima. Alinhamentos diários ou assíncrono por padrão. O desencontro de estilos de trabalho causa mais desligamentos do que falta de habilidade técnica.
A troca que importa
A pergunta não é se vale a pena avaliar com cuidado. É se você prefere gastar de 5 a 10 horas a mais por candidato no começo ou centenas de horas lidando com uma contratação errada no fim.
Na EnzRossi, nossa taxa de aprovação é de 5%. Ou seja, 95 de cada 100 candidatos não passam no processo. Alguns desses 95 são tecnicamente competentes. Só não atingem o nosso padrão de comunicação, senso de dono ou alinhamento cultural.
Dizer não para um candidato tecnicamente bom parece caro na hora. É a decisão mais barata que você vai tomar no ano.
Avaliar bem não é ser exigente demais. É ser honesto sobre o que realmente prevê sucesso num time. Habilidade técnica é necessária. Não é suficiente. Os custos escondidos de ignorar todo o resto são altos demais para continuar fingindo que não existem.
