Como verificar ou avaliar as habilidades de depuração de uma pessoa? [fechadas]

Que tipo de habilidades determina uma pessoa capaz de depurar código com facilidade? Algum tempo atrás, meu amigo realizou uma entrevista com um programador relativamente bom. O programador foi contratado. Ele sabia escrever um bom código, entender as estruturas e os padrões de design. O que ele estava perdendo era - habilidades de depuração. Ele não conseguiu depurar e encontrar problemas com o código dele ou de outra pessoa era uma grande dor para ele.

Desde então, estamos pensando em como podemos avaliar ou estimar as habilidades de depuração de uma pessoa.

Portanto, a primeira pergunta é: quais habilidades determinam se uma pessoa pode efetivamente depurar software?

E a segunda: como testar essas habilidades durante a entrevista?

Se a primeira coisa que a pessoa deseja fazer é olhar para o código e percorrê-lo com um depurador, essa pessoa não é uma ótima solução de problemas.

Se você ainda não possui um plano de ação e mergulha no cego do depurador, está basicamente na Páscoa. Isso vale para QUALQUER tipo de solução de problemas.

Em uma situação de entrevista, uma pessoa que pergunta como o sistema opera e pergunta sobre o histórico do sistema seria alguém que poderia ser um bom solucionador de problemas. Uma pessoa que pensa primeiro no sistema e depois na mecânica pode ser uma boa solução de problemas.

Isso vale para qualquer sistema complexo.

Eu argumentaria que a melhor medida de um bom desenvolvedor de software em uma linguagem ou estrutura específica é a capacidade de analisar criticamente problemas complexos e ter boas habilidades de depuração na linguagem ou estrutura. Eles devem ser capazes de demonstrar a depuração de baixo nível, bem como a proficiência em depuração de alto nível com ferramentas de depuração comuns.

Isso significa criar um cenário para eles que demonstre alta aptidão das ferramentas de depuração no IDE escolhido. Você deve procurar coisas como:

• Executando aplicativo ou servidor em área restrita no modo de depuração ou construindo aplicativo com símbolos para depuração

• Disponibilização e demonstração de portas de depuração remota ou depuração de aplicativo sem área restrita que foi criada com símbolos (se aplicável ao idioma)

• Uso estratégico de pontos de interrupção

• Propriedades personalizadas de pontos de interrupção, expressões condicionais em pontos de interrupção (se aplicável ao idioma)

• Uso de expressões ou controles variáveis ​​para monitorar valores ou referências variáveis

• Uso do valor variável ad-hoc ou manipulação de referência ou ponteiro em tempo real

• Demonstrar capacidade de entrar e sair do fluxo do aplicativo

• Avaliação crítica da pilha de chamadas

• Depurando aplicativos multithread e compreendendo isso.

Outras estratégias de depuração sem ferramentas também devem ser demonstradas, como a análise de logs e o código-fonte, bem como a capacidade de executar alguma depuração de baixo nível sem o uso de um IDE também.

Eu diria que destile um bug que você teve no seu sistema para algo que possa ser discutido no contexto de uma entrevista. Ligue o depurador e deixe-o fazer isso.

Faça-lhe perguntas como esta:

1. Como você lida com um problema?

2. Qual é o projeto complexo que você fez e como conseguiu?

3. Quais ferramentas de depuração você usou?

4. Você tem alguma preferência por determinadas ferramentas?

5. Dê um exemplo do seu próprio cenário e pergunte a ele como ele vai lidar com isso?

6. Como você avaliaria sua capacidade de entrar no código de outra pessoa?

Você pode resolver suas preocupações fazendo perguntas. Sempre existe o risco de ele ser ou não bom em certas habilidades. Mas se ele é um bom aluno, isso ajudará muito.

Se você quiser ver se um programador pode depurar, forneça o código a ser corrigido. É a mesma abordagem se você quiser ver se eles podem escrever código. Dê a eles um problema e peça que escrevam código.

Agora, estou confuso sobre esse programador que não tem problemas para escrever código, mas falha de maneira notável quando solicitado a depurar. Essa pessoa regurgita exemplos de código ou apenas adere a áreas que possui experiência como ler e gravar em um banco de dados? A menos que eles acertem o código da primeira vez, eles não podem corrigi-lo?

Talvez a pessoa simplesmente não goste da depuração e não faça nenhum esforço? Eu não sou bom nisso, então pare de me pedir para fazê-lo - desamparo aprendido.

Trabalhar em uma base de código existente requer examinar o código, a documentação e, possivelmente, fazer algumas anotações e desgins.

