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

48

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?

Michal B.
la source
14
En fait, on m'a donné du code pour déboguer, sur un ordinateur, lors d'une interview. Ils avaient modifié le code source en tar ou gzip ou quelque chose du genre et ils voulaient voir comment je le déboguerais.
wkl
4
Le seul moyen d’en être sûr est de le laisser "vivre". Informez-le à l'avance de votre environnement de développement et indiquez qu'il existe un test de codage et de débogage simple.
Il n'est même pas nécessaire que ce soit en direct, @ ThorbjørnRavnAndersen. J'ai interviewé à quelques endroits qui m'ont remis un imprimé d'une petite fonction, avec une spécification de ce que cette fonction fait, puis je me suis demandé de "trouver le bogue".
quanticle
@quanticle Pareil, ma société propose un test de programmation en 5 questions (dont environ la moitié est un débogage) avant que votre candidature ne soit retenue pour une entrevue en personne. Apparemment, ça
élimine la
Donnez-lui une trace de pile à analyser :-)
JustMe

Réponses:

24

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.

ElGringoGrande
la source
1
+1 pour une bonne perspective à ce sujet. Je suis d’accord, mais quand ils pensent en second lieu à la mécanique, ils doivent maintenant savoir comment utiliser les outils. Tout comme dans les voitures, un ingénieur qui ne comprend pas ou ne peut pas utiliser les outils de mécanique n’est pas du tout un ingénieur qualifié.
maple_shaft
16
Cette réponse ne laisse aucune place au débogage instinctif. Quelqu'un qui a travaillé avec suffisamment de systèmes, types de code ou langues, sera souvent capable de "sentir" son chemin vers tout ce qui est funky. Parfois, vous n'avez pas besoin de connaître les tenants et les aboutissants du système pour pouvoir en identifier les défauts.
Jordanie
Tout d’abord, il n’existe pas de "débogage instinctif". Il existe des heuristiques ("indices de jambe cassés") que les experts utiliseront. Si sûr. Si des heuristiques sont disponibles, les experts les utiliseront efficacement. Mais ces heuristiques peuvent mordre ces experts dans le cul. Allez lire sur les tonnes de travaux effectués sur des experts en psychologie cognitive et vous verrez. Donc, un bon expert peut avoir une bonne idée de par où commencer mais il ne devrait jamais se fier complètement à ces instincts. Et ils devraient pouvoir expliquer, au moins dans une certaine mesure, ces sentiments instinctifs.
ElGringoGrande
10
Je suis en désaccord à 100% avec votre noir et blanc si la première chose qu'ils commentent. Je dirais que si une personne pense que lancer le débogueur n'est pas une bonne première option dans certains cas, cette personne n'est également pas un bon dépanneur. Si le problème est que les communications sont arrêtées, la première chose que je vais faire est d’activer le débogueur et de déterminer quels processus / threads / tâches sont bloqués ou ont cessé de fonctionner. Une autre raison d'activer le débogueur est d'essayer de voir si le problème est reproductible. Une fois que vous savez briser le système, trouver la solution devient beaucoup plus facile.
Dunk
5
@ ElGringoGrande, il suggérait le contraire de ce que je lis. Le fait est que les gens deviennent naturellement meilleurs en déboguant à mesure qu'ils acquièrent de l'expérience. Les outils ou la méthodologie ne sont pas aussi importants que leur efficacité. C'est pourquoi votre réponse est incomplète. Il existe de nombreuses façons valables de déboguer, y compris prendre une chaise et parcourir le code, poser des questions, etc. J'ai efficacement débogué de gros programmes PHP avec print. Je n'aime pas le faire, mais l'outil ne concerne pas tant l'outil que la connaissance du fonctionnement général des systèmes.
Jordanie
15

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.

