Was sind die Vor- und Nachteile für den Arbeitgeber von Code-Fragen während eines Interviews? [geschlossen]

16

Die Joel-Test- Frage Nr. 11 lautet: "Schreiben neue Kandidaten während ihres Interviews Code?". Was spricht dafür und dagegen, neue Kandidaten aufzufordern, während des Interviews Code zu schreiben und eine Entscheidung darüber zu treffen?

Duros
quelle
Schreiben Sie Code wie in physisch mit einem Bleistift und Ihrer Hand oder schreiben Sie wie in Typcode auf einer Maschine?
Chris
Der Hauptbetrüger ist, dumme oder nutzlose Fragen zu stellen und zu denken, dass Sie es richtig gemacht haben. Zum Beispiel der Kommentar von jemandem, der gebeten wurde, eine linked_list zu schreiben.

Antworten:

13

Ich sehe die Nachteile nicht. Ein Interview besteht aus vielen Teilen, und ein Kandidat sollte ein paarmal „in die Höhe“ befürwortet werden.

Ich interviewe wöchentlich ~ 10 Leute. Ich bin wirklich sehr dankbar dafür, dass die Personalabteilung die gesamte Hintergrundarbeit geleistet und mir viele Notizen gemacht hat. Bis sie zu mir kommen, ist es Zeit für mich, ihre Tests zu bewerten.

Die Tests hängen vollständig von der Position ab. Im Allgemeinen versuche ich zu prüfen:

  • Allgemeine Programmierkenntnisse. Können Sie Operatoren effektiv einsetzen? Können Sie sich ein numerisches System vorstellen, das einen Radix ungleich 10 hat?

  • Wissen Sie, wie man das macht, wofür wir Sie beauftragen?

  • Bewertung Ihrer Beiträge zu Open Source-Projekten, die Sie aufgelistet haben

Ich versuche es kurz und lustig zu halten. Wenn ich ins Büro gehe, greife ich nach den Antworten, schaue sie mir an und führe dann ein Zweitinterview durch. Um eingestellt zu werden, müssen Sie normalerweise drei Interviews absolvieren.

Ich messe auch, wie gut Sie zu dem Team passen werden, das Sie empfängt. Dieses Team verlässt sich darauf, dass ich das effektiv mache.

Es ist eine Sache, Fragen in Meta-Form zu beantworten, eine andere, tatsächlich Code zu produzieren. Wenn ich Sie einstellen will, muss ich wirklich sehen, dass Sie Code produzieren.

Tim Post
quelle
Hmmm ... ich betrachte mich als qualifizierter Entwickler. Während meiner letzten drei Interviews, als ich nach etwas gefragt wurde, was eine bestimmte Methode tut oder etwas Ähnliches, habe ich beschlossen, es aufzugeben. Da ich nie einen Job suche, bei dem ich etwas machen soll, das ich sehr gut kenne. Es ist nicht interessant. Wie mein Ex-Chef sagte: "Wiederverwendbar? Programmierer sollten wiederverwendbar sein, Programme - vielleicht".
Duros
@ Duros Es tut mir leid, das zu hören. Ein guter Interviewer sollte in der Lage sein, den Prozess unterhaltsam zu gestalten. Er sollte erkennen, dass andere Programmierer Tests hassen.
Tim Post
Es ist nicht so, dass ich mich beim Testen nicht wohl fühle. Mir ist gerade klar, welche Möglichkeiten ich hätte, etwas Neues zu lernen und auszuprobieren, wenn sie mich als Programmierer einstellen würden ... Während des letzten schickte ich den Interviewer, um die Javadocs zu lesen ...: - / Vielleicht habe ich
Ich
10
Ich wurde einmal in einem Interview gebeten, Accessoren für eine verknüpfte Liste in Perl zu schreiben. In den 8 Jahren, in denen ich mit Perl gearbeitet habe, bin ich auf kein einziges Produktionsprogramm gestoßen, das verknüpfte Listen verwendet. Natürlich habe ich auf Papier Methoden zum Einfügen () und Entfernen () und ein Hash-basiertes Objekt erstellt, von dem ich dachte, dass es die Aufgabe erfüllen würde. Das erste, was der Interviewer sagte, als er sich die Zeitung ansah, war "Ihnen fehlen ein paar Semikolons"
leed25d
1
Es ist eine andere Sache, Code zu produzieren - das ist so, so, wahr. Ich war wiederholt überrascht von Leuten, die einen plausiblen Algorithmus beschreiben, ihn aber nicht einmal auf Code reduzieren können. Das oder sie sind über einen nicht algorithmischen Schritt gelaufen, der beim Schreiben von Code nicht vermieden werden kann.
Poolie
34

