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 iniciais. 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.

iMasters