Comment vérifier ou évaluer les compétences de débogage d'une personne? [fermé]

Quels types de compétences déterminent une personne capable de déboguer le code facilement? Il y a quelque temps, mon ami a interviewé un relativement bon programmeur. Le programmeur a été embauché. Il pouvait écrire un bon code, comprendre les cadres et les modèles de conception. La chose qui lui manquait était - des compétences de débogage. Il ne pouvait pas du tout déboguer et trouver des problèmes avec son code ou celui de quelqu'un d'autre lui faisait très mal.

Depuis lors, nous réfléchissons à la manière dont nous pouvons évaluer ou estimer les compétences de débogage d'une personne.

La première question est donc la suivante: quelles compétences déterminent si une personne peut effectivement déboguer un logiciel?

Et le second: comment tester ces compétences lors de l'entretien?

Si la première chose que la personne souhaite faire est de regarder le code et de l'expliquer avec un débogueur, cette personne n'est pas une grande aide à la résolution des problèmes.

Si vous n'avez pas encore de plan d'action et que vous plongez dans l'aveugle du débogueur, vous êtes fondamentalement Easter Egging. Ceci est vrai pour TOUT type de dépannage.

Dans une situation d’entretien, une personne qui demande comment le système fonctionne et s’enquiert de l’historique du système serait une personne qui pourrait être un bon dépanneur. Une personne qui pense système d'abord et mécanique ensuite pourrait être un bon dépanneur.

Cela est vrai de tout système complexe.

Je dirais que la meilleure mesure d'un bon développeur de logiciels dans un langage ou un cadre particulier est la capacité d'analyser de manière critique des problèmes complexes et d'avoir de bonnes compétences en débogage dans le langage ou le cadre. Ils doivent être capables de démontrer le débogage de bas niveau ainsi que la maîtrise du débogage de haut niveau avec des outils de débogage courants.

Cela signifie créer pour eux un scénario qui démontre une grande aptitude des outils de débogage dans l'EDI choisi. Vous devriez chercher des choses comme:

• Exécution d'une application ou d'un serveur en mode bac à sable en mode débogage ou création d'une application avec des symboles pour le débogage

• Mise à disposition et démonstration de ports de débogage à distance ou de débogage d'applications non-sandbox construites avec des symboles (si applicable à la langue)

• Utilisation stratégique des points d'arrêt

• Propriétés personnalisées des points d'arrêt, expressions conditionnelles sur les points d'arrêt (si applicable à la langue)

• Utilisation d'expressions ou de surveillances de variables pour surveiller les valeurs de variables ou les références

• Utilisation de valeur de variable ad-hoc ou de manipulation de référence ou de pointeur en temps réel

• Démontrer la capacité d'intervenir dans, de sortir et de sortir du flux d'applications

• Évaluation critique de la pile d'appels

• Déboguer des applications multithreads et comprendre cela.

D'autres stratégies de débogage sans outils doivent également être démontrées, telles que l'analyse des journaux et du code source, ainsi que la capacité d'effectuer un débogage de bas niveau sans l'utilisation d'un IDE.

Je dirais que distiller un bug que vous aviez dans votre système en quelque chose qui peut être discuté dans le contexte d'une interview. Lancez le débogueur et laissez-le s'exercer.

Posez-lui des questions comme celle-ci:

1. Comment abordez-vous un problème?

2. Quel est le projet complexe que vous avez fait et comment l'avez-vous réalisé?

3. Quels outils de débogage avez-vous utilisés?

4. Avez-vous une préférence pour certains outils?

5. Donnez un exemple de votre propre scénario et demandez-lui comment il va s'y attaquer.

6. Comment évalueriez-vous votre capacité à entrer dans le code de quelqu'un d'autre?

Vous pouvez répondre à vos préoccupations en posant des questions. Il y a toujours un risque qu'il puisse ou non être bon dans certaines compétences. Mais s'il apprend bien, cela aidera beaucoup.

Si vous voulez voir si un programmeur peut déboguer, donnez-leur le code à corriger. C'est la même approche si vous voulez voir s'ils peuvent écrire du code. Donnez-leur un problème et demandez-leur d'écrire du code.

Maintenant, je suis confus à propos de ce programmeur qui n'a pas de problème pour écrire du code mais qui échoue à la volée lorsqu'il est invité à déboguer. Cette personne régurgite-t-elle des exemples de code ou se limite-t-elle à des domaines dans lesquels elle a de l'expérience, comme lire et écrire dans une base de données? À moins que le code soit correct la première fois, ils ne peuvent pas le réparer?

Peut-être que la personne n'aime pas le débogage et ne fait aucun effort? Je ne suis pas doué pour ça, alors arrêtez de me demander de le faire - une impuissance acquise.

Travailler sur une base de code existante nécessite de parcourir le code, la documentation et éventuellement de créer vos propres notes et desgins.

Je sais que nous pensons que le débogage consiste à corriger le code de production qui a échoué, mais je dois déboguer le code pendant que je l'écris. Soit cette personne n'est pas un très bon programmeur, soit elle préfère simplement écrire un nouveau code. Ne nous tous.

