Seções iMasters
Carreira

Alguns desenvolvedores simplesmente não conseguem desenvolver

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.

Comente também

33 Comentários

Mayko

Eu já fiz estágio e hoje estou trabalhando como desenvolvedor, nas duas vezes tive que mostrar meus conhecimentos na prática.Para entrar no estágio, tive que desenvolver um sisteminha crud básico com as tecnologias que eles utilizavam. No meu emprego atual, tive que realizar uma prova teórica, abordando conceitos , ainda me deram um projeto simples, para que eu pudesse, corrigi-lô, identificar padrões de projeto, explicar como erá a arquitetura dele (tudo isso na empresa), enfim. Além disso, depois passei por uma entrevista técnica em que fui colocado realmente a prova o que eu sabia. Eu creio que só assim, você descobre se a pessoa realmente é desenvolvedor ou não, se ele propõe soluções e consegue se virar com o trabalho do cotidiano. Conheço pessoas, que tem praticamente a mesma formação que eu, e tem incrivel dificuldade para programar, ou até mesmo pensar de maneira a resolver problemas.

    Amanda

    Ah não, pra estágio acho meio ridículo comprovar que você sabe fazer aquilo. Fala sério, né? Se é uma vaga para ESTÁGIO, é pra pessoa APRENDER. :P

    Paulo

    Aprender a gente aprende na Faculdade, no curso. No trabalho, sendo ESTÁGIO ou não, devemos PROVAR que JÁ aprendemos alguma coisa.

    Quem procura o primeiro estágio deve no mínimo já ter aprendido conceitos básicos pra poder se salvar, como diz o texto.

    É simples:

    “É uma troca justa; eu te pago pra você resolver problemas, a medida que você cresce eu também cresço. Não te contrato e te pago pra aprender. Sou seu chefe, não seu Pai.”

    Rodrigo

    Tem que ter teste sim. É estágio, vc quer aprender, mas tem gente que quer a msm vaga e já sabe. Quem vai ser contratado?

    Paulo Calixto

    É importante haver teste mesmo em estágios, por que se fosse pra pessoa apenas aprender no serviço não precisaria nem existir faculdade, era só estagiar até aprender tudo! Seria até melhor para as empresas que estariam com mão de obra mais barata em troca do aprendizado.

    abrçs

Gabriel

No meu atual emprego, fui contratado após a dona da empresa jogar, como é mesmo o nome ? tarô ? buzios ? hehehe e ainda pediu pra mim escrever sobre a minha vida desde pequeno… hehehe…

annonymous psn

Alguns redatores simplesmente não conseguem escrever e apenas traduzem artigos de outros.

Luiz Fernando Picolo

Idéia legal, porém além de usar muito senso comum na escrita, acredito que usar códigos em uma entrevista não é o caminho mais correto, pois os mesmos, pelo nervosismo ou pela tensão gerada pelo momento, podem não conseguir atingir o status desejado pelo entrevistador, contudo, em momentos de mais “calmaria” o objetivo pode ser alcançado com mais exatidão. Portanto, essa não seria a forma correta de dar a categoria de bom programador ou mal programador para um pessoa que já atua na área.

Já em relação ao falso currículo, isto sim é um caso grave, porém existe a experiência para que todas as dúvidas em relação ao candidato sejam tiradas

Heloisa Biagi

O currículo falso é realmente preocupante e envolve mais do que a questão de “o candidato não conseguir programar”, envolve também sua índole. Por isso não custa “vasculhar” a vida do candidato um pouquinho antes de contratá-lo.

Quanto à prova prática, como alguns já disseram, acho que às vezes ela não é a melhor solução justamente por conta da tensão e do nervosismo. Mas o que um entrevistador pode fazer é pedir para o candidato explicar algum programa ou código que já tenha feito. Como é um projeto com o qual ele estará presumidamente familiarizado, o nervosismo será menor e ele ainda terá a chance de mostrar seus conhecimentos e seu raciocínio para o entrevistador.

    Paulo

    Acho que é como passar de ano no colégio. Com nervosismo ou não, pra evoluir você tem que fazer a prova. Isso faz parte da cultura humana a anos. Não há como ser “não prático” agora.

    Se o candidato estudou, se informou, e realmente gosta do que faz, prova da NASA nenhuma deixa ele nervoso. Se ele encontra um teste muito superior aos seus conhecimentos, é só ser franco e dizer. As vezes a sinceridade vale mais que o conhecimento. Principalmente na análise de carater.

    Junior Soares

    Concordo com o Paulo. Um bom profissional tem que conseguir mostrar o que é capaz de fazer e, o nervosismo é natural, temos que saber lidar com ele. Porém o entrevistador tem que levar em consideração a situação que o candidato está enfrentando, e criar no ambiente um clima tranquilo para que o futuro novo desenvolvedor da empresa sinta-se a vontade a ponto de dizer sem dificuldade o que ele não consegue fazer, e ainda que a sua sinceridade não eliminar completamente as suas chances de ser contratado.

