30 de abril de 2011

Como identificar bons programadores

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." [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”[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!

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

Referências:

16 comentários:

Blogildo disse...

Na consultoria Michael Page (que é muito melhor que a famosa Catho), programadores e analistas de sistemas são contratados para ser entrevistadores. Fiz uma entrevista com eles uma vez e achei excelente o nível das perguntas. O entrevistador era, sem dúvida alguma, alguém da área.

Dirlei Dionísio disse...

Opa, esse é um trabalho que eu toparia fazer como freelancer.

No ano passado fiz uma entrevista numa das maiores empresas de TI do Brasil e o entrevistador também era da área (havia sido programador e analista antes de ser gerente), mas as perguntas dele eram bem semelhantes as o gerente de circo desse artigo: sabe fazer x? e y? já fez z? Ok, gostei de você... qual a sua pretensão?

Renan Monteiro's Sharepoint disse...

Fala Dirlei!

Cara, sem sombra de dúvidas me arrisco a dizer que seu blog foi uma das descobertas mais bacanas que fiz no Dev in Rio 2010 (li na sua camisa ainda haha!), seus posts são inteligentes e de excelente qualidade!

Quanto ao tópico gostaria de saber quanto tempo demora para se terminar um processo seletivo desse porte.

Supondo por exemplo que 3 candidatos tenham passado da fase de análise de CV, quanto tempo iria demorar, de 1 a 2 semanas? Ou pelo fato de alguns candidatos serem eliminados muito rápido em algumas etapas isso agilizaria o processo? As vezes (e com muita frequência) só se contrata quando o gestor de fato vê que a atual equipe não vai dar conta, ou seja, o processo tem que ser rápido podendo colocar em prática a qualidade dos filtros usados na seleção dos candidatos... Em TI ainda, isso é bem frequente!

Aqui no Brasil acredito que nem ao menos 5% das Empresas de TI tem um processo desse tipo, ou estou errado?

Abração, e mais uma vez, parabéns pelo blog!

Dirlei Dionísio disse...

Opa Renan!

Seu comentário confirma que "propaganda é a alma do negócio"... hehehe. Obrigado pelos elogios ao blog.

Sobre seu questionamento, avaliações técnicas como as que citei aqui não duram muito tempo. Exceto pelo miniprojeto (se aplicável), cada avaliação pode ser feita em 1h ou menos. Portanto, poderiam ser feitas todas no mesmo dia. O que é mais determinante para a duração do processo é conciliar o tempo dos candidatos com o tempo das pessoas envolvidas na avaliação. Sem houver muitos candidatos, esse problema é agravado, daí a importância de anunciar nos lugares corretos, como disse no artigo anterior.

A maioria dos processos que acompanhei, desde o anúncio das vagas até o início do trabalho dos selecionados levou bem mais de 1 mês. Quando um bom candidato era encontrado, em geral, observei prazos de 1 ou 2 semanas para se decidir pela contratação. Mas o tempo de desligamento da empresa anterior pelo selecionado, quando era o caso, tornava o inteiro processo mais longo. Essa é uma variável que não dá pra desconsiderar. Quando nenhum candidato adequado era encontrado, já vi processos ficarem em aberto por meses até serem cancelados. Em outros casos, vi contratações de candidatos com nível aquém do desejado (por causa da pressa), mas com péssimos resultados.

Não sei dizer sobre números, mas certamente bem poucas empresas no Brasil selecionam programadores de uma forma semelhante a que apresentei aqui. As grandes consultorias tem processos que passam bem longe desse aqui. Já as top de linha em tecnologia, certamente tem processos muito mais rigorosos.

Valeu pelo comentário!

Grande abraço!

Leandro Laia disse...

Muito bom este método Dirlei! Achei prático e justo.

Dirlei Dionísio disse...

Obrigado Leandro! Abração!

Paulo Riceli disse...

Parabéns!

Seus posts são de excelente qualidade.

E desejo que receba meus sinceros agradecimentos por compartilhar suas idéias conosco.

Dirlei Dionísio disse...

Muito obrigado pelo feedback, Paulo! Seu comentário foi motivador e espero continuar compartilhando ideia úteis por aqui.

Grande abraço!

Eduardo Spaki disse...

gostei! e eu publico em um blog! :)

Gustavo Nogueira disse...

Dirlei,

Acabo de conhecer o blog e esse foi o segundo post que li. Achei muito bom!