Mit Entschuldigung an Scott Whitlock:

Nachteile:

  • keiner

Vorteile:

  • Spart viel Zeit und Herzschmerz, wenn Sie nicht jemanden einstellen, der nicht programmieren kann
  • Erfordert, dass Sie eine technische Person im Interview haben
Armand
quelle
Kann "Erfordert, dass Sie eine technische Person im Interview haben" als Betrug angesehen werden?
Yeikel
1
Es hängt davon ab, ob Sie versuchen, eine Rolle zu besetzen oder nur einen Stuhl zu besetzen. Aber IMO nein, es kann nicht als Betrug angesehen werden.
Armand
19

Wenn Sie einen Jongleur einstellen würden, wären Sie verrückt, wenn er nicht für Sie jongliert. Oder ein Musiker, den Sie vorsprechen würden. Ansonsten bekommst du Sachen wie den tollen Jojo "Master" K-Strass .

Auf einem Whiteboard durch etwas zu laufen, ist das Äquivalent eines schnellen Demo-Jonglierens für Programmierer.

Whatsisname
quelle
+1 für den Link. Ich denke immer noch, dass Jonglieren sich nicht an Dinge wie Methodensignaturen oder ähnliches erinnert, sondern nur in der Lage ist, Probleme zu denken und zu lösen, denen Sie noch nie begegnet sind ...
Duros
4
Abgesehen davon, dass das Jonglieren eine unmittelbare Fähigkeit mit nur wenigen Varianten ist, die oft vor Publikum ausgeführt wird. Das Programmieren ist eine schwerfällige, tiefe Aufgabe, die selten als solche ausgeführt wird. Auch auf Papier oder Whiteboards ist es weitaus weniger produktiv. Trotzdem können Pseudocodetests (oder das Ignorieren trivialer mittlerer Fehler) sehr nützlich sein.
Bruce Alderson
10

Ich finde es super nützlich und mache es immer, aber da die Vorteile so gut abgedeckt sind, werde ich nur auf die (offensichtlichen) Nachteile eingehen.

Ich denke, Codetests geben Ihnen mit größter Wahrscheinlichkeit keine Fehlalarme: Die Wahrscheinlichkeit, dass jemand, der tatsächlich keinen Code schreiben kann, es schafft, ihn in einem Interview zu fälschen, ist gering, zumindest wenn Sie eine Skala von Fragen haben, deren Schwierigkeitsgrad zunimmt. (Vielleicht ist das wahrscheinlichste Szenario, dass sie betrügen, indem sie einen Freund fragen, ob es sich nicht um ein persönliches Interview handelt.)

Die Probleme sind eher falsch-negativ: Werden Codetests dazu führen, dass Sie die Person ablehnen, die tatsächlich der beste Kandidat ist?

Lampenfieber

Möglicherweise haben Sie jemanden, der eigentlich ein wirklich guter Entwickler ist, der jedoch sehr nervös in Bezug auf dieses Interview ist und der im Wesentlichen Lampenfieber bekommt. In gewissem Maße ist es wichtig, unter Druck aufzutreten, aber der Umgang mit Lampenfieber ist kein wesentlicher Bestandteil des Programmierens (im Vergleich zu anderen Berufen), und es wäre bedauerlich, jemanden abzulehnen, der darunter schwer leidet. Das kann noch schlimmer sein: Wenn die Person eine Frage nicht beantworten kann, von der sie weiß, dass sie sie beantworten sollte, kann sie enger werden. Oder, wie in dieser Frage , haben sie das Gefühl, nicht gleichzeitig sprechen und codieren zu können.

