Existe um número que ninguém mede, mas todo mundo sente: a maior parte dos desligamentos de devs no primeiro ano não tem nada a ver com capacidade técnica.
A pessoa conhecia a stack. Passou no teste de código. Falou bem de arquitetura na entrevista. Mas, depois de três meses, as coisas começaram a desandar. Prazos estouravam sem aviso prévio. As descrições de pull request tinham uma linha. Ela ficava na defensiva no code review. Trabalhava sozinha quando a feature pedia colaboração.
A gente vê esse padrão o tempo todo. Depois de alocar mais de 200 profissionais em times de produto, ele aparece quase sempre do mesmo jeito: a empresa contrata alguém que parece perfeito no papel e se separa dessa pessoa entre 6 e 12 meses depois, por causa de tudo que o papel não mede.
O padrão que a gente vê sempre
Funciona assim. Uma empresa abre uma vaga para dev React sênior. Cinquenta pessoas se candidatam. O time de contratação filtra por anos de experiência, conhecimento do framework e nota no desafio técnico. Entrevista as três melhores. Uma delas vai muito bem na etapa técnica: código limpo, respostas certas, boa visão de arquitetura.
Ela recebe a proposta.
A primeira semana vai bem. Na quarta semana, a liderança percebe que essa pessoa nunca fala na daily, a não ser que alguém pergunte direto. Na oitava, um problema em produção fica seis horas sem ser escalado porque o dev não sabia para quem avisar. Na décima segunda, um colega pede para parear numa feature complexa e leva um fora.
No sexto mês, a liderança gasta mais tempo gerenciando essa única pessoa do que o resto do time inteiro. O dev é habilidoso. Só não é efetivo.
Por que isso acontece
Processos seletivos são montados para medir o que é fácil de medir. Teste de código tem resposta certa e errada. Anos de experiência cabem numa coluna de planilha. Conhecimento de framework vira checklist.
Comunicação, senso de dono e bom julgamento diante de ambiguidade não cabem em planilha. Então a maioria dos processos ignora essas coisas, ou reduz tudo a uma conversa de "fit cultural" que, na prática, quer dizer "eu tomaria uma cerveja com essa pessoa?".
Isso não é processo. É cara ou coroa com cara de entrevista.
O resultado é previsível. Você contrata pelo que mediu (habilidade técnica) e demite pelo que não mediu (todo o resto).
O que "soft skills" significa em engenharia
O termo "soft skills" não faz justiça ao que está em jogo. Essas habilidades não têm nada de leves. São elas que decidem se uma pessoa tecnicamente capaz entrega valor de verdade num time.
Quando avaliamos soft skills na EnzRossi, olhamos para cinco coisas:
Comunicação proativa. Quando trava num problema, o dev fica dois dias parado ou avisa em poucas horas? Quando um prazo corre risco, ele avisa o time antes de estourar ou depois? Esse é o maior indicador de sucesso para quem trabalha remoto.
Escrita clara. Times remotos funcionam por escrito: mensagens no Slack, descrições de PR, documentos no Notion, atualizações assíncronas. Um dev que escreve bem acelera o time inteiro. Um dev que escreve mal cria um custo fixo para todo mundo.
Senso de dono. É a diferença entre "terminei meu card" e "terminei meu card, vi que os testes de integração estavam instáveis, corrigi e atualizei a documentação". Ter senso de dono é pensar além das bordas da tarefa.
Abertura a feedback. Como a pessoa reage quando o código dela recebe questionamento? Discute o ponto ou fica na defensiva? É no code review que a cultura de um time se sustenta ou desmorona.
Julgamento diante de ambiguidade. Requisito nunca vem perfeito. Quando a especificação tem uma lacuna, o dev trava, constrói a coisa errada ou faz a pergunta certa? Em time remoto isso pesa ainda mais, porque não dá para virar a cadeira e perguntar.
Como avaliar isso antes de contratar
A boa notícia: dá para avaliar essas habilidades num processo seletivo. Só precisa ser de propósito.
A mudança na entrevista
Troque o "me fala sobre você" por perguntas de cenário. Em vez de pedir que a pessoa descreva a experiência dela, coloque a pessoa numa situação. "Você está há dois dias numa feature e percebe que o contrato da API não bate com o protótipo. A designer está de férias. O que você faz?" Não existe uma única resposta certa, mas o jeito como a pessoa raciocina mostra muito sobre como ela se comunica e decide.
Faça um exercício de colaboração ao vivo, não um teste de código ao vivo. Entregue uma feature parcialmente construída, com um bug e alguns requisitos pouco claros. Resolvam juntos, com tela compartilhada. Você não está avaliando se ela acha o bug em doze minutos. Está observando como ela pergunta, como explica o raciocínio e como lida com o momento em que trava.
Avalie a comunicação assíncrona diretamente. Passe um desafio para fazer em casa e avalie a mensagem de entrega tanto quanto o código. A pessoa explicou a abordagem? Apontou os trade-offs? Listou o que faria diferente com mais tempo? O código pode estar ótimo e a comunicação, péssima. Você precisa saber as duas coisas.
Peça uma história real de conflito. "Me conta de uma vez em que você discordou de um comentário de code review." Se a pessoa não lembra de nenhuma, ou é júnior demais ou concorda com tudo. Se ela conta uma situação em que estava claramente certa e o outro claramente errado, isso é um sinal de alerta. As melhores respostas mostram alguém que lidou com a discordância de forma produtiva.
O que a gente faz diferente
Na EnzRossi, todo profissional passa por uma entrevista comportamental antes mesmo de agendarmos a etapa técnica. Fazemos isso de propósito. Se a pessoa não consegue se comunicar com clareza numa conversa estruturada, não precisamos ver o código dela.
Nessa entrevista, avaliamos as cinco coisas que descrevi acima: comunicação proativa, escrita clara, senso de dono, abertura a feedback e julgamento. Cada uma recebe uma nota separada. Um candidato pode ser excelente tecnicamente e mesmo assim não passar no nosso processo se tiver nota baixa em comunicação ou senso de dono.
Não é exigência por exigência. É respeito pelo tempo dos nossos clientes. Todo profissional que alocamos entra num time real, com prazos reais. Se ele cria trabalho extra de comunicação em vez de reduzir, a gente falhou.
O mercado de contratação adora otimizar velocidade. "Primeira shortlist em 3 dias" é uma promessa que a gente também faz. Mas velocidade sem precisão é só errar mais rápido. Montamos um processo de avaliação que é rápido porque é estruturado, não porque pula etapas.
Se você cansou de contratar devs que vão bem na entrevista e entregam mal, comece invertendo o processo. Avalie comunicação primeiro. Filtre a parte técnica depois. Você vai contratar menos gente que fica bonita no papel e mais gente que entrega.
