Selecionando os melhores programadores?

Conversando com um amigo no ICQ há pouco tempo atrás tive uma discussão bem interessante sobre qual a melhor maneira de contratar um profissional.

Já tive de fazer algumas entrevistas em candidatos, todos muito bons, para uma vaga, e sei como essa é uma tarefa complicadíssima. Quais as "melhores práticas" pra isso?

Moderador Membro desde: 21/02/2003 16:19:19 Mensagens: 1647 Offline

Hummmm ... eu ainda não precisei selecionar ninguem, mas ja fiz muitas entrevistas

O estilo que eu mais gosto é:
1. Perfil psicológico (inclui emocional): verifica se o candidato se encaixa psicologicamente na vaga (tipo, alguns trabalhos sao macantes, um puta programador pode ou nao gostar de fazer coisas repetidas ... no meu caso prefiro ter um projeto diferente do outro, se só fizesse trabalhinhos com banco de dados eu morria, outros não)
2. Habilidade técnica: primeiro com uma conversa com um tecnico pq isso pode mostrar muito mais do que uma prova ... e depois se necessario (depende da vaga) uma provinha.

testar o candidado na prática, passando um pequeno problema (mas que faça ele pensar bastante) pra ele resolver na frente do micro (sem pizza, nem coca-cola)

pede pra ele te levar o melhor e pior codigo que ele ja escreveu.

ve se ele documenta, faz tudo bonitnho, usa interfaces.

ai voce pede pra ele fazer algo bem idiota
um sistema web de cadastro de usuarios e depois lista os usuarios. ele pode escolher o banco de dados, se vai saur ejb/jdo/jdbc etc e como vai ser a camada de apresentacao, que pode ser tosca.

vc da 4 horas pro cara. matou. vai ter nenguinho fazendo em 30 min com as ferramentas certas. vai ter nenguinho que vai estar no javadoc do jdbc. ai voce ve o perfil que voce quer.

Paulo Silveira wrote:vai ter nenguinho que vai estar no javadoc do jdbc.

isso é [muito] ruim?

Moderador Membro desde: 21/02/2003 16:19:19 Mensagens: 1647 Offline

Naaaaaaaaaaaaaaaaaao pergunta isso ... o Paulo vai ficar escrevendo sobre o Hibernate horas a fio eheheheh

Não concordo com essa tática do Paulo.

Nem sempre as pessoas podem aplicar no seu dia a dia tudo quanto é ferramenta e técnicas.

O importante pra mim é o cara saber MUITO lógica de programação, saber se virar pra aprender a usar ferramentas, conhecer as técnicas existentes e ter idéia de como usar (pra nao demorar muito pra aplicar em um projeto) e por ai vai.

claro que depende do perfil ... se vc tem um projeto usando determinada tecnica e quer um cara experiente essa prova vale muito, mas se precisa de um programador pra acrescentar a sua equipe acho que vale mais o perfil do cara pra aprender e desenvolver-se do que exatamente o que ele já fez.

smota wrote:Naaaaaaaaaaaaaaaaaao pergunta isso ... o Paulo vai ficar escrevendo sobre o Hibernate horas a fio eheheheh

hehehe, eu perguntei porque acho que olhar a API (seja qual for ela) é um "hábito sadio", sempre.
Tanto que um bom teste seria apresentar uma API estranha para o candidato e pedir à ele que faça algo útil com ela.

Tb nunca selecionei ninguem, mas fiz muitas entrevistas.

e acho q colocar o cara para programar é uma péssima ideia, ainda mais se o cara estiver desempregado. Pois, pode acontecer do cara ser um ótimo profissional, mas devido a sua situaçao atual e a entrevista em sí, pode fazer alguma besteira, ou simplesmente não programar da "melhor" maneira.

acho q é melhor ter uma conversa amigavel, com colaboração de ambas as partes, com o entrevistador querendo realmente achar um profissional qualificado e não querendo deixar o entrevistado em má situacao.

Obs: tb acho q consultar o doc é um "hábito sadio". E não a diferença entre o bom e o mal profissional. Ao contrario do q o nosso amigo disse, deve contar pontos a favor.

marciolx wrote:Tanto que um bom teste seria apresentar uma API estranha para o candidato e pedir à ele que faça algo útil com ela.

Taí, gostei

Melhorando um pouquinho a idéia, se a vaga pretende que o cara mexa com uma API especifica (Servlets, JDBC, etc), pedir pra ele enumerar alguns defeitos que ele vê na API também faz o cara pensar bastante. E se ele afirmar categoricamente que a API não tem defeitos, é bom que ele (e vc, lógico

) tenha argumentos pra provar isso.

smota wrote:O importante pra mim é o cara saber MUITO lógica de programação, saber se virar pra aprender a usar ferramentas, conhecer as técnicas existentes e ter idéia de como usar (pra nao demorar muito pra aplicar em um projeto) e por ai vai.