Schadensbegrenzung: Beginnen Sie mit einigen Fragen zum Kennenlernen des Hintergrunds, der Ziele usw., bevor Sie technische Fragen beantworten. Beginnen Sie vielleicht mit einigen einfacheren technischen Fragen, damit sie etwas Schwung bekommen. Seien Sie während des Interviews kein Dick (streiten Sie sich über Semikolons usw.).

Es ist ein lautes Maß

Interessante Code-Fragen haben möglicherweise mehr als eine richtige Antwort. Wenn eine Person eine korrekte und eine effizientere Antwort schreibt, wie viel Gewicht sollten Sie darauf legen?

In gewissem Maße ähnelt dies dem Problem mit einigen "Rätsel" -Fragen: Die Person hat entweder die Einsicht oder nicht, und Sie erhalten ein nahezu binäres Ergebnis. Die Intelligenz beeinflusst wahrscheinlich die Wahrscheinlichkeit, diese Einsicht zu haben, aber nur wenige Stichproben geben Ihnen ein grobes Maß.

Das stört mich an Code-Fragen (obwohl ich sie immer noch benutze). Die beste Minderung, die ich mir vorstellen kann, ist, so viele mögliche Lösungen wie möglich zu haben: Die Person kann zumindest eine grobe Brute-Force-Antwort oder eine Antwort auf diese schreiben ein Teil des Problems. Zu erkennen, dass das besser ist als nichts, ist ein gutes Zeichen. Wenn sie dann mehr entdecken, können sie den Code effizienter oder eleganter gestalten. Vermeiden Sie es so weit wie möglich, Fragen zu stellen, die binäre Antworten erhalten.

Es ist nicht wirklich repräsentativ

Das Programmieren ist nicht die Aufgabe, zehnminütige algorithmische Probleme nacheinander zu lösen: Es gibt viel mehr Arbeit, um größere Systeme zu verstehen und zu entwerfen und sich über längere Zeiträume zu konzentrieren, ganz zu schweigen von den zwischenmenschlichen Fähigkeiten. Code-Fragen testen das nicht wirklich.

Code-Fragen sind jedoch nicht die einzigen Fragen, die Sie stellen werden: Sie können sich ihren Hintergrund, ihre Referenzen, ihre Open-Source-Arbeit (falls vorhanden) ansehen, um Beweise für anhaltende Anstrengungen, Kreativität und zwischenmenschliche Fähigkeiten zu finden.

Zu wissen, wie man kleine algorithmische Probleme löst und wie man sie in Code umwandelt, ist eine notwendige, aber nicht ausreichende Bedingung: Wenn Sie kleine Probleme nicht lösen können und keinen nicht trivialen Code schreiben können, ist all das Gesamtdenken der Welt nicht ausreichend Sie werden zu einem produktiven Entwickler.

Jeder könnte das lösen

Nein, anscheinend nicht. Wie der berühmte FizzBuzz-Post hervorhebt , sind Probleme, von denen Sie denken, dass sie nicht nur neue Absolventen sind, sondern auch Leute mit langjähriger Branchenerfahrung. Ich weiß nicht warum. Entweder ist der Code-Test eine schlechte Maßnahme (was, obwohl ich für unwahrscheinlich halte, möglich ist), oder sie haben in ihrem Lebenslauf nicht viel zu den Projekten beigetragen, oder sie haben viel erreicht, indem sie nicht algorithmischer Code (was möglich ist.)

Es lohnt sich anzuerkennen, dass Sie wirklich viel erreichen können, ohne einen algorithmischen Code zu schreiben. Die Leute verdienen eine Menge Geld mit Apps, deren Wert in der Grafik oder Geschäftslogik liegt, nicht in dem, was man "Programmieren" nennt, und das ist in Ordnung. Wenn Sie jedoch Programmierer benötigen, ist dies keine gute Lösung.

