Como reconhecer um bom programador? [fechadas]

Nossa empresa está procurando novos programadores. E aí vem o problema - há muitos desenvolvedores que parecem realmente ótimos na entrevista, parecem conhecer a tecnologia que você precisa e tem uma boa experiência profissional, mas após dois meses de trabalho, você descobre que eles não conseguem trabalhar uma equipe, escrever algum código leva muito tempo e, além disso, o resultado não é tão bom quanto deveria ser.

Então, você usa algum teste formalizado (existe algum?)? Como você reconhece um bom programador - e uma boa pessoa? Existem perguntas simples 'boas' que podem revelar os problemas futuros? ... ou é apenas sobre o seu 'sentimento' sobre a pessoa (isto é, principalmente sua experiência) e experimentá-la?

Edit: De acordo com a resposta de Manoj, aqui está a pergunta relacionada à tarefa de codificação na entrevista de emprego.

Faça com que eles falem sobre o que está interessado. Ainda não conheci um desenvolvedor que seja realmente apaixonado por falar em programação, mas que não possa realmente codificar. Eles podem muito bem existir, é claro - e sua entrevista deve verificar também a competência -, mas a paixão é um bom indicador na minha experiência. (Observe que isso não é o mesmo que ser capaz de "falar a conversa" em termos de chavões).

Pergunte a eles o que eles não gostam em seu idioma ou plataforma favorito. Como eles consertariam as coisas? O que eles gostariam de ver na próxima versão? Eles têm projetos de hobby? Se eles têm um blog, leia-o. Verifique a presença online geral.

Contratar pessoas boas é difícil .

Foram necessários alguns erros reais para eu melhorar. Você começa a confiar muito mais no trato intestinal após as primeiras vezes em que não confia e se arrepende.

Tenho um grande respeito pelas perguntas na tela do telefone de Steve Yegge e usei isso como base para entrevistar pessoas com algum sucesso.
Também acho que me tornei melhor em entrevistar pessoas depois de ler o guia de Joel para entrevistas de guerrilha (agora na versão 3.0, que está à frente da versão para a web e tudo mais, só precisa ser bom).

Também existem 57 outras perguntas (em 20/11/2008) no Software Engineering Stackexchange marcadas com entrevista e algumas delas parecem muito relevantes, portanto, verifique-as.

Algumas ideias:

• Faça várias perguntas abertas de vários ângulos diferentes:

  • Revise algum código. O que foi identificado? Erros técnicos, inconsistências de estilo, comentários, algoritmos, manutenção, etc ...
  • Escreva algum código. Procure processo, prova de balas, legibilidade etc.
  • Crie um design de alto nível para um sistema pequeno. Procure a compreensão do problema, abordagem, comunicação, integridade, detalhes.
  • Descreva o processo de desenvolvimento de software. Procure por design, colaboração, revisão, teste, bons / maus hábitos e experiência geral.

• Escolha algo - qualquer coisa - que o candidato afirme conhecer bem. Faça uma pergunta simples e, com base na resposta, faça outra, um pouco mais detalhada, e continue "cavando" até atingir o limite de conhecimento do candidato. Isso lhe dá uma idéia de:

  • Honestidade: ele / ela sabe tanto quanto reivindicado?
  • Profundidade do conhecimento: quão bem ele aprende as coisas?
  • Comunicação: quão bem ele / ela explica algo desconhecido para você? O processo de pensamento é lógico?
  • Reação a situações estressantes: quão duro ele / ela trabalha para responder? Ele / ele finge? O inevitável "não sei" é fácil ou difícil?

• Pergunte como o candidato lidou com várias situações de empregos anteriores: o trabalho em equipe, projetos vencidos, depuração, etc . As respostas são positivas ou negativas? Apaixonado? Inteligente? Arrogante?

Acho que os melhores candidatos estão entusiasmados, experientes, confiantes, mas educados e, o mais importante, presentes . Você precisa saber que tem alguém lá dentro. :-)

