Sie nötigen einen Programmiertest. Aber es sollten 5-10 Minuten sein. Höchstens 30 Minuten. Es gibt keinen 2-stündigen Test, der Ihnen genau sagt, wie gut ein Programmierer ist. Sie werden nicht in der Lage sein zu sagen, ob sie ständig wartbaren Code schreiben, oder ob sie immer richtig kommentieren, oder ob sie mit einem unleserlichen Durcheinander von “cleveren” Problemlösungen aufwarten können, usw. In 2 Stunden werden Sie nur herausfinden können, wer bezüglich seiner Sprach-/Programmierkenntnisse lügt

Außer, dass Sie in der Lage sein sollten, Betrügereien in weitaus weniger als 2 Stunden zu erkennen. 5 Minuten FizzBuzz schreiben und 2-3 kurze Fragen zu sprachspezifischen Merkmalen werden Ihnen sagen, ob sie absolut wertlos sind. Und das ist so ziemlich das Beste, was man in einem Vorstellungsgespräch tun kann.

Lassen Sie mich Ihnen sagen, was ich denken würde, wenn ich eine zweistündige Prüfung für das Privileg, ein Vorstellungsgespräch führen zu dürfen, erhalten würde:

“Entweder denken diese Leute, dass dies einen Wert hat, was bedeutet, dass sie keine Ahnung haben, was sie tun, ODER sie wissen, dass dies eine Zeitverschwendung ist, aber aus irgendeinem Grund (wahrscheinlich blind der Bürokratie der Personalabteilung folgend) sind sie bereit, die Zeit der Kandidaten zu verschwenden, bevor der Kandidat überhaupt eingestellt wird. Stellen Sie sich vor, was sie denken werden, wenn sie mich erst einmal bezahlt haben.

So oder so, ich will dort nicht arbeiten.”

• *

Es gibt noch eine andere Sache, die die Kandidaten vertreiben könnte: Die Länge Ihres Interviewprozesses. Sie lassen Leute ein Telefoninterview durchführen. Dann einen Take-Home-Test, den sie in einer Woche abschließen müssen. Dann gehen Sie die Tests durch. Dann arrangieren Sie ein Vorstellungsgespräch mit dem Management. Dann (nehme ich an) machen Sie ein paar persönliche Interviews. Dann holen Sie den Mann zurück, den Sie einstellen wollen. Was ist dazu nötig? Wie lange dauert das? 2 Wochen? Länger?

In dieser Zeit habe ich bereits 3 Angebote erhalten. Ich habe eines angenommen und fange nächste Woche an. Glauben Sie, dass ich Ihren 2-Stunden-Test machen werde?

Lassen Sie mich damit beginnen, dass die Einstellung von Mitarbeitern im Allgemeinen eine erbärmlich ungenaue Wissenschaft ist, und Sie werden verschiedene Ergebnisse erzielen, egal was Sie versuchen. Ich denke, dass Programmierübungen ein Reinfall sind, vor allem, weil man damit Leute erreicht, die verzweifelt sind und viel zu viel Zeit zur Verfügung haben. Wenn sie einen Vollzeitjob haben, muss man sich fragen, wie viel Zeit/mentale Energie sie von ihrem derzeitigen Arbeitgeber benötigen, um für jemanden zu arbeiten, der sie nicht einmal bezahlt. Wollen Sie, dass sie solche Dinge mit Ihnen tun?

Wenn sie gut sind, führen sie außerdem höchstwahrscheinlich Vorstellungsgespräche mit vielen Arbeitgebern. Raten Sie mal, welchen von ihnen Vorrang einräumen werden? Diejenigen, die nicht darum bitten, Projekte abzuschließen, bevor sie überhaupt mit einem technischen Leiter telefoniert haben.

Es gibt auch das Problem des Plagiats. Sicherlich wird man sie im persönlichen Gespräch herausfinden, aber bis dahin haben Sie bereits die Zeit der (vermutlich) hoch bezahlten Mitarbeiter des Unternehmens verschwendet, die diese Person interviewen.

Mein derzeitiges Unternehmen hat es gut gemacht, und diesen Weg würde ich an Ihrer Stelle einschlagen. Geben Sie ihnen eine kleine Aufgabe, die vielleicht nur 90-120 Minuten dauern sollte, und sagen Sie ihnen, sie sollen in den Kommentaren begründen, warum sie diesen Weg zur Lösung des Problems gewählt haben. Dies ist etwas, das in einer Nacht erledigt werden kann und Ihnen Einblick in ihre Denkweise geben wird.

Ich kann Ihnen jetzt schon sagen, dass ich mich bei ihnen bedanke, wenn ich ein Projekt bekomme, das mehr als 8 Stunden dauert, aber ich bin nicht interessiert. Ich habe einen guten Job und ein Leben. Wenn ein Manager das als Problem sieht, sagt mir das, dass er sich nicht um meine Work-Life-Balance am Arbeitsplatz kümmern würde (vor allem, wenn es ihn nicht interessiert bevor ich es habe). Kein Unternehmen außer vielleicht Google, Apple oder Facebook könnte damit durchkommen.

Meiner Erfahrung nach werden bei Projekten, die man mit nach Hause nimmt, schlechte Programmierer nicht aussortiert, und gute Programmierer finden wahrscheinlich einen Job, bei dem sie nicht durch einen Reifen springen müssen, um mit dem Einstellungsleiter zu sprechen.

Denken Sie so darüber nach. Ein guter Coder kann leicht telefonische und persönliche Interviews bekommen. Jeder zusätzliche Reifen, durch den sie springen müssen, bedeutet, dass sie den einfacheren Weg wählen und ein Vorstellungsgespräch mit jemand anderem führen (und eingestellt werden), der genauso viel zahlt. ** Wenn Sie die Leute durch Reifen springen lassen, stellen Sie sicher, dass sie von Anfang an sehen, dass es sich für sie lohnt.**

Ein schlechter Entwickler kann sich so lange Zeit lassen, wie er will. Sie werden nicht sehen, dass sie 4x so lange brauchen; Sie werden nur den fertigen Test sehen. Sie werden auch nicht sehen, wie sie Google oder ihren Kumpel um Hilfe mit einer if-Anweisung bitten.

Meine letzte Firma hat dies getan, und die große Mehrheit der Leute, die wir für ein persönliches Interview hinzugezogen haben, sind gescheitert Fizz buzz (etwa 65%). Ich glaube, dies geschah, weil wir versehentlich gute, vielbeschäftigte Leute aussortiert haben, die kein Vorstellungsgespräch bei einem anderen Unternehmen brauchten, und gleichzeitig ein einfaches Vorstellungsgespräch vor schlechten Codierern baumeln ließen.

Was wir meiner Meinung nach stattdessen hätten tun sollen

Anstatt den Leuten einen Auftrag zum Mitnehmen zu geben, der 15-20 Minuten zur Benotung erforderte, hätten wir ein 15-20-minütiges Skype-Interview machen sollen, bei dem wir Fragen wie Fizz buzz stellten. Das hätte genauso viel Zeit in Anspruch genommen, aber ich hätte wahrscheinlich die schlechten Programmierer vor einem zweistündigen persönlichen Interview aussortiert.

FYI -> Hier ist ein sehr ausführlicher Artikel über Fizz-buzz und allgemeine Interview-Praktiken.

Eine gegensätzliche Sichtweise, von jemandem, der auf beiden Seiten dieser Frage im Graben liegt. Ich vermute, dass diese Antwort Abwärtsstimmen anziehen wird, aber es ist eine hoch informierte Meinung, die sich über mehrere Jahrzehnte in diesem Geschäft entwickelt hat. Weil ich das gerne tue, schreibe ich immer noch jeden Tag für meinen Lebensunterhalt und als Hobby in meiner “reichlich vorhandenen Freizeit” Code, aber ich war auch der letzte Entscheidungsträger bei der Einstellung von ein paar Dutzend Programmierern, und ich habe bei Vorstellungsgesprächen geholfen und bei der Einstellung einer ziemlich großen Zahl von mehr beraten.

