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

Se a primeira coisa que a pessoa deseja fazer é olhar o código e passar por ele com um depurador, essa pessoa não é uma ótima solução de problemas.

Se você ainda não tem um plano de ação e mergulha no debugger blind, você é basicamente Easter Egging. 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 a história do sistema seria alguém que poderia ser um bom solucionador de problemas. Uma pessoa que pensa primeiro no sistema e em segundo na mecânica pode ser um bom solucionador de problemas.

Isso vale para qualquer sistema complexo.

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

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

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

• Disponibilizando e demonstrando portas de depuração remota ou depuração de aplicativos sem área de segurança que foram criados com símbolos (se aplicável a 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 à linguagem)

• Uso de expressões ou relógios variáveis para monitorar valores de variáveis ou referências

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

• Demonstrar capacidade de entrar, sair e sair do fluxo de aplicativos

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

• Depurando aplicativos multi-thread e entendendo isso.

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

Eu diria destilar um bug que você tinha em seu sistema para algo que pode ser discutido no contexto de uma entrevista. Acione o depurador e deixe-o entrar.

Faça perguntas como esta:

1. Como você resolve um problema?

2. Qual é um dos projetos complexos que você fez e como você conseguiu isso?

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

4. Você tem alguma preferência por certas 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 em outro código?

Você pode responder às suas dúvidas fazendo perguntas. Há sempre um risco de que ele possa ou não ser bom em certas habilidades. Mas se ele é um bom aluno, isso vai ajudar muito.

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

Agora, estou confuso sobre esse programador que não tem problemas para escrever código, mas falha de forma missível quando solicitado a depurar. Essa pessoa regurgita exemplos de código ou simplesmente fica em áreas que ele tem experiência como ler e escrever em um banco de dados? A menos que eles acertem o código na primeira vez, eles não podem consertar?

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

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

Sei que achamos que a depuração consertará o código de produção que falhou, mas preciso depurar o código enquanto escrevo. Ou essa pessoa não é um bom programador ou apenas prefere escrever um novo código. Não todos nós.

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

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

Dê um passo adiante e sente-os na frente de um computador e observe-os depurar 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 "verificar os logs" e eu digo "os logs não mostram nada anormal, exceto que não há nada escrito neles desde que o problema começou a acontecer". E assim continua, até que estou satisfeito que avaliei a capacidade dos candidatos para resolver problemas.

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

Durante a entrevista, (dependendo da sua senioridade) você pode atribuir a eles uma tarefa de quebra-cabeças, como um algoritmo ou algo assim. Essa é a maneira mais simples.

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

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

Durante uma entrevista, peça a eles para falar sobre um bug que eles corrigiram no passado e os passos que eles usaram para depurá-lo.

Faça com que eles falem sobre o que fizeram em seu último trabalho, trabalho de casa, etc. E o que eles passaram para encontrar o problema.

Compartilharei uma experiência junto com uma perspectiva de recruta sobre o teste de habilidades de um candidato na depuração. Eu consegui uma entrevista que teve três etapas. O segundo estágio foi um "caso prático". Eu não sabia mais naquele momento. Enquanto lá fui informado há um sistema que parou de funcionar e eles não sabem. Alguns insetos estão deitados.

Foi organizado como um desktop remoto para um ambiente de teste antigo. Provavelmente para um ambiente desconectado ou isolado. O projeto foi alguns webforms com alguns controles ASP.NET e código de arquivo de código relacionado. O codefile se refere a um tipo de camada de negócios para o qual eu tenho apenas uma dll, sem código-fonte e descrições de método. O Webforms fez 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 Views e SP em um servidor sql.

Eles fizeram algumas partes em diferentes níveis. Recebi um papel com sintomas. "Não é possí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 de 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 contra o Sqlcommand foi digitado incorretamente e causou um mau funcionamento do formulário da web. Também foi omitido um campo que era o campo que faltava no GridView (Autogeneratecolumns). Um botão ASP.NET foi referenciado a algo que deve ser um método duplicado e aprimorado, e "esqueceu" de apontar o botão para um novo método.

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

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

