Recrutamento – Guilherme Chapiewski

Sobre entrevistas (parte 3)

Em determinada etapa da sua carreira quando você se torna um desenvolvedor mais experiente ou líder de uma equipe, fazer entrevistas passa a fazer parte do seu dia-a-dia. Entrevistar pessoas é bastante cansativo, demorado e difícil, porém é um trabalho que precisa ser muito bem feito para que você consiga contratar os profissionais que melhor se encaixam na sua equipe e empresa.

A última vez que escrevi sobre entrevistas aqui no meu blog foi há três anos. De lá para cá liderei ou participei de algumas dezenas – talvez centenas – de entrevistas e umas dúzias de contratações, sempre tentando resolver o mesmo problema: Quais são as melhores abordagens para conseguir analisar uma pessoa e entender sua experiência tão bem quanto possível em apenas algumas horas?

Durante esses três anos tentei um monte de coisas diferentes, desde fazer filtro de profissionais com uma consultoria de RH até chamar pessoas para trabalharem na minha equipe por alguns dias e ver como elas funcionam. Todas as abordagens tem seus prós e contras e não há uma fórmula secreta para resolver esse problema, mas ficam aqui algumas dicas novas de coisas que deram certo nesses últimos anos:

Entrevista por telefone

Houve uma época em que eu chamava qualquer pessoa para uma entrevista presencial. Basicamente só entrevistava por telefone pessoas de outros estados, mas sempre que possível preferia entrevistar ao vivo porque sempre achei que uma conversa “olho no olho” é muito melhor para conhecer as pessoas. De fato isso é verdade, porém o que acontece é que em geral você recebe uma dezena de currículos e fica muito difícil entrevistar todo mundo. Pior ainda é que muitas vezes o candidato tem um currículo excelente mas na hora da entrevista você percebe que ele na verdade tem um currículo muito bem escrito e não passa disso, ou seja, você perdeu o seu tempo (e o candidato também).

Para resolver esses problemas hoje em dia eu entrevisto praticamente todas as pessoas por telefone. Depois de escolher as pessoas que quero conhecer, marco uma conversa de 30 minutos onde tento explorar conhecimento sobre tecnologias que usamos, valores, interesses pessoais e o mais importante: saber se essa pessoa é mesmo boa ou tem apenas um currículo bonito. Se você não tem idéia de como entrevistar pessoas por telefone, este artigo do Joel Spolsky é um bom começo para aprender.

Com essa abordagem consigo entrevistar um número significativamente maior de pessoas, primeiro porque é uma entrevista mais curta – portanto me sobra mais tempo -, segundo porque sendo por telefone dá para falar em horários mais alternativos – o que facilita a vida de todo mundo e aumenta o número de pessoas que podem participar imediatamente -, e terceiro porque isso diminui drasticamente o número de pessoas que são entrevistadas presencialmente. Deixe para entrevistar presencialmente somente as pessoas que você acha que realmente têm chance de participar do seu time.

Programe e discuta código com o candidato

Dá até vergonha de dizer, mas acredite, no passado (não muito distante) eu já contratei desenvolvedores sem ver uma linha do seu código. Mais vergonhoso ainda é saber que isso é uma prática extremamente comum no mercado. Já vi isso acontecer em inúmeras empresas de todos os tamanhos. O problema disso é que, uma vez que você contrata um desenvolvedor ruim, a trapalhada já está feita, não tem mais como voltar atrás. Você até pode demitir o cara e contratar outro, mas você vai ficar demitindo e contratando até achar alguém que te agrade? Além de ser uma abordagem bem ineficiente, acho que não é ético. Imagine que o profissional estava bem em uma determinada empresa e você o tirou de lá para trabalhar na sua equipe. Por culpa sua ele não só perdeu o emprego antigo como também perderá o novo (porque você não foi eficiente avaliando-o na entrevista).

Evite isso e dedique uma boa parte da sua entrevista a ver e discutir código com o seu candidato. Nesse último ano passei inclusive a pedir para que os cadidatos resolvessem problemas bem simples de programação como um caça-palavras ou um problema simples de criptografia. O objetivo é entender como o candidato organiza seu código, ver se ele escreve testes, saber se ele faz BDUF sem necessidade, se usa design patterns quando faz sentido e por aí vai. Quando o candidato passa por toda essa parte “remota” do processo de seleção, discutimos o código presencialmente e adicionamos algumas novas funcionalidades juntos para ver como ele funciona programando em par/time.

