O problema que ninguém admite sobre contratação
Hard skills e soft skills são duas categorias de habilidades que todo gestor de RH e liderança técnica conhece na teoria, mas raramente aplica com consistência. Na prática, você vai ver gente sendo contratada por causa do currículo impressionante e demitida seis meses depois porque não consegue se comunicar com o produto. Ou vice-versa: alguém que se dá bem na conversa mas não entrega código funcional. A separação entre essas categorias é mais útil do que perfeita.
Hard skills e soft skills são duas categorias de habilidades com aplicação prática diferente
Hard skills são competências técnicas mensuráveis. Você passa num teste, faz um exercício técnico, entrega um projeto e o resultado é objetivo. Python, SQL, AWS, modelagem de dados, engenharia de APIs — isso tudo é hard skill. O problema é que o mercado de tecnologia virou uma máquina de Certificações™ e os recrutadores usam certificados como atalho para filtrar currículos. Eu vi um candidato com cinco certificações AWS passar na triagem técnica e não conseguir explicar o fluxo de dados de um lambda trigger básico. O certificado provou que ele sabia marcar bolinhas numa prova de múltipla escolha, não que ele sabia construir algo. Soft skills são competências comportamentais e interpessoais. Comunicação, negociação, resolução de conflitos, adaptabilidade, liderança. O problema aqui é completamente oposto: elas são difíceis de avaliar e fáceis de manipular durante uma entrevista. Candidatos que praticaram respostas de entrevista comportamental soam extremamente comunicativos e colaborativos em trinta minutos. Ninguém percebe que a pessoa não sabe ouvir até ela estar em uma reunião real de sprint planning discutindo escopo com engenharia e produto.
No meu trabalho com equipes de engenharia, eu adotei um padrão bem específico há uns anos: todo candidato para vaga técnica tem um exercício prático de trinta minutos onde ele precisa explicar uma decisão técnica pra mim como se eu fosse um gerente de produto sem background técnico. Isso revela duas coisas de uma vez. Primeiro, se ele domina o conteúdo suficiente pra simplificar. Segundo, se ele tem empatia cognitiva — a capacidade de se colocar no lugar de quem não sabe o que você sabe. A maioria das pessoas que passam nos testes técnicos tradicionais travam completamente nesse exercício. E muitos dos que falham nos testes técnicos conseguem se comunicar tão bem que eu acabo levando pra segunda rodada só pra ver o que acontece no código deles.
Como montar um quadro de avaliação que realmente funciona
O erro mais comum é tratar hard skills e soft skills como pesos iguais num processo seletivo. Na verdade, o peso ideal depende do nível da vaga e do contexto da equipe. Para uma vaga de júnior, hard skills pesam mais porque você espera maturação comportamental no dia a dia. Para uma vaga de senior ou staff, o inverso é verdadeiro: técnico você contrata, comportamento você convive. Aqui está o que eu uso como framework prático:
👉 Clique no botão abaixo para saber mais sobre o assunto!
Para hard skills: exercícios práticos reais, não puzzles de lógica. Peça para a pessoa construir algo mínimo que resolva um problema do dia a dia da equipe. Um endpoint de API, uma query SQL otimizada, um script de deploy. O tempo ideal é entre quarenta e noventa minutos. Se passar de duas horas, você está testando velocidade, não competência. O que eu aprendi na prática é que questões muito abstratas ("faça um sistema de recomendação") produzem resultados piores do que problemas concretos ("essa query leva três segundos, identifique o gargalo e otimize"). Para soft skills: pare de fazer perguntas do tipo "qual é seu maior defeito". Todo mundo tem uma resposta ensaiada. Em vez disso, use cenários hipotéticos contextualizados. "Você e o product owner discordam sobre o prazo de uma feature. Ela acha que pode entregar em duas semanas, você acha que são quatro. O que você faz?" A resposta correta não existe, mas o processo de raciocínio do candidato revela muito. Pessoas que pulam direto para "eu delego pra outra equipe" têm perfil diferente de quem começa perguntando sobre dependências e trade-offs.
O que funciona de verdade e quase ninguém faz é o trabalho de referência contextualizado. Não aquele e-mail genérico pro recruiter perguntando "esse cara é bom". Ligação de quinze minutos com um colega de trabalho real que projetou junto com a pessoa. Perguntas específicas: "em que situação essa pessoa foi difícil de lidar?", "o que ela faz quando está sob pressão?", "você voltaria a trabalhar com ela?". Se o ex-colega hesitar antes de responder, isso já é um dado importante.
Onde esse modelo falha e alternativas
Esse sistema tem limitações que eu descobri na prática. A principal é que soft skills avaliadas em contexto artificial de entrevista não predizem performance real com alta confiança. Estudos em ciência organizacional mostram correlação modéstia entre entrevistas comportamentais estruturadas e desempenho posterior no cargo. O work sample test (o exercício prático) é consistentemente o preditor mais forte de performance, tanto para hard quanto para soft skills, porque ele simula o trabalho real. Outro problema é viés de confirmação. Quando um entrevistador sente quimária positiva com o candidato nas primeiras cinco minutos, ele tende a interpretar todas as respostas subsequentes de forma mais indulgente. Eu resolvi isso implementando scorecards individualizados: cada entrevistador recebe três critérios objetivos pré-definidos e nota cada um de um a cinco, sem poder de discutir a nota com outros entrevistadores antes de submeter. Isso elimina o efeito manada.
Se a sua equipe é muito pequena ou o volume de contratações é baixo, o framework inteiro pode ser overkill. Nesses casos, uma abordagem mais leve funciona: um coffee chat de trinta minutos com dois membros da equipe atuais mais um exercício técnico rápido. O coffee chat revela o que o currículo não mostra. O exercício técnico filtra quem não tem o básico. Custo baixo, resultado aceitável para equipes de menos de vinte pessoas. A parte mais contraintuitiva que eu aprendi trabalhando com isso: hard skills envelhecem mal em muitos contextos de tecnologia. Uma pessoa que domina React hoje pode precisar de três meses para se adaptar ao ecossistema Vue ou ao pipeline de dados da empresa no ano que vem. Soft skills básicas — capacidade de aprender, feedback receptivo, comunicação clara — são muito mais portáteis entre tecnologias e contextos. Por isso, em vagas para tecnologias emergentes ou em transformação, eu peso soft skills com ainda mais ênfase do que o padrão. Um bom desenvolvedor que sabe se comunicar e aprender rápido se adapta a qualquer stack. Um desenvolvedor brilhante que não comunica decisões técnicas vira um risco operacional para a equipe inteira.
No final das contas, hard skills e soft skills são duas categorias de habilidades que se complementam, não competem. O segredo não é escolher uma em detrimento da outra, mas entender quando cada uma determina o limite inferior da sua competência — e quando ela determina o teto do seu crescimento. Contratação é, essencialmente, uma aposta sobre qual delas vai pesar mais no longo prazo para aquele lugar específico.
