Como identificar bons programadores
Autor: Dirlei Dionisio | Publicado: 2011-04-30T02:29:00-03:00











Gerente de circo: Você faz malabarismo há quanto tempo?

Candidato: Humm, há cerca de seis anos.

Gerente de circo: Você faz malabarismo com três, quatro e cinco bolas?

Candidato: Sim, sim e sim.

Gerente de circo: Sabe lidar com objetos chamejantes?

Candidato: Claro.

Gerente de circo: ...facas, machados, caixas de charuto abertas e chapéus?

Candidato: Faço malabarismo com qualquer coisa.

Gerente de circo: Você faz o público rir durante o malabarismo?

Candidato: Sim, sou hilário.

Gerente de circo: Gostei de você. Está contratado!

Candidato: Mas... você não quer me ver fazendo malabarismo?

Gerente de circo: Caramba, nunca pensei nisso.

(Peopleware. “Hiring a Juggler”)




Qualquer um consideraria insano contratar um malabarista sem antes vê-lo demonstrando suas habilidades. É uma questão de bom senso. Mas é impressionante como esse bom senso é simplesmente ignorado por muitas empresas ao contratar programadores. Elas se limitam a ler currículos e fazer entrevistas que talvez avaliem um monte de coisas, menos se os candidatos têm talento pra fazer software.

Se você quer contratar bons programadores, precisa saber como identificá-los. Não tenho um passo-a-passo para lhe oferecer, mas algumas lições que aprendi durante alguns anos de observação e execução dessa tarefa podem lhe ser de ajuda.



Quem pode identificá-los?

Identificar um bom programador é similar a identificar um bom malabarista: é preciso vê-lo demonstrar suas habilidades. Mas há uma diferença sutil: alguém que nunca fez malabarismo, pode identificar um bom malabarista; mas alguém que nunca fez software, dificilmente poderá identificar um bom desenvolvedor de software. Existe um abismo que separa software de bom software e só quem compreende a profundidade desse abismo pode identificar aqueles capazes de criar bom software.

Portanto, se você não sabe programar, encare a realidade: sozinho, você não pode recrutar programadores. É claro que pessoas não técnicas podem (e devem) contribuir para o processo seletivo. Psicólogos, por exemplo, tem muito mais chances de identificar um candidato insubordinado, com dificuldades de relacionamento ou até um psicopata do que nós, técnicos. Minha intenção não é desmerecer o trabalho de ninguém, mas deixar claro o que cabe a cada um. E identificar bons programadores, do ponto de vista técnico, cabe a bons programadores.

Qual o contexto?

Se alguém me disser: “Preciso de um bom programador, você tem alguém pra indicar?”. Minha resposta será: “Depende, o que ele fará?”. O fato de alguém ser um bom programador não quer dizer que ele é adequado para todos os tipos de trabalho que envolvem criação de software. Num extremo há os trabalhos que exigem um perfil mais generalista, no outro os que exigem um perfil altamente especialista. No meio está a maioria, onde se exige um misto desses dois perfis. Essa e outras peculiaridades do trabalho formam o que chamo de contexto.

Se você já programou por algum tempo e conheceu vários outros programadores, sabe que não se pode dizer que fulano é melhor que beltrano e ponto final. Lembre-se: programadores são pessoas, não mercadorias. As habilidades de duas pessoas não podem ser comparadas como se mede altura delas (ambos têm a mesma altura ou um é maior e outro menor).  A comparação deve ser feita mais ou menos como se comparam dois gráficos de barras. Em algumas barras (habilidades), um candidato pode parecer melhor que outro, em outras, equivalente ou pior. O contexto ajuda o recrutador a descobrir que “barras” do gráfico são mais relevantes para o processo seletivo em questão. 

As ferramentas

A seguir, algumas das ferramentas que já utilizei para identificar bons programadores.



O bom e velho currículo

O currículo ainda faz parte da primeira etapa de avaliação de candidatos na maioria das empresas.  Não tenho nada contra eles, desde que não sejam supervalorizados. Eles são ótimos para demonstrar habilidades de redação e marketing, mas ineficientes para demonstrar se alguém tem talento para fazer software. Seja como for, há algumas informações pelas quais tenho interesse especial ao ler currículos:



Primeiras experiências: Se as primeiras experiências do candidato aconteceram quando ele ainda era bem jovem, possivelmente se trata de alguém autodidata. Pontos adicionais são somados se essas experiências estiverem relacionadas a trabalhos autônomos, feitos para si mesmo ou para outros.

Raridade de conhecimento: Apesar de o conhecimento diretamente ligado ao trabalho que será executado ter sua importância, gosto de ver que o candidato tem conhecimentos técnicos não muito solicitados pelo mercado. Não tanto pela utilidade direta desse conhecimento, mas pelo que ele representa. Investir tempo em aprender algo que não trará um retorno imediato geralmente revela um candidato apaixonado pelo que faz, além de interessado em se aperfeiçoar e não apenas em ter um bom emprego. Ademais, certos conhecimentos abrem a mente para novas formas de resolver problemas.