Eu sei que consideramos a depuração como a correção do código de produção que falhou, mas preciso depurar o código enquanto estou escrevendo. Essa pessoa não é um programador muito bom ou apenas prefere escrever um novo código. Não todos nós.

Da mesma maneira que você determinaria a capacidade de codificação de alguém, faça perguntas sobre a depuração.

Pergunte a eles "como" eles localizariam um bug em uma determinada situação.

Dê um passo adiante e sente-os na frente de um computador e observe-os depurando um problema.

Eu sempre dei aos candidatos situações hipotéticas ... por exemplo, um sistema de produção parou de responder. O que você faz? Eles podem responder "verifique os logs" e eu digo "os logs não mostram nada de anormal, exceto que não há nada escrito neles desde que o problema começou a acontecer". E assim continua, até que eu esteja satisfeito por ter avaliado a capacidade dos candidatos em solucionar problemas.

Normalmente, pessoas com boa aptidão também são as que possuem boas habilidades de depuração.

Durante a entrevista (dependendo da antiguidade), você pode atribuir a eles uma tarefa do tipo quebra-cabeça, como um algoritmo ou algo assim. Essa é a maneira simples.

Se puder, você pode imprimir um código de algum trabalho e perguntar à pessoa se algo está errado aqui e se sim, como corrigi-lo.

Eu não prefiro fazer perguntas de entrevista ofuscadas que tendem a se concentrar na capacidade das pessoas de ler e corrigir sintaxe.

Durante uma entrevista, peça que eles lhe digam sobre um bug que eles corrigiram no passado e as etapas que eles usaram na depuração.

Faça com que eles lhe digam o que fizeram em seu último trabalho, tarefa de casa, etc. E o que eles fizeram para encontrar o problema.

Compartilharei uma experiência juntamente com uma perspectiva de recrutas sobre o teste de habilidades de um candidato na depuração. Eu segui em uma entrevista que tinha três etapas. A segunda etapa foi um "caso prático". Eu não sabia mais naquele momento. Enquanto lá fui informado, existe um sistema que parou de funcionar e eles não sabem. Alguns erros estão por trás.

Foi organizado como uma área de trabalho remota em um ambiente de teste antigo. Provavelmente para um ambiente desconectado ou isolado. O projeto incluiu alguns formulários da web com alguns controles ASP.NET e código de arquivo de código relacionado. O arquivo de código se refere a um tipo de camada de negócios para a qual eu apenas tenho uma dll, sem código-fonte e descrições de métodos. Os Webforms executaram as funções CRUD que você pode esperar. Também uma pequena função de pesquisa. A camada de negócios, por sua vez, conversou com o Views e o SP em um servidor sql.

Eles quebraram algumas partes em diferentes níveis. Foi-me dado um papel com sintomas. "Impossível pesquisar" "O campo 'região' desapareceu após a última atualização" e tal. Como você pode receber de seus usuários.

Não me lembro de todos os detalhes, mas pelo menos um campo da tabela foi renomeado, o que levou a um SP quebrado, que foi usado pela função de pesquisa. Isso significa que não há erro no VS e nenhum código-fonte BL para rastrear nomes de campos. Um parâmetro SELECT no Sqlcommand foi digitado incorretamente e causou o mau funcionamento de um formulário da web. Também foi omitido um campo que era o campo ausente no GridView (Autogeneratecolumns). Um botão ASP.NET foi referido a algo que deveria ser um método duplicado, aprimorado e "esqueceu" para apontar o botão para o novo método.

Também coisa menor usando título em uma tag html que não permite. A tag ALT oposta também foi omitida em um controle que exigia. Houve também alguns erros com tags html fechadas incorretas, mas que não funcionaram corretamente. Não tenho certeza se tudo isso foi um puro erro de projeto de teatro ou talvez o mesmo projeto para diferentes recrutamentos. Eu nunca perguntei. O nível de dificuldade deve, obviamente, corresponder à necessidade do recruta.

Provavelmente, esse teste deve ser rastreado (não seguido) para ver, após a entrevista, como a depuração foi realizada. Para mim, nessa fase, achei o teste um pouco ridículo, mas esse também seria o grande ponto. Se foi ou não, deve valer muito ter o candidato no lugar certo.

* Acho que esse teste foi comprovado pelos candidatos / minhas habilidades *
* Analise um sistema estrangeiro
* Use um mínimo de informações para encontrar erros e bugs
* Sob estresse no tempo e sem que alguém o ajude, codifique as correções assumidas
* Diferentes níveis de conhecimento;
** sql db e procedimentos armazenados,
** uso de dll no projeto,
** técnica asp.net,
** arquitetura em camadas
** aspecto orientado a problemas

