Avaliando
Oct 4th, 2008 by Thiago Galesi
Contratar pessoas sempre é sempre complicado, e provavelmente essa tarefa caia em minhas mãos (aonde eu estou) brevemente. Avaliar gente que nunca vi antes. Para cargos técnicos.
Logo, planejo usar Entrevistas Técnicas. Parece que aqui no país o pessoal ainda prefere as entrevistas “tradicionais”, coisas como “Quais são as suas qualidades, fraquezas, etc”. Pra mim isso é tão eficiente quanto perguntar se o entrevistado gosta de sorvete de chocolate, pra que time ele torce, ou pior, avaliar o candidato pelas roupas que ele está usando (qualquer coisa não esdrúxula tá valendo, sério). Perguntas como “Você sabe C++” também não adiantam muito… É sabido que toda pessoa que está procurando emprego (eu inclusive, lógico) vai colocar todas as keywords que já mexeu, viu, leu em algum lugar, etc, no CV. Pois o pessoal de RH que só conhece grep vai achar que uma pessoa que sabe Java é desqualificada para um trabalho de J2ME (poisé!), etc e tal…
Experiência?? Cada vez mais acredito que EXPERIENCE IS OVERRATED. Principalmente em certas empresas (tenho meu “caderninho paticular” de empresas) que tem funcionários que não sabem a diferença de um int para um float passam anos “”trabalhando”" (i.e. mandando email de um lado para outro) e daí põe no CV “10 anos de experiência em C++”. (É que 2 anos foram passados esperando o checkout do controle de versão, sabe…)
O que sobra??? Entrevistas técnicas. Case in Point:
If you want a job at a company like Microsoft, Yahoo!, Apple, or Amazon.com, they’re going to have high standards. It doesn’t matter if you “know how to program”. They’re going to test you on algorithmic complexity analysis, advanced data structures, algorithm design, searching and sorting, internationalization techniques, network protocols, OS-level memory management, parsing and semantic analysis, recursion and mathematical induction, graph theory, combinatorics, programming language theory, machine architecture, discrete math and logic, graphics and window systems, fonts and typesetting, color spaces and representations, databases and query languages, filesystems and storage, embedded systems, device drivers, mobile and wireless protocols, and internet standards and technologies.
If you’re lucky, that is.
Não, a empresa onde estou não passa nem perto de uma MS ou Google da vida em qualidade técnica. Mas vejo que é necessário ter qualidade na contratação por diversos fatores; o fator principal é parecido com aquele ditado: “Eu bebo pouco, e me transformo em uma pessoa que bebe muito” (ou algo assim)
Funcionário com má bases técnicas tende a ter idéias idiotas. E poucas idéias idiotas viram muitas idéias idiotas, daí você chega no fim do projeto sem dinheiro, com um produto que é uma droga, que ninguém quer comprar e que você não tem dinheiro pra vender. (E eu já vi MUITAS VEZES combinações disso).
Não estou falando da “crítica” dos especialistas, coisas como “quem vai usar um OS feito de graça” ou “mecanismo de busca já tem o Yahoo, pra que precisa outro” estou falando das idéias suicidamente idiotas, como “vamos portar todo o nosso produto para Java” (produto embarcado com limitação de memória), “vamos gastar milhares de dólares em ferramentas ruins porque tem um nome famoso”, “vamos apenas arrumar os bugs que o cliente reporta, não o bug gigante que está visível e que deixa o software inusável” etc.
Mas então, como fazer?!?! Primeiro, o que não fazer:
- A entrevista não é o Show do Milhão. Não pergunte coisas que podem ser googladas/wikipediadas em 2 segundos (claro que certas coisas são esperadas com um certo nível de experiência, um especialista em C tem que saber usar o printf, alguém que usa linux tem que conhecer ls, mas tudo com moderação)
- Nada de pegadinhas, nada de quebra-cabeças. Se o candato sabe passar uma zebra, uma galinha e o Bono Vox pela ponte sem ninguém comer ninguem ou saber ligar 10 pontos com 2 linhas bom pra ele, mas dificilmente esse é o tipo de pergunta que vai adiantar alguma coisa. (Exceção (e olha lá…) - ANALOGIAS a algoritmos) Responder a uma perguntas “Ahá” só querem dizer que o candidato ouviu a resposta “Ahá”.
- Pegue leve! Se o candidato é bom ou não vai ser evidente.
Então, o que perguntar??? Como fazer?
1 - Suas áreas de conhecimento. Baseie-se nisso Programador Web não precisa saber tanto de bits e bytes quanto precisa de Banco de Dados, logo adapte-se! Nem todo mundo precisa ou conhece expressões regulares.
2 - Perguntas justas. Tem algum problema fácil (mas desafiador) que a equipe enfrentou e que poderia ser transformado em um problema de poucas linhas??
3 - Independência de linguagem. Deixe o candidato resolver algo na linguagem que a empresa usa/usará e que ele se sinta melhor. Se estiver fazendo isso no quadro ou no papel, não implique com a sintaxe. (Pseudo-código sucks, mas algo como pseudo-C, pseudo-python, pseudo-lisp tá valendo no quadro)
4 - Dê dicas. O candidato está nervoso, e dá branco mesmo. O candidato tá se afogando, jogue uma corda. Não deu, jogue uma bóia. Ainda não deu?? Colete salva-vidas. Explique como usa. Daí se ele ainda assim falar “huh?!?!”, aí você deixa ele afundar 
5 - Perguntas fechadas. Se você quer que o candidato escreva uma função que faz X, forneca o protótipo.
Você também pode fazer algo “com consulta”, acesso a compilador, etc, lógico que daí a pergunta vai ser mais difícil…
Pode-se pegar outras idéias daqui: http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
E no fim, uma coisa para se pensar: http://www.paulgraham.com/avg.html
After a couple years of this I could tell which companies to worry about and which not to. The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening– that’s starting to sound like a company where the technical side, at least, is run by real hackers. If I had ever seen a job posting looking for Lisp hackers, I would have been really worried.