Para reconhecer um bom programador, você precisa ser um bom programador. Isso significa que você precisa conhecer muito bem a programação para ver o que foi dito e feito na entrevista e precisa saber quais perguntas fazer.

Vi candidatos que receberam a resposta errada na entrevista, mas a explicação deles mostrou que eles conheciam o assunto (e, portanto, poderiam facilmente obter a resposta certa pesquisando na rede). Para ver isso, você precisa conhecer muito bem o assunto sobre o qual está fazendo perguntas.

Outra coisa é evitar perguntas sobre detalhes que poderiam ser facilmente pesquisados ​​no Google. Essa pergunta mostra apenas o quão bom é o candidato para se lembrar das coisas, não se ele realmente tem o conhecimento e a compreensão que você está procurando.

Minha recomendação é obter ajuda de alguém que conheça bastante programação e tenha boas habilidades de pessoas para ajudar nas entrevistas.

Edit: Eu também escrevi um comentário sobre entrevistas aqui .

Lembre-se de que a capacidade de programação não é tudo. Você poderia ter o melhor programador do mundo trabalhando para você, mas se eles odeiam trabalhar com outras pessoas, você não as achará muito útil.

Uma personalidade de programador deve estar no topo da lista do que a maioria dos empregadores parece classificá-la. No meu local de trabalho atual, eles são muito cuidadosos ao contratar o tipo correto de pessoa.

As pessoas geralmente podem aprender a ser melhores programadores, as pessoas geralmente não podem aprender a ser melhores seres humanos.

Faça-os codificar. Forneça um problema que possa ser resolvido em, digamos, 4 ou 5 horas e inspecione o código em busca de documentação, estilo de codificação, como ele planejou a solução antes de começar a codificar etc. Ele não precisa resolver o problema. E como Jon Skeet mencionou, faça-os falar sobre programação, sua linguagem de escolha e coisas assim. Você pode reconhecer a paixão de um bom programador. Pergunte quantos sites relacionados à programação eles seguem - como stackoverflow. Os blogs que eles seguem também podem ser um bom indicador.

Eu gosto da resposta da paixão. Eu acredito que você tem que ser apaixonado pelo que trabalha para realmente ser muito bom nisso.

Um bom programador programa ao lado, além do trabalho (de vez em quando, pelo menos). Ele / ela gosta de resolver problemas de programação. E quando ele / ela não consegue encontrar um programa que resolve uma necessidade específica em casa, ele normalmente tenta resolvê-lo.

Mas existem vários tipos de programadores.

• Você tem quem gosta de documentar. Pessoalmente, odeio documentar. Mas documentar o que é feito pode ser importante.
• Você tem os "hackers". Aqueles que estão empenhados em resolver um quebra-cabeça complexo onde, se você procurar no Google, provavelmente não encontrará uma solução. Eles podem resolver "qualquer" problema, desde que tenham as ferramentas necessárias.
• Você tem aqueles que se educam para ser programadores apenas porque o mercado era bom para ser contratado para programação. Geralmente são medíocres porque não têm paixão.
• Você tem pessoas excelentes em se comunicar e elas "podem resolver qualquer coisa", mas, depois que conseguem o emprego, ficam com todos os outros para obter ajuda para o problema que estão resolvendo.

Se você encontrar o "hacker" que também documenta muito bem e possui excelentes habilidades de comunicação, eu acredito que você ganhou o jackpot.

Ah, e uma última coisa. Você provavelmente não quer um programador que tenha ambições de líder, pois ele usará apenas a programação para iniciar. Isso significa que você perderá esse recurso mais cedo ou mais tarde.

Uma pergunta que eu faria ao contratar um programador seria: "Por que você se educou como programador?". Seria um sorteio se eles hesitarem lá.

Essa é a minha opinião.