Möglicherweise ist es nicht gut kalibriert

Wenn Sie eine Frage haben, scheint Ihnen die Antwort sehr einfach zu sein. Wenn Sie jedoch eine vergleichbare Frage aus heiterem Himmel oder eine Frage stellen, die nicht auf Ihre eigenen Interessen und Hintergründe zugeschnitten ist, ist dies möglicherweise viel schwieriger.

Schadensbegrenzung: Führen Sie die Tests bei einigen Entwicklern durch, die Sie bereits kennen, und sehen Sie, wie sie vorgehen. Vielleicht hat jemand in Ihrem Team, von dem Sie wissen, dass er sehr schlau ist, Probleme mit einem von ihnen, und Sie können eine Anpassung in Betracht ziehen. Vielleicht fällt ihnen eine bessere oder andere Antwort ein.

Es ist zu viel wie Kleinigkeiten

Ich denke, Code-Fragen können mit Sicherheit eine Rolle spielen, wenn Sie darauf bestehen, dass die Leute obskure APIs auswendig können, die Syntax perfekt ist oder sich an die genaue Definition eines nichttrivialen Algorithmus erinnern. All dies ist vernünftig, um sich auf Dokumente, Websuchen oder Compilerfehler zu verlassen, und hat nur eine geringe Korrelation mit echtem Fachwissen. Nicht einmal zu wissen, wo die API wahrscheinlich ist, ist vielleicht ein Hinweis darauf, dass die Person sie in letzter Zeit nicht verwendet hat, aber das ist nicht unbedingt ein Problem, solange sie nicht in ihrem Lebenslauf liegt.

Die Antwort darauf ist also ziemlich einfach: Stellen Sie keine trivialen Fragen und lassen Sie sich nicht auf triviale Fehler ein. Erinnern Sie den Kandidaten daran, wie die API aufgerufen wird, oder lassen Sie ihn nachschlagen. Syntaxfehler beheben; Testen Sie nicht für Personen, die sich Datenstrukturdefinitionen merken.

Wie vergleichst du?

Wenn Sie zwei Kandidaten haben und beide die Fragen gut beantworten, wie wählen Sie zwischen ihnen aus? Sie könnten den schnellsten wählen, aber vielleicht fangen Sie dort an, Hasen über Schildkröten zu pflücken. Du könntest eine weitere Runde machen und viel schwierigere Fragen stellen, aber da bin ich mir auch nicht sicher. Vielleicht geben Sie beiden einfach ein A + und versuchen, nach anderen Kriterien zwischen ihnen zu wählen (oder versuchen, das Geld zu finden, um beide zu engagieren).

Poolie
quelle
7

Ein Nachteil, den ich mir vorstellen kann, ist, dass es schwierig ist, vor anderen Leuten laut zu "codieren". Es fällt mir schwer, mit jemandem zu tippen, der mir über die Schulter schaut, und ich bin nicht allein. Ich bemerke, wenn mich jemand an seinem Arbeitsplatz anruft, um mir bei irgendetwas zu helfen, fängt er plötzlich an, Tippfehler zu machen, die falsche Code-Vervollständigung auszuwählen und sogar regelrechte Fehler zu machen - keine, die er gemacht hätte, wenn ich nicht genau da gesessen hätte. Verdammt, ich habe Leute gesehen, die das Menü für das Ausschneiden und Einfügen benutzt haben, nur weil sie beobachtet wurden. Dies ist kein normales Verhalten, und die Codierer, von denen ich spreche, sind ausgezeichnete Programmierer und außerdem ziemlich schlau.

