Texto original de Richard Banks, disponível em http://www.richard-banks.org/2009/08/some-developers-just-cant-develop.html
?
Eu tenho entrevistado alguns candidatos para posições de
desenvolvimento há mais de uma década. Nos primeiros anos, eu era muito afobado
para conseguir encontrar as pessoas certas, e isso perdurou até que uma
contratação do inferno aconteceu, e eu percebi que estava fazendo tudo errado.
Anteriormente, eu, e muitas outras pessoas que conheço, entrevistaria as pessoas
olhando para seu currículo, fazendo perguntas sobre seu histórico e
experiência, basicamente tentando sentir a pessoa e como ela poderia se
encaixar no time, partindo do pressuposto de que se ela pode conversar
razoavelmente sobre programação, então deve ser capaz de fazê-lo
também. Então, assumindo que essa conversa me trouxe um bom sentimento, eu
faria algumas checagens de referências e, então, tomaria uma decisão.
Isso resultou em uma taxa de sucesso de cerca de 60%, apesar de eu estar me
gabando aqui. Mas 60% não é muito bom, especialmente quando você
considera os custos de uma má contratação. Mesmo assim, as más contratações que
eu fiz não foram absurdamente ruins, elas apenas não estavam no nível que eu
gostaria. Pelo menos isso era o que eu pensava até que eu fiz uma contratação
muito, muito, muito ruim.
Esse cara era especial. Ele era listado como um líder de equipe .NET, falava sobre sua história e habilidades muito bem, era confiante e
engajado, e suas referências eram incríveis. Então decidi oferecer a ele a
posição, que ele aceitou rapidamente e começou a trabalhar pouco depois
disso. Uma das coisas que eu fazia com recém-contratados era pedir para que
eles trabalhassem em bugs, – me ajudava colocá-los dentro do projeto e dava a eles
exposição a uma variedade de áreas dentro do sistema. Eu também dei a eles
muito tempo para aprender o básico e “pegar no tranco”, e geralmente
demorava alguns dias para eles passarem pelos primeiros bugs e começarem a ter
momentos “ah-ha” com os códigos de projeto.
De qualquer maneira, essa pessoa em particular começava a trabalhar e tinha
seu primeiro bug. Um bug simples e, mesmo assim, ele demorou mais de uma semana
para resolvê-lo, tendo precisado de bastante ajuda no caminho. Eu
também estava recebendo reclamações dos outros desenvolvedores de que esse cara
era incorrigível e um péssimo desenvolvedor, no que eu não conseguia acreditar,
então decidi tirar um tempo para sentar do lado dele e ver o que estava
acontecendo.
Que choque eu tive. Logo se tornou aparente que aquele cara não conseguia
programar nem pra se salvar. Ele… literalmente… não conseguia… codificar.
Chegou a um ponto em que eu comecei a dividir a tarefa em pequenos passos, e pedi
a ele que colocasse o bug em um simples for loop, e ele apenas fitou a tela
completamente vazia. Então perguntei a ele qual era a sintaxe para o for loop,
pensando que ele estivesse travado pensando sobre um problema maior, ou que ele
estava apenas nervoso comigo do lado dele, ficando assim mais frustrado. Ele
não conseguia me responder. Ele simplesmente não conseguia me dizer qual era a
sintaxe. Nem o bom senso o ajudava. E um while loop? Não. Uma condição if? Só
uma parte. Era absolutamente assustador. Como eu pude errar tanto? Eu não
conseguia acreditar que tinha feito um erro tão monumental ao contratar esse
cara. Eu também não conseguia acreditar que suas referências eram tão boas.
Então eu percebi que mentiram para mim. Eu sei – sou muito esperto né? :-)
Imagina alguém mentindo no seu currículo! O choque disso! Imagine alguém
pedindo para seus amigos fingirem ser seus antigos chefes e darem a ele ótimas
referências? Como eu fui bobo.
Então o que eu ia fazer? Eu me lembrei de um artigo que li na época de Joel Spolsky (inglês) que me deu um estalo. Ele basicamente dizia que se você quer contratar um
desenvolvedor, peça a ele para escrever algum código durante a entrevista. Eu
não conseguia acreditar que eu não tinha conseguido perceber isso antes. Claro que as pessoas podem mentir em seus currículos e pedir a seus amigos para
mentir para elas, mas quando você vê alguém escrever um código, não tem como mentir.
Ou você consegue desenvolver, ou não.
A partir daquele momento, eu comecei a pedir para as pessoas fazerem um exercício de
depuração. Eu descobri que se o código estava lá, tudo o que eu realmente estava
pedindo para eles fazerem é ler o código, entendê-lo e fazer algumas mudanças.
Bem parecido com um desenvolvimento normal. :-) Então eu pedia para alguém do
meu time dividir um programa que tinha alguns bugs. Você iria consertar um,
descobrir outro, até que você conseguiria fazer o programa funcionar; e tudo
isso em cerca de 30 linhas de código. Eu cronometrei o tempo que eu havia
demorado para fazer a depuração do código e o pegava como referência para
estimar o nível de habilidade das pessoas que eu estava entrevistando (julgando
em cima de quão nervosas elas estavam). Eu tenho usado esse mesmo teste com
várias melhorias para mudanças de linguagem e assim por diante por alguns anos, e
tem me ajudado incrivelmente em distinguir quais candidatos são capazes de
codificar e quais não são.
Recentemente, eu fui incubido de ajudar outra empresa a escolher candidatos para
uma posição que não precisava de um calibre tão alto quanto eu normalmente
precisava, então pensei que meu exercício de depuração poderia ser um pouco
desafiador demais para o nível em questão. Resolvi então usar algo mais
simples, uma variação do teste Jeff Atwoods FizzBuzz. Se o condidato
conseguisse passar por esse teste rapidamente, eu poderia dar a eles o
exercício de depuração e ver como eles se sairiam com algo um pouco mais difícil.
Infelizmente, eu nunca consegui ir além do exercício FizzBuzz, pois os
candidatos usaram todo o tempo reservado para a entrevista (e até um pouco
mais). Fiquei surpreso com isso? Afinal de contas, esse era um exercício de
codificação bastante simples. Bom, na verdade não.
Se você der uma olhada no post de Atwood e até no post Reg Braithwaite (inglês), verá que ambos
citam esta passagem: “Eu descobri que as pessoas que têm dificuldade em
codificar não apenas têm dificuldade com grandes problemas, ou até com pequenos
problemas (p.e. escrever a implementação de uma `linked list`). Elas têm
dificuldades com problemas minúsculos.”.
Como isso é verdadeiro.
Ao fazer o exercício FizzBuzz, eu apenas confirmei o que eu já sabia a partir
da minha experiência com o exercício de depuração. Então, qual é a lição aqui?
Muito simples. Peça a seus candidatos para escreverem um código durante a entrevista.
Você não precisa de nenhuma ferramenta especial para fazer isso – apenas use um quadro branco e um pseudo código escrito à mão se você quiser. Mas, independentemente do que você
fizer, tenha certeza de que eles provem a você que eles realmente dão conta do
trabalho.
Lembre-se: existem muitos desenvolvedores que simplesmente não conseguem
desenvolver. Evite cometer os mesmos erros que eu, e faça o que você puder para
evitar contratar as pessoas erradas.
33 Comentários
Qual a sua opinião?