Wie überprüfe oder bewerte ich die Debugging-Fähigkeiten einer Person? [geschlossen]

Welche Fähigkeiten bestimmen eine Person, die in der Lage ist, Code mühelos zu debuggen? Vor einiger Zeit führte mein Freund ein Interview mit einem relativ guten Programmierer. Der Programmierer wurde eingestellt. Er konnte guten Code schreiben, die Frameworks und Designmuster verstehen. Was ihm fehlte, war das Debuggen von Fähigkeiten. Er konnte überhaupt nicht debuggen und Probleme mit dem Code seines oder eines anderen zu finden, bereitete ihm große Schmerzen.

Seitdem überlegen wir, wie wir die Debug-Fähigkeiten einer Person einschätzen oder einschätzen können.

Die erste Frage lautet also: Welche Fähigkeiten bestimmen, ob eine Person Software effektiv debuggen kann?

Und die zweite: Wie kann man diese Fähigkeiten während des Interviews testen?

Wenn die Person als Erstes den Code überprüfen und ihn mit einem Debugger durchgehen möchte, ist diese Person keine großartige Fehlerbehebung.

Wenn Sie noch keinen Aktionsplan haben und in den Debugger-Blind eintauchen, sind Sie im Grunde ein Ostereier. Dies gilt für jede Art der Fehlerbehebung.

In einer Interview-Situation ist eine Person, die fragt, wie das System funktioniert, und nach der Geschichte des Systems fragt, möglicherweise eine gute Problemlösung. Eine Person, die zuerst an das System und dann an die Mechanik denkt, könnte ein guter Ratgeber sein.

Dies gilt für jedes komplexe System.

Ich würde argumentieren, dass das beste Maß für einen guten Softwareentwickler in einer bestimmten Sprache oder einem bestimmten Framework die Fähigkeit ist, komplexe Probleme kritisch zu analysieren und über gute Debugging-Fähigkeiten in der Sprache oder im Framework zu verfügen. Sie müssen in der Lage sein, Low-Level-Debugging sowie Kenntnisse im High-Level-Debugging mit gängigen Debugging-Tools nachzuweisen.

Dies bedeutet, dass ein Szenario für sie erstellt wird, das eine hohe Eignung für Debugging-Tools in der von ihnen gewählten IDE aufweist. Sie sollten nach Dingen suchen wie:

• Ausführen einer Sandbox-Anwendung oder eines Servers im Debug-Modus oder Erstellen einer Anwendung mit Symbolen zum Debuggen

• Bereitstellung und Demonstration von Remote-Debugging-Ports oder Debugging von Anwendungen ohne Sandbox, die mit Symbolen erstellt wurden (falls für die Sprache zutreffend)

• Strategische Verwendung von Haltepunkten

• Angepasste Eigenschaften von Haltepunkten, bedingte Ausdrücke für Haltepunkte (falls für die Sprache zutreffend)

• Verwendung von Ausdrücken oder Variablenüberwachungen zur Überwachung von Variablenwerten oder Referenzen

• Verwendung von Ad-hoc-Variablenwerten oder Referenz- oder Zeigermanipulation in Echtzeit

• Demonstrieren Sie die Fähigkeit, den Anwendungsfluss zu betreten, zu überschreiten und zu verlassen

• Kritische Bewertung des Aufrufstapels

• Multithread-Anwendungen debuggen und verstehen.

Es sollten auch andere Debugging-Strategien ohne Tools demonstriert werden, z. B. das Analysieren von Protokollen und Quellcode sowie die Möglichkeit, ein Debugging auf niedriger Ebene auch ohne die Verwendung einer IDE durchzuführen.

Ich würde sagen, Sie destillieren einen Fehler, den Sie in Ihrem System hatten, zu etwas, das im Rahmen eines Interviews besprochen werden kann. Starten Sie den Debugger und lassen Sie ihn dran.

Stellen Sie ihm Fragen wie diese:

1. Wie gehen Sie ein Problem an?

2. Was ist eines der komplexen Projekte, die Sie durchgeführt haben und wie haben Sie es erreicht?

3. Welche Debugging-Tools haben Sie verwendet?

4. Haben Sie eine Präferenz für bestimmte Werkzeuge?

5. Geben Sie ein Beispiel für Ihr eigenes Szenario und fragen Sie ihn, wie er es angehen wird.

6. Wie würden Sie Ihre Fähigkeit bewerten, in einen anderen Code zu gelangen?

Sie können auf Ihre Bedenken eingehen, indem Sie Fragen stellen. Es besteht immer das Risiko, dass er in bestimmten Fähigkeiten gut oder schlecht ist. Aber wenn er gut lernt, hilft das sehr.