Lawrence hat Recht: Einstellungen sind kläglich ungenau. Aber wir werden mit der Zeit immer besser darin. Mehr als Face-to-Face-Chats, mehr als Quizfragen, sind kurze Programmierungsherausforderungen vor Ort ein immer wichtigerer Teil davon: nicht nur wegen der Fähigkeiten, sondern auch wegen der Einstellung.

Beachten Sie, dass ich “kurz ” gesagt habe. Wir geben den Kandidaten einen Laptop, der mit einem ordnungsgemäß installierten Eclipse (unserer gewählten IDE) ausgestattet ist, wenn sie zum Vorstellungsgespräch kommen. Richtig eingerichtet bedeutet, dass sie Zugriff auf die jdk-Quelle haben, die aber kein Internet hat, und sie werden gebeten, während des Tests keine Mobiltelefone zu benutzen. Sie haben eine Stunde Zeit, um null bis fünf Probleme zu lösen, beginnend mit “FizzBuzz” und steigend in der Komplexität bis hin zu einem einfachen Multi-Threaded-Produzenten-/Multiple-Consumer-System.

Niemand hat jemals alle fünf in einer Stunde gelöst, und ich erwarte nicht, dass das jemals jemand tun wird (ich kann Lösungen für fünf in bequem unter einer Stunde schreiben, aber natürlich habe ich die Probleme gesehen und sie alle vorher gelöst, also bin ich kein fairer Test).

Übrigens hatten wir angeblich erfahrene Programmierer, die versagt haben, FizzBuzz richtig hinzubekommen. Lassen Sie mich das noch einmal sagen: Wir hatten eine Handvoll Kandidaten, die FizzBuzz nicht richtig hinbekommen haben. Gewöhnlich, indem sie Anweisungen nicht befolgen, aber das Lesen der Spezifikation ist ein wesentlicher Bestandteil eines Entwicklers.

Wir lassen sie Code schreiben, während sie hier vor Ort sind, anstatt ihnen Hausaufgaben zu geben, und zwar aus verschiedenen Gründen, zum Teil wegen des Risikos, zu betrügen, und zum Teil, um jedem Kandidaten die gleiche Chance zu geben, an den Problemen zu arbeiten. Außerdem rotieren wir die Probleme innerhalb und außerhalb der gestellten Herausforderung, und wir besprechen die Lösungen anschließend mit den Kandidaten.

Ich fühle mich in dieser Frage sehr stark. Ich habe noch nie erlebt, dass ein Kandidat wegen unseres Programmtests eine Stelle ablehnt oder aus dem Interviewprozess aussteigt. Aber das kann dadurch beeinflusst werden, dass wir den Personalvermittlern, die uns bedienen, sagen, dass der Prozess die Programmierung vor Ort einschließt. Es kann also sein, dass wir die Kandidaten einfach nicht sehen, die denken, dass es “unbezahlte Arbeit” ist, wenn sie gebeten werden, eine Stunde Code zu schreiben. Wenn dem so ist, sind wir sie los. Wenn sie der Meinung sind, dass eine Stunde Programmieren eher “Arbeit” als eine Stunde Beantwortung von Quizfragen ist, oder dass ihre Antworten auf Testprobleme irgendetwas Nützliches ergeben können, brauche ich ihre Einstellung nicht.

Wir hatten einmal einen Kandidaten, der sich über den Test beschwerte, weil er dachte, er sei zu alt, um sich beweisen zu müssen (das ist keine Spekulation - er sagte es). Und er hat die Herausforderungen gut gemeistert, und er hatte all die Erfahrung, die wir wollten. Aber er war ein schrecklicher Mitarbeiter: er dachte offenbar auch, er sei zu dienstälter, um Anweisungen zu geben oder zu lernen, und schließlich mussten wir ihn entlassen.

Eines der Dinge, die ich im Laufe der Jahre, in denen wir dies tun, entschieden habe, ist, dass jedes Unternehmen, das keinen Test macht, mich weniger wahrscheinlich als Mitarbeiter bekommt. Wie ihre Antworten auf Fragen wie z.B., was sie für die Quellenkontrolle usw. verwenden, ob ein Unternehmen Tests durchführt, sagt mir viel darüber aus, wie gut sie im Geschäft der Softwareentwicklung sind.

So, was sollten Sie also tun? Sie sollten das tun, was für Ihr Unternehmen funktioniert, aber mein Rat ist, die Tests fortzusetzen, sie aber vor Ort als Teil des Interviews durchzuführen. Sagen Sie ihnen im Voraus, dass dies Teil des Prozesses ist, und tun Sie es, bevor sie sich mit dem oberen Management treffen (aber Sie sollten sie zuerst treffen, um ihnen zu helfen, sich zu beruhigen). Und wirklich: überspringen Sie das Gespräch mit dem oberen Management, wenn sie scheitern. Machen Sie sich keine Sorgen über die Popularität von Kandidaten oder Plakaten im Internet. Die Kosten einer schlechten Einstellung sind viel schlimmer als die Kosten einer Verzögerung, bis Sie eine gute Einstellung erzielen.

Selbst wenn wir die Möglichkeit des Betrugs und den Umkehrfilter ignorieren, der gute und ehrliche Kandidaten dazu veranlasst, Firmen mit Tests für die Codierung zu Hause zu meiden, ist der Wert von Tests für die Codierung zu Hause begrenzt.

Wenn es sich um eine seniore Position handelt, wird ein leitender Entwickler mit Menschenkenntnissen in der Lage sein, innerhalb von weniger als 10 Minuten zu erkennen, ob der leitende Entwickler am anderen Ende des Telefons irgendwo gut ist oder nur Sachen erfindet. Wir werden nicht genau wissen, wie gut, aber wir werden so viel, wenn nicht mehr wissen, als jeder denkbare Codierungstest zu Hause uns sagt.

Wenn es für eine untergeordnete Position ist, erwarten wir nicht viel in Bezug auf technisches Fachwissen. Wir erwarten Enthusiasmus, Lernbereitschaft und Talent - nichts davon ist bei einem Kodierungstest zu Hause zu erkennen. Es gibt zu viele Dinge, von denen die Junioren nichts mitbekommen dürfen. Wenn wir sie einstellen, müssen wir sie ohnehin schulen.

Wie kann man stattdessen testen?

Geben Sie ihnen als Filter einfach 10 Minuten Zeit, um eine FizzBuzz -Variante vor Ort während der ersten Vorstellungsrunde zu lösen, oder, wenn Sie mit guten Lebensläufen überhäuft werden und einen weiteren Filter benötigen, machen Sie es vor der ersten echten Vorstellungsrunde über Skype.

Sobald sie die Filter bestanden haben, müssen Sie mehr über die Codierfähigkeiten Ihrer Kandidaten wissen. Ich empfehle, 30 Minuten bis höchstens 2 Stunden entweder für Paarprogrammierung oder Code-Reviews aufzuwenden - das ist eher eine echte Arbeit als eine Übung. Wiederholen Sie die Übung 1-2 Mal mit verschiedenen Partnern. Der Vorteil von Paarprogrammierung und Code-Reviews besteht darin, dass der Entwickler bereits über ausreichende Kenntnisse verfügt, um einen Beitrag zu leisten.

Machen Sie sich keine Sorgen, dass der Test für jede Einstellung anders ist - das Ziel des Einstellungsverfahrens besteht nicht darin, die Person zu finden, die in ein paar messbaren und wiederholbaren Tests am besten abschneidet. **Das Ziel ist es, eine einzige Person einzustellen, die ihre Arbeit gut macht.

Hier ist ein weiterer Punkt, der meines Erachtens in den vorhandenen Antworten (die meiner Meinung nach das Thema im Allgemeinen gut abdecken) nicht abgedeckt ist. Ich würde mir genau und ernsthaft anschauen, wie lange die Leute tatsächlich brauchen, um das Thema abzuschließen. Ich hatte vier Bewerbungsgespräche, bei denen ich eine Programmierübung zu absolvieren hatte, die jeweils unterschiedlich durchgeführt wurde (und jedes hatte seine eigenen Vor- und Nachteile). Zwei der vier (Nummern 3 und 4 unten) dauerten viel länger, als sie sagten, und beide habe ich schließlich wegen des schwierigen Niveaus aufgegeben. Ich habe sie im Folgenden beschrieben und sie aus meiner Sicht von der besten bis zur schlechtesten Stufe eingeordnet.