Ich hatte kürzlich ein Interview, in dem der Interviewer mich fragte, wie ich eine bestimmte Operation codieren würde, und er sagte: "Zeigen Sie mir einfach die Mathematik." Nun, ich musste zuerst über das Problem nachdenken, bevor ich mich der Mathematik zuwandte, also musste ich säumen und hauen. Was ich anfangs auf die weiße Tafel legte, war peinlich und ich hatte das Gefühl, zu diesem Zeitpunkt zu verlieren. Ich bekam schließlich den A-ha-Moment und fand die Antwort (tatsächlich, als mir endlich einfiel, was er wirklich fragte), aber das "Durcheinander", das ich machte, bevor ich dort ankam, ließ mich sehr unwohl fühlen. Trotzdem bekam ich den Job, aber wenn der Interviewer weniger geduldig gewesen wäre, hätte ich ihn vielleicht nicht.

Ich denke, wenn Sie den Befragten eine Codierungsaufgabe geben, geben Sie ihnen Zeit, um sie auf einem Computer auszuarbeiten, vielleicht sogar in einer IDE, die sie kennen. Lassen Sie sie den Code für Sie schreiben und dann darüber sprechen. Fragen Sie sie, warum sie bestimmte Dinge getan haben und ob ein anderer Weg möglicherweise nicht besser ist. Sie werden mehr aus dieser Art von Prozess herausfinden, als sie zu bitten, (im übertragenen Sinne) direkt vor Ihnen in eine Tasse zu pinkeln.

Robusto
quelle
4
Das ist aber ok. Das Ziel einer Frage zum Codieren von Interviews besteht nicht darin, die Schreibfähigkeit oder sogar das perfekte Wissen über die API zu testen. Tippfehler und so weiter können ignoriert werden. Stattdessen konzentrieren Sie sich auf den Denkprozess des Kandidaten und die Vertrautheit mit den Grundlagen der Programmierung. Zum Beispiel war ich einmal Teil eines Interviews, das zeigte, dass der Kandidat nicht in der Lage war, ein paar Schritte vorauszudenken (sie haben ein kleines Problem behoben, erkannt, dass ein anderes Problem entstanden ist usw.).
Adam Lear
2
Es ist "schwer, vor anderen Leuten zu programmieren"? Fein. Ich stelle nur Leute ein, die harte Dinge können. Einer von ihnen ist in der Lage, Code (dh Programm) mit (vor) anderen Leuten zu diskutieren.
Kevin Cline
1
@ Kevin Cline: Du vermisst meinen Standpunkt. Interessiert es Sie, wie Menschen Ergebnisse erzielen, oder möchten Sie nur, dass sie Ergebnisse erzielen, die Ihren Launen entsprechen? Viele Leute können in einer Teamumgebung gut programmieren, brauchen aber "Zeit für sich", um mit höchster Effizienz zu produzieren. Sie klingen wie ein Typ, der Mark Zuckerberg nicht engagiert hätte, weil er für maximale Produktivität "eingekabelt" werden musste.
Robusto
1
@Robusto: Ich stelle keine tiefen Fragen in einem Interview. Ich muss nur jemanden sehen, der ein einfaches Problem in wenigen Minuten löst. Und ich brauche Leute, die in einem Team arbeiten können. Dies bedeutet die Fähigkeit und Bereitschaft, über Code zu sprechen. Klar, ich vermisse vielleicht einen großartigen Programmierer, der einfach nicht mit dem Druck eines Interviews umgehen kann. Das ist okay. Aber eine schlechte Einstellung ist katastrophal.
Kevin Cline
6

Nachteile: Keine. Jedes Mal, wenn Sie einen PC einrichten, einen Code-Test entwerfen und ihn überprüfen, werden Sie in Zukunft ungeahnte Kopfschmerzen haben.

Vorteile: "Vertrauen, aber überprüfen" - Ronald Regan. So oft habe ich Menschen gesehen und gehört, die endlich von einer Position losgelassen wurden, von der Sie im Interview dachten, Sie bekämen einen Rockstar. Der Beweis ist im Pudding; Ich möchte sehen, was sie tun können. Es wird darstellen, was passiert, wenn Sie Zeit und Geld investieren, um jemanden einzustellen und ein neues Projekt vor sich zu haben.

