Como Contratar um Programador Quando Não Percebe Nada de Tecnologia

O momento em que percebe que está a nadar em águas profundas

Publica a vaga, chegam os currículos, e todos mencionam frameworks de que nunca ouviu falar. Alguém alega cinco anos de "desenvolvimento full-stack com arquitetura de microsserviços escalável" e não faz ideia se isso é impressionante ou algo que copiou de um tutorial uma hora antes da entrevista. Vai acenando durante a chamada. Não tem forma de questionar.

Isto é normal. A maioria das pessoas que gerem uma empresa de 10 a 200 pessoas não são programadores, e mesmo assim precisam de contratar um. A boa notícia é que não precisa de aprender a programar para contratar bem. Precisa é de deixar de tentar avaliar o código e passar a avaliar as provas à sua volta.

Não finja fluência técnica — vai correr mal

Os candidatos apercebem-se quando está a fingir. Perguntar "então fale-me da sua experiência com Kubernetes" e depois responder "ótimo, ótimo" seja qual for a resposta ensina a um candidato esperto que esta entrevista não tem um critério real. Quem fala fluentemente mas não entrega vai passar sem esforço. Os candidatos discretos mas competentes, que assumem que está mesmo a avaliar, vão desvalorizar-se a si próprios.

Em vez disso, seja honesto. "Não sou técnico, por isso vou pedir-lhe que explique as coisas em linguagem simples e vou contar com alguém tecnicamente competente para parte deste processo." Isto não é fraqueza — é exatamente o que faz um bom gestor de contratação ao contratar para qualquer área que não domina pessoalmente.

Peça emprestados os olhos técnicos de outra pessoa — por uma hora, não para todo o processo

Não precisa de um cofundador técnico a tempo inteiro para contratar bem. Precisa de uma hora do tempo de um programador, duas vezes: uma para ajudar a escrever a descrição da vaga e as perguntas de triagem, e outra para participar numa conversa da fase final ou rever uma amostra de trabalho.

Quem pode ser essa pessoa:

• Um programador freelancer a quem paga por duas horas de consultoria
• Um amigo ou conselheiro que já tenha criado software
• Um contratado que já usa para outra coisa

O que lhe deve pedir é algo específico: "Olhe para a resposta deste candidato a esta pergunta em concreto e diga-me se faz sentido." Não "avalie esta pessoa por mim" — isso é demasiado vago e pede demais a um favor.

Peça aos candidatos que expliquem o seu próprio trabalho, não hipóteses

Um programador que realmente construiu algo consegue explicá-lo em linguagem simples, ao nível de detalhe que exigir. Alguém que inchou o currículo normalmente não consegue ir além da superfície.

Boas perguntas, por ordem do que mais revelam:

1. "Descreva-me algo que construiu e do qual se orgulha. O que fazia, e qual foi a sua parte nisso?"
2. "Qual foi o problema técnico mais difícil desse projeto, e como o resolveu?"
3. "Se perguntasse aos outros engenheiros dessa equipa como era trabalhar consigo, o que diriam — e porquê?"
4. "Fale-me de uma vez em que o seu código partiu algo em produção. O que aconteceu e o que fez?"

A quarta pergunta é a que mais revela. Quase todos os programadores a sério já partiram alguma coisa. Alguém que diz "isso nunca me aconteceu" depois de alegar vários anos de experiência ou está a mentir ou nunca lançou nada que realmente importasse.

Use uma pequena amostra de trabalho real

Não precisa que um candidato construa uma funcionalidade completa de graça. Uma tarefa curta e bem delimitada — algo que demore 60 a 90 minutos, próxima do trabalho real que faria na função — diz-lhe mais do que uma hora de conversa.

Mantenha o processo justo:

• Pague por ela, ou torne-a genuinamente pequena o suficiente para ser razoável não pagar (a maioria dos candidatos diz-lhe qual é qual)
• Dê a mesma tarefa a todos nessa fase
• Peça-lhes depois que expliquem a sua própria solução — é aqui que se apanha alguém que teve ajuda e não a mencionou

Se não tiver critério técnico para avaliar o resultado, este é exatamente o momento certo para usar a sua hora de apoio técnico emprestado.

Se preferir não criar uma tarefa do zero, um teste técnico calibrado pode fazer uma primeira triagem antes de chegar a esta fase — o AssessFit executa testes adaptativos numa variedade de competências técnicas, para não ter de enviar todos os candidatos diretamente ao seu único avaliador técnico.

Verifique o que entregaram, não o que dizem saber

Um currículo cheio de nomes de tecnologias diz-lhe o que alguém já experimentou, não aquilo em que é bom. Peça provas em vez disso:

• Um perfil de GitHub, portefólio, ou link para algo em produção que tenham construído
• O nome da empresa e do produto, para poder ver por si próprio
• Que percentagem de um projeto foi realmente da autoria da pessoa, e quanto foi da equipa

Não se deixe impressionar por uma longa lista de ferramentas. Interesse-se por uma ou duas coisas em que a pessoa consiga aprofundar. A profundidade é o sinal; a amplitude de palavras-chave é, muitas vezes, o oposto disso.

Verificação de referências: pergunte sobre entrega, não sobre competência

Não pode perguntar a uma referência "o código dela era bom?" e esperar uma resposta útil, a menos que essa referência também seja técnica — e mesmo assim, é uma pergunta vaga e generosa que raramente é contestada.

Pergunte antes:

• "Cumpriu aquilo que disse que ia cumprir, no prazo que estimou?"
• "Quando algo corria mal, avisava cedo ou só descobriam mais tarde?"
• "Confiaria em entregar-lhe algo ambíguo e deixá-lo resolver, ou tudo tem de estar explicado ao pormenor?"

Estas perguntas também não exigem que a referência perceba de código. Exigem apenas que a referência tenha trabalhado com esta pessoa, o que é um critério muito mais fácil para obter respostas honestas.

O limite honesto disto tudo

Nada disto substitui ter, eventualmente, uma pessoa técnica de confiança. Se esta contratação for o seu primeiro engenheiro e não houver mesmo ninguém na sua rede que possa validar a escolha, vale a pena assumir isso como um risco em voz alta — para si próprio, e possivelmente para um investidor inicial ou conselheiro que possa conhecer alguém. Um período experimental de 90 dias, com marcos de entrega claros e não técnicos (a coisa foi lançada, funcionou, os utilizadores queixaram-se), é a sua rede de segurança caso a contratação se revele mais fraca do que a entrevista sugeria.

Não está a tentar tornar-se programador. Está a tentar construir um processo que capte a diferença entre alguém que construiu coisas e alguém que apenas decorou as palavras certas.