1. Während des technischen Interviews setzten sie mich an einen Computer, der eine abgespeckte Version ihrer Codebasis hatte, und ließen mich drei relativ kurze Probleme lösen, die damit zusammenhingen (einen Fehler finden und beheben, den sie absichtlich hinzugefügt hatten, ein neues Feld zu einer Infotabelle hinzufügen usw.). Sie gaben mir dafür genau eine Stunde Zeit, und nach einer Stunde gingen sie meine Lösung sowie meine Herangehensweise an die Probleme durch. Dadurch erhielten sie mehr Einblick in mich als Programmierer, während sie meine Zeit respektierten, indem sie sie kurz und auf den Punkt brachten.
2. Während des technischen Interviews ließen sie mich ein Problem, auf das sie während der Entwicklung gestoßen waren, an einem Whiteboard durcharbeiten, während ich gleichzeitig in der Lage war, Ideen von ihnen abzuprallen. Dies war die kürzeste Möglichkeit, während sie gleichzeitig die Möglichkeit hatten, zu sehen, wie ich Probleme bearbeite und wie sehr ich die notwendige Arbeit tatsächlich leisten kann.
3. Während des technischen Vorstellungsgesprächs (für eine Junior-Ruby on Rails-Position in der Webentwicklung) wurde ich damit beauftragt, eine Webanwendung von Grund auf zu entwickeln, die zu einer Website navigiert, mehrere Formulare ausfüllt, während sie präsentiert werden, Daten von der resultierenden Seite kratzt und diese dem Benutzer präsentiert. Sie sagten, dies sollte eine schnelle Übung sein, und es mag für einen hochrangigen Webentwickler gewesen sein, aber da ich zu diesem Zeitpunkt erst ein Jahr Berufserfahrung hatte, verbrachte ich vier Stunden damit, alles zum Laufen zu bringen, bevor ich aufgab und nach Hause ging (alle Interviewer waren Stunden vor mir gegangen, weil es ein Nachmittags-Interview war; sie sagten, ich solle einfach das fertige Programm speichern, wenn ich fertig war). Das ist eine lächerliche Aufgabe für die aufgeführte Stelle, sie hatten keine Ahnung von meinen Fähigkeiten im Codieren und es schien mir, als wollten sie nur freie Arbeit aus dem Deal herausholen. Unnötig zu sagen, dass ich die Stelle nicht einmal wollte, als ich an diesem Tag ging.
4. Noch bevor ich überhaupt ein technisches Vorstellungsgespräch hatte, gaben sie mir den Auftrag, eine Webanwendung zu erstellen, die die Vorteile einer API nutzen würde, mit der ihr Unternehmen “etwas Interessantes zu tun” hatte. Dies war genau so umfangreich, wie es sich anhört. Dazu musste ich Folgendes tun, bevor ich überhaupt versuchte, die Anwendung zu erstellen: einen Entwickler-Account für die API erstellen, das API-Entwicklungskit herunterladen, eine öffentlich zugängliche Webanwendung (mit einem anderen Entwickler-Account) erstellen, die API erlernen und eine Datenablage für den Zugriff mit der API erstellen. Dies nahm natürlich viele Stunden in Anspruch, nur um anzufangen, und kurz nachdem ich mit der Webanwendung selbst begonnen hatte, bekam ich ein anderes Vorstellungsgespräch und kurz darauf ein Stellenangebot, so dass ich die Arbeit an der Aufgabe einstellte. Es ist verrückt, so etwas als Teil eines Bewerbungsgesprächs zu haben, denn wer will schon all die Zeit und Mühe in die Entwicklung eines Programms stecken, nur um eine kleine Chance zu haben, im Bewerbungsgesprächsprozess weiterzukommen?

Um Ihre Frage direkter zu beantworten, sollten Sie also eine Programmierübung machen? Ja, aber stellen Sie sicher, dass sie so zugeschnitten ist, dass sie das testet, was Ihnen tatsächlich wichtig ist, und nicht eine Tonne Fremdarbeit für den Interviewten erfordert. Wollen Sie etwas über ihr algorithmisches Denken wissen? Geben Sie ihnen ein algorithmisches Problem. Wollen Sie etwas über ihren Codierstil wissen? Geben Sie ihnen ein Codierungsproblem. Wollen Sie etwas über ihren Entwicklungsprozess wissen? Diskutieren Sie ihren Prozess mit ihnen, während sie ein Problem durcharbeiten.

Lassen Sie mich beginnen mit:

• Ich habe Tests zu Hause absolvieren müssen, die zwischen 15 Minuten und 10 Stunden dauerten.
• Ich habe Online-Tests durchlaufen müssen.
• Ich wurde damit beauftragt, die Antwort auf FizzBuzz und andere modische Internet-Tests auf Whiteboards zu schreiben.
• Ich wurde nach den quadratischen vs. runden Kanaldeckeln gefragt.

Kurz gesagt, ich habe mich mit so ziemlich all den verschiedenen Arten beschäftigt, wie Entwickler gerne mit Interviews umgehen. Um ganz ehrlich zu sein - ich bezweifle ernsthaft, daß die überwiegende Mehrheit der Leute, die mich interviewt haben, überhaupt verstanden hat, was die potentiellen Ergebnisse jedes dieser Tests waren, und letztlich nur Leute eingestellt hat, die sie “mochten” oder nicht.

Bevor Sie überhaupt eine Stellenausschreibung aufgeben, sollten Sie sich hinsetzen und genau durchgehen, was es ist, das Sie einstellen wollen, und “Entwickler” ist keine Antwort, zumindest keine richtige. Eine gute Antwort darauf wäre so etwas wie “Experte für den Hypothekenbereich”.

Jemanden zu finden, der ein bisschen Code schreiben oder in Google danach suchen kann, wie man ein bestimmtes Muster anwenden kann, ist trivial im Vergleich dazu, jemanden zu finden, der in der Branche, in der Sie tätig sind, schon einmal gearbeitet hat und dieses Wissen nutzen kann. Mit anderen Worten, wenn ich für eine Hypothekendokumentationsfirma arbeiten würde, würde ich jemanden nehmen, der über den Unterschied zwischen einem 15-jährigen Festkredit und einem ARM-Darlehen sprechen kann, und nicht jemanden, der in 2 Minuten einen Algorithmus zur Sortierung von Blasen schreiben kann. Der Grund dafür ist, dass “normale” Geschäftsleute alle möglichen merkwürdigen Anforderungen stellen und Domänenexperten leichter zum Kern dessen vordringen können, was benötigt wird, während jemand, der nichts weiß, gerne Dinge hinzufügt, die nutzlos sind oder die App wirklich schlecht machen.

Zurück zu den Fragen, nur Fragen stellen, die gehen / keine gehen.

Ist es entscheidend, dass die Person Ihnen den Unterschied zwischen einer virtuellen und einer abstrakten Methode erklären kann? Könnte sein, ist es aber normalerweise nicht. Ich würde wetten, dass ein guter Teil der Entwickler kaum weiß, wann sie diese Schlüsselwörter verwenden sollen, aber das sind nicht Ihre Superstars, sondern die einfachen Entwickler, die ohne die visuellen Designer keinen Code verwenden können.

Ist es entscheidend, zu erkennen, wann eine Abfrage für die Sql-Injektion geöffnet ist? Für eine Sr.-Position - absolut; für eine Jr.-Position nein. Dies ist etwas, das leicht trainierbar ist und über Code Review gehandhabt werden kann. Daher ist es wichtig, dass die Sr. es in- und auswendig kennt - damit sie die Junioren trainieren können.

Ist es wichtig, dass sie den genauen Maximalwert eines Int32-Datentyps kennen? Normalerweise nicht - dieses Niveau an trivialem Wissen ist das, wofür Google da ist; aber vielleicht ist Ihre Anforderung an die Kodierung auf speicherbeschränkten Geräten - in diesem Fall: absolut.