Trabalhos notáveis: A realização de trabalhos com grau de dificuldade elevado, não convencionais, inovadores ou de grande responsabilidade são algumas das coisas que tornam a experiência de um candidato algo notável. Programadores talentosos, muitas vezes atraem para si esse tipo de trabalho.



Apesar de muitas vezes ficar bem impressionado e curioso para conhecer alguns candidatos por causa dos seus currículos, é preciso reconhecer que com uma leitura de currículo, podemos apenas descobrir que um candidato não serve para a vaga. Será preciso muito mais que isso para descobrir se ele serve.

Mapeamento de conhecimento

Essa é uma ferramenta que utilizo após avaliar um currículo favoravelmente. Se trata de um formulário onde o candidato autoavalia e comenta seus conhecimentos e/ou experiência em uma série de itens relacionados ao desenvolvimento de software, mas não exclusivamente nos quesitos mais relevantes para a vaga em questão.

Um exemplo que criei apenas para usar neste artigo pode ser visto aqui.

O resultado desse formulário é, geralmente, muito mais revelador que o currículo.  Por ser menos formal e ao mesmo tempo mais técnico, os bons candidatos tentem a se sentir mais à vontade para escrever sobre suas habilidades.  Ao mesmo tempo, candidatos que “enrolaram” no currículo vão se “enrolar” na hora de dar detalhes sobre seus conhecimentos.

De posse do currículo e do mapeamento de conhecimento preenchido, tenho uma impressão melhor do perfil do candidato.  Mentalmente, é como se eu formasse um gráfico com os pontos fortes e fracos do candidato.  Se o gráfico parecer adequado ao contexto, levo o candidato para a próxima etapa: a entrevista por telefone.

Entrevista por telefone

A entrevista por telefone não substitui a entrevista presencial, apenas provê um meio mais rápido de conhecer e avaliar os candidatos. Joel Spolsky cita uma das vantagens da entrevista por telefone ao dizer:

"Visto que na entrevista por telefone você não vê o candidato, é fácil se concentrar na qualidade do que ele diz ao invés de em fatores externos e irrelevantes para o trabalho." <span id="cit_ref-1" style="font-size:
70%">[1]

Após uma curta introdução onde faço breves e sinceros elogios com base no que li no currículo e no mapeamento de conhecimento, procuro conhecer melhor o candidato a partir de três pontos principais:



Como ele começou a programar: Peço que o candidato me conte um pouco sobre como se interessou pelo desenvolvimento de software e quais foram as suas primeiras experiências com programação. A resposta de um candidato apaixonado normalmente é carregada de entusiasmo. Eles têm orgulho de falar das suas “façanhas” como aspirantes programadores. Ao mesmo tempo que a resposta do candidato alivia a sua tensão inicial, características importantes como paixão e autodidatismo ficam mais evidentes pelo que ele diz.

Trabalhos que mais gostou: Uma pergunta chave que faço é: de todos os projetos em que você esteve envolvido, em quais mais gostou de trabalhar?  Um candidato apaixonado, citará sem muita demora os projetos mais desafiadores. Peço detalhes sobre cada um desses os projetos.  Quero saber quais foram as responsabilidades dele, que desafios enfrentou, como os resolveu, por que resolveu daquela maneira, se propôs mudanças, se enfrentou resistência e que tecnologias estavam envolvidas.  Vou fundo nessas questões para descobrir se ele realmente sabe do que está falando.

Como ele resolve problemas que nunca viu antes: Se você precisa selecionar programadores que não resolverão sempre os mesmos problemas, é bom avaliar a capacidade de lidarem com problemas nunca antes vistos. Para isso, descrevo brevemente alguns problemas e peço que o candidato me diga como os resolveria.  Propositalmente não forneço muitas informações para descobrir se o candidato sabe fazer as perguntas certas para obter mais informações. A solução para esses problemas deve revelar conhecimentos que vão além de escrever código.  O nível de dificuldade dos problemas e o que será considerado como uma solução viável varia de acordo com o nível do programador que se deseja contratar. A seguir, alguns exemplos que já usei:



Como você implementaria um programa para ordenar um arquivo texto de 10GB?

Como você implementaria um programa para controlar os elevadores de um prédio?

Como você implementaria uma engine de renderização para um browser?

Como você implementaria uma timeline como a do Twitter?



Se o candidato não consegue nem mesmo formular perguntas para entender melhor o problema ou diz que não faz ideia de como resolvê-lo, muito provavelmente ele terá dificuldade para resolver problemas diferentes dos que está acostumado a resolver.



Nesse ponto, já tenho dados suficientes para decidir se gostaria ou não de conversar pessoalmente com o candidato.

O que a internet diz sobre ele?

Se o candidato tem um blog sobre algum assunto ligado ao desenvolvimento de software, leia o que ele escreve e descubra suas opiniões. Se ele participa de grupos de discussão ou comenta em blogs, veja como ele interage com outros. Ele é ferrenho defensor de uma tecnologia específica? Mal sinal. Ele tem uma postura agnóstica sobre tecnologias? Ótimo, isso revela maturidade técnica. Nenhum programador é obrigado a ter uma conta no Twitter, mas se ele tem uma e a utiliza para compartilhar links interessantes, isso é uma boa forma de descobrir o que ele lê. Se o candidato compartilha projetos no Github, ótimo. É uma forma de avaliar a qualidade do seu código. Se ele possui forks de outros projetos, isso mostra que projetos o interessam.

