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,


Sobre garrafas d’água e janelas quebradas

27.março.2009
Há semanas eu queria publicar isso, mas a correria e a avalanche de viagens atrasou um pouco a coisa por aqui. A boa é que meu plano de milhagens ficou mais gordinho depois do último mês.

No escritório em que trabalho há um frigobar. No frigobar há uma garrafa d’água cuja função (duh) é fornecer água gelada aos funcionários e visitantes. Sem dúvida, nesses tempos de calor excessivo, um copo bem servido de água gelada é muito bem vindo.

O problema é que todo mundo gosta de tomar aquele copão de água refrescante, mas ninguém gosta de encher a garrafa de volta e, aquele que pega essa tarefa, gasta bons minutos enchendo uma garrafa vazia e bebendo água morna.

E o que você tem a ver com o que acontece no escritório?

Pense que a garrafa é um software. Você chegou da rua, com calor e suado e quer água gelada. Você foi jogado num projeto e quer código limpo,claro e que funcione, certo?

Só que, sinto dizer, as chances de você encontrar isso no seu novo projeto é ainda menor do que as chances de encontrar água gelada, e o motivo é bem simples: maioria das pessoas quer simplesmente se livrar do problema, pular para a próxima tarefa, correr logo para casa e/ou mostrar produtividade para a chefia. Poucos percebem que isso vai criando uma bola de neve, ou de fezes, que só cresce, e afoga o próximo que tiver que meter a mão no lodo.

“Não tenho tempo”, “o próximo que se dane” ou simplesmente “não reparei que estava fazendo isso” são as desculpas mais comuns e, infelizmente, tentar convencer essas pessoas do contrário é tão produtivo quanto lavar burro com xampu anticaspa.

Alguém um dia disse que, se quisermos um mundo melhor, temos que começar a limpar nosso próprio quintal. Se eu quero ter sempre água gelada, eu completo o que acabei de beber. Se eu quero um código limpo, eu corrijo, dentro do possível, o código em que estou trabalhando, e faço o possível para deixar código limpo para quem vier depois. E não compensa esperar que as outras pessoas mudem de comportamento, por mais que os cursos por aí preguem o contrário.

Conserte as janelas quebradas, escreva testes, não jogue papel na rua, limpe os pés antes de entrar e, pelo amor da sua divindade preferida, encha a porra da garrafa d’água depois de se servir.

E bom fim de semana.


Comunicação é tudo e mais um pouco

26.janeiro.2009
Imagine que você receba a seguinte especificação:

Pegue uma folha de papel A4. Sob a mesa, dobre-a ao meio. Coloque a folha dobrada sobre a mesa.

A especificação parece clara e simples, mas aposto que dobramos as folhas de forma diferente, obtendo resultados diferentes. Eu dobrei a minha folha verticalmente, enquanto provavelmente você dobrou horizontalmente, obtendo uma forma próxima de um quadrado.

Qual foi o problema?

Eu criei uma especificação tendo em mente exatamente o que eu queria. E eu acreditei que aquilo era mais do que suficiente.

Você pegou uma especificação, aparentemente muito simples, e sem questionar seguiu os passos que julgou corretos.

Não houve comunicação, cada parte presumiu coisas e o resultado final não foi o esperado.

O grande diferencial das ditas metodologia ágeis é exatamente permitir a comunicação rápida, clara e sem ruídos entre todos os membros da equipe. Isso não tem nada a ver com post-its, gráficos ou ferramentas na Internet. É por isso que estamos vendo-as falhar, e é por isso que o seu projeto, e o meu, também estão falhando.

É por isso que relacionamentos chegam a níveis insuportáveis de convivência, casamentos terminam, empregos viram um inferno. É por isso que ocorrem desencontros, é por isso que clientes recebem algo que não pediram e que não os atendem.

É por isso também que não consegui comprar um mísero pão doce quando estive fora do país.

Comunicação é, na minha opinião, o fator mais importante, e o menos valorizado. É tudo isso que eu falei, e mais um pouco.


Para pensar

06.janeiro.2009

“Each individual should work for himself. People will not sacrifice themselves for the company. They come to work at the company to enjoy themselves.”

Soichiro Honda


Entrevistando

10.dezembro.2008
Acabei de sair de uma entrevista para trabalhar aqui na empresa. Basicamente, não tinha mais ninguém para entrevistar o rapaz e eu fui escalado em cima da hora.

De repente pode ser um tiro no pé dizer isso, mas eu sinceramente detesto fazer entrevistas. Deve ter algum meio mais fácil, prático e não-traumático de se fazer isso.

Imagino que o cara deva ter faltado no trabalho, pegou trânsito para chegar atrasado aqui e estava um calor desgraçado. Eu fiquei até mais tarde, estressei com a empresa de consultoria por não ter colocado o telefone do candidato no currículo, apliquei uma prova que eu não sei se realmente avalia alguma coisa relevante ao cargo, fiz meia dúzia de perguntas e dispensei o cidadão.

Acho que, nessa hora, o melhor a fazer para os dois lados é ser claro e objetivo, sem enrolar e sem tentar ser o que não é. Deixei claro, ao ser questionado, que não sou eu quem contrato, nem avalio os currículos. No lugar dele eu teria me perguntado “mas então, que diabos estamos fazendo aqui?”. É o que me perguntei.

Enfim. Boa sorte ao colega, dando certo aqui na empresa ou em qualquer outro lugar.