Ich interviewe und stelle Entwickler ein. Ich schicke keine Tests nach Hause - es ist zu einfach, sich von einem Freund helfen zu lassen. Ich benutze keine Online-Testseiten - angesichts der Tatsache, dass die Auswertung automatisiert werden muss, ist das für das Spiel trivial. Ich fordere die Kandidaten nicht auf, die Antwort an Fizzbuzz auszuschreiben - fast jeder hat diesen Test gesehen und sollte die Antwort auswendig kennen; alle anderen haben das Feld im letzten Jahr betreten und sind sowieso Jungs. Ich stelle auch keine belanglosen Fragen - die Antwort aufsagen zu können, bedeutet normalerweise nur, dass man die Frage schon einmal gehört hat.

Was ich mache, um Leute zu interviewen:

• Ich bitte sie, ein oder zwei frühere Projekte zu beschreiben. An dieser Stelle geht es mir nur darum, es ihnen bequem zu machen und sie zum Reden zu bringen. Wenn ich nämlich nicht verstehe, was sie sagen, kann ich nicht mit ihnen arbeiten.

• Ich stelle ihnen ein paar spezifische Fragen in der Technik, die sie benutzen sollen. Wenn es sich um einen SQL-Server handelt, frage ich nach der Aktualisierung bei einem Join. Wenn es HTML ist, gebe ich ihnen eine 10-zeilige html-Datei mit ein paar css-Klassen und frage sie, was die Ausgabe ist. Das sind triviale Fragen für Leute mit Erfahrung in diesen Bereichen, und schnell werden die Prätendenten aussortiert.

• Wenn ich einen Sr. dev suche, dann stelle ich Fragen zum Domänenwissen. Keine Randfall-Dinge, sondern eher Kernprinzipien. Wenn ich Sie brauche, um ein Buchhaltungs-Backend-Projekt zu leiten, dann sollten Sie die Grundprinzipien der Buchhaltung kennen.

• Wenn ich einen Jr. dev suche, dann frage ich nach Lieblingsprojekten. Das sollte Ihnen einen Hinweis darauf geben, was sie wirklich tun wollen. Mit anderen Worten, ein C#-Entwickler wird wahrscheinlich keine Haustierprojekte in php machen. Ich erwarte ehrlich gesagt nicht zu viel von einem Junior-Entwickler, außer dass er trainierbar ist. Wenn sie aktiv an einem Haustierprojekt arbeiten, kann ich sie trainieren.

Ich stelle mir diese Fragen nicht spontan, die potenziellen Antworten werden im Voraus geprüft und passen in ein Muster von go/no go. Wenn eine Frage nicht in dieses Schema passt, ist sie nicht relevant. Ich frage auch jeden Bewerber die gleichen Fragen, es sei denn, ich bin zu 100 % davon überzeugt, dass ich ihn nicht einstelle, dann breche ich das Vorstellungsgespräch ab…

Wenn Sie aus irgendeinem Grund trotzdem darauf bestehen, einen Test nach Hause zu schicken - stellen Sie sicher, dass die für den erfolgreichen Abschluss dieses Tests erforderlichen Fähigkeiten

Ich hatte eine Firma, die mir einen Test zum Mitnehmen mit nach Hause gab, bei dem es darum ging, einen kundenspezifischen Kryptographie-Dienstleister zu schreiben. Ich habe den Test abgeschlossen, weil er etwas interessant war; sie haben mich eingestellt. Zu keinem Zeitpunkt meiner Zeit dort habe ich auch nur im Entferntesten etwas getan, das mit Sicherheit, Kryptographie oder auch nur mit Mathematik zu tun hatte, außer ein paar Zahlen zu addieren. Ich frage mich, wie viele Leute sie mit diesem Test weggefahren haben.

Ich habe früher fest an Codierungstests und Whiteboard-Codierung geglaubt, aber ich habe gemerkt, dass sie ziemlich nutzlos sind, denn

Was testen Sie eigentlich?

Ein Whiteboard-Test oder kurzer Programmiertest gibt Ihnen einen gewissen Einblick in die Person, aber wirklich nicht so viel. Es sei denn, Sie planen, dass jemand seine Zeit damit verbringt, Code auf einem Whiteboard oder Code im FizzBuzz-Stil zu schreiben.

Was wollen Sie?

Sie wollen jemanden, der:

• leidenschaftlich
• lernwillig
• in der Lage ist, Probleme zu lösen*
• ausgesprochen technisch
• Ihrem Team bei der Verbesserung helfen wird

*Note, die meisten Entwickler lösen ihre Probleme, indem sie wissen, nach welchen Begriffen sie in Google suchen sollen.

Die letzte Sache, die Sie einstellen möchten, ist jemand, der nicht gut zu Ihrem Team passt, weil er es nach unten zieht.

Wie können Sie auf diese testen?

• Fragen Sie sie nach einem Projekt, das ihnen gefallen hat. Wenn sie zögern, darüber zu sprechen, versuchen Sie, sanften Unglauben auszudrücken, z.B. “Sie können X nicht machen, oder?”. Wenn es etwas ist, für das sie leidenschaftlich sind, werden sie Sie korrigieren. Das wird Ihnen auch dabei helfen zu erfahren, ob sie technisch versiert sind oder nicht.
• Fragen Sie sie nach Dingen, die sie kürzlich gelernt haben. Oder was sie aus dem Projekt, an dem sie mitgearbeitet haben, gelernt haben, das ihnen Spaß gemacht hat.
• Fragen Sie sie nach dem letzten Mal (oder nach einer Zeit), in der ihnen etwas Wissen gefehlt hat. Wie sind sie an die Informationen gekommen, die sie brauchten? Sind sie zu einem Teamkollegen gegangen? Haben sie das Internet durchsucht?
• Fragen Sie sie, ob es irgendetwas gibt, das sie in ihrem aktuellen/letzten Team verbessert sehen möchten. Brauchten sie bessere Commit-Nachrichten? Mehr Code-Überprüfungen? Mehr Tests? Mehr Automatisierung?
• Fragen Sie sie, welche Technologie sie begeistert und warum.

Wenn Sie jemanden haben, der technisch kompetent an diesem Gespräch teilnimmt, wird es die einfachste Sache der Welt sein, zu sagen, ob diese Person die schlechteste sein wird. Ein Beispiel: Wir ließen ein Kind zu einem Interview kommen - er sagte, auf einer Skala von 1-10 seien seine Java-Kenntnisse wie eine 7-8. Ich glaube, er wusste nicht einmal, dass Java zu einer Jar-Datei kompiliert wurde, die später von der JVM in Maschinensprache kompiliert wurde. Ich würde mich vielleicht auf einer Skala von 2 oder 3 einordnen, und ich weiß das.

Die gleiche Frage stellte ihm unser CTO in einem Interview am Vortag, und unser CTO rief ihn darauf an und erklärte, dass er auf keinen Fall eine 7-8 sei.

Unser CTO fragte ihn auch nach seinem Lieblingsprojekt, das mit Handscannern zu tun hatte. Aber er konnte nichts darüber erklären, wie sie funktionieren, oder dass sie das Polling nutzen, um geschäftige Wartezeiten zu vermeiden. Er konnte nicht eine einzige technische Sache erklären.

Dieser Typ wurde nicht eingestellt.

Finden Sie heraus, nach welcher Art von Attributen Sie suchen, und finden Sie dann heraus, wie man diese testen kann

Aber ich muß wirklich sehen, wie sie codiert!

Okay, das ist in Ordnung - aber wenn sie nicht in einem Silo codiert, ist es das Beste, sie als Auftragnehmer für ein kleines, gut definiertes Projekt einzustellen. Vielleicht fügen Sie die Möglichkeit hinzu, einige Dateien von einem FTP-Server herunterzuladen und sie dann in Ihrer Datenbank zu speichern. Etwas Einfaches, das nicht viel/keine Domänenkenntnisse erfordert.

Lassen Sie Ihre Kandidaten mit einem oder zwei bestehenden Mitarbeitern arbeiten und bezahlen Sie sie für ihre Zeit. Sie werden genau sehen, wie sie arbeiten, und wie gut sie mit dem Team zusammenarbeiten. Kommunizieren sie gut? Werden sie leicht frustriert? Sind sie hartnäckig?

Es gibt Dinge, die Sie tun können, um bessere Mitarbeiter einzustellen… aber ein Programmierwettbewerb gehört wahrscheinlich nicht dazu.

