Qual é a melhor maneira de avaliar novos programadores? [fechadas]

Em relação à seleção de candidatos, costumo ir com um plano de três etapas:

• Teste regular com FizzBuzz- como questões de codificação e muitas questões de conhecimento onde eles têm que dar exemplos codificados. Dependendo da posição, pode ser princípios OO, princípios de design SQL, etc. Eu incremento as dificuldades de perguntas através do teste para ver até onde elas podem ir. A ideia não é realmente ter todas as perguntas respondidas (se o fizerem, melhor), mas também ver se elas podem reconhecer quando não sabem alguma coisa. Confiança é essencial, e eu não quero ter alguém mentindo para mim na minha equipe.

• Retornar ao teste com o candidato e discussão sobre as respostas. Possível extensão das perguntas para atingir os limites do candidato. Isso pode ser extenso e, quanto mais extenso, melhor.

• Última parte, mas não menos importante, A revisão do código . Eu peço ao candidato para trazer um pedaço de código (eu geralmente espaço o teste / discussão anterior e esta revisão por alguns dias, para deixá-los escrever e polir um pedaço de código). Em seguida, fazemos uma revisão regular do código com duas pessoas: uma pessoa que trabalhará diretamente com o candidato e a pessoa que revisou o teste com o candidato anteriormente. Em relação à revisão de código, você pode ler this article de JohnFX .

Ao final de tudo isso, você deve ser capaz de decidir se quer que esse candidato faça parte de sua equipe ou não.

Comece por dar-lhes FizzBuzz para resolver . Isso deve eliminar o pior deles.

Em seguida, algo um pouco mais difícil - por exemplo, como reverter uma string sem incorporar funções de biblioteca. Peça-lhes para conversar enquanto resolvem para ver qual é o seu processo de pensamento.

Você pode continuar dando problemas mais difíceis se eles acharem isso muito fácil, até que você esteja convencido de que eles podem andar pela caminhada e não apenas falar a conversa.

Apenas procure paixão pelo trabalho.

Para citar Joel, procure pessoas que sejam "inteligentes" e realizem tarefas. "

O resto não importa

Baseado em meus 25 anos de programação (que, reconhecidamente, inclui apenas 5 ou 6 instâncias de contratação de outros programadores):

Indicadores positivos:

• Apaixonado por tecnologia

• Programas como hobby

• Falará sobre um assunto técnico se for incentivado

• Significativos (e muitas vezes numerosos) projetos paralelos pessoais ao longo dos anos

• Aprende novas tecnologias por conta própria

• Opinião sobre quais tecnologias são melhores para vários usos

• Muito incomodado com a ideia de trabalhar com uma tecnologia que ele não acredita estar "certa"

• Claramente inteligente, pode ter ótimas conversas em vários tópicos

• Iniciou a programação muito antes da universidade / trabalho

• Tem alguns "icebergs" ocultos, grandes projetos pessoais sob o radar CV

• Conhecimento de uma grande variedade de tecnologias não relacionadas (pode não estar no CV)

Indicadores negativos:

• A programação é um trabalho diário

• Não quer mesmo falar em "talk shop", mesmo quando for incentivado a

• Aprende novas tecnologias em cursos patrocinados pela empresa

• Feliz em trabalhar com qualquer tecnologia que você tenha escolhido, "todas as tecnologias são boas"

• Não parece muito inteligente

• Iniciou a programação na universidade

• Toda a experiência de programação está no CV

• Focado principalmente em uma ou duas pilhas de tecnologia (por exemplo, tudo a ver com o desenvolvimento de um aplicativo java), sem experiência fora dele

Além disso, sugiro:

