Ist „White-Board-Coding“ während eines Interviews unangemessen? [geschlossen]

Dies ist eine etwas subjektive Frage, aber ich würde gerne Feedback / Meinungen von Interviewern / Befragten zu dem Thema hören.

Wir haben unser technisches Interview in 4 Teile geteilt. Schreiben Sie Code, lesen Sie und analysieren Sie Code, entwerfen Sie Sitzung u. Code auf der weißen Tafel.

Als letzten Teil bitten wir die Befragten, einen kleinen Codeausschnitt (4-5 Zeilen) auf das Whiteboard zu schreiben und zu erklären, wie sie diesen durchlaufen. Lassen Sie mich klarstellen, dass der Zweck nicht darin besteht, die Leute zu überlisten. Wir suchen keine perfekte Syntax. Zum Teufel kann es sogar Pseudocode sein. Aber es geht darum, ihnen ein sehr einfaches Problem zu geben und zu sehen, ob ihr Gehirn uns die Lösung mitteilen kann. Mit einfachen Problemen meine ich "Reverse a String", "FizzBuzz" etc ...

Beachten Sie, dass wir immer zuerst nach einer expliziten Sprache fragen. Wir sind ein .NET C # -Haus. Wir haben nur "Pseudo-Code" gesagt, bei dem sich jemand wirklich mit dem Code abgefunden hat.

Meine Frage lautet: "Ist es unangemessen / unvernünftig, zu erwarten, dass ein Programmierer während eines Interviews einen Codeausschnitt auf ein Whiteboard schreibt?"

Meiner Meinung nach ist es sehr angemessen. Wenn Sie möchten, dass ein Job eine bestimmte Fähigkeit ausübt, ist es durchaus angemessen, diese Fähigkeit beim Vorstellungsgespräch unter Beweis zu stellen.

Die Auswirkung dieser Technik auf den Rekrutierungsprozess ist sehr deutlich. 90% der Kandidaten scheitern an dieser Aufgabe. Aber die angeworbenen Entwickler sind gut und die Entwickler werden innerhalb des Unternehmens respektiert.

Wenn Sie als Kandidat mit dieser Technik konfrontiert sind, entspannen Sie sich zunächst. Es geht darum, Sie als Programmierer und Ihre Denkprozesse einzuschätzen. Es geht nicht um Ihre perfekte Syntax. Wenn Sie einen Syntaxfehler machen, spiele ich möglicherweise die Rolle eines Compilers und sage Ihnen, dass der Code in einer bestimmten Zeile nicht kompiliert werden kann. Sie erhalten eine Fehlermeldung und sehen, wie Sie reagieren. Ebenso, wenn Sie ein; Auf eine Schleife oder eine if-Anweisung, die kompiliert werden würde, würde ich den Debugger spielen und Sie durch einen einzelnen Schritt durch den Code führen. Auch hier geht es nicht um den Fehler, sondern darum, wie Sie mit dem Fehler umgehen würden und ob Ihre Denkprozesse gut sind.

Meine Frage lautet: "Ist es unangemessen / unvernünftig, zu erwarten, dass ein Programmierer während eines Interviews einen Codeausschnitt auf ein Whiteboard schreibt?"

Es ist sehr vernünftig. Eine Alternative zu einem Whiteboard könnten ein Laptop und ein Beamer sein, da Programmierer eher daran gewöhnt sind, Code auf einer Tastatur als auf einem Whiteboard zu schreiben. Stellen Sie einfach sicher, dass eine Entwicklungsumgebung wie Eclipse oder VS oder Idle bereits mit einem leeren Projekt ausgeführt wird, wenn der Kandidat startet, damit er keine Zeit mit der Suche in Ihren installierten Anwendungen verschwenden muss.

Es ist nicht unangemessen, aber zu wissen, dass es möglicherweise NICHT immer die wahren Einsichten in die Programmier- oder Problemlösungsfähigkeiten der befragten Person preisgibt. Und genau danach streben Sie wohl.