Wenn Sie sehen möchten, ob ein Programmierer debuggen kann, geben Sie ihm den zu korrigierenden Code. Es ist der gleiche Ansatz, wenn Sie sehen möchten, ob sie Code schreiben können. Geben Sie ihnen ein Problem und lassen Sie sie Code schreiben.

Jetzt bin ich verwirrt über diesen Programmierer, der keine Probleme beim Schreiben von Code hat, aber bei der Aufforderung zum Debuggen kläglich versagt. Bringt diese Person Codebeispiele wieder zum Erbrechen oder hält sie sich nur an Bereiche, in denen sie Erfahrungen mit dem Lesen und Schreiben in einer Datenbank hat? Wenn sie den Code nicht gleich beim ersten Mal richtig verstanden haben, können sie ihn nicht reparieren?

Vielleicht mag die Person das Debuggen einfach nicht und unternimmt keine Anstrengungen? Ich bin nicht gut darin, also hör auf, mich darum zu bitten - erlernte Hilflosigkeit.

Wenn Sie an einer vorhandenen Codebasis arbeiten möchten, müssen Sie den Code und die Dokumentation durchsehen und möglicherweise eigene Notizen und Entwürfe anfertigen.

Ich weiß, dass wir das Debuggen als Beheben von Produktionscode betrachten, der fehlgeschlagen ist, aber ich muss den Code beim Schreiben debuggen. Entweder ist diese Person kein sehr guter Programmierer, oder sie zieht es einfach vor, neuen Code zu schreiben. Tun wir das nicht alle?

Auf die gleiche Weise würden Sie die Codierungsfähigkeit einer Person bestimmen und ihnen Fragen zum Debuggen stellen.

Fragen Sie sie, "wie" sie einen Fehler in einer bestimmten Situation aufspüren würden.

Gehen Sie noch einen Schritt weiter, setzen Sie sich vor einen Computer und beobachten Sie, wie sie ein Problem beheben.

Ich habe Kandidaten oft hypothetische Situationen gegeben ... zum Beispiel reagiert ein Produktionssystem nicht mehr. Wie geht's? Sie antworten möglicherweise auf "Überprüfen Sie die Protokolle" und ich sage "Die Protokolle zeigen nichts Ungewöhnliches an, mit der Ausnahme, dass seit dem Auftreten des Problems nichts darauf geschrieben ist". Und so geht es weiter, bis ich zufrieden bin, dass ich die Fähigkeit der Kandidaten zur Problemlösung eingeschätzt habe.

Normalerweise sind Menschen mit guten Fähigkeiten auch diejenigen mit guten Debugging-Fähigkeiten.

Während des Interviews können Sie ihnen (abhängig von ihrem Dienstalter) eine Art Puzzle zuweisen, wie zum Beispiel einen Algorithmus oder so. Das ist der einfache Weg.

Wenn Sie können, können Sie einen Code ausdrucken, indem Sie die Person fragen, ob hier etwas nicht stimmt und wie Sie es beheben können.

Ich ziehe es nicht ganz vor, verschleierte Interviewfragen zu stellen, bei denen die Fähigkeit der Leute, die Syntax zu lesen und zu korrigieren, im Vordergrund steht.

Bitten Sie sie während eines Interviews, Ihnen von einem Fehler zu erzählen, den sie in der Vergangenheit behoben haben, und von den Schritten, die sie beim Debuggen verwendet haben.

Lassen Sie sich von ihnen erzählen, was sie in ihrer letzten Arbeit getan haben, welche Hausaufgaben sie gemacht haben usw. und was sie durchgemacht haben, um das Problem zu finden.

Ich werde eine Erfahrung zusammen mit einer Rekrutenperspektive über den Test der Fähigkeiten eines Kandidaten beim Debuggen teilen. Ich bekam ein Interview, das drei Phasen hatte. Die zweite Stufe war ein "praktischer Fall". Mehr wusste ich in diesem Moment nicht. Als ich dort informiert wurde, gab es ein System, das nicht mehr funktionierte und sie wissen es nicht. Einige Bugs liegen dahinter.

Es wurde als Remote-Desktop für eine alte Testumgebung eingerichtet. Möglicherweise in einer nicht angeschlossenen oder isolierten Umgebung. Das Projekt bestand aus einigen Webformularen mit einigen ASP.NET-Steuerelementen und zugehörigem Code-Datei-Code. Das Codefile bezog sich auf eine Art Business-Schicht, für die ich nur eine DLL, keinen Quellcode und Methodenbeschreibungen habe. Die Webforms haben die CRUD-Funktionen ausgeführt, die Sie erwarten können. Auch eine kleine Suchfunktion. Die Business-Schicht sprach wiederum mit Views und SP auf einem SQL Server.