Sem dúvida alguma seu processo seletivo vai muito mais à fundo em busca de um programador de qualidade, e por ter gostado demais do que li, tomei a liberdade de fazer algumas observações:

1 - O bom e velho currículo: concordo que a presença dos 3 pontos mencionados evidenciam características de um bom programador. Mas a ausência deles, a meu ver, não apontam obrigatoriamente o contrário. Discordo que o currículo sozinho seja suficiente para desclassificar um candidato. Claro que em alguns casos será, mas creio que em vários outros, será necessário um pouco mais que uma análise curricular para garantir que o profissional não é talentoso.

2 - Mapeamento de conhecimento: interessante a ferramenta, mas achei extensa. A meu ver, pode assustar o candidato que, a partir daí, pode assumir uma postura negativa, com pensamentos do tipo: "avaliando tantos requisitos, essa oportunidade está além de onde posso chegar". Sim, claro que essa postura não é uma postura interessante, mas em uma contagem rápida, apurei 57 itens a serem respondidos pelo candidato. Se não for um profissional muito seguro de si ou muito disposto a buscar a vaga, ele pode desistir do processo. Por outro lado, o item não impede que o candidato que mentiu no currículo continue mentindo ao responder esse formulário.

3 - Entrevista pelo telefone: muito bom este item, principalmente as duas primeiras questões sobre como começou a programar e sobre os trabalhos que mais gostou. Poupa tempo de ambos os lados e aborda assuntos efetivamente importantes. Quanto à avaliação sobre a capacidade de resolver novos problemas, também acho essencial que seja analisada, mas tenho minhas dúvidas se a entrevista por telefone oferece ao candidato o melhor ambiente e a tranquilidade necessária para encontrar as perguntas que precisa fazer. Até porque, no dia-a-dia do trabalho, ao se deparar com uma tarefa como "implementar uma engine de renderização para um browser", dificilmente o profissional precisará encontrar as perguntas certas sobre a pressão de um processo seletivo por telefone, onde normalmente não se deixa o interlocutor no vácuo enquanto se processa um raciocínio em poucos minutos. Em minha opinião, ficaria para a entrevista presencial.

4 - O que a internet diz sobre o candidato: outro ponto essencial. Creio que seja a etapa mais reveladora sobre o candidato. Inclusive acredito que, considerando que as etapas foram apresentadas na ordem cronológica que devem ocorrer, esta análise deveria ser realizada antes, talvez juntamente com a análise do currículo, o que poderia até evitar que candidatos talentosos não sejam eliminados pela ausência dos 3 pontos analisados no currículo.

5 - Miniprojeto: muito bom também, mas, a menos que eu não tenha entendido bem, julgo que seja redundante ao "Show me the code" existente na entrevista presencial. Além disso, deve tomar muito tempo do candidato e do próprio responsável pela seleção, que obviamente precisará analisar com cuidado o miniprojeto em questão.

6 - Entrevista presencial: concordo 100% com tudo apresentado nessa etapa.

E para finalizar, parabéns pelas considerações finais. O que vejo de processos seletivos que não respeitam os candidatos é impressionante! Horários não cumpridos, e-mails não respondidos e perguntas inadequadas são só alguns exemplos pra lá de básicos sobre o despreparo de muitas empresas ao contratarem novos profissionais.

E, por último, eu acrescentaria o seguinte: depois de todo esse processo, garanta que sua empresa é digna dele. Preocupe-se em cultuar verdadeiros líderes e times no lugar de chefes e equipes. Busque um ambiente desafiador, que motive seus profissionais. Permita-os vestirem a camisa da empresa e fazerem a diferença, afinal, se você buscou com tanto cuidado por alguém com efetiva capacidade, faça uso disso!

--

Gustavo Nogueira
(31) 9124-8188
www.gustavonogueira.net
www.gustavonogueira.net/linkedin
www.gustavonogueira.net/twitter

Dirlei Dionísio disse...

Muito obrigado Eduardo! Volte sempre. Grande abraço!

Dirlei Dionísio disse...

Olá Gustavo,

Muito obrigado pelos seus comentários! Parece que concordamos sobre a maior parte desse artigo. Nos pontos em que há discordância, pode ser que em alguns estejamos vendo as questões sob prismas diferentes. Acrescentei alguns comentários para esclarecer:

