Que padrões podem ser esperados dos engenheiros graduados / juniores? [fechadas]

38

É aceitável o estouro de buffer de um desenvolvedor de pós-graduação? Estamos colocando a barra muito alta? Quais são as capacidades esperadas dos engenheiros graduados / juniores?

Contexto:

No momento, estamos recrutando para uma posição de desenvolvedor júnior trabalhando principalmente em C no Linux.

Como parte do processo, exigimos que os candidatos completem um teste de código no seu tempo livre em C.

Até agora, rejeitamos dois candidatos com base no fato de que seu código, apesar de legível e em um caso bastante idiomático, sofria de erros de estouro de buffer devido a gravações de buffer ilimitadas.

[Editar]:

  • Solicitamos explicitamente código de qualidade de produção com verificação de erros.
  • Fornecemos um teste & construir estrutura para os candidatos

[Atualização]:

Como resultado deste tópico e das conversas que tivemos com outros desenvolvedores em pessoa, estamos mudando a maneira como realizamos testes de código e quem direcionamos com nosso recrutamento.

Decidimos que um candidato incapaz de consertar ou entender um estouro de buffer significa que ele seria inadequado para o trabalho que realizamos, em particular, ele levaria mais orientação do que estamos confortáveis. Portanto, ainda rejeitaremos candidatos que não possam, eventualmente, enviar uma amostra de código robusta.

No entanto, implementamos algumas medidas para tornar o processo de recrutamento mais produtivo tanto para nós como para os candidatos.

Em particular:

  • Tornamos nossa expectativa mais explícita, com uma explicação clara do que entendemos por qualidade de produção e um aviso de que o código deve ser robusto com relação a entradas e erros.
  • Agora vinculamos candidatos a recursos em programação defensiva e à biblioteca padrão C na descrição do teste de código.
  • Alteramos nosso público-alvo de desenvolvedores e graduados júnior para segmentar pessoas com alguma experiência relevante.
  • Caso o código enviado falhe de alguma forma, mas caso contrário seria aceito, agora fornecemos um teste mínimo que causa a condição de erro e damos aos candidatos a chance de corrigir seus erros (a menos que o código seja rejeitado por algum outro motivo ). Também vamos apontar linhas / funções problemáticas, se apropriado.
  • O objetivo dos testes em si foi ligeiramente alterado de um filtro de front-end para uma chance de criar uma imagem melhor do candidato, em particular, ele informará nossa discussão por telefone. Dito isso, ainda estamos dispostos a rejeitar apenas com base no código.

[Atualização 2015-07-09]: Andy Davis da Nujob escreveu um artigo interessante e relevante sobre o uso de um teste de código do ponto de vista do candidato, e vale a pena examinar o artigo. Encontrá-lo aqui .

    
por brice 02.08.2013 / 16:09
fonte

7 respostas

109

Eu não acho que você tenha definido a barra muito alta, eu acho que você pode precisar de uma barra diferente.

Acho que os testes de código são úteis para determinar a competência de um candidato, mas não devem ser aprovados / reprovados. Você deve usar os resultados do teste de código para iniciar um diálogo com o candidato.

Se você perceber erros que eles cometeram (especialmente se forem desenvolvedores iniciantes), indique-os e pergunte o que eles fariam de outra maneira ou se eles entenderam o motivo de um problema.

    
por 02.08.2013 / 16:20
fonte
67

Acho que o júnior qualificador é o que faz toda a diferença aqui. Os juniores não devem ser testados em termos de competência, eles devem ser testados quanto à capacidade de aprendizado, curiosidade, paixão, ética e definitivamente humildade. A suposição com um júnior deve ser de que eles não são competentes, é o seu trabalho como senior para fazê-lo.

Obviamente, eles devem ser capazes de escrever código básico como fizzbuzz e ter um conhecimento geral dos conceitos; se você apontou para eles e eles nem sabiam o que era um estouro de buffer, então eu diria que é um não ir, mas eu não espero que um júnior escreva mais de 5 linhas de código sem um bug.

O dia em que você confia na competência do seu júnior é o dia em que o seu deve ser questionado, os juniores devem ser tratados com muita orientação e uma dose saudável de "confiança, mas verifique". Eu era um júnior uma vez e para todos aqueles que estavam lá na época: me desculpe. Lembre-se das coisas terríveis que você fez como júnior? (Por favor, não me diga que foi só eu, você vai me dar um complexo ..)

    
por 02.08.2013 / 16:40
fonte
15

Eu vejo alguns problemas aqui.