Felipe Volpatto

No meu caso, fui posto a um teste de crud. Ali, analisaram tudo, principalmente POO, padrões e o rendimento. Foi bem puxado, mas valeu muito a pena. Sabia do que eu podia fazer e eles ficaram sabendo do que eu sou capaz!

Fernando Martins

Não acredito que contratava assim,sempre fiz testes práticos, mas é complicado avaliar.
imagina os desenvolvedores refém de ferramentas, que estão acostumados a arrastar e soltar.

Carlos Alan

Eu acho que testar o candidato com código, não é a melhor saída, pois envolve o fator psicológico, algumas pessoas podem até sair bem nessa etapa, mas isso não garante que ela vai sempre manter aquele padrão de agilidade e sabedoria.

Acredito que isso seja fácil de resolver, seja sincero com a pessoa, faça um contrato de experiência por 45 dias e diga que tudo depende dela nesse tempo, até pro salário aumentar vai depender dela.

Uma outra saída legal também é bater um papo de linguagem com o candidato, conte um case da empresa ou peça pra ele contar, como resolveram as soluções, as saídas, peça pro candidato contar alguma vivência de bugs, acertos, códigos bizarro que ela já viu por aí. Veja como é o know-how do cara, tome um café com ele.. veja até se ele sabe as piadas de #soudev que rola por aí.

Um exemplo de conversa:
candidato: Fiz um sistema pra minha mãe, ficou bem interessante
entrevistador: Legal cara e voc? deve ter aplicado MVC em?
candidato: Apliquei sim.
entrevistador: O que tu acha de MVC? Tu acha que o M realmente ajuda o C?
candidato: é ajuda sim..
entrevistador: pq?
candidato: heeeeeee… pq ajuda e pronto!

hahahah

CACA-COBRA

<?php

for($i=1;$i<=100;$i++){

if ( ($i%3 == 0) && ($i%5 == 0) ){
print "($i)FIZZBUZZ “;
} elseif ($i%3 == 0){
print “($i)FIZZ “;
} elseif($i%5 == 0){
print “($i)BUZZ “;
} else {
print ““.$i.”“;
}
}

Onde fica minha sala? rsrsrs

thiago

eu não contrataria pq ele esqueceu de fechar a tag do php hauhauahuhaua

    Diogo Matheus

    Thiago, acho que você não seria contratado… #fail

    Douglas Miranda

    haha, mas o pior é que funciona da mesma forma :) em alguns projetos, fechar o bloco php em um arquivo que contém php puro, até atrapalha na depuração.

    Mas eu descontaria um ponto por utilizar HTML dentro do PHP :) .. outro ponto por utilizar impressão de variáveis dentro da string, pois para performance a concatenação ainda é o modo que mais rende em tempo de processamento :)

    Tem o lance do echo ser mais rápido que o print, e o lance da identação não digo pq creio que nos comentários seja removido rsr

    Eita, eu seria um recrutador muito severo O__o’

Douglas Miranda

Eu utilizaria, como critérios de avaliação, a entrevista básica, com referências, análise de curriculo e propor a conversa sobre alguns temas como padrões de projeto, comunidade open-source, OO, entre outros.

Mas não ficaria somente em detalhes técnicos, iria mais a fundo, perguntando sobre um pouco da vida pessoal, como a pessoa lida com estudos, trabalho e vida pessoal. Se a pessoa possui algum hobby e até questões de como a pessoa se alimenta, pois as precisamos de programadores que amam desenvolvimento, mas não precisamos de ninguém desmaiando em cima do teclado ou ficando com anemia, LER, entre outras.

Ultrapassar limites é bom, às vezes, mas reconhecê-los e saber até onde conseguimos chegar é melhor ainda.

Reiny

Na verdade o titulo do artigo deveria ser:

Alguns “farsantes”, simplesmnte não conseguem desenvolver !

Bom artigo =) !

Yuri Wayne Ferreira