HardCode
quelle
4

Nachteile:

  • Erfordert, dass Sie eine technische Person im Interview haben

Vorteile:

  • Spart viel Zeit und Herzschmerz, wenn Sie nicht jemanden einstellen, der nicht programmieren kann
Scott Whitlock
quelle
25
Wenn Sie Entwickler interviewen, ohne dass technische Mitarbeiter teilnehmen, sind Sie sowieso zum Scheitern verurteilt.
David Thornley
@ David: Ich stimme zu, ich denke, die Vorteile hier überwiegen bei weitem die Nachteile, aber es war das einzige "Manko", an das ich denken konnte.
Scott Whitlock
4

Bei einem Vorstellungsgespräch für meinen aktuellen Job erhielt ich vom Personalvermittler eine Liste mit Fragen, für die ich den Code schreiben musste. Ich war sehr beeindruckt, weil die Fragen offensichtlich von jemandem geschrieben wurden, der sich mit SQL gut auskannte, so dass es in beide Richtungen funktioniert.

Larry Coleman
quelle
2

Sie möchten wirklich , dass die Person Code in das Interview schreibt - und noch besser, dass sie das Programm mit einem Mitglied Ihres Teams über einen Zeitraum von X paart (was immer Sie sich zeitlich und personell bequem leisten können).

Es ist so ziemlich die einzige Möglichkeit, festzustellen, ob diese Person codieren kann oder nicht.

Ich bevorzuge die Paarprogrammierung ein wenig, da sie die Teamarbeit demonstriert, ihnen eine echte IDE zur Verfügung stellt und sie an einem „echten“ Problem arbeiten lässt (die andere Person im Paar kann sie an Umgebungsspezifikationen vorbeiführen, die der Befragte hat) könnte es nie vernünftigerweise wissen).

Wir haben begonnen, diese Einstellungspolitik anzuwenden und sind mit den Ergebnissen sehr zufrieden.

Martijn Verburg
quelle
+1 für Paartests: beweist sowohl die Fähigkeit, mit einem Teamkollegen zusammenzuarbeiten, als auch die Fähigkeit, Code zu schreiben.
Bruce Alderson
2

Sie beurteilen einen Vogel nach seinen Federn und einen Programmierer nach seinem Code.

Als ich mit der aktuellen Firma anfing, für die ich arbeite, wurde ich gebeten, einen C-Code zu schreiben, der das Paritätsbit einer Binäreingabe generiert oder überprüft (abhängig davon, ob Sie codieren oder decodieren). Dies war eine Interviewfrage, genau weil diese Art von Problemen während der Arbeit gelöst werden. Natürlich denke ich nicht an die Paritätsprüfung, sondern arbeite auf einem niedrigen Niveau.

Ende
quelle
2

Alle bisherigen Antworten (die ich gelesen habe) haben nicht die Tatsache angesprochen , dass der Joel-Test NICHT (nur) eine Best-Practice-Liste für Unternehmer ist, sondern eine Checkliste, die Ihre Bewertung eines potenziellen Arbeitgebers erleichtert .

Die Sache ist ... wenn sie ihre Kandidaten gründlich testen, dann stellen sie wahrscheinlich Leute ein, die sich mit ihren Sachen auskennen ... das bedeutet für Sie

  1. weniger Kopfschmerzen und auch
  2. die erhöhte Chance , etwas von Ihren Mitarbeitern zu lernen

anstatt nach ihnen Fehler zu beheben ...

Raffael
quelle
1

Ich würde sagen:

Vorteile

  • Zeigt, dass der Kandidat zumindest über ausreichende Programmierkenntnisse verfügt, da Lebensläufe fabriziert / verschönert werden können
  • Wenn der Interviewer den Kodex mit dem Kandidaten bespricht, im Gegensatz zu einem schriftlichen Test, könnte dies ein guter Indikator dafür sein, wie Sie sich sozial "vernetzen" und ob der Kandidat gut zu dem Unternehmen / der Firma passt und das Team gut ist passt für den Kandidaten