Muitos candidatos acabam desistindo de participar quando vêem que precisam mostrar código. Outros candidatos mandam código mas acabam não indo bem na entrevista presencial porque ficam nervosos de programar “em público”. Infelizmente nesse tipo de abordagem provavelmente teremos falsos negativos, por outro lado dificilmente teremos falsos positivos.

Analise sob vários pontos de vista

Já faz algum tempo que percebi que é muito útil fazer com que os candidatos sejam entrevistados por vários desenvolvedores do time. Nesses últimos três anos, poucas foram as vezes em que os cadidatos não foram entrevistados por pelo menos duas ou três pessoas. É muito útil poder discutir com outras pessoas do seu time sobre as entrevistas. Às vezes você achou o candidato bom, porém outras pessoas perceberam problemas que você não percebeu (e vice e versa). Ou então você ia esquecer de perguntar alguma coisa importante, mas o time que sempre participa junto das entrevistas acaba lembrando de perguntar. A melhor parte disso tudo é que é muito mais fácil errar tomando uma decisão desse tipo sozinho, então quando você está entrevistando em grupo e o time inteiro sai satisfeito de uma entrevista, a sensação de que você está tomando uma decisão certa sobre contratar alguém é muito maior.

Além disso é interessante que o candidato converse com pessoas de diferentes especialidades. Nesse último ano vários dos nossos candidatos conversaram não apenas com desenvolvedores mas também com pessoas de produto, especialistas de processo e por aí vai. Como são pessoas de especialidades bem diferentes, as perguntas que eles fazem são bem diferentes, o que te ajuda a analisar o candidato por vários ângulos.

Vasculhe seu candidato na Internet

Olhar o Github do candidato, Bitbucket e afins é o mínimo que você deve fazer. Eu pessoalmente gosto de olhar o LinkedIn, Facebook e Twitter também, para ter uma idéia do que a pessoa gosta, quem ela segue, o que ela fala e como se comporta. Por exemplo, há não muito tempo um candidato que me mandou currículo tinha escrito no Twitter uma frase bem chata reclamando do seu chefe, do tipo “meu chefe é um idiota”. O que eu espero de um profissional sério é que ele vá conversar com o seu chefe e resolva seus problemas. E se ele não conseguir e o chefe for realmente um idiota, peça demissão e trabalhe em outro lugar. É bem melhor do que ter uma atitude idiota em um lugar público onde todo mundo pode ver – incluindo o seu (ex) futuro chefe.

E por falar em atitudes idiotas…

“No asshole rule”

Existe até um livro sobre isso. Se você quer ser feliz, evite ao extremo contratar “assholes”. Comportamentos do tipo “eu sou mais inteligente que todo mundo e não preciso de ninguém para fazer meu trabalho além de mim mesmo, porque eu sou um rockstar e ninguém tem nada a me acrescentar” podem levar seu time para o buraco (o quase-trocadilho com “asshole” não foi intencional).

Sabe aquele tipo de ambiente onde a fofoca rola solta, com conversinhas venenosas de corredor, onde todo mundo tenta queimar todo mundo? Ou aqueles times onde, se você der sua opinião, alguém vai contrariar só por contrariar para tentar aparecer? Ou então aquelas pessoas que arrumam confusão gratuitamente? Se você não quer ter esse tipo de problema na sua empresa (e eu acho que ninguém quer), o primeiro e melhor passo que você pode dar é tentar ao máximo possível não contratar “assholes”. Mesmo que o cara seja muito bom tecnicamente, na minha experiência é melhor ter um cara “menos bom” mas que trabalhe em equipe, seja construtivo, empolgado e confiável.

Se não for o candidato certo, não contrate

Se o candidato não é a pessoa 100% certa para o seu time, então não contrate. Em alguns casos você vai encontrar candidatos que são quase ideais e pode ser difícil resistir à tentação – porque em muitos casos são problemas que você acha que pode consertar. O problema é que às vezes (como já aconteceu comigo) as pessoas não estão dispostas a mudar e sua vida pode se tornar bem difícil. Hoje em dia prefiro entrevistar mais uma dezena de pessoas e demorar mais um mês para contratar (ou até não contratar) do que correr o risco de errar.