O primeiro é supor que um graduado médio em ciência da computação saiba, bem, qualquer coisa. Eles não. Francamente, estou agradavelmente surpreso quando vejo um graduado em ciência da computação que sabe como instalar e configurar o Visual Studio . Caramba, recentemente trabalhei com um cara que afirma ter mais de cinco anos de experiência na pilha da Microsoft escrevendo .NET código que não conseguia descobrir o que TFS era ou como se conectar.

O segundo é o seu pool muito limitado. Também temos candidatos fazendo um teste de programação. Existem cinco "programas" separados que eles precisam escrever. Eles fazem isso em casa e enviam o código. Os testes são extremamente simples (sem banco de dados, sem dependências externas) e podem ser facilmente feitos usando a versão Express do Visual Studio. Os testes são facilmente concluídos por um cara mais velho em cerca de 30 minutos. Note que geralmente só fazemos isso para recém-formados em até três anos de experiência de trabalho verificável.

O que quantificamos é que cerca de 70% dos que receberam o teste simplesmente nunca voltaram para nós. Cerca de 15% de turnos em coisas que não serão compiladas, geralmente devido a erros de sintaxe flagrantes (por exemplo, falta de ; ). Outros 10% compilam, mas não executam as ações necessárias.

Isso deixa um enorme 5%. Neste ponto, nem estamos considerando condições como inserir um caractere alfa como entrada quando um valor numérico é necessário. É puramente dado um conjunto muito limitado de X como entrada, o aplicativo faz a saída apropriada. Além disso, esses números vêm de cerca de 500 candidatos nos últimos quatro anos: mantivemos estatísticas porque queríamos saber.

Se fôssemos examinar mais a estrutura de código e as técnicas defensivas de codificação, como descartar adequadamente recursos não gerenciados ou usar as instruções try .. catch , quase ninguém passaria.

A questão, claro, é por quê?

Por que uma criança com um diploma neste campo de uma universidade de quatro anos não consegue realizar tarefas simples de programação? A resposta é que as faculdades estão completamente fora de contato com as necessidades do negócio e ficam muito atrasadas do que consideramos estado da arte. Há 10 anos, os padrões de codificação eram tais que a segurança era algo que você fazia depois do fato; e os testes de unidade ainda não estavam em voga. Considerando que a segurança de hoje estará melhor na vanguarda de sua mente com todos os recursos ou aprimoramentos. Apenas lembre-se: a maioria dos professores nunca trabalhou nessa área ou não trabalhou nela por muito tempo. Uma vez que você sabe disso, você começa a entender por que eles estão tão atrasados. Pior, alguns desses professores gastam muito tempo com uma tecnologia em particular ( Java , PHP , seja o que for) e não discutem questões fundacionais sérias como estrutura de código ou abordagens aceitáveis (e PORQUÊ!).

Apenas um exemplo paralelo. Um graduado recente estava me contando sobre algumas de suas experiências ao escrever um sistema operacional móvel para uma de suas aulas, mas ele não conseguia explicar, nem em termos básicos, como um servidor da Web funcionava. Ele simplesmente não sabia. 15 ou 20 anos atrás era provavelmente o momento certo para entender como criar um sistema operacional. Hoje não muito. No entanto, essa era uma classe obrigatória, quando uma aula sobre programação defensiva seria muito mais útil para eles e para o mundo exterior.

Então, o que fazemos?

Fora desses 5%, vamos entrevistar um pouco mais para ter uma idéia de sua personalidade e ajuste. Então nós escolhemos os "melhores" com total conhecimento de que vamos gastar cerca de seis meses "reprogramando" eles para se livrar da porcaria que seus professores os preencheram.

    
por 02.08.2013 / 23:12
fonte
5

Eu acho que você está olhando para o problema da maneira errada. O que você deve se perguntar é o seguinte: o que precisamos de um candidato para que ele possa fazer o trabalho? Você deve avaliar corretamente a posição e o que ela implica. Abaixo estão algumas sugestões sobre quando contratar um desenvolvedor júnior e quando não.

Quando contratar um desenvolvedor júnior: - Se houver um excesso de trabalho fácil a ser feito, o que seria um desperdício de tempo para um desenvolvedor mais sênior. - Se você estiver disposto a orientar e treinar essa pessoa nos próximos anos. - Se você está tentando crescer a empresa e quer alguém que vai ficar por um longo tempo. Um desenvolvedor júnior que permanece por apenas um ano seria um desperdício de recursos da empresa, eles fariam pouco para produzir qualquer coisa, e a maioria dos resultados seria em seu próprio crescimento pessoal. - Quando você sentir vontade de gastar dinheiro com o crescimento de alguém. Mais uma vez, a maioria dos benefícios será o que eles aprendem.