Sie haben einige Teile auf verschiedenen Ebenen zerbrochen. Ich bekam eine Arbeit mit Symptomen. "Suche nicht möglich" "Das Feld 'Region' ist nach der letzten Aktualisierung verschwunden" und so weiter. Wie Sie von Ihren Nutzern erhalten können.

Ich erinnere mich nicht an alle Details, aber zumindest ein Tabellenfeld wurde umbenannt, was zu einem defekten SP führte, der von der Suchfunktion verwendet wurde. Das bedeutet, dass kein Fehler in VS und kein BL-Quellcode zum Verfolgen von Feldnamen vorliegt. Ein SELECT-Parameter für Sqlcommand wurde falsch geschrieben und führte zu einer Fehlfunktion eines Webformulars. Es wurde auch ein Feld weggelassen, bei dem es sich um das fehlende Feld in GridView (Autogeneratecolumns) handelte. Eine ASP.NET-Schaltfläche wurde auf etwas verwiesen, das als duplizierte, erweiterte Methode gedacht sein muss und "vergessen" hat, die Schaltfläche auf eine neue Methode zu verweisen.

Auch solche Kleinigkeiten, die title in einem HTML-Tag verwenden, lassen dies nicht zu. Das gegenüberliegende ALT-Tag wurde in einem Steuerelement, das es benötigte, ebenfalls weggelassen. Es gab auch einige Fehler mit unkorrekten geschlossenen HTML-Tags, die jedoch keine Fehlfunktion zeigten. Ich bin mir nicht sicher, ob all das ein reiner Spielhaus-Projektfehler oder vielleicht dasselbe Projekt für verschiedene Rekrutierungen war. Ich habe nie gefragt. Der Schwierigkeitsgrad sollte natürlich den Bedürfnissen des Rekruten entsprechen.

Ein solcher Test sollte wahrscheinlich überprüft (nicht befolgt) werden, um nach dem Interview zu sehen, wie das Debuggen durchgeführt wurde. Für mich selbst in diesem Stadium fand ich den Test ein wenig lächerlich, aber das wäre auch der große Punkt. Wenn es war oder nicht, sollte es viel wert sein, den Kandidaten an der richtigen Stelle zu haben.

* Ich denke , dass Test der Kandidaten / meine Fähigkeiten * bewiesen wurde
* Analyse einer fremden System
* Verwenden Sie eine minimale Informations Fehler und Fehler zu finden
* Unter Zeitstress und ohne dass jemand helfen Ihnen, Code angenommen Korrekturen Auf
verschiedenen Ebenen des Wissens *;
** SQL-Datenbank und gespeicherte Prozeduren,
** Verwendung von DLL im Projekt,
** ASP.NET-Technik,
** geschichtete Architektur
** problemorientierter Aspekt

Aber auch die offensichtlicheren Dinge wie der Umgang mit der Entwicklerumgebung finden und verstehen das Db Server Management Tool. Sicherlich gibt es Kandidaten, die auf dem Papier wirklich gut aussehen, sich aber in der Praxis an solchen Aufgaben festhalten könnten.

Ich wähle ein tatsächliches Problem aus, das für die Position relevant ist, und präsentiere es dem Kandidaten so, wie es mir präsentiert wurde. Natürlich biete ich ihnen einige allgemeine Hintergrundinformationen und eine kleine Menge relevanter Dokumentationen wie einen Codeausschnitt oder ein schematisches Diagramm.

Ich sage ihnen, dass es ihre Aufgabe ist, das Problem zu lösen, und ich biete ihnen an, alle technischen Fragen zu beantworten und ihnen das Ergebnis aller Experimente mitzuteilen, die sie durchführen möchten. Wenn sie sagen: "Ich würde hier eine Zielfernrohrsonde einsetzen", skizziere ich ihnen eine Spur dessen, was sie finden könnten. Wenn sie ein printfin eine Schleife einfügen wollen, werde ich ihnen sagen, dass es niemals herauskommt (!) Oder zuerst "7" und dann wiederholt "5" ausgeben. Wenn sie so weit vom Unkraut entfernt sind, dass ich keine aussagekräftigen Antworten geben kann, gebe ich zu, dass wir auf dem falschen Weg sind und woanders hin. Wenn sie stecken bleiben, stelle ich wichtige Fragen oder gebe Hinweise, bis wir weitermachen können.