Mas também as coisas mais óbvias, como lidar com o ambiente do desenvolvedor, encontrar e entender a ferramenta Db Server Management. Certamente, existem candidatos que parecem realmente legais no papel, mas, na prática, podem ficar presos nessas tarefas.

Eu escolho um problema real que encontrei que seja relevante para a posição e apresento ao candidato da mesma forma que foi apresentado a mim. É claro que ofereço a eles algumas informações gerais e uma pequena quantidade de documentação relevante, como um trecho de código ou um diagrama esquemático.

Eu digo a eles que o trabalho deles é resolver o problema e me ofereço para responder a quaisquer perguntas técnicas que eles tenham e dizer o resultado de qualquer experimento que eles desejem realizar. Se eles disserem: "Eu colocaria uma sonda de escopo aqui", esboçarei um rastro do que eles podem encontrar. Se eles quiserem inserir um printfem um loop, direi a eles que nunca sai (!) Ou primeiro imprime "7" e depois repetidamente "5". Se eles ficarem tão distantes no meio do mato que eu não puder dar respostas significativas, admitirei que estamos no caminho errado e voltamos para outro lugar. Se eles ficarem presos, farei perguntas importantes ou darei dicas até que possamos seguir em frente.

O que eu quero ver são processos de pensamento ordenados, determinação para chegar à solução, perguntas e experimentos bem considerados e, idealmente, uma identificação bem-sucedida do problema. Às vezes, escolho problemas complexos demais para alguém depurar completamente em uma entrevista de uma hora e, no final, dou a resposta real. Nesse momento, estou procurando uma reação que mostre que eles estavam envolvidos com o problema e experimentaram aquele momento "aha" e gratificação por chegar à causa. Os melhores candidatos espontaneamente farão perguntas de acompanhamento nesse ponto, tentando vincular seu mapa mental do problema ao que realmente estava acontecendo.

Coloque-os em um computador com alguns símbolos binários simples (com depuração) que segfaults com referência de ponteiro nulo ou + código-fonte + gdb e veja se eles conseguem encontrar a causa do travamento?

Se seus candidatos fizerem um teste preliminar de código, peça que modifiquem o código durante a entrevista para solucionar um bug ou adicionar um novo recurso ou, melhor ainda, aos dois. Se você tornar as especificações de teste de código bastante vagas, isso tornaria mais fácil criar casos de teste com "bugs".

Encontrar "o bug" em um pequeno trecho de código é uma situação muito artificial. Suponho que possa ser útil da mesma maneira que os quebra-cabeças e quebra-cabeças.

Uma abordagem mais abrangente faria perguntas comportamentais sobre como o candidato executou a depuração no passado, citando incidentes específicos e depois acompanhando as perguntas.

Alguém que seja bom em solucionar problemas poderá falar mais do que apenas os recursos de depuração no IDE. Que tal ... as ferramentas de relatório de bugs, a interação do usuário final, a reprodução do bug, a análise do arquivo de log, a verificação?

Há MUITO MAIS na depuração do que rastrear um bloco de código e qualquer avaliação da habilidade de alguém na depuração deve refletir isso.

Dê a alguém um código incrível que sua empresa executa na produção. Peça que introduzam um bug sutil. Pergunte a eles por que eles escolheram aquele. Pergunte a eles como iriam encontrar e consertá-lo.

Ponto de bônus se eles encontrarem um erro no código original.

Bônus de ponto duplo se eles puderem corrigir o erro no código original.

Costumo pedir às pessoas que me descrevam o bug mais difícil que já tiveram que rastrear e consertar e o que fizeram para encontrá-lo e consertá-lo. Eu também sei que se o bug mais difícil era algo que você esperaria que apenas um iniciante achas difícil, provavelmente eles não são bons solucionadores de problemas (a menos que seja uma entrevista para iniciantes). Se é algo realmente difícil e eles descrevem seu processo de pensamento enquanto tentam localizá-lo, posso ter uma ideia do nível de habilidade deles. O que sempre me surpreendeu é o grande número de pessoas que têm uma aparência de "cervo nos faróis" e não conseguem pensar em um único exemplo de algo que fizeram que foi complicado. Desculpe, alguém que deixa os problemas difíceis para outra pessoa resolver, não é alguém que me interessa, a não ser um aluno direto da escola,

Gostaria de fazer algumas perguntas agnósticas sobre tecnologia, como as seguintes:

• Siga-me em todas as etapas para identificar a causa raiz e corrigir um bug (defeito)
• Como você usaria a pilha de chamadas durante a depuração de um aplicativo multi-threading

Isso funciona muito bem especialmente em entrevistas por telefone, pois você só precisa que a pessoa lhe dê uma resposta convincente que mostre como ele realmente funciona enquanto soluciona um problema.