Aus der Sicht eines Arbeitssuchenden vermeide ich in der Regel Orte, die mehr als 1 Stunde für die Programmierung benötigen. Einmal war ich an einem Ort, der ein fast 3 Tage langes Java-Codierungsprojekt erforderte. Ich habe alles gemacht, und der Typ war sogar davon beeindruckt, aber sie sagten mir, dass sie nach der zweiten Interviewphase jemand anderen eingestellt hätten. Wenn ich danach in ein Unternehmen komme, würde ich also jedes Projekt ignorieren/übergehen, das mehr als ein paar Stunden zum Abschluss benötigt. Meine Zeit ist genauso wertvoll wie ihre, und ich möchte sie lieber nicht für Dinge verschwenden, die mich nicht weiterbringen.

Abgesehen davon, wenn Ihre Programmierübung zu lang ist, sind die Leute vielleicht nicht bereit, diese Zeit zu investieren. Ich würde versuchen, sie so zu verkürzen, dass sie höchstens eine Stunde dauert, gleichzeitig aber ein Verständnis für das Kodieren demonstrieren und vielleicht eine Deadline setzen wie “Bitte bis morgen im COB abschließen” oder so etwas. Sie können immer noch etwas online “kopieren und einfügen”, aber sie können es schwierig machen, indem sie spezifisch sind und nicht etwas, das Sie online lesen.

Wie andere bemerkt haben, können einige Entwickler durch eine 1-2 stündige Programmierübung abgeschreckt werden, um sich für eine Stelle zu bewerben. Was möglicherweise besser funktioniert, ist eine White-Board-Sitzung, bei der der Kandidat während des Bewerbungsgesprächs ein Problem an einer weißen Tafel löst. Dies gibt Ihnen die Möglichkeit, ein persönliches Gespräch zu führen und gleichzeitig sicherzustellen, dass sie technische Probleme haben.

Diese Probleme sollten nicht extrem schwierig sein oder dazu dienen, einen Entwickler zu stören. Ein klassisches Beispiel ist FizzBuzz . So können Sie sehen, wie sie denken, und Sie wissen auch, dass sie zumindest programmieren können und nicht zu googeln brauchen, wie man eine Schleife macht.

Meiner Meinung nach ist das Problem, das Sie hier haben, nicht unbedingt der Programmtest. Zuerst haben Sie das technische Telefoninterview und dann einen Heimarbeitstest vor einem persönlichen Interview. Das klingt, als würden Sie Ihre Kandidaten auf Distanz halten und es bis zur letzten Minute vor dem Treffen mit ihnen belassen. An welchem Punkt erwarten Sie von den Kandidaten, dass sie sich entscheiden, dass sie **für Sie arbeiten möchten ?

Ich nehme an, Ihre Stellenanzeige ist den meisten ähnlich und konzentriert sich daher auf Standort, Gehalt und eine (Wunsch-)Liste von Fähigkeiten. Die Kandidaten wissen nicht wirklich, woran sie arbeiten würden, nichts über das Umfeld oder die Menschen, mit denen sie zu tun haben würden. Sie haben ihnen die Stelle noch nicht verkauft, hier bitten Sie sie, ihre technischen Fähigkeiten zweimal unter Beweis zu stellen, bevor sie eine einzige Frage über die Arbeit stellen dürfen.

Ich schlage vor, Sie versuchen, das Format des technischen Telefoninterviews so zu ändern, dass es ein 30-45-minütiges Gespräch über die Stelle ist, einschließlich vieler Gelegenheiten für Fragen der Kandidaten, dann 15 Minuten lang technische Fragen als Bildschirm, so dass Sie immer noch die Möglichkeit haben, die besseren Bewerber auszuwählen, ohne dass es zu mühsam wird.

Ich würde auch erwägen, die Herausforderung der Programmierung vor Ort vor den Interviews zu verlegen. Das erscheint den Bewerbern erreichbarer, gibt ihnen einen Anreiz, den Prozess im Auge zu behalten, und Sie hätten den Vorteil, die tatsächlich für die Herausforderung aufgewendete Zeit zu beobachten (ich denke, Sie werden überrascht sein).

**

Ich wage zu behaupten, dass Sie das nicht wollen.

Programmierer einzustellen, die nicht in der Lage sind, Probleme zu lösen und Code zu schreiben, ist ein guter Weg, ein Technologieunternehmen zu ruinieren. Und Sie werden die Programmierer, die nicht programmieren können (und davon gibt es eine Menge da draußen), nicht effektiv aussortieren können, wenn Ihr Einstellungsverfahren keine Art von Programmiertest beinhaltet.

Sind Sie bereit, Ihre Standards zu senken, weil jeder versucht, Programmierer einzustellen?

Vielleicht sind Sie es, aber ich denke nicht, dass Sie es tun sollten. Wie in den Kommentaren und Antworten bemerkt wurde, gibt es da draußen Kandidaten, die sich nicht die Mühe machen werden, Programmierübungen als Teil eines Bewerbungsgesprächs zu machen, weil sie es einfach nicht müssen, um einen Job zu bekommen.

Aber sind das wirklich die Leute, die Sie sowieso einstellen wollen? Diejenigen, die den Weg des geringsten Widerstandes gehen, das tun, was ihnen kurzfristig am meisten nützt, und sich nicht wirklich genug um Ihr Unternehmen kümmern, um eine einfache Programmierübung zu absolvieren? Das scheinen keine positiven Eigenschaften zu sein, und sie geben nicht viel Vertrauen in die Fähigkeit, diese Kandidaten langfristig an sich zu binden (was auch für ein Technologieunternehmen wichtig ist, da die Lernkurven tendenziell steil sind und die Kosten für den Ersatz des vorhandenen Personals sehr hoch sind).

Lassen Sie also diese anderen Unternehmen die Programmierer haben, die nicht einmal belästigt werden können. Sie wollen sie sowieso nicht einstellen. Im Gegensatz zu ihnen haben Sie einen Plan. Einen, der nicht auf dem Trugschluss “ein Programmierer ist ein Programmierer” basiert. Ihr Schwerpunkt sollte auf Qualität und Nachhaltigkeit liegen, nicht auf der Zahl der Mitarbeiter.

Ist es ein Problem, Kandidaten abzuschrecken?

Im Allgemeinen nein, solange sie aus einem guten Grund abgeschreckt werden. Sie wollen keine Leute einstellen, die nicht auf der Höhe der Zeit sind. Und einige der Leute, die sagen, dass sie aufgrund der hohen Nachfrage “nicht belästigt werden können”, könnten das tatsächlich als Ausrede benutzen, um eine Situation zu vertuschen, in der sie “nicht wirklich so gut im Programmieren sind und daher die ganze Woche brauchen würden, um eine einstündige Übung zu absolvieren”…

Es ist gut, diese Kandidaten zu verscheuchen. Sie wollen die fähigen, motivierten Kandidaten einstellen. Solange Sie diese nicht auch verscheuchen, sind Sie gut.

Jeder Kandidat, den Sie nicht verscheuchen, ist einer, den Sie ausprobieren und bewerten müssen. Und das kann schwierig sein, wenn Sie Ihren technischen Kandidaten keine technischen Übungen zur Beurteilung geben.

Wie kann ich unseren Einstellungsprozess verbessern?

Überprüfen Sie den Inhalt Ihrer Programmierübung. Ist er vernünftig und angemessen für einen Interview-Kontext?

Sie wollen nicht, dass etwas, das Tage (oder sogar Stunden) dauert, abgeschlossen wird. Was Sie wollen, ist etwas Einfaches, um die Leute auszusortieren, die nicht programmieren können, idealerweise mit genügend Raum für Nuancen, damit die Leute, die wirklich gut programmieren können, sich differenzieren können. Denken Sie daran, was Sie erreichen wollen (ungelernte und nicht seriöse Kandidaten aussortieren), und stellen Sie sicher, dass Ihr Inhalt auf dieses Ziel zugeschnitten ist. Übertreiben Sie es nicht.

Wenn Sie bereits über technisches Personal verfügen, können Sie es zur Gesundheitskontrolle (und/oder Hilfe bei der Gestaltung) Ihrer Übung einsetzen.

