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?
Antworten:
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.
Mit Entschuldigung an Scott Whitlock:
Nachteile:
Vorteile:
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.
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).
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.
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.
Nachteile:
Vorteile:
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.
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.
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.
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
anstatt nach ihnen Fehler zu beheben ...
Ich würde sagen:
Vorteile
Nachteile
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 .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.
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.