Como posso eliminar rapidamente os codificadores "copiar e colar"? [fechadas]

Preciso de uma maneira de filtrar currículos de pessoas que simplesmente copiam e colam o código e depois esperam que funcione, e, se funcionar, fazem o check-in. Tudo isso acontece sem ter um entendimento (ou cuidado) para entender o restante do código no sistema.

Claro que sei que copiar e colar código faz parte do aprendizado de um novo objeto, controle, etc ... mas como saber se isso representa 70% (ou mais) da carreira de desenvolvimento?

Encontrei alguns caras de nível sênior, talvez cujas habilidades sejam tão desatualizadas ou irrelevantes para o projeto, que tudo o que eles fazem é o google, copie e cole algum código sem pensar na solução como um todo. Como resultado, temos uma quebra de JSON, AJAX, retornos de chamada, ASMX, WCF e postbacks no mesmo projeto. É claro que não há coerência ou lógica por trás de onde cada tecnologia está sendo usada.

Na pior das hipóteses, esse tipo de desenvolvedor cria problemas de segurança e vetores para ataque.

Questão

Como você recomendaria que eu filtrasse pessoas que têm um histórico de programação ruim? Posso fazer isso no nível do currículo? Caso contrário, como faço isso durante a entrevista.

Encontrei alguns caras de nível sênior, talvez cujas habilidades sejam tão desatualizadas ou irrelevantes para o projeto, que tudo o que eles fazem é o google, copie e cole algum código sem pensar na solução como um todo. Como resultado, temos uma quebra de JSON, AJAX, retornos de chamada, ASMX, WCF e postbacks no mesmo projeto. É claro que não há coerência ou lógica por trás de onde cada tecnologia está sendo usada.

Não acho que as habilidades de seus desenvolvedores sejam o problema. Seu problema está em outro lugar, talvez um líder de equipe ou arquiteto que não tenha autoconfiança para "incentivar" melhores disciplinas de codificação ou uma equipe de gerenciamento que não entenda a importância do gerenciamento da dívida técnica e não desenvolvedores o tempo e os recursos para fazer isso. Sua empresa possui revisões de código?

Liderança pode ser o problema, não copiar e colar desenvolvedores.

A maneira de eliminar programadores que não podem programar é defini-los como um exercício prático de programação como parte da fase de triagem ou entrevista. (O último é provavelmente melhor porque você pode controlar o ambiente para evitar trapaças.)

Mas não acho que isso realmente resolva o seu problema.

... temos uma quebra de JSON, AJAX, retornos de chamada, ASMX, WCF e postbacks no mesmo projeto. É claro que não há coerência ou lógica por trás de onde cada tecnologia está sendo usada.

Na IMO, o verdadeiro problema aqui é que sua equipe não está revisando o código interno o suficiente e não está desenvolvendo um "manual de instruções" de soluções preferidas para problemas conhecidos. Isso é parcialmente um problema de cultura, parcialmente um problema de comunicação e (provavelmente) parcialmente um problema com os prazos do projeto.

Outra questão é que o projeto normalmente tem uma vida útil longa e, durante essa vida útil, novas tecnologias / técnicas aparecerão e as antigas provavelmente cairão em desuso. Se você deseja evitar o uso de tecnologias / técnicas "café da manhã para cães", é necessário:

• definir e aplicar uma lista de tecnologias / técnicas que podem ser usadas por projeto, ou
• invista esforços para atualizar as tecnologias usadas por um projeto.

Contrate pessoas em estágio de 3 meses. Demita-os se sugam.

Se você não inspeciona, não pode esperar. Revisões de código, ferramentas de auditoria. Um servidor de IC pode executá-los automaticamente.

Faça perguntas reais em suas entrevistas, como nas perguntas do código real.

Faça com que eles escrevam código no quadro branco.

Se você é um gerente não técnico, não é qualificado para julgar isso.

Se você não for qualificado, procure um consultor profissional sênior respeitável para fazer o teste. Pergunte ao seu pessoal existente e aos concorrentes de negócios se eles conhecem uma pessoa 100x produtiva. Pague-os para fazer a entrevista.

Se você deseja administrar um hospital sem uma cirurgia, vá em frente.

