Fragmental

Há mais de dois anos que entrevistar candidatos faz parte do meu dia-a-dia. Neste período eu aprendi bastante sobre como entrevistar e ser entrevistado, acho que é um bom momento para compartilhar… não estou dizendo que o texto abaixo é ótimo, é aplicável ao seu caso, ou sequer que você deva usar. É apenas uma descrição sobre o que eu tenho de experiência nesta área.

Lição 1: Seja Claro no que Procura

Não são só arquiteturas que sofrem com padronização desnecessária, entrevistas também devem ser desenhadas de acordo a situação, especialmente com o que se espera encontrar.

É preciso saber o que se procura. Geralmente alguém decide que a equipe precisa de mais um ou mais membros para ter melhor performance mas a primeira coisa a fazer -como sempre- é fugir do senso comum e se perguntar: é isso mesmo? Será que estamos fazendo as coisas certas? Será que não podemos melhorar nosso desempenho simplesmente mudando a forma de trabalho? Empresas de três letras ensinaram ao mercado que quando um projeto vai mal devemos enfiar pessoas nele (e cobrar por homem/hora, não se esqueça) mas isso é simplesmente contra tudo que sabemos sobre projetos de software. Enfiar mais pessoas em um projeto só o faz atrasar mais (leia Fred Brooks).

Se a resposta for realmente mais pessoas, então que tipo de profissional precisamos contratar? Seja lá o que for deixe bem claro no anúncio, você não vai evitar que panfletadores de curriculum encham sua caixa de email (aliás, crie uma caixa só para isso e desative-a quando não existirem mais vagas) mas vai melhorar as chances que alguém realmente interessante e interessado responda. Também não coloque em qualquer lugar seu anúncio, divulgue em listas especializadas e em grupos de pessoas que confie. Aliás, grupos de pessoas são ótimos porque você pode verificar o histórico da pessoa que enviar o curriculum.

Lição 2: Capriche na Triagem

Se você for bem específico como sugeri na lição acima dificilmente vai ter uma chuva de curriculums, mas caso tenha uma técnica de triagem se faz necessária. Se você tem tempo faça a primeira entrevista por telefone. Se você não tem muito tempo sequer para entrevistas presenciais faça o seguinte: crie uma lista com alguns problemas e peça para o cara resolver e te mandar a resposta.

Os problemas precisam ser diferentes, crie um problema sobre concorrência, um sobre otimização, um sobre modelagem, eles precisam ter o mesmo nível de dificuldade também. O problema que a pessoa escolher (só deve escolher um) te diz sobre o perfil dela. Depois faça uma revisão via telefone do código com a pessoa, é mais para evitar fraude mas ainda assim é uma ótima oportunidade para perguntar alguns aspectos técnicos, porque tomou a decisão X e não fez Y, como refatorar a solução para que fique mais XYZ, etc.

Lição 3: Nada de Perguntas McDonald’s

Para entrar numa grande empresa fui entrevistado pelo meu futuro gerente. Ele tinha na mão uma lista com umas 10 páginas de perguntas variadas sobre Java e SQL, basicamente. Após a segunda página nós já havíamos abolido a folha e partido para um fluxo mais aberto de conhecimento mútuo. Dessa experiência eu tirei um fluxo de entrevista um pouco diferente do que costumo ver.

Quando seleciono um curriculum eu geralmente monto um estereótipo para aquela pessoa: “Arquiteto”, “junior”, “pleno”, “especialista em XXX”, “enrolão”, etc. Deste estereótipo eu penso em algumas primeiras perguntas.

Quando a pessoa chega eu geralmente peço a ela que se apresente, conte um pouco da sua história. Desta o estereótipo inicial pode ser alterado ou não, geralmente após isso eu já tenho uma boa noção do perfil profissional da pessoa. Aí começam as perguntas reais.

Se eu penso que o cara é junior eu começo com algumas perguntas pedindo para ele descrever conceitos. Eu dificilmente pergunto pelo conceito diretamente mas sim algo que indiretamente vai requisitar dele que o faça, como comparações. Continuando com conceitos eu vejo se possui boas bases ou é apenas apertador de parafusos. Eu continuo perguntando, seguindo os perfis de pleno, arquiteto e especialista até ver que o cara não sabe mais. Muitas vezes encontrei juniores que sabiam mais que arquitetos.

