Entrevistas “Evil”

Hoje participei de uma entrevista “evil”. Aquela onde você perde tempo, se estressa e ninguém ganha nada com isso. Entrevista mal elaborada, mal feita, mal aplicada.

Tudo começou quando cheguei até a consultoria. Procuro filtrar antes onde faço meu CV correr para não cair nas empresas fundo-de-quintal-zona-leste-com-pagode. Mas enfim, nem sempre o filtro funciona. Um site bonitinho engana muita gente!

Ao chegar, primeira decepção: um formulário em papel questinando dados pessoais (que estão no meu CV), últimos empregos (que estão no meu CV), idiomas (no CV), skill (no CV) e… vocês entenderam! Considerando que, apesar de eu ser uma pessoa muito calma, em São Paulo, por causa do trânsito, você sempre chega estressado nos lugares, receber um formulário destes é o começo de uma longa lista de erros. Mas já que eu estava por lá e já tinha pago R$10,00 num estacionamento só pela primeira hora, vamos adiante.

Desta vez a pessoa que me recebeu foi até que muito simpática. Não vou mencionar outros momentos “evil” como nas muitas vezes em que fiquei esperando quase uma hora para ser “entrevistado”, uma outra vez que a “menina do RH” me pediu explicações sobre a diferença entre “servidor de aplicação e Java” pois ela achava que era tudo a mesma coisa e ainda outra onde a entrevista foi “coletiva” com pelo menos 12 programadores na mesma sala de reunião com direito a falar 5 minutos; a empresa precisava agilizar o processo de contratação.

Queridas meninas que trabalham no RH, façam testes bizarros como continuar o desenho inacabado, ligar os pontos, grifar adjetivos ou questione sobre “qual nosso maior defeito”. Mas por favor, coloque alguém da área técnica cara-a-cara, frente-a-frente para nos entrevistar.

E é por isto que o post veio ao blog. Entrevistas que não sabem avaliar técnicamente o candidato, especificamente, pedidos pra que você codifique em papel.

Programação SIM; Perder tempo NÃO!

Vou classificar as entrevistas de duas formas daqui pra frente: as que respeitam e as que não respeitam os programadores.

Respeito com os programadores é pedir para que codifiquem um programa e entreguem uma solução válida, compilada e executável como aparentemente é o que encontramos por aí no trabalho. Ou alguém anda commitando código em papel, talvez num arquivo morto pixado em vermelho CVS? E código em planilha Excel? E no Word? Alguém aí é privado de consultar APIs enquanto trabalha? Livros? Internet? Algum chefe como lema “ou programa sem consultar nada ou furo seu olho esquerdo”?

Nas últimas 5 entrevistas que realizei ao longo deste ano somente 2 me pediram pra codificar. O que é lamentável, já que estava fazendo testes para programar! Porém os dois testes de programação foram feitos de forma errada: um em papel, outro em Excel.

Programar em papel já é um velho conhecido de todos os que passaram por testes em consultorias de bodyshop que não tem o mínimo interesse no profissional a não ser limar os que realmente não tem capacidade nem de escrever public static void main... . Programar em papel é tão “evil” quanto tomar chá de boldo do Chile. Simplesmente porquê programação não é a arte de decorar… programação é a arte do saber fazer (e fazer bonito).

Como mostram exames de Raio-X em quadros de artistas famosos, quando pintam um quadro, começam com um esboço a lápis. Um fundo branco. Testes com alguma côr, testes com outra, e desta forma, constroem pouco a pouco uma peça de arte perfeita. Tudo leva dias, meses, anos. A obra está pronta na cabeça do pintor mas não na tela.

Quando me pedem pra programar algum código, minha cabeça começa a pensar rápido e a juntar peças e conhecimentos que adquiri no passado e novas idéias até formar a solução para o problema proposto. Porém na prática a construção é bem diferente.
Apesar de digitar código frenéticamente toda a construção é refeita a todo momento até que o código vire uma obra de arte. Código grande? Extract Method. Construção confusa? Simplifique. Classe comprida? Componentes. Esqueceu um método? Consulte a API. Existe uma classe pronta pra isto? API. Que biblioteca faria isso? Google! Qual o melhor design para este problema? Conversa com amigos durante o almoço. Chegando em casa e ainda querendo aprimorar? Livros, blogs, conversa com amigos nerds no barzinho mais próximo!