Quando não contratar um desenvolvedor júnior. - Quando o trabalho é muito complicado. Neste caso, é apenas fora de sua liga. - Quando você quer economizar dinheiro. Um desenvolvedor sênior deve concluir as mesmas tarefas em uma fração do tempo com resultados de melhor qualidade e, portanto, deve ser sempre mais barato. - Quando o trabalho é terceirizado ou não é suficiente para manter um funcionário ocupado. Em tais casos, seria melhor descarregar parte do trabalho para um contratado particular.

Um último ponto importante. Não contrate um desenvolvedor júnior porque "é tudo o que podemos pagar", ou "é tudo o que estamos dispostos a gastar" quando não são adequados para o trabalho. No final, tudo o que você vai fazer é jogar dinheiro no vaso sanitário. Além disso, uma vez que eles adquiram essas habilidades, eles pedirão as quantias chorudas de qualquer maneira.

Sobre mim:

  • Licenciatura em física com quase nenhum treinamento formal.
  • Dois anos de experiência de trabalho. Então eu sei o que é o processo de aprendizagem.
  • Inicie o desenvolvedor de software. Eu fiz um trabalho muito exigente e vi todos os diferentes níveis de habilidade de vários indivíduos. Muitos deles não conseguem lidar com muito do que eu faço.
por 02.08.2013 / 18:23
fonte
4

Como outros mencionei, posições júnior podem ter pouca experiência com C. Eu, pessoalmente, aprendi apenas brevemente sobre transbordamentos de buffer em C e mesmo que eu pudesse prestar atenção neles, é provável que eu ainda apresentasse alguns (especialmente se atribuição que se presta à criação de buffer overflows). Provavelmente, muitos desenvolvedores júnior serão uma situação semelhante, na qual podem saber sobre estouro de buffer, mas não estão preparados para identificá-los e lidar com eles de maneira extensiva.

Dado isso, eu acho que a resposta apropriada é ter a questão levantada na próxima interação possível e perguntar a eles o que eles sabem sobre o estouro de buffer para testar seu conhecimento geral. Depois disso, diga a eles que você encontrou um deles em seu suposto código pronto para produção. Isso lhe daria uma boa janela para julgar como eles reagiriam à correção e instrução.

Não é comum que um desenvolvedor júnior que saiba menos, mas esteja disposto e seja capaz de aprender e melhorar, tenha mais valor do que um desenvolvedor júnior que sabe mais, mas que não pode ou não vai melhorar?

Dito isto, em um de seus comentários, você mencionou que você entregou a eles testes que indicariam o estouro de buffer no código deles, se eles os tivessem usado. Então, talvez a maior questão seja por que eles não fizeram os testes (se eles fizeram, por que eles entregaram o código com bugs)?

    
por 02.08.2013 / 18:25
fonte
3

Um estouro de buffer é um absoluto no-go. Você poderia ter uma pergunta de código correspondente. Em um tudo o que está errado (pode dar errado) com este pedaço de código, o candidato deve ser capaz de identificar o problema. A questão é se o problema é irrelevante, já que você está executando o clint mesmo assim.

No entanto, em um teste artificial de código de forma livre, eu seria moderado em uma violação como sprintf. Muito pouco tempo (assumido), mente hiperativa, muito grande vontade de apresentar algo funcionando.

    
por 02.08.2013 / 16:43
fonte
2

Acho que você está fazendo a pergunta errada. Não há bar objetivo para ser um programador profissional. Se houvesse, haveria um exame de programação padrão, mas não há. Sua barra individual precisa ser definida com base em quão exigente você pode ser, quanto você pode pagar, quanto erro seu software pode aceitar, e quanto tempo você pode dedicar ao ensino.

Nesse caso, acredito que um buffer overrun provavelmente signifique que esse código, que o candidato apresentou como uma amostra de um trabalho exemplar, falha com uma falha de segmentação em vez de fazer o que você pediu. Então, você deve aceitar um codificador que escreve código que falha com uma falha de segmentação em vez de fazer o que você pediu? Pergunte:

  • Sua organização é capaz de atrair qualquer pessoa que possa escrever código de trabalho?

  • O seu processo de desenvolvimento é suficientemente robusto para que alguém que possa quase escrever código possa escrever código de trabalho com a ajuda de revisão por pares e suporte a testes?

  • Você é capaz de ensinar aos programadores como ser um programador, e está disposto a gastar esse esforço e esperar talvez alguns anos e esperar que o talento interior do candidato se concretize?

por 03.08.2013 / 04:06
fonte