Categories
Gerenciamento

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?

Categories
Etc.

Que ferramentas você vai usar na hora de programar?

Há uns dois meses estava eu numa madrugada típica brincado de escrever códigos aleatórios, dessa vez usando o Google App Engine. Num determinado momento (acho que eu estava testando o versionamento de deploys – que é lindo demais) fiquei tão empolgado que soltei um daqueles posts meio aleatórios no Twitter dizendo: Google App Engine kicks serious ass!. Muita gente estranhou, incluindo o meu amigo Rodrigo Kumpera que prontamente respondeu: @gchapiewski I thought you used to work for yahoo!.

O mesmo “fenômeno” aconteceu no Yahoo! Open Hack Day que fizemos em São Paulo em março. Muitas pessoas acharam estranho e ficaram abismadas pelo fato do Yahoo! e seus funcionários mostrarem hacks que faziam uso de Google Maps, Twitter, Facebook e outros produtos que não são do Yahoo!.

Vamos lá, qual o problema? Sério mesmo, qual o problema? 🙂 Agora que eu trabalho no Yahoo! tenho que usar Y! Mail ao invés de Gmail? Ou então tenho que programar usando apenas YUI ao invés de jQuery? A política do Yahoo! é muito simples e na minha opinião bem coerente: a Internet está cheia de serviços excelentes e nós também temos alguns ótimos serviços. Porque não combinar o que há de melhor e fazer uma coisa melhor ainda?

Sempre falo isso e já até me falaram que parece meio “piegas”, mas é a pura verdade (e nunca é demais repetir): use a melhor ferramenta para resolver cada problema!

Esse modo de pensar é bem difícil nesse mercado. Muita gente acha que linguagens e tecnologias são como religiões, mas não é o que eu acredito. Não me importo de usar Java se for a melhor opção para resolver meus problemas – apesar de adorar programar em Ruby. Ou de aprender uma nova linguagem/ferramenta se ela se mostrar melhor para resolver alguma coisa (como quando eu precisei aprender ActionScript para fazer coisas legais para o Globo Vídeos – apesar de eu nunca ter tido simpatia por Flash).

Para pessoas da nossa área, acredito em um posicionamento profissional baseado em fatos e dados, não em preferências, traumas ou qualquer outro argumento sem lógica. No caso que comecei a contar no início desse post, eu estava programando um webservice REST em Python e o Google App Engine é o melhor lugar para ele estar hospedado. Aliás, eu usei Python já pensando em fazer o deploy lá, porque é super simples de usar, funciona muito bem e vai me liberar mais rápido para fazer outras coisas interessantes. É óbvio que todos temos nossas preferências de linguagens e tecnologias, mas o papel de um profissional é ser pragmático é fazer o que for mais adequado para cada situação.

Sempre que você está programando você precisa atingir um objetivo. Como eu ouvi falar esses dias, você “não senta e começa a programar igual a um cavalo”, você está desenvolvendo um produto ou alguma coisa maior e precisa ter isso em mente o tempo inteiro. Seu objetivo é entregar um software de qualidade, performático, bem testado, manutenível e que atenda ao seu cliente/objetivo. O seu objetivo não é usar as ferramentas da sua empresa ou as tecnologias que você gosta. Pense nisso.