Um amigo meu está trabalhando em uma empresa onde eles têm uma etapa adicional no processo de contratação: após a triagem e a entrevista iniciais, o candidato precisa "testar o trabalho" por alguns dias. Ele me disse que, embora um candidato tivesse todas as habilidades e talentos necessários, eles não o contrataram porque ele não era uma pessoa agradável de se trabalhar.

É muito difícil reconhecer um programador apenas com base em uma entrevista de emprego.

Algumas coisas que decidem que alguém é um bom programador são:

• capaz de trabalhar em equipe
• escreve um bom código que seja compreensível e mantenível
• é capaz de aprender sobre novas tecnologias

Então você tem algumas dicas que você pode descobrir em uma entrevista:

• O candidato conhece uma linguagem de tecnologia / programação ou conhece várias? Se ele conhece idiomas diferentes, parece capaz de aprender coisas novas e, possivelmente, conhece as desvantagens de sua atual tecnologia / idioma preferido. Portanto, peça conhecimento além da tecnologia que você usa em sua empresa.
• Peça projetos nos quais ele já trabalhou, especialmente projetos de hobby e de código aberto. Os projetos de hobby mostram que ele gosta de programar e faz isso mesmo em seu tempo livre (e, dessa maneira, melhora suas habilidades). Em um projeto de código aberto, você pode procurar o código que ele escreveu. Se o projeto envolver mais de uma pessoa, você poderá obter dicas sobre as habilidades de sua equipe. Em um projeto de sistema operacional, você pode consultar os arquivos da lista de discussão para saber mais.

Você poderia realizar algum teste na entrevista.

Mas muitas vezes também há um problema com o próprio ambiente de trabalho. Certamente isso pode não ser o caso em sua organização, mas é bastante comum no setor de software que a dívida tecnológica se torne muito grande. Então, quando você contrata novas pessoas, não ajuda muito se elas são boas ou não, por causa da dívida. Maximizar a legibilidade e a compreensão do código do seu programa ajuda os recém-chegados a trabalhar.

Muitas pessoas também são capazes de cooperar, mas às vezes não há como cooperar. Por exemplo, se todas as pessoas são desenvolvedores, elas devem fazer seu trabalho. Bem, eles fazem. Mas você tem um arquiteto, que dirige o projeto de desenvolvimento e mantém reuniões e tal? Os desenvolvedores normais podem achar que não têm o mandato necessário para iniciar reuniões e podem pensar que interromper outras pessoas de vez em quando não é o caminho.

A comunicação entre si não deve ser o objetivo final. Quanto menos comunicação for necessária, melhor, mas apenas se menos for possível. Menos se torna possível se você tiver um arquiteto. A quantidade total de comunicação pode permanecer em um bom nível, mas você obtém mais resultados para a mesma quantidade de comunicação.

primeiro começo com o material habitual da entrevista, considero muito importante ver se a pessoa na minha frente vale alguma coisa e determinar suas habilidades e conhecimentos.

Depois disso, uso algumas técnicas no campo de Java, como discutir alguns princípios, principalmente extraídos do Effective Java.

Nesta fase, quando penso que posso ter um bom programador diante de mim, dou a ele um pedaço de código para revisá-lo. O que eu quero ver é que ele pode identificar as partes perigosas do código, dar algumas dicas sobre melhorias, encontrar armadilhas no desempenho em vários threads E que ele pode distinguir entre observações importantes e "observações de gosto". Tudo isso me ajuda a encontrar um funcionário mais eficiente.

mas no final sempre lembro que contratar é uma espécie de jogo ... muito difícil antecipar ...

Sei que isso não responde ao que você está perguntando, mas eu recomendo, sempre que as leis o permitam, contratar sempre temporariamente no início (duas semanas ou um mês, dependendo do trabalho). Se a pessoa vale a pena, ela não se opõe, além de ser uma salvaguarda para vocês dois (você pode deixá-la ir e ela pode acabar não gostando do trabalho e saindo).