De la même manière que vous déterminez la capacité de codage d’une personne, posez-lui des questions sur le débogage.

Demandez-leur "comment" ils rechercheraient un bogue dans une situation donnée.

Allez un peu plus loin et installez-les devant un ordinateur pour les regarder résoudre un problème.

J'ai souvent donné aux candidats des situations hypothétiques ... par exemple, un système de production a cessé de répondre. Que faire? Ils pourraient répondre "vérifier les journaux" et je dis "les journaux ne montrent rien d'anormal, sauf qu'il n'y a rien d'écrit depuis que le problème a commencé à se produire". Et ainsi de suite, jusqu'à ce que je sois convaincu d'avoir évalué la capacité des candidats à résoudre les problèmes.

Habituellement, les personnes ayant de bonnes aptitudes sont également celles qui ont de bonnes compétences en débogage.

Au cours de l'entretien, vous pouvez leur attribuer une tâche similaire à celle d'un puzzle, par exemple un algorithme. C'est le moyen simple.

Si vous le pouvez, vous pouvez imprimer un code sur un travail en demandant à la personne si quelque chose ne va pas ici et si oui, comment y remédier.

Je ne préfère pas vraiment poser des questions d'entretien obscurcies qui ont tendance à mettre l'accent sur la capacité des personnes à lire et à corriger la syntaxe.

Au cours d'une interview, demandez-leur de vous parler d'un bogue qu'ils avaient corrigé dans le passé et des étapes qu'ils utilisaient pour le déboguer.

Demandez-leur de vous dire ce qu’ils ont fait dans leur dernier emploi, leur devoir, etc. Et ce qu’ils ont fait pour trouver le problème.

Je partagerai une expérience avec le point de vue des recrues sur le test des compétences d'un candidat en débogage. J'ai eu une interview en trois étapes. La deuxième étape était un "cas pratique". Je n'en savais pas plus à ce moment. Pendant que j'étais là-bas, un système a cessé de fonctionner et ils ne le savent pas. Quelques insectes sont derrière.

Il a été organisé en tant que bureau distant pour un ancien environnement de test. Probablement dans un environnement débranché ou isolé. Le projet consistait en quelques formulaires Web avec des contrôles ASP.NET et le code de fichier code associé. Le fichier de code faisait référence à une sorte de couche de gestion pour laquelle je viens d'avoir une dll, pas de code source ni de description de méthode. Les formulaires Web ont rempli les fonctions CRUD auxquelles vous pouvez vous attendre. Aussi une petite fonction de recherche. La couche métier a à son tour parlé à Views et à SP dans un serveur SQL.

Ils ont cassé des pièces à différents niveaux. On m'a donné un papier avec des symptômes. "Recherche impossible" "Le champ" région "a disparu après la dernière mise à jour" et autres. Tels que vous pouvez recevoir de vos utilisateurs.

Je ne me souviens pas de tous les détails mais au moins un champ de table a été renommé, ce qui conduit à un SP cassé, utilisé par la fonction de recherche. Cela signifie qu'aucune erreur dans VS et aucun code source BL ne permet de suivre les noms de champs. Un paramètre SELECT associé à Sqlcommand a été mal orthographié et a provoqué un dysfonctionnement d'un formulaire Web. Un champ a également été omis, qui était le champ manquant dans GridView (Autogeneratecolumns). Un bouton ASP.NET a été référencé à quelque chose qui doit être censé être une méthode dupliquée, améliorée et "oublié" de pointer le bouton sur la nouvelle méthode.

Aussi une telle chose mineure en utilisant le titre dans une balise HTML qui ne le permettent pas. De plus, la balise ALT opposée a été omise dans un contrôle le nécessitant. Il y avait aussi quelques erreurs avec des balises html fermées non correctes mais qui ne fonctionnaient pas mal. Je ne sais pas si tout cela était une pure erreur de projet de théâtre ou peut-être le même projet pour différents recrutements. Je n'ai jamais demandé. Le niveau de difficulté devrait bien sûr correspondre au besoin de la recrue.

Ce test devrait probablement être examiné (non suivi) pour voir, après l’entretien, comment le débogage a été effectué. Pour moi à ce stade, j’ai trouvé le test un peu ridicule, mais c’est aussi ce qui importe. Si c'était ou ne l'était pas, le candidat devrait occuper une place de choix.

* Je pense que ce test a été prouvé aux candidats / à mes compétences pour *
* Analyser un système étranger
* Utiliser un minimum d'informations pour trouver des erreurs et des bugs
* Sous contrainte de temps et sans aide, code supposé des corrections
* Différents niveaux de connaissances;
** db sql et procédures stockées,
** utilisation de dll dans un projet,
** technique asp.net,
** architecture en couches
** aspect orienté problème

Mais aussi les choses les plus évidentes comme gérer l’environnement de développeur, trouver et comprendre l’outil de gestion de serveur Db. Certes, il y a des candidats qui ont l'air vraiment sympa sur le papier mais qui, en pratique, pourraient rester coincés dans de telles tâches.