* Eu acho que o teste foi provado os candidatos / minhas habilidades para *
* Analisar um sistema externo
* Use um mínimo de informações para encontrar erros e erros. * Sob o estresse do tempo e sem alguém te ajudar, o código assumiu correções. * Diferentes níveis de conhecimento,
** banco de dados sql e procedimentos armazenados,
** uso de dll no projeto,
** técnica asp.net,
** arquitetura em camadas
** aspecto orientado para o problema

Mas também as coisas mais óbvias, como lidar com o ambiente de desenvolvedor, encontrar e entender a ferramenta de Gerenciamento de Servidor Db. Certamente há candidatos que parecem realmente bons no papel, mas, na prática, podem ficar presos em tais tarefas.

Eu escolho um problema real que encontrei que é relevante para a posição e a apresento ao candidato do modo como 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 ofereço-me para responder a quaisquer perguntas técnicas que eles tenham e dizer-lhes o resultado de qualquer experiência que eles queiram realizar. Se eles disserem: "Eu colocaria uma sonda de escopo aqui", então eu os esboçarei um traço do que eles podem encontrar. Se eles quiserem inserir um printf em um loop, eu direi a eles que ele nunca sai (!) Ou primeiro imprime "7" e depois repetidamente "5". Se eles ficarem tão distantes nas ervas daninhas que eu não puder dar respostas significativas, admitirei que estamos no caminho errado e voltamos para outro lugar. Se eles ficarem presos, eu vou fazer perguntas ou dar dicas até podermos seguir em frente.

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

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

Se você tiver seus candidatos fazendo um teste de código preliminar, peça que eles modifiquem o código durante a entrevista para resolver um erro ou adicionar um novo recurso ou, melhor ainda, ambos. Se você tornar as especificações de teste de código bastante vagas, isso facilitará a criação de casos de teste com "bugs".

Encontrar "o bug" em um pequeno trecho de código é uma situação muito artificial. Acho que pode ser útil da mesma forma que quebra-cabeças e quebra-cabeças são.

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

Alguém que é bom em resolução de problemas poderá falar sobre 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 para depurar do que rastrear por meio de um bloco de código e qualquer avaliação da habilidade de alguém na depuração deve refectir isso.

Dê a alguém um código incrível que sua empresa executa em produção. Peça-lhes para introduzir um bug sutil. Pergunte por que eles escolheram aquele. Pergunte a eles como eles iriam encontrar e consertar.

Ponto de bônus se encontrar um bug no código original.

Duplo ponto de bônus se eles puderem corrigir o bug no código original.

Eu costumo pedir às pessoas que descrevam para mim o erro mais difícil que já tiveram para rastrear e consertar e o que fizeram para encontrá-lo e corrigi-lo. Eu também sei que se o bug mais difícil for algo que você esperaria que apenas um iniciante encontre difícil, então provavelmente eles não são bons solucionadores de problemas (a menos que seja uma entrevista para o nível de entrada). Se é algo genuinamente difícil e eles descrevem o seu processo de pensamento enquanto tentam rastreá-lo, então eu posso sentir qual é o nível de habilidade deles. O que tem alaways me surpreendeu é o grande número de pessoas que recebem um olhar de "cervo nos faróis" e não conseguem pensar em um único exemplo de algo que eles fizeram que era complicado. Bem, desculpe alguém que deixa os problemas difíceis para outra pessoa consertar não é alguém que eu estou interessado em qualquer coisa, exceto um trabalho de nível muito júnior fora da escola.

Gostaria de fazer algumas perguntas agnósticas de 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 ao depurar uma multithreading? app

Isso funciona muito bem, especialmente em entrevistas por telefone, pois você só precisa da pessoa para lhe dar uma resposta convincente que mostre como ele realmente faz as coisas enquanto resolve um problema.