Para “desenvolvedor pleno” a coisa começa relativamente ao contrário. Eu peço para ele descrever alguma coisa em que tenha trabalhado e depois para ele dissecar a arquitetura. No meio do caminho surgem diversos pontos interessantes para explorar como Domain Models, BO/VO, programação concorrente, técnicas de performance, etc. Sempre que possível eu faço perguntas baseadas em um cenário real que eu já tenha vivido, até para a pessoa sentir o tamanho do desafio (é difícil fazer alguns entenderem o tamanho da encrenca). Muita gente morre aqui simplesmente porque não entende nada do que trabalha. O cara está há anos desenvolvendo aplicações e não tem idéia do porque usa um padrão ou outro. Todo mundo sabe responder “um design pattern é uma solução para um problema comum blablabla” mas ninguém sabe dizer que problema o tal do BO/VO soluciona.

Tenho que admitir que para arquitetos o buraco é way over mais embaixo. A coisa começa com descrições sobre arquiteturas que ele já tenha trabalhado e, principalmente, desenhado. Geralmente nestas descrições vai haver uma menção um pouco mais interessante que o usual, como conectores JCA, filas, caches ou clusters. Aí é que está o pulo do gato: um arquiteto tem que saber como isso funciona num projeto. Não importa se na época ele não se entitulava arquiteto, não é admissível alguém que nunca parou para saber como aquilo funcionava! Algumas perguntas sobre arquitetura da JVM são sempre boas também. Você consegue descrever como o Garbage Collector funciona com muita e com pouca memória disponível? Identificar erros mais simples de parametrização da JVM?

Interessante notar que não é preciso responder certo as perguntas. Aliás, eu nem espero que sejam respondidas. As respostas ideais, da melhor para a pior:

1. Resposta certa
2. Caminho certo (não chegou na resposta mas elaborou bem)
3. Resposta errada por uma bobeira qualquer
4. Dizer que não sabe

Nessa lista não está a resposta errada. Se um candidato não assume que não conhece a resposta (e algumas perguntas não supõem que você conheça a resposta!) e chuta ele perde muitos pontos numa entrevista dessa. Mentir sobre projetos e empresas é sempre engraçado, no Rio de Janeiro eu conheço muita gente em muitas empresas e sempre consigo lembrar de alguém que teoricamente teria trabalhado com o candidato no tal projeto.

Eu sempre insisto para a pessoa tentar chegar na resposta ao menos. Na sala sempre vai haver papel e caneta ou um quadro-branco, o ato de seguir por um caminho lógico para tentar chegar à resposta é muito importante. Uma das coisas que consigo verificar assim é escalabilidade, dificilmente aparece alguém que sabe como criar um site que suporte um fluxo muito grande de acessos mas geralmente as pessoas têm pelo menos uma idéia sobre conceitos que podem usar enste caso.

Tem gente que fica muito nervosa neste ponto então é melhor criar o ambiente mais descontraído possível. Aqui isso não é problema, geralmente eu converso com a pessoa com meu jeans e camiseta usual, muitas vezes com o pé na cadeira. Não é para impressionar, é assim que as coisas são e é bom a pessoa saber disso. Eu não quero saber se a pessoa é boa ou ruim, quero apenas saber se ela é quem eu estou procurando neste momento ou não.

Lição 4: Explique o Cenário

Após a entrevista em si eu explico o cenário. Descrevo como as coisas funcionam na equipe, a hierarquia, os tipos de projeto, tecnologias e o que espero da vaga. No final respondo dúvidas.

Por que não antes? Porque pode influenciar a pessoa. Ao ouvir que nós plantamos bananas ele vai se vender como o melhor bananeiro desde Jorge Ben Jor.

Lição 5: Racionalize o Candidato

As vezes você procura um semi-deus e aparecem apenas juniores, as vezes você procura juniores e o próprio Zahl aparece. Hoje em dia um gestor tem que saber flexibilizar seu quadro de pessoal.

Se você tem vaga de senior e arrumou um junior muito interessante que tal dividir a grana do senior em dois? Ou que tal pagar o salário do junior e com o resto do orçamento investir na equipe para que todo mundo suba de nível técnico?

O tipo de entrevista acima não dispensa ninguém. Se na segunda pergunta você já viu que o cara não serve para a vaga continue, descubra quem o cara é. Num mercado como esse no mínimo você pode indicá-lo a outro gestor precisando de pessoas ou guardar na manga para outra oportunidade. Claro que se o cara for ruim ele é ruim e pronto.

Eu sei bem que não é o ideal, mas este modelo de entrevista já me fez boas contratações e, sinceramente, nenhuma ruim. Um dos efeitos ruins é que as vagas demoram bons meses para serem preenchidas mas atualmente isso é “menos pior” do que ficar meses com um desenvolvedor não-qualificado.

This entry was posted on Monday, October 22nd, 2007 at 3:02 pm and is filed under gerencia, metodologias, você.pergunta. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.