Was ich sehen möchte, sind geordnete Denkprozesse, Entschlossenheit, zur Lösung zu gelangen, gut durchdachte Fragen und Experimente und im Idealfall eine erfolgreiche Identifizierung des Problems. Manchmal wähle ich Probleme aus, die zu komplex sind, um sie in einem einstündigen Interview vollständig zu debuggen, und am Ende gebe ich ihnen die richtige Antwort. An diesem Punkt suche ich nach einer Reaktion, die zeigt, dass sie mit dem Problem beschäftigt waren und diesen "Aha" -Moment und die Befriedigung erfahren, zur Ursache zu gelangen. Die besten Kandidaten werden zu diesem Zeitpunkt spontan Folgefragen stellen und versuchen, ihre mentale Karte des Problems mit dem zu verknüpfen, was wirklich vor sich ging.

Setzen Sie sich an einen Computer mit einigen einfachen Binärsymbolen (mit Debug-Symbolen), die standardmäßig mit einem Nullzeiger oder einem solchen + Quellcode + gdb versehen sind, und prüfen Sie, ob sie die Ursache für den Absturz finden können.

Wenn Sie von Ihren Kandidaten vorläufige Code-Tests durchführen lassen, bitten Sie sie, den Code während des Interviews zu ändern, um entweder einen Fehler zu beheben oder eine neue Funktion hinzuzufügen, oder besser beides. Wenn Sie die Codetestspezifikationen ziemlich vage gestalten, würde dies das Erstellen von Testfällen mit "Bugs" erleichtern.

Das Finden von "The Bug" in einem kleinen Code-Snippet ist eine sehr künstliche Situation. Ich nehme an, es könnte genauso hilfreich sein wie Rätsel und Denksportaufgaben.

Ein umfassenderer Ansatz würde verhaltensbezogene Fragen dazu stellen, wie der Kandidat in der Vergangenheit das Debuggen durchgeführt hat, wobei bestimmte Vorfälle angeführt und anschließend Fragen beantwortet werden.

Jemand, der gut in der Fehlersuche ist, kann über mehr als nur die Debug-Funktionen in der IDE sprechen. Was ist mit ... den Tools zur Fehlerberichterstattung, der Interaktion mit dem Endbenutzer, der Reproduktion des Fehlers, der Analyse der Protokolldateien und der Überprüfung?

Das Debuggen ist VIEL MEHR als das Durchsuchen eines Codeblocks, und jede Bewertung der Fähigkeiten einer Person beim Debuggen sollte dies widerlegen.

Geben Sie jemandem einen tollen Code, den Ihr Unternehmen in der Produktion ausführt. Bitten Sie sie, einen subtilen Fehler einzuführen. Fragen Sie sie, warum sie diesen ausgewählt haben. Fragen Sie sie, wie sie es finden und beheben würden.

Bonuspunkt, wenn sie einen Fehler im Originalcode finden.

Verdoppeln Sie den Bonuspunkt, wenn Sie den Fehler im Originalcode beheben können.

Ich neige dazu, die Leute zu bitten, mir den schwierigsten Fehler zu beschreiben, den sie jemals finden und beheben mussten, und was sie getan haben, um ihn zu finden und zu beheben. Ich weiß auch, dass, wenn der schwierigste Fehler etwas war, von dem man erwarten würde, dass er nur von Anfängern als schwierig empfunden wird, diese wahrscheinlich keine guten Problemlöser sind (es sei denn, dies ist ein Interview für Anfänger). Wenn es etwas wirklich Schwieriges ist und sie ihren Denkprozess beschreiben, während sie versuchen, ihn aufzuspüren, dann kann ich ein Gefühl dafür bekommen, wie gut sie sind. Was mich immer wieder erstaunt hat, ist die schiere Anzahl von Menschen, die einen "Hirsch im Scheinwerferlicht" sehen und sich kein einziges Beispiel für etwas vorstellen können, das kompliziert war. Tut mir leid, dass jemand, der die schwierigen Probleme jemand anderem überlässt, für nichts anderes interessiert ist als für einen Schulabbrecher.

Ich würde ein paar technologieunabhängige Fragen stellen, wie die folgenden:

• Führen Sie mich durch alle Schritte, die Sie unternehmen, um die Ursache zu ermitteln und einen Fehler zu beheben.
• Wie würden Sie den Call Stack beim Debuggen einer Multithreading-App verwenden?

Dies funktioniert besonders bei Telefoninterviews sehr gut, da Sie nur die Person benötigen, die Ihnen eine überzeugende Antwort gibt, die zeigt, wie es ihm bei der Behebung eines Problems wirklich geht.