• O teste FizzBuzz (ou algo parecido para testar a capacidade básica de escrever um algoritmo.
• Versão mais difícil do teste FizzBuzz (para levá-los ao ponto de falha ou quase-falha).
• Discuta o código deles e veja se eles estão dispostos a se auto-criticar e procurar melhorias (o que eles provavelmente não tiveram tempo fazer em um curto teste no local) como:
  • bons nomes de variáveis (experientes codificadores experientes usam variáveis em produção como "flag" (WTF ??)
  • modularização.
  • Antecipando problemas e fazendo "codificação defensiva"
• A vontade de ver "falhas" como oportunidades de melhoria. Eu acho que os melhores codificadores sempre olham com firmeza para falhas em seu código anterior. Eles não são tão egocêntricos quanto a achar que encontrar uma falha é uma afronta pessoal. Eles vêem isso como uma oportunidade para fazer melhor. (Aqueles que não conseguem enxergar as falhas com firmeza, ficam impressionados quando vêem uma falha (e ficam super confiantes ou, para evitar isso, ignoram as falhas).
• Eles podem depurar?
• Eles podem fazer o teste de unidade? (Eu conversei com muitos programadores que dizem "QC faz isso". Eu não estou falando sobre Testes, estou falando de testes: você escreve uma função, funciona? Ela faz esforços razoáveis para lidar com problemas prováveis (entrada NULL, etc)? Se você não pode fazer isso, como você sabe quando você está feito?
• Eles têm boa capacidade de comunicação? (no mínimo: boa compreensão e auto-conhecimento sobre quando eles entendem e não entendem e disposição para dizer "eu não entendo, por favor explique de novo".

Grande parte do resumo acima é de Como identificar um bom programador , que é um ótimo artigo, focou um pouco mais em indicadores de alcance mais longo. Isso definitivamente confirma minhas intuições e experiências. Também é um monte de coisas (como "paixão") que normalmente não são mencionadas em uma lista de verificação de "o que é um bom programador".

Avaliar inteligência de programação é uma forma de teste de Turing. Portanto, não existem (atualmente) procedimentos de avaliação de forma fechada que funcionem com segurança. É preciso que programadores inteligentes reconheçam outros programadores inteligentes, mas apenas com alguma probabilidade razoável.

Suas chances serão melhores se você tiver entrevistadores em sua equipe que possam sentir o cheiro de neve, e instintivamente não gostarem de trabalhar com pessoas estúpidas (mesmo as que têm boa aparência, têm currículos impressionantes e podem soltar todas as soluções enlatadas comuns) da memória).

(Uma metodologia de possibilidade que ajudaria a qualidade do stackoverflow como um efeito colateral é desenterrar questões antigas de stackoverflow, relacionadas de alguma forma às suas exigências de trabalho, mas que na sua opinião têm respostas inferiores; pergunte ao entrevistado como eles responda, e peça-lhes que o publiquem se for uma boa resposta. Semelhante a uma recapcha para o OCR de origem coletiva.)

Dê a eles um problema, de preferência um associado ao domínio do problema no qual eles trabalharão, e peça que eles discutam como eles abordariam o problema. Você pode fazê-los apenas discutir, pseudo-código ou escrever pedaços de código real, dependendo de como você está confiante em seu nível de habilidade

Por exemplo, se sua organização fez conferências, peça-lhes que descrevam como elas codificariam um sistema de registro on-line seguro. Eles devem ser capazes de cobrir alguns dos princípios básicos e fazer boas perguntas sobre exatamente o que precisa ser implementado. À medida que você interage, você deve ser capaz de determinar se eles serão adequados para sua organização e para o papel que você precisa preencher.

Eu não sou um grande fã de testes de programação e quebra-cabeças. Embora possam ser divertidos para algumas pessoas, elas também podem incomodar e / ou estressar outras pessoas, incluindo pessoas que podem ser as melhores para sua equipe. Além disso, informações sobre muitos desses testes estão prontamente disponíveis on-line e encorajarão o preenchimento de testes e outras táticas que diminuiriam sua viabilidade para avaliar a capacidade do programador.

Lendo esta pergunta e algumas das respostas que recebeu me motivaram a escrever um artigo que eu acho que pode ser de interesse:

Práticas de recrutamento estranhas ao contratar desenvolvedores de software

Ok, então o título do artigo é lixo, mas o artigo chega ao cerne do problema. Não é o problema do candidato que você escolheu para entrevistá-los, não importa quão inapropriados eles sejam para o papel que você tem em mente. Se você não conseguiu definir um procedimento de contratação bem-fundamentado para permitir que você encontre as gemas em bruto, então você vai apenas ter que viver com as conseqüências, e sim, isso significa conseguir alguns candidatos que poderiam nunca encontre suas expectativas. Filtrar seus candidatos com base em suas cartas e currículos requer que você primeiro, peça a seus candidatos que escrevam uma carta sobre si mesmos e o que eles querem da função e, em seguida, observem como o currículo está escrito. Se você tiver apenas um ou dois candidatos em potencial para entrevistar, provavelmente já fez a pré-triagem corretamente. Se você não conseguir decidir entre seus candidatos nesse estágio e ainda tiver cem aplicativos, provavelmente terá definido suas expectativas muito baixas ou não terá sido agressivo o suficiente no processo de filtragem.

Quando você eventualmente encontrar os 1 ou 2 candidatos que você considera realmente valer o seu tempo, não pergunte a um punhado de perguntas do testador, mas invista tempo para conhecer essas pessoas e se envolver em atividades abertas. discussões sobre engenharia de software em geral. Você aprenderá mais com uma abordagem casual sobre o candidato do que com a situação de entrevista tradicional (e de certa forma contraditória). Além disso, não basta se contentar com uma única entrevista, mas sim tratar seus principais candidatos em várias reuniões em que a discussão aberta é usada e onde o candidato pode se encontrar com seus futuros colegas. O tempo nunca é desperdiçado, uma vez que candidatos inadequados não vão prosperar muito bem em uma discussão altamente técnica, e mostrarão suas falhas muito rapidamente à medida que baixam a guarda. Se você gasta o tempo e ainda não tem uma contratação, você teve a oportunidade de aprender mais sobre as suas necessidades e pode continuar melhorando seu processo de entrevistas com base no que aprendeu com as entrevistas "fracassadas". / p>     

Você não disse qual idioma, mas é bastante fácil testar o conhecimento de alguém. Isso também depende do nível que você está procurando, mas há um conjunto bastante grande de perguntas em relação às perguntas da entrevista.

No entanto, você decide realizar sua entrevista, don pergunta àquelas perguntas da entrevista "quebra-cabeças de pensamento lateral" .

Eu sugiro que você vá com uma pergunta do FizzBuzz e contrate o primeiro que passar. Testes adicionais tendem a ser falhos, já que nem todo bom programador abordará um problema como você, ou lidará com uma entrevista sem gaguejar, ou saberá as línguas que você quer ou se preocupará, ou trocarão inteiros sem uma terceira variável (quem precisa disso?) significa, desde que a RAM excedeu 128 bytes?).

Pense nisso. Se a questão do FizzBuzz elimina 199 dos 200, então acaba de eliminar centenas de entrevistas. Você realmente entrevistaria centenas de prospects?

Parece um retorno decrescente após o FizzBuzz. Isso está supondo que 199/200 é até aproximadamente próximo. E presumo que o seu tempo também é valioso ...

Eu não tenho certeza se isso é um comentário ou uma resposta, mas basicamente o que Matthieu disse. Você quer perguntas fáceis e estúpidas que demoram um minuto ou dois (mas não mais que 5) minutos para fazer e devem ser sobre diferentes áreas.

Esses exemplos de perguntas fáceis e estúpidas são uma questão sobre recursão, tal como você tem uma lista e você deve imprimir em ordem inversa sem usar um loop. Uma questão simples de regex se regex é normalmente feito em seu desenvolvimento. Uma pergunta sobre bits e bytes se estiver usando C ++ (escreva um template que aceite char to long e imprima a representação binária. A especialização não é necessária, apenas use sizeof () para descobrir o comprimento do bit)

Deve demorar cerca de < = 3 minutos por pergunta

Pergunte-lhes sobre o desafio de programação mais interessante que eles já tentaram resolver, mas não conseguiram, que abordagem usaram para resolvê-lo, porque não conseguiram resolver e que outra abordagem eles acham que pode resolvê-lo.

Isso é o suficiente para eu julgar as habilidades de um programador como programador.

1. Eles podem defender o que afirmam saber? Eles colocam no currículo como uma habilidade ou algo que fizeram em outro projeto. Veja como eles podem aprofundar o assunto.

2. Eles podem aprender algo novo? Fale sobre um aspecto de alto nível da tecnologia que você está usando ou algo específico para o negócio em que você trabalha e veja se eles conseguem entender o assunto. Eles fazem perguntas inteligentes? Eles podem chegar a uma analogia? É semelhante a algo que eles fizeram em outro setor ou tecnologia?

3. Eles prefeririam estar programando? Não precisa ser o número um em sua lista, mas eles têm que mostrar preferência por escrever código. E eu quero dizer realmente escrever código e fazer algo, não ficar sentado e falar sobre isso ou desenhar no quadro o dia todo. Não para minimizar o planejamento ou para promover o código cowboy, mas você precisa ter código eventualmente. Evite aqueles que evitam o teclado. Esta não é uma posição de gerenciamento.

Você pode fazer algumas pontuações em uma escala de uma a dez ou confiar em ser capaz de cheirar sua própria espécie.

Se isso faz você se sentir melhor, os maus programadores existem em praticamente todos os países. Como eliminá-los é o problema.

Primeira remoção de ervas daninhas é o currículo. Uma coisa que eu procuro é muita experiência de linguagem reivindicada e nada para descrever o que eles fizeram naquela língua. Eu vi currículos que praticamente afirmam que eles sabem todas as línguas já inventadas e, ainda assim, sua experiência mostra que eles realmente só trabalharam com Access e Visual Basic. Aqueles vão para a direita no lixo. 10 páginas continuam no lixo (especialmente dez currículos de pessoas com menos de dois anos de experiência que recebi). De recém-formados com pouca experiência, você tem que ser muito exigente sobre como eles se apresentam. Os melhores candidatos são cuidadosos com seus currículos, eles não têm erros. Você está realmente procurando alguém que se importe tão pouco que ele não se preocupou em revisar seu currículo?

Currículos preparados profissionalmente também vão para o lixo. Depois de ler centenas de currículos, você pode selecioná-los, pois eles usam exatamente o mesmo fraseado. Você não pode confiar no conteúdo de um currículo preparado profissionalmente e sabe que a pessoa não fez sua própria preparação. Esse é o tipo de pessoa que vai depender dos outros para resolver seus problemas para ele, você realmente quer isso em uma posição de programação?

Procure por itens que façam a pessoa se destacar pelos escolhidos. É mais difícil, claro, com os que estão fora da escola, mas procurem por realizações, contribuições para o código aberto, etc.

A próxima saída é a entrevista por telefone. Pergunte sobre conceitos básicos relacionados ao trabalho real que você tem. Se as pessoas não tiverem conhecimento básico dos conceitos que você precisa, não vale a pena se incomodar em fazer uma entrevista pessoal. Os jovens muitas vezes acham que isso é injusto, pois eles podem pesquisar tudo na Internet, mas a verdade é que eu nunca encontrei um bom programador que teve que procurar tudo na Internet. Você deve ter algum conhecimento de sua profissão que você não precisa procurar cada vez.

Após a entrevista por telefone, você deve escolher os melhores 4-5 candidatos e entrevistar. Claro, se você tiver apenas 1-2 bons candidatos, não se incomode em entrevistar pessoas que você já eliminou. Agora você vai fazer as perguntas difíceis e ter uma ideia de como elas abordam os problemas. Eu nunca usaria o teste fizzbuzz porque ele é muito conhecido, então as respostas não dizem nada. Em vez disso, crie alguns problemas com sua própria base de código. Eu poderia dar-lhes uma exigência e um pedaço de código e perguntar-lhes se o código atende ao requisito e, se não, por que não e o que eles podem fazer para atender ao requisito. Gostaria de pedir-lhes que descrevessem o problema de programação mais difícil que tiveram para resolver e que medidas tomaram para encontrar a resposta. Gostaria de fazer mais algumas perguntas técnicas aprofundadas. Lembre-se de que você está tentando entender a competência técnica, a capacidade de solucionar problemas e depurar e a capacidade de se adequar à equipe existente. Eu também faço perguntas que eles provavelmente não sabem a resposta para julgar o quão bem eles lidam com o estresse, é um trabalho estressante, eu não quero alguém que desiste da entrevista porque o estresse do trabalho é maior do que o estresse da entrevista. . Busco pontos strongs em áreas em que atualmente estamos enfraquecidos e a capacidade de trabalhar em equipe e de nos apresentar aos clientes (nossos desenvolvedores lidam bastante com os usuários), sua lista pode ser diferente.

Os candidatos devem ter um problema do mundo real para resolver com a liberdade de usar qualquer tecnologia.

Se ela sair em cores voadores, ela é In!