Zweitens ist zu beachten, dass es immer die Angst vor dem Versagen gibt, das Gehirn der Person ständig zu betäuben. "Was, wenn ich es vermassle?", "Was, wenn ich einen dummen Fehler mache". Der größere Teil des Gehirns der Person ist ständig damit beschäftigt zu überprüfen, wie es ihnen geht - nur wenige können die Nerven halten.

In einer solchen Situation könnten selbst die Besten ins Stocken geraten.

Als letzten Teil bitten wir die Befragten, ein kleines Code-Snippet (4-5 Zeilen) auf das Whiteboard zu schreiben und zu erklären, wie sie es durchlaufen

Das ist ok. Aber nur weil jemand etwas nicht richtig erklären kann, heißt das noch lange nicht, dass er es nicht gut kennt. (Erklärung ist eine Redekunst).

Wenn ich du wäre, würde ich das für den letzten Teil tun ...

Stellen Sie sie für ein sehr kleines (aber realistisches) Projekt ein. Sehen Sie, wie sie codieren, Entscheidungen treffen, die Arbeitsbedingungen und die Teammitglieder anpassen usw., und treffen Sie dann basierend auf diesen die endgültige Entscheidung.

Nicht unangemessen, aber denken Sie daran, dass manche Leute (und vielleicht ein größerer Teil der Programmierer) in einem Interview sehr gestresst sein können. Ich denke, die meisten von uns kennen den Typ aus dem Büro, der ein brillanter Programmierer und eine sehr vertrauenswürdige Person ist, aber in einer solchen Situation würde er zusammenbrechen. Seine Leistung konnte in einem solchen Test nicht gemessen werden, machen Sie dies also nicht zu einem Go / No-Go-Test.

Ich persönlich denke, dass dies eines der besten Dinge ist, die Sie tun können. Wie Sie sagten, suchen Sie nicht nach der richtigen Syntax oder etwas Ähnlichem. Das Wichtigste dabei ist, zu sehen, ob jemand kommunizieren kann. Ich habe so viele gute Entwickler gesehen, die nur alleine in ihrem eigenen Bereich arbeiten können ist in einer Vielzahl von Fällen nicht möglich, daher ist es ein wertvolleres Mitglied des Teams, einen erfahrenen Mann zu haben, der auch in der Lage ist, klar und präzise zu sagen, was er denkt, als jemand, der denkt: "Sie werden es nicht verstehen jedenfalls mache ich es einfach selbst und zeige es später ".

Kommunikation, Kommunikation, Kommunikation - das ist die Grundlage für jedes mittelgroße bis große Projekt (auch wenn es einmal kleiner sein muss).

Ich denke, es ist keine vernünftige Sache. Wir versuchen, Kandidaten zu finden, die die von ihnen gewünschte Aufgabe gut erfüllen. Das Schreiben von Code auf einem Whiteboard gehört nicht dazu, und ich denke nicht, dass es ein gültiger Filter ist, um gute Kandidaten zu finden.

• Guter Code wird nicht geschrieben, sondern neu geschrieben. Ein Whiteboard ist ziemlich unveränderlich, da es schwer zu ändern ist, wenn Sie es einmal geschrieben haben. Es sollte so einfach wie möglich sein, Ihre Meinung zu ändern, sobald Sie das Problem besser verstehen.
• Die Teilnahme an einem Vorstellungsgespräch ist eine stressige Situation. Es ist nicht erforderlich, den Kandidaten zusätzlich unter Druck zu setzen. Viele Computerleute haben keine gute Handschrift. Moderne IDEs bieten viele Tools, an die Sie gewöhnt sind. Und in der Lage zu sein, etwas in der Minute zu googeln, in der Sie es benötigen, gehört auch zum Arbeitsstil der meisten Programmierer. Warum all diese Dinge wegnehmen und eine künstliche Umgebung schaffen, in der sie niemals arbeiten müssen, wenn Sie ihnen ein Angebot machen?
• Wir sind auch sehr daran interessiert, gute Tests zu schreiben, vielleicht sogar TDD zu machen. Dies ist während der Whiteboard-Codierung nicht zu sehen.