Und überlegen Sie auch, wie Sie die Übung verwalten. Wenn Sie ihnen einfach ein paar Unterlagen geben und sagen: “Hier, machen Sie das in der nächsten Woche und schicken Sie es mir per E-Mail”, wird das wahrscheinlich nur minimal effektiv sein.

Besser wäre es vielleicht, wenn Sie die Übung über ein Webportal laufen lassen könnten, in das die Kandidaten einchecken und die Übung starten können, und sobald sie starten, beginnt ein Timer, der von 1 Stunde herunterzuzählen beginnt. Dann reichen sie entweder innerhalb dieser Stunde etwas ein oder nicht. Das ist weniger ergebnisoffen, behält den Fokus des Kandidaten besser bei und bietet eine klare Deadline/Zeitbox, so dass 1) Sie nicht die ganze Woche auf ein Ergebnis warten müssen, das nie kommen wird, und 2) nicht qualifizierte Kandidaten nicht eine Woche ihrer Zeit wegwerfen, um Ihre Programmierübung zu beenden. Sie bekommen 1 Stunde, entweder lösen sie das Problem oder sie lösen es nicht, und Sie kennen das Ergebnis sofort.

Und noch besser wäre es, sie zu einem Vorstellungsgespräch vor Ort zu bringen. Stellen Sie sie einem Mitglied Ihres Entwicklungsteams vor. Schließen Sie sie in einem Raum zusammen mit einer Arbeitsstation ein. Lassen Sie Ihren Entwickler mit einigen allgemeinen/sanften Interviewfragen beginnen, und dann kann er mit dem Kandidaten ein Pairing programmieren, um die Programmierübung zu lösen. Dadurch erfahren Sie nicht nur, ob der Kandidat programmieren kann oder nicht, sondern auch, wie gut er mit Ihrem Team zusammenarbeitet. Ihr Entwickler sollte auch in der Lage sein, eine Menge zusätzlicher Informationen zu sammeln, die Sie einfach nicht bekommen, wenn Sie sich einen Haufen Code ansehen, den ein Kandidat geschrieben und Ihnen dann per E-Mail zugeschickt hat.

** Fazit**

Nein, Sie wollen Ihre Programmierübung nicht loswerden. Aber vielleicht möchten Sie sie auf geeignete Inhalte überprüfen, sicherstellen, dass die Lösung nicht zu lange dauert, und auch darauf achten, wie Sie sie in Ihren übergreifenden Interviewprozess einpassen.

Eine selbstgesteuerte Übung zum Mitnehmen ist wahrscheinlich nicht der beste Ansatz. Aber die Lösung dafür ist nicht, die Übung ganz zu streichen. Jedenfalls nicht, wenn man mit der Einstellung von Mist-Programmierern einverstanden ist.

Besser eine Menge schlechter Kandidaten und eine Handvoll guter Kandidaten verscheuchen, als die Schleusen zu öffnen und ein paar schlechte einzustellen.

Eine Sache scheint niemand erwähnt zu haben; selbst wenn der Test nicht Ihr Thema ist, sollten Sie nach anderen Wegen suchen, um Talente anzuziehen.

Wenn Sie auf der Suche nach guten Leuten auf der Grundlage ihrer bereits veröffentlichten Arbeiten sind, brauchen Sie den Test nicht an ihnen durchzuführen.

Wenn Sie nur Leute über Personalvermittler und Filter geschickt bekommen, sind Sie anfällig für die Tatsache, dass Ihre Bedürfnisse und die Bedürfnisse der Personalvermittler nicht perfekt aufeinander abgestimmt sind. Sie wollen jemanden bei Ihnen unterbringen. Sie wollen einen Ingenieur auf höchstem Niveau. Wenn sie einen Spitzeningenieur finden können, der großartig ist, weil Sie zu ihnen zurückkommen werden, aber wenn sie es nicht können (und Spitzeningenieure haben in der Regel Dinge am Laufen, die wenig Zeit für Vorstellungsgespräche lassen), werden sie sich damit zufrieden geben, einfach einen gemäßigten Ingenieur mit einem schönen Anzug zu vermitteln. Der Verlust für sie ist ein langfristiger Verlust, aber verglichen mit dem Verfehlen ihrer Ziele ist das ein kleiner Verlust. Wenn dies in Ihrem Fall nachweislich nicht zutrifft, behalten Sie diesen Anwerber im Auge und lassen Sie ihn niemals gehen_(*), Anwerber, die einer langfristigen Beziehung Vorrang vor Zielen einräumen, sind wertvolle Diamanten in einem Ozean von Kohlenstaub.

Was Sie tun wollen, ist, nachweislich interessante Kandidaten zu finden. Jagen Sie durch StackOverflow und GitHub nach Top-Ingenieuren (ich habe gehört StackOverflow hat ein Tool, das Ihnen dabei helfen soll ), suchen Sie nach technisch interessanten Firmen, die gute Software produzieren, aber ihre Finanzen oder Monetarisierung vermasselt haben und gerade 10 Top-Ingenieure entlassen haben. Verbringen Sie Zeit damit, an Universitäten zu arbeiten und bei den Projekten des Abschlussjahres zu assistieren. Identifizieren Sie gute potentielle Kandidaten und freunden Sie sich mit ihnen an, vorzugsweise persönlich, alternativ per Fernzugriff; selbst wenn sie Angebote haben, hängen gute Ingenieure mit guten Ingenieuren zusammen. Außerdem können sie Ihnen sagen, wie sie über Ihren Einstellungsprozess denken.

Klingt das nach viel Arbeit? Sollte es. Einer der Gründe, warum das Einstellen so “schwer” erscheint, ist, dass Sie versuchen, es so effizient wie möglich zu machen. Je mehr Zeit, Intelligenz und Ressourcen Sie dafür aufwenden, desto einfacher ist es. Ob diese Ressourcen besser für den Versand von Produkten eingesetzt werden sollten, ist die ewige Managementfrage. Aber wenn Sie viel Zeit auf “Mist-Programmierer-Filterung” verwenden, ist das verbranntes Geld. Zumindest haben die oben skizzierten Schritte über den Einstellungsprozess hinaus einen inhärenten Wert.

(*): Zur Hölle, miete sie.

Ich mag keine Take-Home-Tests als Teil von Vorstellungsgesprächen, und zwar aus vielen der Gründe, die die Leute bereits erwähnt haben - verlängert den Einstellungsprozess, wertet die Zeit des Bewerbers ab, bekommt möglicherweise sowieso keinen Rückruf usw.

Mein Hauptproblem ist, dass es unrealistisch ist, wie das Team tatsächlich arbeitet und den Interviewprozess einseitig macht. Ein Bewerber möchte wissen, ob dieser Ort gut zu ihm passt, einschließlich der Kultur, wie das Team Probleme angeht und löst. Sie wollen in erster Linie auch, dass er passt, einschließlich der Art und Weise, wie er arbeitet und ob er über die richtigen Fähigkeiten verfügt. Ein Take-Home-Test bietet einem Bewerber keine Gelegenheit, die weichen Qualitäten eines Arbeitsplatzes zu bewerten, und Arbeitgeber erhalten keine Gelegenheit zu erfahren, wie der Bewerber an das Problem herangegangen ist.

Eine bessere Lösung könnte darin bestehen, dem Bewerber ein offeneres Problem zu geben, das auf jede Art von kreativer Weise gelöst werden kann. Man könnte es sogar auf die Sprache X beschränken. Statt es per E-Mail einzusenden, laden Sie sie zurück, um es sich selbst und dem oberen Management vorzustellen. Es gibt ihnen Autonomie und einen Anreiz, gut abzuschneiden, denn es verspricht ein weiteres Vorstellungsgespräch und zeigt, dass es Ihnen wichtig ist, zu wissen, was sie denken.

Wenn Sie mit einem Test überprüfen müssen, welche Kandidaten es zum Vorstellungsgespräch mit der oberen Führungsebene schaffen, würde ich den Test in das Vorstellungsgespräch einbeziehen, damit Sie gemeinsam ihren Gedankengang besprechen können.