Lógica de programação, por si só, não faz nada. Dá pra pegar a primeira pessoa que aparecer na frente na rua e ensinar lógica de programação em algumas semanas. O que geralmente se quer, mascarado na forma de 'lógica de programação', é habilidade em resolver problemas.

E, infelizmente, não dá pra ensinar qqer um na rua a resolver problemas rápido. Mas, se é assim, então como saber se o candidato sabe resolver problemas? Botar um cubo mágico na frente dele ou fazer pegadinhas de programação não adianta. E é por isso que eu gostei da idéia do Paulo - o cara tem que resolver o problema, não escrever uma tese sobre o modelo MVC.

O Joel Spolsky (http://www.joelonsoftware.com) uma vez postou um artigo muito interessante sobre isso. Não é sobre contratar os melhores programadores que já existiram na face da Terra, é contratar os melhores resolvedores de problemas, que por acaso sabem programar. Eis a URL:

http://www.joelonsoftware.com/articles/fog0000000073.html

Existe um livro interessante que trata do assunto..

IT Problem Management..

http://www.oziel.com.br/ebooks.html

O teste do Paulo é legal, mais depende do contexto.

Se minha empresa ja trabalha com tecnologias XYZ e tem um projeto para iniciar em uma semana, e quero alguem experiênte nelas para iniciar rapidamente os trabalhos, o teste será com elas(não acho legal contratar no desespero mais ja vi isso acontecer).

Caso o desejo seja conseguir alguem para somar a equipe de desenvolvedores, uma pessoa que seja dinâmica e que aprenda rápido.
Eu faria o teste do Paulo porém, acrescentava o seguinte:

Ele teria um caso de uso para resolver e teria liberdade para escolher quais tecnologias usar para isso(assim como o Paulo recomendou), ao final além do programa estar rodando, o candidato deveria justificar cada tecnologia empregada na solução, o porque disso etc. Também seria levado em conta o tempo para resolver o problema, ou seja, ele tb poderia justificar que outra solução seria melhor mais como seria necessário mais tempo ele optou por uma outra solução.

Outro tipo de teste é mostrar um sistema para ele e pedir para que ele aponte os defeitos e indique que soluções devem ser usadas e porque.

Bem nunca fiz teste com ninguem, mais acho que esse levaria em conta a criatividade e conhecimento técnico do candidato.

A teoria toda é muito legal.

Na verdade acredito que o ideal mesmo é o feeling, nada como conversar com a pessoa e sentir até onde ela é capaz de ir.

Aplicar provas, em certas ocasiões é interessante, porém, como já dito anteriormente, o profissional pode estar passando por algum problema no dia e não apresentar o melhor que pode.

Conversando com a pessoa e olhando o nível de evolução dela (o quanto agregou de conhecimento em determinado período), o que já fez anteriormente (se for possível ver o projeto), deve ser uma boa saída pois assim você sabe do que ela foi capaz e tem como estimar o que será capaz de fazer.

Concordam?

Eu nunca avaliei ninguém, porém, creio que esta seja uma idéia pelo menos boa... (desde que quem entrevista tenha os conhecimentos necessários para tanto, o que muitas vezes não acontece).

[]'s

marciolx wrote:

Paulo Silveira wrote:vai ter nenguinho que vai estar no javadoc do jdbc.

isso é [muito] ruim?

opa
soh para deixar claro
consultar o javadoc eh MUITO bom. mas apos quatro horas de programacao, se ele ainda estiver procurando coisas no javadoc da conexao para fazer o insert, ai eh sinal de que: o cara tinha nenhuma ou pouca experiencia com jdbc, ou o cara eh ruim.

ter muita logica de programacao nao adianta muito nao. eu considero que eu tenho bastante, mas se um cara quer um programdor de C++ pra hoje, eu nao vou ser de muita ajuda a ele.

Eu acho que a prova prática deve ser critério de "desempate". Se o cara passou ileso pela análise de curriculo e pelo bate-papo (onde se pode avaliar um monte de coisa, jogando assuntos para vc sentir até onde vai o conhecimento do cara, em design, arquitetura, onde ele busca atualização, etc e tal), uma prova prática cai bem, se vc tem mais opções do que vagas.

Nesse caso, acho que colocar o candidato numa situação adversa é um bom teste. Uma aplicação mal-desenhada, para o candidato "resolver" o problema, e vc avaliar como ele se comporta. Talvez até num micro lento, só pra sentir a paciência do cara!

Acho que colocar o candidato pra fazer uma aplicação "do zero" é fria, todo mundo com um minimo de material na mão não começa nada do zero. Isso pode atrapalhar a avaliação.

Notícias, artigos e o maior fórum brasileiro sobre Java