Uma pergunta interessante que você pode se fazer é: Se você estivesse contratando alguém para a SUA startup, você contrataria essa pessoa? Aliás, recomendo a leitura desse artigo do Steve Yegge na íntegra.

E você, o que aprendeu nos seus processos seletivos?

Sobre Entrevistas (parte 2)

O Phillip Calçado blogou há alguns meses sobre entrevistas e eu resolví agora fazer uma espécie de continuação. Depois daquele post já aconteceram dois processos seletivos aqui na equipe e tenho algumas coisas a acrescentar.

Com o passar do tempo e das entrevistas, acabamos aprendendo algumas coisas e já tínhamos algumas idéias para serem aplicadas, como o Phillip bem disse. Tiramos algumas idéias interessantes do Joel Spolsky, mas ainda não era o suficiente. Ainda estava faltando um formato definido para as entrevistas, um roteiro. É claro que as entrevistas têm que ser flexibilizadas de acordo com o seu andamento ou o candidato, mas eu particularmente ainda sentia falta de não termos um planejamento definido para as conversas. Muitas vezes o candidato ia embora e eu sentia que eu tinha ido muito mal na entrevista, o que era péssimo.

Depois de misturar algumas idéias de Scrum com coisas que eu lí no Peopleware e mais todas as experiências anteriores, fiz um roteiro para o nosso último processo seletivo que acabou funcionando bem melhor do que eu imaginava.

Vou tentar explicar um pouco melhor como funciona:

Etapa 1: Captando currículos.

Para captar currículos legais, tentamos escrever uma mensagem o mais clara possível do que estávamos procurando e com a cara da nossa equipe. O Phillip escreveu a primeira versão dessa mensagem e depois ao longo do tempo ela foi sendo ajustada. No final ficou mais ou menos assim.

É um pouco diferente do que se vê por aí mas explica com bastante detalhes o dia a dia do trabalho e mostra nosso clima descontraído e irreverente. Acho que o fato de passarmos emoções na mensagem faz com que algumas pessoas se identifiquem com a oportunidade mais facilmente (ou que a descartem logo de cara). O principal objetivo da mensagem era passar a seguinte idéia: venha trabalhar aqui porque é muito legal!

Etapa 2: Selecionando os currículos.

Fazer uma seleção curricular cuidadosa foi importante para conseguir selecionar os candidatos mais adequados e não perder muito tempo entrevistando pessoas que não se encaixavam no perfil requerido para a vaga.

Alguns currículos foram muito fáceis de descartar, porque os candidatos simplesmente não conseguiram atender a um único e simples pedido: não enviaram a relação dos 3 últimos livros que leram. Das duas uma: ou o candidato não leu nada (e nós não queremos gente que não lê), ou não leu a mensagem até o final (e pode ser um daqueles que envia currículo para todas as oportunidades do planeta, que nós também não queremos).

A lista dos 3 últimos livros lidos é muito interessante porque diz muito sobre os interesses e o nível técnico da pessoa. É tiro certo: os candidatos que leram os livros mais interessantes geralmente têm os currículos mais interessantes.

Etapa 3: Entrevista pessoal.

Na entrevista pessoal a estratégia era falar a menor quantidade de tempo possível. A justificativa é simples: você tem apenas alguns minutos para descobrir o máximo possível sobre a pessoa. Fazendo uma matemática simples, podemos concluir que quanto menos se fala mais o candidato tem oportunidade para falar.

Quando a entrevista já estava mais para a última metade eu começava com as perguntas mais técnicas e difíceis. Na medida do possível tentei perguntar detalhadamente sobre a maioria das coisas que foram colocadas no currículo, especialmente quando o currículo era recheado de siglas. Fiz questão de me assegurar de que aquilo não estava ali só para fazer volume. Acabei descobrindo que muita gente não sabe para que servem os Design Patterns que estão em seus currículos, que não sabem resolver problemas simples de arquitetura ou que não conhecem o básico sobre concorrência, sistemas operacionais, redes, protocolos, algorítmos, etc.

Nos minutos finais eu explicava detalhadamente como funciona a empresa, com o que a empresa trabalha e com que tipo de coisas o candidato iria se deparar. Uma vez tentei fazer isso no começo da entrevista mas percebí que isso fazia com que o candidato ficasse o tempo todo tentando falar coisas que ele achava que eu queria ouvir, então achei melhor continuar fazendo no final mesmo.

