Entrevista de emprego

15.maio.2009

dilbert-1

Há seis meses fiz uma entrevista de emprego totalmente improvisada e despreparada. O carinha não entrou na empresa, o que não considero necessariamente negativo, e eu não participei de nenhuma outra entrevista de emprego, o que foi muito positivo. Para ser bem honesto, eu nem mesmo acho que o resultado daquela entrevista serviu pra alguma coisa.

As vezes, mais como um exercício mental, eu penso como seria uma entrevista de emprego para minha empresa fictícia, para uma vaga de desenvolvedor. Vamos supor que seja para trabalhar com Java, que é meu atual ambiente natural.

Primeiro aquela olhada no currículo. O cara tem meia dúzia de certificações, um emprego numa fábrica de software conhecida, formado numa faculdade da moda e chega de gravata para a entrevista. Sem julgamentos precipitados, lembre-se que esse é o perfil padrão de qualquer entrevista de emprego. Pode apostar, pelo menos um candidato vai aparecer nesses moldes. Numa empresa comum, ele estaria muito bem cotado a entrar.

Mas vamos à parte que interessa.

Antes de aplicar qualquer prova escrita, vou fazer algumas perguntas. Poucas, e em português mesmo. Considere que a entrevista é um momento tenso por natureza, e que não vai ajudar em nada piorar essa situação. Lembre-se de que a vaga é para desenvolvedor Java, e não para atirador de elite da SWAT.

Você gosta de ler? Qual a sua média de livros técnicos por mês? Você dá preferência a livros traduzidos ou em inglês?

Caso responda ‘não’ à primeira pergunta, podemos encerrar a entrevista por aqui mesmo. Preferência por livros traduzidos ao invés de livros em inglês, para mim, pode denotar preguiça e comodismo. Mas não acredito que esse ponto seja fundamental para definir a qualidade do profissional nesse ponto da entrevista.

Você já leu “Effective Java” (Joshua Bloch), “Test-Driven Development” (Kent Beck) e “Refactoring” (Martin Fowler)? O candidato ganha bônus se também já leu “Practices of an Agile Developer” (Venkat Subramaniam e Andy Hunt), “The Art of UNIX Programming” (Eric Raymond). Claro, pergunte também o que ele pensa dos livros e, principalmente, em que pontos ele discorda.

Eu considero os três primeiros leituras obrigatórias para qualquer programador que se considere profissional. Os seguintes são leituras importantes que não podem ser ignoradas. Se bem que, atualmente, se eu entrevistar um sujeito que realmente leu e consiga levar uma discussão rápida sobre todos eles, é bem provável que eu encerre a entrevista ali mesmo e o contrate de imediato. Novamente, se o candidato não leu nenhum deles, podemos encerrar por aqui para evitar mais perda de tempo.

O candidato conhece o Manifesto Ágil? Não estamos cobrando aqui nenhuma certificação-papel-de-bobo de Scrum ou coisa parecida (acalmem-se trolls, eu também tenho uma). Também não quero que o cara tenha o Manifesto decorado na ponta da língua. Importante é conhecê-lo e entender o que significa. Conhece TDD (ok, mesmo lendo o livro) e consegue usar essa abordagem de forma pragmática? Por pragmática entenda-se: sim, você tem que escrever testes antes de codificar. Não, você não pode perder tempo tentando alcançar utópicos 100% de cobertura de código. A tarefa do programador não é entregar as Obras Completas de Shakespeare em Java, mas sim código de qualidade em tempo relativamente curto. Utópico, mas que entrevista de emprego não é?

O candidato tem algum pet-project? Participa ou participou de algum projeto open source? (tradução de arquivos de i18n não conta). Programa porque gosta ou apenas porque alguém disse que dava dinheiro? Estuda tecnologias, linguagens ou abordagens que não estão necessariamente relacionadas ao trabalho? Conhecer Lisp, Erlang, Haskell e/ou linguagens dinâmicas ajuda a enxergar maneiras novas e até mesmo mais simples e limpas de se resolver um mesmo problema.

Na seqüência, se ainda não foi encaminhado à porta de saída, o candidato deve escrever uma dissertação breve, de vinte linhas, sobre algum assunto relacionado à área. A idéia aqui é apenas avaliar a clareza de raciocínio ao passar idéias para o papel e evitar futuros problemas com analfabetos funcionais. Seco e direto assim.

Agora a sobremesa. A hora preferida do verdadeiro desenvolvedor: a prova prática.

O candidato deve resolver um code kata em tempo pré-determinado (aqui a pressão faz parte do jogo), previamente definido e exibido todo o tempo. Um relógio na parede ajudaria nesse ponto. O desenvolvedor deve conviver com prazos definidos, que geralmente são curtos, e pressão. Nada de anormal. É exigido que o candidato utilize TDD ao resolver. Se ele chegou até aqui, pode apostar que ele consegue.

Ah sim. Arranje uma máquina decente com um ambiente semelhante ao real para que ele faça essa parte da entrevista. Codificar em folha de papel é uma das coisas mais ridículas de uma entrevista. Só perde para dinâmica de grupo e entrevista com psicóloga (note o gênero).

Avalie a expressividade do código. Isso é importante. Você não vai querer pegar um código suíço pela frente, cheio de variáveis enigmáticas e abreviações que não querem dizer nada.

Como eu disse no início desse texto, que saiu mais longo do que eu esperava, isso é apenas um exercício mental. Mas no momento está me parecendo um modo bem mais honesto e efetivo do que passar um dia inteiro numa empresa escrevendo redações sobre minhas férias, sendo entrevistado por psicólogas (de novo o gênero) que mal sabem o que a empresa faz, e para terminar, com fome e dor de cabeça, uma entrevista técnica com um sujeito que não acha a própria bunda usando as duas mãos (do tipo que briga com você jurando de pés juntos que C# aceita herança múltipla). Ouviu, sevencomm?

Bom fim de semana,


Um modelo diferente

12.novembro.2008

Estava pensando num modelo de negócios (ach) diferente para lidar com equipes de TI, onde os desenvolvedores (analistas, programadores, testers, etc) receberiam bônus por qualidade de software.

Por exemplo:

  • Quantidade de bugs comprovados (qualidade interna)
  • Avaliação dos usuários (qualidade externa)

e não simplesmente por ‘linhas programadas’, nem por ‘funcionalidades criadas’, já que isso criaria uma corrida do ouro para que fosse feito o máximo de itens possível, com o máximo de linhas possível, mas com a qualidade sendo jogada para escanteio.

Outro item que seria interessante, para evitar que mais nada fosse criado pra nao gerar novos bugs, seria avaliar também o retorno de investimento estimado para os clientes. Ou seja, quanto mais o cliente ganhou com isso, maior seria o bônus. Isso obrigaria a equipe a focar só no que é importante, e fazer bem feito.

Claro que isso ainda é só um rascunho, mas já dá uma boa idéia de como isso poderia funcionar.