Miniprojeto

Ao avaliar novatos em programação, gosto de pedir que executem em casa miniprojetos de software. Algo que dê pra fazer em um fim de semana. Não devem ser projetos muito simples e nem excessivamente complexos. O objetivo final deve ser claro, mas a forma como ele será atingido deve ficar em aberto. Eventuais dúvidas devem poder ser esclarecidas por e-mail ou telefone.  Quando o candidato considerar a solução terminada, deve enviá-la por e-mail. Isso dá ao avaliador a oportunidade de verificar a qualidade do código do candidato. A forma como o problema foi resolvido deve ser discutida e eventuais ajustes podem ser solicitados. O objetivo não deve ser que o candidato entregue uma solução perfeita, mas uma que funcione bem ao fim de algumas iterações. Os resultados que tive com esse tipo de ferramenta ao avaliar candidatos a estágio ou profissionais juniores foram excelentes.

Entrevista presencial

Essa é a etapa que considero mais importante no processo seletivo. Os que chegam até ela, até certo ponto, já conquistaram minha admiração e normalmente estou ansioso para conhecê-los.

Uma boa entrevista deve se parecer com uma conversa. A meta do entrevistador deve ser criar situações onde o candidato possa mostrar o seu potencial. Procuro fazer isso de duas maneiras.



Detalhes sobre projetos realizados: Solicito mais detalhes sobre projetos citados na entrevista por telefone. Algo como: estive pensando naquele projeto que você executou na empresa X. Como funcionava a parte de...? Ou, por que você implementou usando...? Você teve problemas com...? Que achou de usar...? Preferia ter usado outra linguagem/tecnologia? Chegou a sugerir isso? Deixe-o à vontade para responder observe se ele demonstra que tinha genuíno interesse pelo que estava fazendo. Programadores apaixonados não fazem um bom trabalho porque são pagos para isso, o fazem porque têm prazer nisso. São essas pessoas que você deve procurar. Procure pelo brilho nos seus olhos.

Ao mesmo tempo, essa conversa mais detalhada permitirá que ele demonstre a variedade e nível do seu conhecimento técnico, que deverá estar alinhado com o que foi informado no mapeamento de conhecimento.

Me mostre o código: Como diria Linus Torvalds: “Show me the code”<span id="cit_ref-2" style="font-size:
70%">[2]. Nessa parte final, me certifico de que o candidato sabe não apenas falar sobre programação, mas também sabe praticá-la. Para isso, solicito que ele resolva alguns problemas simples de programação na sua linguagem predileta, usando um computador com um editor de textos simples (não será preciso compilar o código).  Os problemas podem ser algo como:


Crie uma função que receba uma string e retorne uma cópia dela com o primeiro caracter em maiúsculo;
Crie uma função que receba um array e inverta a ordem dos seus elementos;
Crie uma função que retorne a quantidade de arquivos existentes num diretório (incluindo seus subdiretórios).


O primeiro problema é realmente muito fácil e espera-se que todos sejam capazes de resolvê-lo em poucos segundos. O segundo, dependendo da linguagem, envolve algum conhecimento sobre ponteiros e o terceiro sobre recursão. O código de cada solução dará margem para alguma pergunta ou sugestão e isso deve ser explorado pelo avaliador para que o candidato se mostre capaz de explicar o que fez. Considerações de performance e consumo de memória podem ser levantadas. O candidato deve ter a chance de melhorar seu algoritmo, se assim desejar. Essa troca de ideias ajuda o avaliador e perceber como o candidato raciocina e como reage ao receber uma crítica construtiva sobre seu código. Apenas lembre de esperar até que o candidato diga que terminou uma solução, antes de falar qualquer coisa. O tempo que ele levar para resolver cada problema e a quantidade (ou ausência) de bugs também são fatores de avaliação.





Considerações finais

Se você está em busca de bons profissionais, lembre-se de duas coisas: (1) eles são a exceção e (2) sua empresa não é a única opção deles. Lembrar disso o ajudará a tratar seus candidatos com respeito, desde o primeiro contato. Isso vai desde a forma como você responde aos e-mails, passando pela flexibilidade de horários das entrevistas e indo até a sua pontualidade ao recebê-lo para uma entrevista presencial. Trate os candidatos como você gostaria de ser tratado, sempre.

O que você acha da forma como as empresas tentam identificar bons programadores? Tem alguma experiência para contar? Algo a dizer sobre esse artigo? Deixe seu comentário!

&#8212;



Foto: Vladik Myagkostupov no show 'Dralion' do Cirque Du Soleil. Créditos a Sandra Mu/Getty Images AsiaPac.

  Referências:

  

    [1] ^ Joel Spolsky. "Smart and Get Things Done"

    [2] ^ Linus Torvalds. "Talk is cheap. Show me the code"