Ich glaube, dass Sie Ihre Frage ein wenig falsch formuliert haben, aber die Art und Weise, wie Sie sie formuliert haben, spiegelt ein weit verbreitetes Missverständnis bei der Einstellung von Programmierern wider. Werden die Kandidaten durch die Programmieraufgabe “abgeschreckt”, oder filtern sie Ihr Unternehmen aufgrund der Aufgabe aus ihren eigenen Überlegungen heraus?

Eine Anekdote, um meinen Standpunkt zu verdeutlichen: Bei der Jobsuche vor nicht allzu langer Zeit sah ich eine Stelle für ein Unternehmen, die mir durchschnittlich erschien. Die Art und Weise, wie sie ihren Programmierungsprozess beschrieben, klang recht gut, aber es gab nur sehr wenige Details, so dass ich skeptisch war. Vielleicht waren sie ein guter Arbeitsplatz, vielleicht auch nicht. Aber ich dachte mir, ich würde mich darum kümmern, zu einem Telefonbildschirm zu gelangen, um die Details herauszufinden und zu sehen, ob sie so gut waren, wie sie schienen.

Ich klickte auf die Stellenausschreibung und wurde sofort gebeten, ein Anschreiben zu schreiben. Pfui Teufel. Ich glaube, jeder Bewerber hasst Anschreiben. Ich kannte diese Firma nicht und kannte ihre Produkte nicht, was sollte ich also über sie sagen? Ich googelte sie, las ihre Website und ihre Produktangebote, fand heraus, wo ich wahrscheinlich in ihr Organigramm passen würde, wenn ich eingestellt würde, und kam selbst auf ein paar Absätze, die ich “verkaufte”.

Als nächstes stellte ich meinen Lebenslauf und Zugang zu meinem LinkedIn zur Verfügung - aber sofort danach baten sie mich, meine relevante Berufserfahrung mit Daten und Beschreibungen auszufüllen. Diese Informationen befinden sich sowohl auf meinem LinkedIn als auch auf meinem Lebenslauf, es war lächerlich, dreimal die gleichen Angaben machen zu müssen. Ich schloss die Registerkarte des Browsers. 5 Minuten später bewarb ich mich bei einer anderen Firma, die einige wirklich coole Vorteile anbot, was die erste nicht tat. Ich konnte mich tatsächlich schneller bei einem anderen Unternehmen mit besseren Leistungen bewerben, als ich durch die Reifen springen konnte, die das erste Unternehmen von mir wollte.

Sie müssen sicher sein, dass Ihre Kandidaten in Ihr Unternehmen im Besonderen investiert sind, bevor Sie ihnen irgendwelche Reifen präsentieren, durch die sie springen können, sonst werden sie nicht springen. Tun Sie das?

Beispiele für Qualitätsvorteile, die ich häufig bei Technologieunternehmen sehe:

1. Arbeiten aus der Ferne:

2. Kostenlose Computer/Monitore als Unterzeichnungsbonus.

3. Das Unternehmen trägt zu angesehenen Open-Source-Projekten bei.

4. Kostenerstattung für Berufsausbildung und/oder Konferenzen

5. Flexible Arbeitszeiten;

6. die Möglichkeit, mit neuen oder unbekannten Technologien zu arbeiten;

7. die “Startup-Kultur” - auch bekannt als Mangel an Politik/Bürokratie;

8. Firmenkapital

9. Bekanntheitsgrad: Ihr Unternehmen oder Ihr Produkt ist bekannt. Kandidaten erwähnen gerne, wo sie arbeiten, und hören die Leute mit “Oh, toll! Ich mag ihre Produkte”

10. Wohltätige oder revolutionäre Unternehmensziele/Visionen. Menschen schreiben gerne Code, der das Leben der Menschen besser macht.

11. Überdurchschnittlich gut bezahlt. Geld deckt eine Vielzahl von organisatorischen Sünden ab.

12. Jährliche Rückzüge des Unternehmens an kühle Orte

Diese Liste ist nicht umfassend, aber wenn Ihr Unternehmen ein oder mehrere Dinge wie die Punkte auf dieser Liste nicht anbietet, dann könnte jedes Hindernis in Ihrem Einstellungsverfahren einen Kandidaten auf die Suche nach einem Kandidaten schicken, der dies tut.

Nehmen wir also an, dass Sie aus welchem Grund auch immer keine Anreize wie die oben genannten für Ihre Kandidaten anbieten oder anbieten können, um sie davon zu überzeugen, für Sie kostenlos Code zu schreiben. Was können Sie dann tun? Ich habe zwei Alternativen, die die meisten Kandidaten einer emsigen Programmierarbeit vorziehen werden:

Alternative #1 - Zahlen Sie ihnen einen Stundensatz, damit sie Ihre Programmieraufgabe so erledigen, als wären sie ein Auftragnehmer. Das ermutigt sie dazu, es ernst zu nehmen, sowohl aus beruflichen Gründen als auch weil… sie bezahlt werden. Das kostet Sie Geld, aber das gilt auch für jede Form der Rekrutierung. Wenn Sie wirklich gut sind, können Sie sogar einen Weg finden, wie sie einen tatsächlichen Fehler in Ihrem Code diagnostizieren und beheben können, in diesem Fall bekommen Sie etwas Nützliches für Ihr Geld.

Alternative #2 - Sie haben wahrscheinlich schon kostenlosen Code geschrieben, den sie Ihnen zeigen werden, wenn Sie nur fragen. Die meisten Programmierer haben Code auf Github, Bitbucket, Q&A-Webseiten wie Stack Overflow oder könnten Ihnen Code zur Verfügung stellen, den sie noch nicht veröffentlicht haben.

Warum sollten Sie sie dazu bringen, Code zu schreiben, der ihnen egal ist, wenn Sie sie stattdessen ein leidenschaftliches Projekt mit Ihnen teilen lassen könnten? Es ist garantiert weniger langweilig, als noch eine weitere Lösung für dasselbe allgemeine Problem zum 100. Mal zu lesen. Und da der Code bereits geschrieben ist, sparen sowohl Sie als auch Ihr Kandidat Zeit. Außerdem erhalten Sie einen Einblick, welche Art von Code sie gerne schreiben, was Aufschluss über ihre Persönlichkeit gibt und wie gut sie zu Ihrer Unternehmenskultur passen werden.

Als direkte Antwort auf Bobos Antwort (die die akzeptierte Antwort ist, weil der Typ sie selbst geschrieben und akzeptiert hat, was ich ehrlich gesagt etwas pathetisch finde):

Sie kommen von einer völlig falschen Prämisse. Ich will nicht für Sie arbeiten. Wie kommen Sie auf die Idee, dass jemand für Sie arbeiten möchte? Sie sind nur eines von vielen Unternehmen, die eine Stelle anbieten. Ich möchte nicht für Sie arbeiten. Ich möchte Ihr Unternehmen bewerten, und wenn Sie sich an die Spitze aller anderen setzen, dann möchte ich für Sie arbeiten.

Es gibt ein Dutzend Unternehmen, in denen ich arbeiten kann, Sie stehen nur irgendwo in der Schlange. Ich schaue mir zuerst an, welche Firmen es gibt, schicke ihnen meinen Lebenslauf, sie können ihn lesen und entsprechend beeindruckt sein oder auch nicht, dann haben Sie normalerweise ein kurzes Telefongespräch, bei dem sie mir zeigen, dass sie eine interessante Arbeit haben, und ich zeige, dass ich die Fähigkeiten habe, und jeder Kodierungstest kann ganz am Ende kommen.

Ihr Take-Home-Test bringt Sie ganz ans Ende der Schlange. Als Ausgleich müssten Sie eine Gehaltsspanne von £10.000 höher als andere ausweisen. Einen Job zu finden ist ohnehin zeitaufwendig; jemand, der es zehnmal so zeitaufwendig macht, steht am Ende der Liste. Wenn ich die Wahl habe, einen Lebenslauf zu schicken, ein Telefoninterview mit zehn Unternehmen zu führen und Hausaufgaben für Sie zu machen, dann raten Sie mal, was ich tun werde.

Was passiert, ist, dass Sie Kandidaten finden, die für Sie arbeiten wollen, weil sie anderswo keinen Job bekommen.

Ich glaube wirklich, dass es helfen kann, festzustellen, wer die im Lebenslauf aufgeführten Sprachen wirklich kennt.