Die meisten Hinweise, die Sie aus einer Whiteboard-Codierungssitzung herausholen können, können Sie auch aus einer Pairing-Sitzung herausholen. Ich glaube, Pairing ist ein viel besseres Instrument, um ein Gefühl dafür zu bekommen, wie ein Kandidat ein Problem löst und wie er arbeitet. Er kann seinen eigenen Computer mitbringen und in einer Umgebung arbeiten, in der er sich wohlfühlt. Und es ist viel einfacher, sich auf die Aufgabe zu bewerben, die sie erledigen sollen, wenn sie erst einmal dabei sind. Wir haben zum Beispiel eine große alte Codebasis, deshalb bitten wir sie, extrahierten Code für das eigentliche Projekt umzugestalten. Tatsächlich arbeiten wir so gut wie möglich in unserer täglichen Arbeit zusammen.

Während eine Whiteboard-Sitzung wahrscheinlich hilft, schlechte Kandidaten herauszufiltern, filtert sie wahrscheinlich auch viele gute Programmierer heraus.

Persönlich würde ich jeden Interviewer verlassen, der mich auffordert, FizzBuzz zu machen. Ich weiß nicht, wann dies der neue Industriestandard wurde, aber es ist wirklich Zeitverschwendung. FizzBuzz ist ein Filter, der vor einem Interview verwendet werden kann, obwohl ich persönlich denke, wenn ich aus N Kandidaten auswählen müsste, von denen genug Open-Source-Code oder ein Blog vorhanden sind, das ich mir ansehen kann, würde ich das definitiv als Filter vorziehen .

Einfach ausgedrückt, denke ich, dass in einem Interview für eine Programmierposition (außer vielleicht für Junioren oder Praktika) bereits festgelegt sein sollte, dass der Befragte programmieren kann.

Aber ja, Whiteboard ist perfekt, obwohl ich denke, dass Sie eine andere Reihe von Problemen haben sollten. Werfen Sie ihnen ein reales Problem und lassen Sie sie eine Reihe von UML-ischen Squibbles zeichnen, um ihre Gesamtstrategie zur Lösung dieses Problems zu erläutern. Geben Sie ihnen einen Computer mit Internet, damit sie nach Bibliotheken von Drittanbietern suchen können, die sie als Blackbox in ihrer Squibblescape verwenden können.
Innerhalb weniger Minuten werden Sie wirklich sehen, wie sie Probleme angehen. Sie können dies tatsächlich zu einer sehr interessanten Sache machen, indem Sie Probleme auswählen, für die Sie nicht unbedingt eine Lösung im Sinn haben, und versuchen, sie gemeinsam zu "lösen", um zu sehen, wie gut sie kommunizieren und wie gut sie Eingaben einbeziehen können (wie auch immer treiben sie nicht zu fest an - manche Leute frieren vielleicht ein, wenn Sie das tun). Und fügen Sie dann einige Anforderungen im Handumdrehen hinzu. Dies entspricht einer Softwareentwicklung ohne Implementierung und vor allem ohne Debugging. 15 Minuten sind also viel Zeit.

Lassen Sie mich mit einer anderen Frage antworten:

Bietet das Schreiben von Code auf einer weißen Tafel einen echten Vorteil bei der Beurteilung der Programmierfähigkeit im Vergleich zum Schreiben und Ausführen des Codes auf einem Computer?

Ich halte es für absolut angemessen, einen Kandidaten zu bitten, in einem Interview Code zu schreiben. Die Fähigkeit, den Code auszuführen, ist für mich jedoch ein kritischer Teil der Rückkopplungsschleife, aus der sich die Programmierung zusammensetzt. Auf einer weißen Tafel binden Sie eine Hand hinter meinem Rücken, und Sie bekommen kein vollständiges Bild davon, wie ich mit einem Problem umgehe.

Nein, aber IMO wäre ein besserer Ansatz, das Whiteboard für den beabsichtigten Zweck zu verwenden und UML / Skizzen / Notizen für ein fiktives Projekt zu verwenden, anstatt die alte "Schreibe mir eine SQL-Abfrage, um alle Datensätze zu erhalten" oder "schreibe eine Methode, die" kehrt einen String um ".