Bem, voltando as entrevistas, a gota d’agua foi pedirem novamente pra codificar em papel (ok, era pra codificar num WordPad e depois colar tudo numa célula no Excel (oque dá na mesma)). Além disto, questões mal formuladas e respostas ambíguas as quais você não tem o direito de reclamar e questionar e discutir porquê está sozinho em uma sala minúscula e mesmo porquê a menina simpática que lhe entregou o teste é do RH e não sabe a diferença entre um HD e um cooler.

O que me deixa muito irritado é saber que estes testes são criados por programadores e serão avaliados por programadores. Então, você está sendo avaliado por um programador ruim! Isto é triste. E o resultado final é um cara ruim dando uma nota pra um teste mal feito dizendo que você não tem competência para programar um sistema que usa Struts 1.x, DAO e zilhões de código Java no JSP. Lamentável.

Como se faz uma entrevista

Eu não sou expert em contratação. Não estudei psicologia e quase tudo que li em “O Corpo Fala” eu já esqueci. Mas tem coisas que são óbvias na avaliação de alguém que irá programar.

Primeiramente, o curriculum diz muita coisa sim. Candidatos que mencionam algo como “Conhecimento avançado em Word, Excel e HTML” ou “Curso Data Byte” estão automaticamente eliminados a não ser para a vaga de trocador de galão de 20L de água. Particularmente eu olho apenas 4 coisas num CV: onde trabalhou, idiomas, palavras chaves e a organização do texto. Palavras chaves mudam de tempos em tempos. Nesta época por exemplo, 2009, palavras chaves são por exemplo Ruby, Rails, XP, Scrum, Python, Scala, Haskel, meu usuário no twitter é x, o endereço do meu blog é y. Mostram interesse pela área e um perfil atualizado, que pode ser conferido numa entrevista posterior. Onde estudaram e se estudaram em uma faculdade realmente não me diz nada. Certificações? Se foi por motivação pessoal, aplausos. Se foi esperando uma melhor colocação, perdeu tempo!

Feito o primeiro corte, existem pelo menos 3 coisas a avaliar num candidato: avalie seu código, avalie sua redação e avalie a pessoa.

Código

Mas é claro que um candidato a programador deverá programar. Show me the code! Ofereça condições de avaliar o que ele fará quando estiver trabalhando. Caso o código seja feito durante a entrevista isto inclui deixá-lo a vontade, servir um café, ter acesso a internet para consulta, uma estante cheia de livros atrás, um editor de texto e um compilador. No final, o código tem que executar, óbvio. E SE executar, aí vamos ver a estética, a lógica, a criatividade, a simplicidade, enfim, se o código é ou não de fazer orgulho pra mãe. Sente com o programador e discuta o código. Questione os pontos que podem melhorar e veja se ele dá outras soluções.

Numa das melhores entrevistas que já fiz a empresa me enviou algumas propostas de código por email. Eu poderia escolher qualquer uma, codificar em casa, enviar por email e durante uma entrevista como pessoal técnico discutir meu código! Simples e brilhante!

Redação

É incrível a quantidade de pessoas que NAUM sabem mais escrever. Obrigado Orkut e escolas públicas. Me critiquem se for apenas preconceito mas todos bons programadores que eu conheço sabem escrever corretamente. Como é possível contratar alguém que sabe escrever um código de forma simples e legível e não sabe escrever um português com a mesma elegância? Faça o candidato escrever. Sugira por exemplo para que ele escreva uma crítica sobre o último livro técnico que leu. Aí você já matou dois coelhos!

Pessoa

Por último avalie a pessoa. Como eu já disse, não sou mestre em avaliar questões subjetivas como, candidato desenhou a linha pra esquerda? É psicopata. Linha pra direita? Matou a mãe! O que eu converso com o programador é o que eu converso com meus amigos programadores. Converso sobre tecnologia específica sim, seja Java ou C# mas converso a maior parte do tempo sobre livros, blogs, linguagens de programação, frameworks, eventos, open-source, web, twitter, etc. Eu converso para saber se a pessoa gosta da área, se ela está atualizada e se vai saber o que procurar e o que fazer no dia-a-dia.

Concluíndo

Entrevistar é uma arte e fazer uma entrevista efetiva é trabalhoso. Custa muito caro pra empresa contratar alguém que não retorne todo o tempo e investimento. Por mais criterioso que seja o processo eu não conheço nenhuma empresa que acerte 100%. Só o trabalho lado-a-lado mostra como uma pessoa reage a pressão, a prazos, a demanda por inovação, a criativadade necessária para as soluções mais complexas. Contudo, fazer da entrevista um processo agradável e avaliar com critérios é o começo para encontrar bons profissionais e criar desde o início uma imagem boa da empresa e das pessoas.