Wenn das wirklich Ihr Ziel ist, würde ich einen anderen Ansatz in Betracht ziehen. Wie andere Antworten bereits angedeutet haben, JA, sollten Sie immer eine Codierungsfrage haben, aber Codierungsfragen gehen selten ins Detail der Sprache. Ich habe einige Fragen gesehen, die zum Testen nützlich sind:

1. Vergleichen und Gegenüberstellen von Java und C (oder was auch immer zwei Sprachen relevant sind, auf dem Lebenslauf des Kandidaten stehen usw.)
2. Welche Funktionen sollten Ihrer Meinung nach der Sprache hinzugefügt werden (oder noch besser, was halten Sie von dieser speziellen vorgeschlagenen/neuen Änderung der Sprache?)

Ingenieure, die das eine oder andere gesehen haben, wissen, wie man diese Fragen ziemlich einfach und in nur wenigen Minuten beantworten kann.

Was ist Ihr Geschäftsproblem?

Wenn man alle Argumente für oder gegen bestimmte Tests außer Acht lässt, läuft alles auf einen Kompromiss hinaus - mehr Filter werden einige gute Kandidaten abschrecken, weniger Filter werden schlechte Kandidaten durchlassen, die Sie vielleicht bald nach der Einstellung ersetzen müssen.

Es läuft alles darauf hinaus, Ihre Geschäftssituation zu betrachten, statt auf allgemeine Praktiken.

Haben Sie derzeit ein Problem, bei dem es Ihnen an qualifizierten Kandidaten mangelt und Sie nicht so schnell einstellen können, wie Sie Ihre Geschäftsziele erreichen müssen? Sie müssen sich von dieser anfänglichen Programmieraufgabe verabschieden.

Haben Sie derzeit ein Problem, bei dem Sie mit der Qualität Ihrer letzten Einstellungen nicht zufrieden sind? Dann müssen Sie weitere Filter wie diesen implementieren.

Haben Sie beide dieser Probleme, und beide sind gleichermaßen schmerzhaft? Herzlichen Glückwunsch, Sie haben die richtige Balance für diesen Kompromiss gefunden.

IMHO gibt es eine fast 0%ige Chance, dass ein frischgebackener Hochschulabsolvent in der Lage wäre, einen harten Programmiercode auf Einstiegsniveau zu beherrschen. Wenn Ihr Codierungstest eine Woche Zeit in Anspruch nimmt, sollten Sie in Ihrer Anforderung deutlich erwähnen, dass Sie Programmierer mit mindestens 2+ Jahren Erfahrung suchen, denn ich denke, dass für eine Code-Arbeit, die eine Woche dauert, viel Erfahrung erforderlich sein sollte. Und ich denke, wenn Sie auf der Suche nach frischen Absolventen sind, dann entwerfen Sie Ihren Test entsprechend, und Sie können viele Ideen im Internet finden, oder aber Sie können erfahrene Programmierer, die für Sie arbeiten, bitten, einen geeigneten Test für frische Absolventen zu entwerfen.

Ich dachte, dass ich diese Frage beantworte, aber es ist schon ein Jahr her, dass sie gestellt wurde, und wir haben uns daran gehalten.

FINDINGS

Positive der Annäherung

1) Nehmen Sie testweise die demotivierten Kandidaten mit nach Hause und ersetzen Sie sie durch Kandidaten, die wirklich für Sie arbeiten wollen. Das allein macht es schon lohnenswert, denn motivierte Menschen = produktive Mitarbeiter. Wenn sie sich nicht die Mühe machen können, eine einstündige Aufgabe zu erledigen, dann sagt das viel über ihre Einstellung aus, den Job zu bekommen.

2) Ich stimme mit anderen überein, dass der Take-Home-Test nicht länger als eine Stunde dauern sollte - meiner ist sehr einfach. Ich habe die folgenden Ergebnisse erhalten, als ich ihn in den Rekrutierungsprozess eingebracht habe -

a) Einige Kandidaten füllen ihn nicht aus. Lohnt sich nicht, eingestellt zu werden.

b) Einige Kandidaten versuchen es, füllen ihn aber schlecht aus. Es lohnt sich nicht, eingestellt zu werden.

c) Einige Kandidaten betrügen, weshalb es sich lohnt, weitere Fragen zu ihrem Auftrag zu stellen. Wir taten dies mit einem kürzlich eingestellten Kandidaten, der sich dann nicht die Mühe machte, auf unsere E-Mail über den Auftrag zu antworten. Es lohnt sich nicht, ihn einzustellen.

d) Einige Kandidaten ziehen ihre Bewerbung plötzlich zurück, nachdem sie von einem technischen Auftrag gehört haben, für den sie sich zuvor sehr interessiert gezeigt hatten. Wahrscheinlich sind sie einer Kugel ausgewichen.

e) Einige Kandidaten machen sich sehr gut, kommentieren ihren Code und stellen bei ein oder zwei Gelegenheiten Unterlagen zur Verfügung. Worth hiring.

Negative Herangehensweise

1) Bewerbungsabbrüche von Kandidaten, die durch die “Take Home”-Aufgabe abgeschreckt werden, machen es länger, jemanden Geeigneten zu finden.

2) Man kann nicht immer sagen, ob jemand geschummelt hat, aber deshalb wird oft ein technisches Telefoninterview geführt.

Ergebnis dieses Ansatzes

Einer unserer Mitarbeiter, den ich mit diesem Ansatz eingestellt habe, hat sich als Star-Angestellter erwiesen. Er arbeitet nach über einem Jahr immer noch für uns. Er ist zuverlässig und technisch begabt.

Eine ungewohnte Maus oder ein unerwartetes Tastaturlayout (insbesondere Mac vs. PC) oder eine andere IDE können die Leistung dramatisch verlangsamen, ohne dass ein Unterschied in der Kompetenz besteht. Außerdem erfordert eine vollständige Anwendung oft eine Menge Code, für dessen Eingabe ein Entwickler möglicherweise nicht genug Zeit hat oder sich nicht einmal daran erinnern kann. Eine neue Anwendung komplett von Grund auf neu zu starten, ist eigentlich eine sehr seltene Aufgabe; die meiste Arbeit konzentriert sich auf die Erweiterung oder Verbesserung des vorhandenen Codes.

Daher schlage ich vor, während des Interviews nur sehr kurze und sorgfältig vorbereitete Aufgaben zu geben. Am besten ist es, das Schreiben einer Funktion zu verlangen, die vorgegebene Parameter nehmen und das erklärte Ergebnis zurückgeben muss, und ich würde empfehlen, dies auf Papier zu tun und auf Computer ganz zu verzichten.

Ich würde sie zu einem Online-Quiz schicken, bei dem man Leute herausfiltern kann, die keine Ahnung haben. Zumindest hätte man ein Gespür dafür, ob sie wissen, wovon sie reden.

Zu Beginn meiner Karriere sagten mir Headhunter: “Sie haben es mit Leuten zu tun, die den Kasten lesen und eine Bewerbung auf ihren Lebenslauf setzen. Ich nehme an, dass dies immer noch den jungen und naiven Leuten passieren kann, aber wenn man in ein paar Interviews beschimpft wird, erfährt man, dass dies ein schlechter Rat ist…

Ich habe kürzlich einen Test zum Mitnehmen bekommen. Es handelte sich um eine ausgewachsene Anwendung, die eine Verbindung zu einem Socket-Server herstellen musste, der einen langsamen Feed simulieren musste. Der Client musste dynamisch aktualisieren, in der Lage sein, den Feed abzubrechen und XML zu schreiben und zu lesen.

Ich möchte sowieso irgendwie Sockets lernen, da ich darüber nachdenke, sie für einen Poker-Server zu verwenden, den ich gerade schreibe.

Ich wollte XMLreader und XMLwriter lernen.

Zuerst dachte ich, ich hätte es vergessen. Aber dann sah ich es als eine Chance, zu beweisen, was ich kann. Da ich keinen CS-Abschluss habe, fehlen mir einige theoretische Sachen. Sie fragten, was die 3 Säulen der OOP sind und wollten sagen, wen das interessiert.

Meine Botschaft ist, dass Leute, die den Job haben wollen, den Test absolvieren sollten.