Eines der besten Interviews, das ich hatte, bestand darin, etwa 20 Minuten lang mit dem leitenden Entwickler über die Architektur (keine Software) einer Villa für verrückte Wissenschaftler zu diskutieren (komplett mit geheimem Versteck, Todesstrahl und Hundehütte). Er hat meine Herangehensweise an das Lösen von Problemen gesehen, und das Problem war etwas, das Spaß machte und kein typisches rotes Programmierzeug, das von modernen Sprachen tausendfach gelöst wurde. Übrigens habe ich auch schon mal so einen Code gemacht, aber ich fühlte mich viel mehr "unter Druck" als mit dem Architekturteil.

Heutzutage wird viel in Teams programmiert. Damit Teams arbeiten können, müssen Menschen kommunizieren können. Ein großer Teil davon ist die Möglichkeit, vor einem Whiteboard zu kommunizieren (Brainstorming, Mentoring, Überprüfung der vorgeschlagenen Korrekturen usw.).

Ich würde nachsehen, ob der Kandidat die Lösung eines Programmierproblems mit Whiteboard-Code erklärt. Wenn die Erklärung gut genug ist, werden die anderen guten Programmierer im Raum Tippfehler / Fehler auf der Tafel automatisch korrigieren.

Für die meisten Arten von Teampositionen wäre es unvernünftig, von einem Kandidaten NICHT zu erwarten, dass er seinen Lösungsversuch erklären und kritzeln kann.

Nein, es ist eine gute Sache, für ein Interview zu codieren, aber Sie sollten Code in jeder vernünftigen Sprache zulassen, da es in der Regel einfacher ist, einen Kodierer, der mit einer anderen Sprache konkurriert, zu schulen, als einen so lala Kodierer in der Sprache zu bekommen, die Sie wollen auf ein konkurrierendes Niveau.

Ich würde sagen, es ist angemessen, aber in den meisten Fällen ist es kein effizienter Weg, um herauszufinden, wer gut in der Programmierung ist und wer nicht. Wenn Sie einen Job erledigen möchten (= jemanden einstellen, der fähig ist), sollte sich das Interview auf die Messung der realen Fähigkeiten konzentrieren. Bisher das beste Interview, an dem ich so gearbeitet habe:

• Grüße, willkommen von HR.
• Ein paar Worte über mich, über die Firma usw. und sie erklärte den Rest des Interviews.
• Sie gab mir einen Laptop mit einem Programm, bei dem nur wenige Teile fehlten, und die Unit-Tests waren deshalb fehlgeschlagen. Die fehlenden Teile wurden dort als Texte kommentiert, es ging darum, eine Grundaufgabe wie die Herstellung einer Verbindung zwischen wenigen Klassen und die Einführung einer einfachen Geschäftslogik umzusetzen.
• Wenn alles gut lief, wurden die Unit-Tests grün.
• Verabschiedung und Einverständnis, in wenigen Tagen wiederzukommen.
• An diesem Tag traf sich der Leiter mit mir und fragte nach dem fertigen Programm, was ich getan habe und warum.
• Auch dieser Anführer fragte nach meinen früheren Erfahrungen und nach einigen anderen Fragen.

Um es zusammenzufassen: Wenn Sie Mitarbeiter in einem Produktionscode suchen, testen Sie deren Fähigkeiten in der realen Umgebung. Wenn Sie neugierig auf ihr theoretisches Wissen sind, ist es besser, sie nach diesen Dingen zu fragen. Wenn Sie von der IDE befreit sind oder nervös sind, weil Sie vor jemandem auf Whiteboard programmieren müssen, kann ich verstehen, dass vor allem in der IT manchmal Leute introvertiert sind und viele von uns mit diesen Situationen nicht gut umgehen können, also auf Weiß An Bord wird unsere Effizienz schlechter aussehen, als es tatsächlich ist.

Ich finde es nicht unvernünftig, wenn der Befragte keine schlechte Handschrift hat (oder ich sollte Boardwriting sagen) :-). Der einzige Unterschied in Ihrer Herangehensweise besteht in der Verwendung einer Tafel und eines Markers. In einigen Fällen tun die Interviewer dies, geben aber stattdessen ein Blatt Papier und einen Stift. Wenn 3-4 Personen das Interview führen, würde ich sagen, dass Ihr Ansatz viel besser und geeigneter ist.