Nachteile

  • Könnte für Kandidaten eine Beleidigung sein, wenn die Fragen roter / trivialer Unsinn sind, der während des Jobs niemals auftauchen würde (z. B. "Schreibe eine Blasensorte", wenn in allen modernen Frameworks, die man für den Job verwenden würde, eine Sortierung eingebaut ist, "Kehre einen String um "Wenn es eine eingebaute ReverseMethode oder ähnliches gibt, oder für schriftliche Tests Dinge wie" Was sind die Argumente für die FooMethode der BarKlasse ", wenn jeder Idiot diese googeln oder die Dokumentation benutzen könnte, im Gegensatz zu Architektur- / Designfragen, die zeigen Der Kandidat kann Dinge erledigen und geschäftliche Probleme lösen .
Wayne Molina
quelle
1
Ich denke, "Reverse a string" ist eine hervorragende Ausgangsfrage in einem Coding-Interview. Wenn sie nicht wissen, wo sie anfangen sollen (und eine erstaunliche Anzahl von Leuten nicht), möchten Sie sie wahrscheinlich nicht einstellen. Wenn sie die eingebaute Methode verwenden, ist das gut - es sagt Ihnen, dass sie nicht versuchen werden, ihr eigenes Rad zu bauen, wenn eines bereitgestellt wird - aber dann eine hypothetische Situation präsentieren, in der die eingebaute Methode einen Fehler aufweist, so dass sie müssen ihre eigenen schreiben. Sie können den Code dann als Ausgangspunkt verwenden, um andere Fragen zu stellen, z. B. zur Behebung von Fehlern, Speichernutzung, Laufzeit usw.
Gabe,
0

Ein Pro ist, dass es zeigt, dass jemand Grundkenntnisse in Programmierung oder was auch immer hat (als ich das letzte Mal darauf gestoßen bin, war ich überrascht, wie grundlegend die SQL-Frage war). Es kann auch als Grundlage für eine technische Diskussion dienen, in der gefragt wird, warum der Kandidat dies und jenes getan hat und wie es verbessert werden könnte.

Es braucht Zeit im Interview, die für andere Dinge verwendet werden könnte. Darüber hinaus ist das Schreiben von Code auf einem Whiteboard keine natürliche Umgebung, und manche Menschen haben immer weniger ernsthafte Probleme damit. Es könnte dazu führen, dass Sie einen Entwickler vermissen, der ohne normale Tools oder Referenzen nervös wird.

David Thornley
quelle
3
Was Sie noch mehr überraschen würde, war, wie viel mehr Menschen diese grundlegende Frage nicht beantworten konnten als wer.
HLGEM
0

Das Programmieren ist eine hochtechnische Fähigkeit mit einer Reihe klarer "Leistungen". Entweder kann ein Kandidat sie liefern oder nicht. Es gibt also keine "Nachteile", technische Fragen zu stellen. Es ist nur zu sagen: "Zeigen Sie mir Code für diese Anwendung, oder" Zeigen Sie mir den Code für eine Anwendung, die Sie bereits geschrieben haben. "

Dies NICHT zu tun, kann zu folgendem Ergebnis führen: Ein reicher Mann hat einen Tutor befragt, um seinen Kindern das Schachspielen beizubringen (als geisteserweiternde Übung). Der Tutor öffnete ein Schachbrett und begann über die 64 Felder zu sprechen, berührte aber keine Schachfigur. Aus Zeitgründen stellte der Vater den Tutor trotzdem ein. Und der Tutor brachte den Kindern bei, CHECKERS zu spielen.

Tom Au
quelle
Das zeigt nur ein Beispiel eines inkompetenten Interviewers, nicht die Notwendigkeit, tatsächlich Schach in einem Interview zu spielen. Der reiche Mann hätte mich einfach bitten können, mir Castling oder ähnliches zu erklären, und sofort eine Vorstellung davon bekommen, was der Tutor wusste.
GroßmeisterB