Je choisis un problème réel que j'ai rencontré qui est pertinent pour le poste et je le présente au candidat de la même manière qu'il l'a été. Bien entendu, je leur offre des informations générales et une petite quantité de documentation pertinente, telle qu’un extrait de code ou un diagramme schématique.

Je leur dis que leur travail est de résoudre le problème et je propose de répondre à leurs questions techniques et de leur dire le résultat des expériences qu'ils souhaitent réaliser. S'ils disent: «Je mettrais une sonde de portée ici», je leur ferai un aperçu de ce qu'ils pourraient trouver. S'ils veulent insérer une printfboucle, je leur dirai qu'elle ne sort jamais (!) Ou qu'elle imprime d'abord "7", puis plusieurs fois "5". S'ils s'éloignent tellement dans les mauvaises herbes que je ne peux pas donner de réponses significatives, j'admettrai que nous sommes sur la mauvaise voie et que nous reculons ailleurs. S'ils restent bloqués, je poserai des questions suggestives ou des conseils jusqu'à ce que nous puissions passer à autre chose.

Ce que je veux voir, ce sont des processus de pensée ordonnés, la détermination de trouver la solution, des questions et des expériences réfléchies et, idéalement, une identification réussie du problème. Parfois, je choisis des problèmes trop complexes pour qu'une personne puisse déboguer complètement lors d'une interview d'une heure et, à la fin, je leur donne la vraie réponse. À ce stade, je suis à la recherche d’une réaction qui montre qu’ils ont été impliqués dans le problème et ont vécu l’expérience du moment "aha" et de la gratification de parvenir à la cause. Les meilleurs candidats poseront spontanément des questions de suivi à ce stade, en essayant de relier leur carte mentale du problème à ce qui se passait réellement.

Asseyez-les devant un ordinateur avec quelques symboles binaires simples (avec le débogage) qui segmentent les valeurs par défaut avec une référence de pointeur nulle ou par exemple + code source + gdb et voyons s'ils peuvent trouver la cause de l'accident?

Si vos candidats font des tests de code préliminaires, demandez-leur de modifier le code lors de l'entretien pour résoudre un bogue ou ajouter une nouvelle fonctionnalité, voire mieux les deux. Si vous rendez les spécifications de test du code assez vagues, cela facilitera la création de scénarios de test contenant des "bogues".

Trouver "le bogue" dans un petit extrait de code est une situation très artificielle. Je suppose que cela pourrait être utile de la même manière que les énigmes et les casse-tête.

Une approche plus complète poserait des questions de comportement sur la manière dont le candidat a effectué le débogage dans le passé en citant des incidents spécifiques, puis en posant des questions.

Une personne douée en résolution de problèmes pourra parler de plus que des installations de débogage dans l'IDE. Qu'en est-il des outils de rapport de bogue, de l'interaction de l'utilisateur final, de la reproduction du bogue, de l'analyse du fichier journal, de la vérification?

Il y a BEAUCOUP plus pour le débogage que pour le traçage via un bloc de code et toute évaluation des compétences de quelqu'un en débogage devrait refléter cela.

Donnez à quelqu'un du code génial que votre société exécute en production. Demandez-leur de présenter un bogue subtil. Demandez-leur pourquoi ils ont choisi celui-là. Demandez-leur comment ils s'y prendraient pour le trouver et le réparer.

Point bonus s'ils trouvent un bug dans le code d'origine.

Double bonus si ils peuvent corriger le bogue dans le code original.

J'ai tendance à demander aux gens de me décrire le bogue le plus difficile qu'ils aient jamais eu à dépister et à corriger, et ce qu'ils ont fait pour le trouver et le réparer. Je sais aussi que si le bogue le plus difficile est quelque chose que vous ne voudriez que difficile à un débutant, alors ce ne sont probablement pas de bons dépanneurs (sauf s’il s’agit d’une interview pour débutant). Si c'est quelque chose de vraiment difficile et qu'ils décrivent leur processus de pensée en essayant de le localiser, je peux alors avoir une idée de leur niveau de compétence. Ce qui m’a toujours étonné, c’est le nombre considérable de personnes qui ont l’aspect «cerf dans les phares» et qui ne peuvent penser à aucun exemple de ce qu’ils ont fait qui soit compliqué. Eh bien, désolé, quelqu'un qui laisse les problèmes difficiles à régler ne soit pas quelqu'un qui m'intéresse sauf pour une simple sortie de l'école,

Je voudrais poser quelques questions agnostiques sur les technologies, telles que:

• Suivez-moi à travers toutes les étapes que vous suivez pour identifier la cause première et corriger un bogue (un défaut)
• Comment utiliseriez-vous Call Stack lors du débogage d'une application multi-threading?

Cela fonctionne très bien spécialement dans les entretiens téléphoniques, car il vous suffit de demander à la personne de vous donner une réponse convaincante qui montre comment il fait vraiment tout en résolvant un problème.