Etapa 4: Entrevista com a equipe.

Quem passou na entrevista pessoal chegou na etapa mais interessante do processo: a entrevista com a equipe de desenvolvimento. Por isso é tão importante fazer um bom filtro na fase anterior, porque a equipe tem mais o que fazer e eles não podem perder muito tempo. Todas as pessoas que foram para essa fase tinham plenas condições de trabalhar aqui, só precisavamos escolher as melhores. Basicamente a idéia dessa fase é que não há ninguém melhor do que as pessoas que fazem o trabalho para avaliar se alguém também está apto para fazê-lo.

Nesta etapa estabeleciamos um timebox (de 30 a 40 minutos) para que aqueles candidatos que gostam de falar demais saibam que eles tem tempo curto e que devem ser breves e objetivos. As perguntas não eram planejadas e a equipe perguntava sobre o que vinha na cabeça.

Nos primeiros 15 minutos fazíamos perguntas mais abstratas como “o que você sabe sobre x” ou “conte sobre sua experiência com y” e por aí vai. A partir daí a equipe ia pegando “ganchos” no que o candidato ia falando e as perguntas iam fluindo. Como tinham muitas pessoas na sala e todos queriam perguntar, tivemos que usar uma bola para organizar quem ia falar. Quem estava com a bola estava no comando e quem não estava ficava calado e escutava.

Nos últimos 15 minutos fazíamos as perguntas cascudas. Normalmente pegávamos situações do nosso dia a dia e criávamos problemas para as pessoas resolverem. Perguntamos sobre problemas de concorrência, arquitetura da JVM, arquitetura de sistemas de cache, algorítmos e por aí vai. As perguntas eram bem pesadas e o clima geralmente ficava bem tenso, mas o intuito era esse mesmo. Muitas pessoas que tinham ido muito bem na etapa individual travaram completamente quando ficaram sob pressão.

No final, para descontrair, falávamos várias bobagens e fazíamos perguntas sociais: tipos de música preferidos, hobbies, time que torce, se é casado, tem filhos, piadas nerds diversas e coisas do tipo.

Etapa 5: Escolhendo o candidato.

Depois da equipe entrevistar todos os candidatos fizemos um debate para escolher quem seria selecionado. Todas as pessoas opinaram e escolhemos juntos quem entrou. Essa idéia veio do Scrum, onde o time toma as decisões em conjunto de tudo que é feito. Isso é bom por dois motivos. O primeiro é que várias cabeças pensam melhor que uma. Se todas as pessoas gostam de alguém e só eu que não gosto, o problema possivelmente está comigo. No fim das contas eu acabo me previnindo de fazer alguma besteira e escolher a pessoa errada. O segundo motivo é que como todos concordaram em escolher um determimnado candidato, ninguém pode ser culpado posteriormente por ter feito a escolha errada. Se errarmos, erramos todos juntos (o que é bem mais difícil de acontecer).

Esses debates foram muito engraçados porque o pessoal acabava comprando a briga de um ou outro candidato e virava um mega flame war. Nos casos em que todo mundo concordava, era maravilhoso, porque era a certeza absoluta que o candidato era o certo. Em compensação, quando ninguém entrava em acordo, era 458 mil vezes mais difícil de resolver. Quando isso acontecia, todo mundo dava sua opinião (eu inclusive) e tentávamos fazer com que alguém mudasse de idéia. Por sorte temos um número ímpar de pessoas na equipe e dava pra desempatar. Quando ninguém entrava em acordo e ficávamos empatados e totalmente travados, eu acabava dando o voto de desempate.

Etapa 6: Entrevista final com o gerente.

Depois dos candidatos serem escolhidos pelo “comitê” eles foram para uma última entrevista comigo e o gerente da área. Essa etapa foi a mais tranquila de todas porque as pessoas que chegaram até ela já tinham recebido a certificação de capacidade técnica pela equipe, então as perguntas foram muito mais sobre questões sociais, objetivos de vida, profissionais e por aí vai. Basicamente é a entrevista para o candidato ser abençoado e o martelo ser batido.

Não sou nenhum especialista em recursos humanos e nem em recrutamento, mas esse processo me parece que funciona bem. Estou satisfeito com as pessoas que contratamos e contente por termos achado uma forma mais divertida e eficaz de selecionar pessoas.