Contratando desenvolvedores: você está fazendo errado

Texto
original em Inglês de
Udo Schroeter disponível em http://devinterviews.pen.io/

?

Quando Evan Carmi postou sua experiência em uma
entrevista de emprego no Google (http://ecarmi.org/writing/google-internship/) no
HN, eu me lembrei dos meus dias inicias. Em mais de uma década de entrevistas
para empresas startups de TI, não fizemos nenhum progresso. Eu fui parte do
problema por alguns anos. Eu simplesmente copiava um mecanismo de contratação
que parecia padrão na época e, ao fazer isso, falhei miseravelmente no que
dizia respeito ao principal objetivo que uma empresa deve ter ao contratar
desenvolvedores. Hoje, as primeiras páginas de tecnologia estão cheias de esforços de Larry
Page para transformar a empresa,
mas acredito que os problemas de performance em empresas focadas em
desenvolvimento podem estar atrelados a seu DNA devido a um processo falho de
contratação.

Como nós fazíamos

Meu co-fundador e eu estávamos administrando uma pequena loja de
desenvolvimento web na Alemanha. Começamos literalmente do porão da casa de
nosso amigo. Com o tempo crescemos, e nos mudamos para um escritório de
verdade. No início foi fácil encontrar novos colaboradores, nós podíamos apenas
pedir para nossos amigos virem trabalhar para nós. Claro que esse modelo não
funcionava em grande escala, mas ele fazia uma determinada função muito bem:
garantia que contratássemos pessoas que eram boas para a empresa, tanto no
sentindo pessoal quanto no profissional. Até que chegou o dia em que tivemos que
preencher posições para as quais precisávamos trazer pessoas de fora.

Uma das características do serviço regional de desemprego
na Alemanha é que eles te enviam uma pilha enorme de CVs, poucas horas depois
de você ter falado com eles no telefone. Eu fiquei felizmente surpreso que não
tivemos que contratar uma agência para fazer isso. Juntamente com os CVs que já
havíamos recebido de pessoas que se inscreveram para a posição através de nosso
site, agora tínhamos que fazer uma triagem. No final das contas, concordamos
sobre 12 os melhores e os convidamos para uma entrevista. Essa é a parte em
que tudo deu errado.

A entrevista padrão para desenvolvedores

Um candidato chegaria, normalmente usando seu melhor terno e sua melhor
gravata, e nós sentaríamos para ter uma conversa. Essa conversa era algo
essencialmente parecido com um exame oral de faculdade. Eu pediria a ele para
codificar algoritmos para todos os problemas de CS bonitinhos, e obteria
respostas com vários níveis de qualidade. Alguns deles atiravam suas respostas
prontas em uma velocidade absurda. Eles estavam preparados exatamente para
aquele tipo de entrevista. Outros se renderiam à pressão, quase incapazes de
conseguir terminar a entrevista.

Para ser sincero, quando começamos a fazer isso, eu tinha
que dar uma olhada nesses quebra-cabeças antes, principalmente para garantir
que eu não passaria vergonha. Este deveria ter sido o primeiro sinal de que
talvez não estivéssemos testando as habilidades mais relevantes para nossos
requisitos. Se essas dúvidas passaram pela minha cabeça, eu deveria tê-las deixado
de lado rapidamente. Afinal de contas, era a maneira como todo mundo fazia
entrevistas.

Claro que optamos por contratar o funcionário com as
respostas mais inteligentes. Inevitavelmente, outras posições se tornaram
disponíveis, e nós repetimos o processo inúmeras vezes, por todo o tempo de
vida da empresa. Se isso soa familiar para você, certamente você não está
sozinho.

Performance real de trabalho

Mas como medimos o trabalho dos candidatos que selecionamos? A verdade é que
tivemos resultados bastante variados. Muitos deles estavam dentro da média, muito
poucos eram excelentes e alguns eram simplesmente horríveis em suas
posições. Portanto, a entrevista não tinha nenhum efeito real sobre a qualidade
das pessoas que estávamos selecionando, e receio que esse processo pode ser
sido mais favorável à seleção de pessoas ruins.

O que de bom e de ruim isso significa nesse contexto? Vamos dar uma
olhada em alguns benchmarks que
considero importantes:

Cultura da Organização: Olhando para trás, uma das qualidades
mais importantes que um novo funcionário deve ter é compatibilidade com o
espírito das pessoas que já trabalham na empresa. A entrevista padrão teve o
pior desempenho nesse quesito, por razões óbvias. É difícil julgar a
personalidade das pessoas em entrevistas, porque elas não são exatamente elas
mesmas naquele momento. Na verdade, são incentivadas a não serem elas
mesmas.

Competência em Programação: De alguma maneira, contrariando minha intuição, os
exemplos de códigos feitos durante a entrevista foram um indicador ruim da real
competência no trabalho. Projetos do mundo real raramente consistem em
implementar buscar binárias sem acesso a um analisador ou literatura. O que
aconteceu foi que os empregados que se deram melhor nos exemplos de código nem
sempre eram capazes de trazer seu conhecimento teórico para soluções práticas.
Ter candidatos escrevendo algoritmos sortidos no whiteboard é um método que beneficia pessoas com ótima memória a
curto prazo, que vêm preparadas exatamente para esses tipos de perguntas. No
nosso caso, precisávamos de codificadores engenhosos, que escrevessem softwares
organizados, estáveis e elegantes – e o processo de entrevista não estava os
selecionando.

Gerenciamento de Projetos: Pessoas que foram bem na entrevista não são,
necessariamente, bons colegas de equipe ou até bons apresentadores perante os
clientes. Esse resultado foi surpreendente para mim. Acontece que aguentar uma
entrevista por uma hora é uma habilidade completamente diferente de, digamos,
ser bom em coordenar seus colegas de trabalho ou a pessoa que paga suas contas.
A performance da entrevista também não indicava a habilidade de escrever uma
boa documentação, ou como se comportar em comunicações online.

O resultado

O resultado de um processo seletivo como esse pode ser um dos fatores
responsáveis pela perda do espírito de startup da empresa e sua alma criativa.
Esse foi, definitivamente, o caso da nossa empresa. Como CEO, a maior falha foi
certamente minha. No entanto, ter as pessoas erradas para o trabalho foi em
grande parte a causa da incapacidade da empresa de entregar a quantidade e
a qualidade necessárias para se sustentar. As brigas internas envenenaram nossos
times. A incompetência era mascarada com boas capacidades de apresentação e
puxação de saco. Boas pessoas deixaram a empresa porque elas odiavam essa nova
atmosfera.

Apesar de eu ter dispensado várias pessoas por razões
distintas ao longo dos anos, no final das contas, eu tive que fazer o discurso
mais difícil da minha vida na manhã em que dissolvi a empresa.

Claro que esse é um exemplo extremo. A maioria das empresas
prospera, apesar disso tudo. Mas eu ainda acredito que podemos melhorar muito as
chances de encontrar os candidatos certos, ao mudar radicalmente a maneira como
fazemos entrevistas. E, no nosso caso, isso provavelmente teria feito toda a
diferença do mundo.

Uma alternativa

Como seria, então, uma entrevista para desenvolvedores? Simples: elimine a
parte dos exames completamente da entrevista. Em vez disso, pergunte questões
em aberto, que convidem seus candidatos a elaborar sobre seu trabalho de
programação.

• Qual foi o último projeto no qual você trabalhou no seu último emprego?

• Me conte sobre seus projetos preferidos.

• Em que projetos você está trabalhando no seu tempo livre?

• De quais comunidades online hackers você participa?

• Me conte sobre alguns pontos (técnicos/de programação) pelos quais você se
  sente entusiasmado.

Essas questões foram formuladas para revelar bastante
sobre a pessoa que você tem na sua frente. Elas podem te ajudar a decidir se o
candidato está interessado nas mesmas coisas que você, se você gosta do seu
jeito de pensar e onde seus interesses reais estão. É mais difícil para eles conseguirem a vaga na malandragem, porque o entrevistador pode investigar
questões mais profundas à medida que eles vão se apresentando.

Mas e a habilidade de codificação? Bom, pegue alguns minutos após a entrevista
para dar uma olhada em alguns códigos que o candidato escreveu. Talvez para um projeto
open source, talvez eles tenham que te enviar algo que não é publico, não
importa. Olhar para a produção real do código pode te falar muito mais do que
as linhas artificiais escritas no whiteboard.

Tenho certeza de que você pode criar outras questões e outras maneiras de engajar
o entrevistado. Nesse ponto, qualquer ideia já indicaria uma melhora.

Ditados

A maioria das pessoas é rápida ao defender seu status quo, e com certeza essa é uma posição gratificante de se
segurar. É livre de riscos e você sempre pode recorrer ao argumento “muitas
pessoas inteligentes, ricas e bem sucedidas fazem as coisas do jeito antigo,
então meu dinheiro está no que eles estiverem fazendo”.

“Legal,
mas isso não
funciona pra empresas grandes de sucesso. Sua idéia não é escalável.”

Claro que é escalável. Em termos de esforço por entrevista não é diferente. Não
existe razão por que isso não deveria funcionar em empresas grandes. No final
das contas, o entrevistado sempre toma uma decisão pessoal e subjetiva. Estou
meramente sugerindo uma maneira que entregue informações mais relevantes para
aquele objetivo.

“Os
melhores programadores não
executam projetos em seu tempo livre” ou: “As pessoas mais talentosas
que conheço trabalham de 9 às 5 E então vão para casa assistir futebol/estar
com suas famílias/ou qualquer outra coisa.”

Essa não é minha experiência. Não estou dizendo que um bom programador não
deveria ter uma vida. Mas eu acredito que uma certa quantidade de entusiasmo
por programação é necessária. E, realmente, se você tem uma ótima habilidade,
não usá-la parece um grande desperdício para mim.

“No meu
tempo livre, estou trabalhando pelo próximo milhão da minha empresa. Oh,
quando não estou trabalhando para minha empresa? Estou com minha família e
amigos.” (verbete
de http://news.ycombinator.com/item?id=2385148)

isso é ótimo, essas pessoas podem de fato me mostrar algo em que elas estavam
trabalhando. No entanto, eu consideraria a falta de hobbies um problema para
alguns trabalhos de desenvolvimento.

Pensamentos finais

Na minha experiência, a entrevista tradicional para desenvolvedores é
insuficiente para encontrar bons candidatos. Enquanto os exercícios típicos de whiteboard se relacionam de alguma
maneira com a competência em CS, eles são um indicador limitado de performance
real de programação.

Discordo do processo e acredito que temos feito as
entrevistas dessa maneira por anos simplesmente porque assim elas são mais fáceis
de administrar, mas os dados gerados por essas entrevistas são amplamente
irrelevantes – para não falar outra coisa. Nós, como parte da indústria,
deveríamos apresentar questões mais personalizadas nas entrevistas,
completamente focadas nas habilidades do candidato. Também acredito que é mais
produtivo julgar a produção de código em oposto a quebra-cabeças modulares
abstratos que não têm conexão real com o trabalho em si.

Mais importante, estou
convencido de que conhecer a personalidade real do desenvolvedor é tão importante
quanto checar sua competência profissional, porque uma escolha errada pode
destruiu o time inteiro.