-> Sobre currículos, aqueles 3 pontos são os que mais me chamam a atenção, porém não os uso como requisitos que devem sempre ficar evidentes no currículo para levar um candidato adiante no processo. Sei que há programadores talentosos que não são tão bons em redigir currículos quanto em escrever código. Por causa deles, uso o bom senso antes de concluir através do currículo que alguém não tem o talento necessário. Se tenho dúvidas, o mapeamento de conhecimento resolve.

-> É verdade que esse mapeamento pode parecer extenso para muitos candidatos, por isso o utilizo com muito cuidado. Analisado isoladamente, ele pode ser intimidador, mas no contexto de todo o processo, que inclui um anúncio muito bem redigido e emails simpáticos e personalizados, a intimidação dá lugar a sensação que que a avaliação será justa e não arbitrária. Não tenho números para provar isso, mas é o meu feeling. Sobre o candidato mentir nesse formulário, sim, é possível. Mas ele precisará ser um mentiroso muito melhor, já que precisará comentar sobre seu seu falso conhecimento e não apenas dizer que o possui. Mas nem vejo a mentira como um problema comum; mais comum é alguém acreditar que sabe muito sobre algo quando de fato sabe apenas o básico. Qualquer q seja o caso, o mapeamento barra boa parte desses candidatos logo no início do processo.

-> Sobre a entrevista por telefone, preciso acrescentar que o dia e horário devem ser escolhidos pelo candidato, ciente da duração aproximada dela. Mas mesmo assim, concordo que o candidato dificilmente terá a tranquilidade ideal para propor soluções àqueles problemas. Porém, penso que isso não vai melhorar na entrevista presencial, pelo contrário. Vale lembrar que o tipo e o nível dos problemas deve ser compatível com o perfil desejado. De qualquer forma, se um problema deixa o candidato empacado, pode-se passar para um problema mais simples e sem seguida para um outro mais complexo. Pode ser que nenhum candidato tenha um desempenho extraordinário nessa etapa, mas os melhores candidatos certamente ficaram mais evidentes que os demais.

-> O miniprojeto se aplica apenas a novatos, que geralmente possuem mais tempo e não se incomodam com a redundância nas avaliações. O maior tempo gasto pelo(s) avaliador(es) se justifica nesse caso, pois estamos lidando com candidatos que podem ter um potencial extraordinário, mas ainda não foram descobertos pelo mercado. Eles são como ações compradas na baixa do mercado.

Pra concluir, as ferramentas são secundárias. O mais importante são os avaliadores. Bons avaliadores saberão escolher as ferramentas mais apropriadas para cada caso e utilizá-las da forma apropriada.

Muito obrigado pela troca de ideias que seu comentário nos proporcionou!

Grande abraço.

Eduardo Farias disse...

Seguindo as orientações desse post e voltando a me empolgar com outras linguagens resolvi aprender Python (já programo em Java). Estou querendo fazer um "pet project" desses que você recomendou serem feitos em um final de semana. Você poderia me dar alguma ideia? Seria mais pra testar e consolidar meus conhecimentos na nova linguagem.

De qualquer forma esse foi um estimulante post, muito obrigado!

Dirlei Dionísio disse...

Posso sim, Eduardo. Recomendo o Project Euler: http://projecteuler.net/problems

Um abraço!

Unknown disse...

Será que dá para fazer um post de "Como encontrar um Profissional Programador Desenvolvedor de Web"?
Depois que descobritram que freelance é um lance de ficar livre de compromissos eu não encontro Profissionais para trabalhar e ganhar dinheiro.
É mais facil contratoar o cara lá na India do que achar alguém que queira assumi compromisso de trabalhar todo dia.
Quando eu encontrar um você acha que eu vou fazer testes e mais teste???
Na real, tem que contratar igual o Mac Donald.
Peep Web Power

Dirlei Dionísio disse...

Oi Paulo,

Eu não sei onde e como você está procurando programadores, nem quais são as condições do trabalho oferecido, por isso não tenho como avaliar se realmente é uma questão de comprometimento.

Se ainda não tiver lido, veja se o artigo Como atrair bons programdores te sugere algo diferente do que você está fazendo.

Sobre os testes, eles não são necessários se você ou alguém da sua confiança conhece o trabalho do candidato. Se esse não for o caso, só você pode dizer se vale a pena correr o risco de contratar um mau programador.

Obrigado pela visita e pelo comentário! Espero que consiga encontrar e contratar o profissional que está procurando.

Um abraço!