maple_shaft
la source
+1 liste très utile. Et plus appliqué.
Dipan Mehta
8
Je suis d’avis que le débogage d’applications multithreads est un tout autre réel que le débogage d’applications à un seul thread. Différent et beaucoup, beaucoup plus difficile.
Bruce Ediger
20
@JarrodRoberson Brian Kernighan et Rob Pike ont écrit dans The Practice of Programming qu'ils préfèrent toujours les instructions d'impression aux débogueurs, car elles sont moins transitoires. Beaucoup de gens préfèrent un bon système de journalisation qui leur donne une vue détaillée du chemin du code sans interrompre le programme à mi-parcours. Il est également plus facile de lire un fichier journal, puis de déboguer un fichier de sauvegarde. Votre test décisif risque donc de rejeter certains bons programmeurs, car tout le monde n’est pas d’accord sur le fait que les débogueurs sont aussi utiles que les approches alternatives de débogage (journaux, tests unitaires, assertions)
MetricSystem
12
Les instructions d'impression de débogage sont correctes et peuvent être préférables à un débogueur, en particulier lorsque la simultanéité est impliquée. Votre problème avec eux pourrait vraiment être avec un compilateur lent.
Ricky Clarkson
8

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.

Michael Brown
la source
7

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.

noname
la source
6

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.

JeffO
la source
2
Nous déboguons tous nos programmes. Au début, c’est facile parce que le programme est petit et qu’il est facile de tout avoir dans la tête. Mais à mesure qu'il grandit et se complexifie, le débogage devient plus difficile. Et maintenant - certaines personnes peuvent toujours gérer cela et trouver un bogue en un temps raisonnable et certaines personnes sont tout simplement perdues. Ils ne savent pas sur quoi se concentrer et comment le trouver ...
Michal B.
1
@ MichalB: Nous déboguons tous nos programmes, mais certaines personnes présenteront une approche fondée sur des principes, tandis que d'autres modifieront les choses au hasard et verront ce qu'il se passera .
Matthieu M.
Je ne comprends pas pourquoi vous seriez confus. Être un bon développeur et un bon mainteneur sont des compétences très différentes. Au mieux, la plupart des gens ne sont compétents que dans l'un ou l'autre de ces domaines, voire pas du tout (ce qui, malheureusement, concerne la majorité des développeurs).
Dunk
3

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.

ozz
la source
3

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.

James Roper
la source
2

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.

Dipan Mehta
la source
+1 excellente réponse! Je conviens que les meilleurs développeurs de logiciels possèdent de bonnes compétences en débogage et j’ai également le sentiment que la détection des erreurs de syntaxe n’est pas très révélatrice. La plupart des IDE et même de bons éditeurs de texte (Notepad ++) identifieront les erreurs de syntaxe dans les langages courants. Je ne suis pas d'accord cependant qu'un puzzle démontre les compétences de débogage. Les puzzles démontrent une pensée critique qui est une compétence différente mais liée.
maple_shaft
@maple_shaft merci pour (encore +1). Certes, les énigmes ne sont pas directement liées au débogage . Mais il est bon de juger de la façon dont les gens abordent les problèmes - une chose vraiment indirecte.
Dipan Mehta
2
Je regarde puzzle et je suis comme ewwwwwwww. vous n'avez vraiment rien de mieux que "Gotcha"? et comment "l'ancienneté" entre-t-elle en scène? Les personnes âgées sont-elles supposées résoudre des énigmes plus difficiles? tous les bons programmeurs (ou débogueurs) sont-ils des fans de sudoku? vous pourriez finir par ennuyer de très bons programmeurs et vous faire des reproches dans la ville. les questions gotcha sont une insulte <période> s'il vous plaît proposer quelque chose de meilleur hommes.
Chani
@Scrooge Je pensais uniquement à la programmation - je n'ai jamais joué au sudoku avec des centaines d'interviews que j'ai prises.
Dipan Mehta
2

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.

Schleis
la source
2

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.

indépendant
la source
2

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.

Ben Jackson
la source
1

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?

Kimvais
la source
2
Tout cela vous dit que la personne peut analyser le code et les fichiers binaires pour trouver une référence potentielle de pointeur null. Cela ne démontre pas réellement une utilisation habile des outils de débogage courants.
maple_shaft
1

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".

Sardathrion - Rétablir Monica
la source
1

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.

Angelo
la source
J'aime supposer qu'il y a des bogues dans le logiciel que nous n'avons pas encore découverts. C'est comme chercher des failles sismiques. La question est de savoir comment on cherche des signes indicateurs.
Christopher Mahan
1

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.

Christopher Mahan
la source
1

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,

HLGEM
la source
1

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.

Jaime Botero
la source