Acho que o autor foi muito feliz em suas colocações. Mas acho que uma prova é muito complicada, pois se das 10 perguntas acontecer de o candidato não souber responder 5/6 dessas mas conseguir chegar no resultado de outra forma( do que a proposta pelo problema ) ou com alguma pesquisa, então ele foi sim avaliado erroneamente. Alguma vezes essas provas são absurdas, como obrigar um advogado a saber TODAS as leis, quando se ele souber 80% e você perguntar sobre justamente os 20% que ele não sabe ele ser descartado… pode ter potencial para muito mais.

Ricardo

Eu fui feliz em minha contratação em uma grande Agência Web… realizei o teste porém não utilizei uma arquitetura 100% OOP como solicitado mesmo pq meu conhecimento era pouco… mas independente disso eu entreguei a tarefa solicitada no teste 100% e o gestor foi mto honesto comigo… apresentou teste de alguns desenvolvedores que implementaram o teste em pura OOP mas o resultado não foi satisfatoriamente como o meu até então aquela classe com um monte de método… e disse que me contrataria por este motivo pois sentiu que eu tinha muito potencial… e hoje sim entendo bem participei de alguns cursos fornecidos pela Agência… e 4 anos mais tarde, ou seja, nos dias de hoje me tornei gestor e me sinto satisfeito em ter implementado aquele código-fonte durante a entrevista que acabou “me salvando” ehehhe abraços…

Cléber

Todos sabem que existem a sintaxe básica de programação( if, while, for…), isso é essencial para um programador “amador” saber, a grande questão é quebrar a tensão durante uma entrevista, pois acredito eu que não seja a mesma do cotidiano da vida de um desenvolvedor.

Acho ainda que o entrevistador precisar ir além das habilidades existentes do candidato, ele precisa encontrar o potencial na capacidade de resolver problemas e inovar, como dizia meu chefe “Programador já nasce programador”.

Enfim provas durante a entrevista não acho tão eficiente assim, mas uma boa conversa que vão além dos termos técnico é determinante para uma contratação eficiente e satisfatória.

Roberto

Muito bacana analisar um candidato por sua habilidade técnica, acho que funciona muito bem para desenvolvedores de qualquer tipo de linguagem, mas cá entre nós, eu sou designer, e no caso de um teste desse tipo, o resultado ás vezes beira o ridículo com candidatos que não manjam nada de harmonia em cores, usabilidade, métricas, layouts, wireframes etc. Design ainda é um bicho de sete cabeças ás vezes. O resultado de uma avaliação é muito subjetivo e não dá pra recriminar um sujeito que não tenha pleno domínio de photoshop, dreamweaver, flash e companhia. Eu tenho mais de 15 anos de experiência na área e ainda não domino completamente o photoshop. São inúmeros recursos!

Por um acaso alguém já se deparou com esse mesmo problema na minha área? Como o Imasters contrataria um designer?

Eu gosto do método: entrevista + apresentação de currículo + portfólio + produção de um wireframe e layout de um projeto qualquer.

Alguém tem alguma outra receita?

Abs.
Roberto.

Matheus

Gostei bastante do texto. Acontece que muitas pessoas querem iniciar no desenvolvimento no entanto não tem oportunidade. E o que as empresas pedem para um programador júnior é muito além do que o júnior pode saber. Não em todos casos, é claro.

Lembro que quando quando iniciei nesta área, eu tive que fazer provas escritas e responder sobre algumas tecnologias.

Não acho errado fazer uma prova, mas pelo menos coloquem o candidato na frente de um computador pra ele programar de verdade e depois analisem o código dele. Simples. :)

Cristian Clever Oliveira

Muito bom o artigo!
Obrigado!

marcos willian

O que seria a prova prática de desenvolvimento?

Na minha concepção seria um problema como autor cita, mas resolvendo esses bug’s ou criando um sistema munidos de um computador, já aconteceu comigo de ir em uma empresa(MULTINACIONAL) e chegando lá me deram uma folha com papel e caneta e pediram para criar um sistema todo no LÁPIS? É mole? e tive que fazer tudo em 1 hora, e ainda tinha mais uma outra a parte de SQL com uma modelagem de 2 tabelas para fazer algumas instruções.

João Fraga

for i in 1..100 do
    print i
    print “FIZZ” if ( i % 3 == 0 )
    print “BUZZ” if ( i % 5 == 0 )
    print “\n”
end

ps: Funcionaria em 4 linhas tambem!

Jan Palach

result = ['Fizz' if i % 3 == 0 else 'Buzz' if i % 5 == 0 else "FizzBuzz" for i in xrange(0, 100)]

Qual a sua opinião?