Passei os últimos anos entrevistando pessoas e descobrindo que 90% dos candidatos simplesmente não podem programar. Minha técnica de entrevista para determinar a programação é fornecer ao candidato um resumo muito simples e deixá-lo resolvê-lo usando um marcador e um quadro branco.

Os modos de falha incluem:

criando um design e implementando algo diferente. Esses candidatos são rejeitados porque são perigosos para uma equipe. não seguir especificações, escrever bugs etc ...

Não ser capaz de inventar um design. Um número surpreendente de candidatos "experientes" precisa de uma especificação para incluir o design da implementação.

sem conhecer a linguagem de programação, apesar da experiência em reivindicar currículo

Não fazendo perguntas adicionais para extrair especificações mais completas.

Não ser capaz de explicar as decisões de design. Este é importante. Se alguém não pode explicar o porquê, cada vez que faz isso de maneira diferente, perde-se a consistência.

O resultado final foi que passei muito tempo entrevistando, e não recrutando com muita frequência. no entanto, a equipe de desenvolvimento era muito boa e tinha o respeito total de toda a empresa e foi entregue!

Eu sugeriria ao FizzBuzz que Jeff Atwood menciona no post em http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html .

Escreva um programa que imprima os números de 1 a 100. Mas, para múltiplos de três, imprima "Fizz" em vez do número e para os múltiplos de cinco, imprima "Buzz". Para números múltiplos de três e cinco, imprima "FizzBuzz".

Eu faço três perguntas da entrevista

1. Escreva uma lista vinculada capaz de armazenar algum tipo numérico em java sem importar nada da estrutura de coleções
2. Escreva um código mostrando como você pode adicionar / remover nós dessa lista
3. Escreva um código mostrando como você pode obter o máximo / mínimo dessa lista

Vi pessoas concluindo isso em 5 minutos e vi pessoas lutando por 30 minutos antes de desistir.

Você não pode fazer isso no nível do currículo, pois eles têm essencialmente um tempo infinito para escrevê-lo, mas pode fazê-lo em uma entrevista por telefone se fizer algumas perguntas que exijam conhecimento técnico sobre o que eles fazem. Isso dá a você a resposta (boa ou ruim) e quanto tempo eles levaram para chegar lá.

Quando em uma entrevista, faça-os escrever código. É a única maneira de saber se eles podem programar de verdade. Simplifique o problema, forneça a eles um computador com conexão à Internet e o IDE que você usa instalado, faça qualquer pergunta (exceto gimme-hte-codez) e observe como eles funcionam.

EDIT: Para análise post-mortem, parece que o PMD possui um detector de copiar / colar para encontrá-lo: http://pmd.sourceforge.net/cpd.html

Simples

• (1) Tranque-os dentro de uma sala + oxigênio livre.
• (2) Forneça a eles um PC com conexão à Internet + IDE de escolha + acesso a Alimentos.
• (3) Tenha wireshark ou método semelhante para registrar todo o tráfego de entrada e saída.
• (4) Dê-lhe uma tarefa mediana.
• (5) Examine todo o tráfego HTTP, após a conclusão da atribuição.
• (6) Se o sujeito tiver copiado grandes partes do código-fonte, encerre o Assunto .....

Editar:

Como criador das coisas7, como indicado, em termos práticos, pode-se fazer uma captura de vídeo (captura de tela).

Se você deseja "eliminar" os codificadores ruins, pode tentar, por exemplo, a Matriz de Competências para Programadores (útil, mas que não se aplica a todas as áreas possíveis - é claro que você pode criar suas próprias) ou codility.com (as tarefas são muito boas e Isto economiza muito tempo).

Geralmente, contratar bons codificadores é difícil e geralmente requer muitos anos de prática. Você pode iniciar seu próprio banco de dados de perguntas da entrevista, não apenas perguntando sobre codificação, mas também com matemática, lógica, para não mencionar questões de motivação.

Eu diria que o problema com seus candidatos não é que eles não podem programar, mas que não têm a menor ideia de usar a ferramenta certa para o trabalho. Minha sugestão é uma pergunta de ensaio em que seriam fornecidos requisitos de alto nível para um novo sistema e solicitados a fornecer uma arquitetura e justificar suas escolhas de componentes. Mas mantenha o FizzBuzz para os candidatos que não podem codificar sem um navegador.