Sie benötigen einen Programmiertest. Aber es sollten 5-10 Minuten sein. 30 Minuten höchstens. Es gibt keinen 2-Stunden-Test, der Ihnen genau sagt, wie gut ein Programmierer ist. Sie werden nicht erkennen können, ob sie ständig wartbaren Code schreiben, oder ob sie immer richtig kommentieren, oder ob sie mit unlesbarem Durcheinander von 'klugen' Lösungen für Probleme usw. aufwarten. In 2 Stunden das einzige, was Sie werden zu erreichen, ist herauszufinden, wer offen darüber lügt, eine Sprache/Programmierung zu kennen.

Nur sollten Sie in der Lage sein, Betrug in weitaus weniger als 2 Stunden zu erkennen. 5 Minuten FizzBuzz schreiben und 2-3 kurze Fragen zu sprachspezifischen Funktionen werden Ihnen sagen, ob sie absolut wertlos sind. Und das ist ungefähr das Beste, was Sie in einem Vorstellungsgespräch tun können.

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

„Entweder denken diese Leute, dass dies einen Wert hat, was bedeutet, dass sie keine Ahnung haben, was sie tun, ODER sie wissen, dass dies Zeitverschwendung ist, aber aus irgendeinem Grund (wahrscheinlich blindlings der Bürokratie der Personalabteilung folgend) sind sie bereit, die des Kandidaten zu verschwenden Stellen Sie sich vor, was sie glauben, damit davonkommen zu können, wenn sie mich bezahlen.

Auf jeden Fall möchte ich dort nicht arbeiten."

Es gibt noch etwas, was Kandidaten abschrecken könnte : Die Dauer Ihres Vorstellungsgesprächs. Sie haben Leute, die ein Telefoninterview führen. Dann ein Test zum Mitnehmen, den sie eine Woche lang abschließen müssen. Dann gehst du die Tests durch. Dann vereinbaren Sie ein persönliches Gespräch mit dem Management. Dann (nehme ich an) machst du ein paar persönliche Interviews. Dann kehren Sie zu dem Typen zurück, den Sie einstellen möchten. Was braucht das? 2 Wochen? Länger?

In dieser Zeit habe ich bereits 3 Angebote eingeholt. Ich habe eins angenommen und fange nächste Woche an. Glaubst du, ich mache deinen 2-Stunden-Test?

Lassen Sie mich zunächst sagen, dass die Einstellung von Mitarbeitern im Allgemeinen eine erbärmlich ungenaue Wissenschaft ist, und Sie werden verschiedene Ergebnisse erzielen, egal was Sie versuchen. Trotzdem hatte ich das Gefühl, dass ich meine Gedanken dazu teilen sollte.

Ich denke, Programmierübungen sind ein Reinfall, vor allem, weil Sie Leute finden werden, die verzweifelt sind und viel zu viel Zeit haben, um sie zu erledigen. Wenn sie einen Vollzeitjob haben, müssten Sie fragen, wie viel Zeit/geistige Energie sie ihrem derzeitigen Arbeitgeber nehmen, um für jemanden zu arbeiten, der sie nicht einmal bezahlt. Willst du, dass sie dir solche Dinge antun?

Wenn sie gut sind, führen sie außerdem höchstwahrscheinlich Vorstellungsgespräche mit vielen Arbeitgebern. Ratet mal, welche sie priorisieren werden? Diejenigen, die nicht darum bitten, Projekte abzuschließen, bevor sie überhaupt mit einem technischen Leiter telefonieren.

Es gibt auch das Problem des Plagiats. Sicher, sie werden im persönlichen Gespräch herausgefunden, aber bis dahin haben Sie bereits die Zeit von (vermutlich) hochbezahlten Leuten im Unternehmen verschwendet, die diese Person interviewen.

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

Ich kann Ihnen jetzt sagen, dass ich ihnen danke sage, 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 dies als Problem ansieht, sagt mir das, dass ihm meine Work-Life-Balance im Job egal wäre (insbesondere, wenn es ihm egal ist, bevor ich sie habe). Kein Unternehmen außer vielleicht Google, Apple oder Facebook könnte damit durchkommen.

Meiner Erfahrung nach scheiden Take-Home-Projekte schlechte Programmierer nicht aus und führen wahrscheinlich dazu, dass gute Programmierer einen Job finden, bei dem sie nicht durch einen Reifen springen müssen, um mit dem Personalchef zu sprechen.

Denken Sie so darüber nach. Ein guter Programmierer kann leicht telefonische und persönliche Interviews erhalten. Jeder zusätzliche Hürden, durch den sie springen müssen, bedeutet, dass sie den einfacheren Weg nehmen und von jemand anderem interviewt (und eingestellt) werden, der genauso viel bezahlt. Wenn Sie Leute dazu bringen, durch Reifen zu springen, stellen Sie sicher, dass sie von Anfang an sehen, dass es sich lohnt.

Ein schlechter Entwickler kann so lange brauchen, wie er will. Sie werden nicht sehen, dass sie 4x so lange brauchen; Sie sehen nur den abgeschlossenen Test. Sie werden auch nicht sehen, dass sie sich an Google oder ihren Kumpel wenden, um Hilfe bei einer ifAussage zu erhalten.

Mein letztes Unternehmen hat dies getan, und die überwiegende Mehrheit der Leute, die wir zu einem persönlichen Vorstellungsgespräch eingeladen haben, scheiterte am Fizz-Buzz (etwa 65 %). Ich denke, das ist passiert, weil wir versehentlich gute, vielbeschäftigte Leute aussortiert haben, die kein Interview mit einem anderen Unternehmen brauchten, und gleichzeitig ein einfaches Interview vor schlechten Programmierern baumeln ließen.

Was wir meiner Meinung nach stattdessen hätten tun sollen

Anstatt den Leuten eine Aufgabe zum Mitnehmen zu geben, deren Benotung 15 bis 20 Minuten dauerte, hätten wir ein 15 bis 20-minütiges Skype-Interview führen sollen, in dem wir Fragen wie Fizz Buzz gestellt haben. Dies hätte die gleiche 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 detaillierter Artikel über Fizz-Buzz und allgemeine Interviewpraktiken.

Eine gegensätzliche Ansicht von jemandem in den Schützengräben auf beiden Seiten dieser Frage. Ich vermute, dass diese Antwort Ablehnungen hervorrufen wird, aber es ist eine hochinformierte Meinung, die sich über mehrere Jahrzehnte in diesem Geschäft entwickelt hat. Weil ich das gerne mache, schreibe ich immer noch jeden Tag Code für meinen Lebensunterhalt und als Hobby in meiner "reichlichen Freizeit", aber ich war auch der letzte Entscheidungsträger bei der Einstellung von ein paar Dutzend Programmierern und habe geholfen, Interviews zu führen und über die Einstellung einer ziemlich großen Anzahl mehr beraten.

Lawrence hat Recht: Die Einstellung ist erschreckend ungenau. Aber wir werden mit der Zeit immer besser darin. Mehr als persönliche Chats, mehr als Trivia-Fragen, kurze Programmierungsherausforderungen vor Ort sind ein zunehmend wesentlicher Bestandteil davon: nicht nur für das Können, sondern auch für die Einstellung.

Beachten Sie, dass ich "kurz" gesagt habe . Wir geben Kandidaten einen Laptop, der mit einer 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, aber kein Internet haben, und sie werden gebeten, während des Tests keine Mobiltelefone zu verwenden. Sie haben eine Stunde Zeit, um zwischen null und fünf Probleme zu lösen, angefangen bei „FizzBuzz“, bis hin zu etwas in der Größenordnung eines einfachen Multi-Threaded-Producer/Multiple-Consumer-Systems.

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

Übrigens haben wir vermeintlich erfahrene Programmierer daran gescheitert , FizzBuzz richtig hinzubekommen. Lassen Sie mich das noch einmal sagen: Wir hatten eine Handvoll Kandidaten, die FizzBuzz nicht richtig ausgefüllt haben. Normalerweise, indem man Anweisungen nicht befolgt, aber das Lesen der Spezifikation ist ein wesentlicher Bestandteil des Entwicklerdaseins.

Wir lassen sie Code schreiben, während sie hier vor Ort sind, anstatt ihnen aus mehreren Gründen Hausaufgaben zu geben, teils wegen des Betrugsrisikos, teils um jedem Kandidaten die gleiche Chance zu geben, die Probleme zu lösen. Wir rotieren auch Probleme in und aus dem Challenge-Set und diskutieren anschließend Lösungen mit den Kandidaten.

Ich fühle mich sehr stark zu diesem Thema. Ich habe noch nie erlebt, dass ein Kandidat wegen unseres Programmiertests eine Stelle abgelehnt oder das Vorstellungsgespräch abgebrochen hat. Dies kann jedoch durch die Tatsache beeinflusst werden, dass wir den Personalvermittlern, die uns betreuen, mitteilen, dass der Prozess eine Vor-Ort-Programmierung umfasst. Wir sehen also vielleicht einfach nicht die Kandidaten, die denken, dass es "unbezahlte Arbeit" ist, eine Stunde Code zu schreiben. Wenn ja, gute Besserung. Wenn sie denken, dass eine Stunde Codieren eher „Arbeit“ ist als eine Stunde Quizfragen zu beantworten, oder dass ihre Antworten auf Testprobleme etwas Nützliches hervorbringen 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 Angestellter: Er dachte anscheinend auch, er sei zu alt, um Anweisungen zu geben oder zu lernen, und schließlich mussten wir ihn gehen lassen.

Eines der Dinge, die ich im Laufe der Jahre, in denen wir dies tun, entschieden habe, ist, dass jedes Unternehmen, das nicht testet, mich weniger wahrscheinlich als Mitarbeiter einstellen wird. Wie ihre Antworten auf Fragen, wie sie für Quellcodeverwaltung usw. verwenden, sagt mir die Frage, ob ein Unternehmen testet, viel darüber aus, wie gut es im Geschäft der Softwareentwicklung ist.

Also, was sollten Sie tun? Sie sollten das tun, was für Ihre Organisation funktioniert, aber mein Rat ist, die Tests fortzusetzen, aber sie vor Ort als Teil des Vorstellungsgesprächs durchzuführen. Sagen Sie ihnen im Voraus, dass dies Teil des Prozesses ist, und tun Sie dies, bevor sie sich mit dem oberen Management treffen (aber Sie sollten sie zuerst treffen, um sie zu beruhigen). Und wirklich: Überspringen Sie das Interview mit dem oberen Management, wenn es scheitert. Machen Sie sich keine Sorgen um die Popularität bei Kandidaten oder Postern im Internet. Die Kosten einer schlechten Einstellung sind viel schlimmer als die Kosten einer Verzögerung, bis Sie eine gute Einstellung vorgenommen haben .

Warum keine Heimtests?

Selbst wenn wir die Möglichkeit des Betrugs und den Rückwärtsfilter ignorieren, der dazu führt, dass gute und ehrliche Kandidaten Unternehmen mit Codierungstests für zu Hause meiden, ist der Wert von Codierungstests für zu Hause begrenzt.

Wenn es sich um eine leitende Position handelt, kann ein leitender Entwickler mit Menschenkenntnis innerhalb von weniger als 10 Minuten sagen, ob der leitende Entwickler am anderen Ende der Leitung gut ist oder sich nur etwas ausdenkt. Wir werden nicht wissen, wie gut genau, aber wir werden so viel wissen, wenn nicht mehr, als uns jeder denkbare Codierungstest für zu Hause sagt.

Wenn es um eine Junior-Position geht, erwarten wir nicht viel in Bezug auf technisches Know-how. Wir suchen Enthusiasmus, Lernbereitschaft und Talent - nichts davon wird bei einem Coding-Test zu Hause entdeckt. Es gibt zu viele Dinge, die Junioren vergessen dürfen. Wenn wir sie einstellen, müssen wir sie sowieso ausbilden.

Wie stattdessen testen?

Geben Sie ihnen als Filter einfach 10 Minuten Zeit, um eine FizzBuzz- Variante vor Ort während der ersten Interviewrunde zu lösen, oder, wenn Sie mit guten Lebensläufen überschwemmt werden und einen weiteren Filter benötigen, tun Sie dies vor der ersten richtigen Interviewrunde über Skype.

Sobald sie die Filter bestanden haben, müssen Sie mehr über die Programmierfähigkeiten Ihrer Kandidaten erfahren. Ich empfehle, 30 Minuten bis höchstens 2 Stunden entweder mit Paarprogrammierung oder Code-Reviews zu verbringen – echte Arbeit und keine Übung. Wiederholen Sie 1-2 Mal mit verschiedenen Partnern. Der Vorteil von Pair Programming und Code Reviews liegt darin, dass der Entwickler bereits über ausreichende Kenntnisse verfügt, die er einbringen kann.

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

Hier ist ein weiterer Punkt, den ich in den vorhandenen Antworten nicht sehe (von denen ich denke, dass sie das Thema im Allgemeinen gut abdecken). Ich würde mir genau und ernsthaft ansehen, wie lange es tatsächlich dauert, bis die Leute fertig sind. Ich hatte vier Vorstellungsgespräche, bei denen ich eine Programmierübung absolvieren musste, die jeweils anders durchgeführt wurden (und jedes seine eigenen Vor- und Nachteile hatte). Zwei der vier (Nummern 3 und 4 unten) haben viel länger gedauert als angegeben, und beide habe ich aufgrund des damit verbundenen Schwierigkeitsgrades aufgegeben. Ich habe sie unten beschrieben und aus meiner Sicht vom Besten zum Schlechtesten geordnet.

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 (einen Fehler finden und beheben, den sie absichtlich hinzugefügt hatten, ein neues Feld hinzufügen eine Infotabelle usw.). Sie gaben mir genau eine Stunde dafür, und nach einer Stunde gingen sie meine Lösung und meine Herangehensweise an die Probleme durch. Das gab ihnen einen besseren Einblick in mich als Programmierer, während sie meine Zeit respektierten, indem sie sie kurz und bündig hielten.
2. Während des technischen Interviews ließen sie mich ein Problem durcharbeiten, auf das sie während der Entwicklung auf einem Whiteboard gestoßen waren, während sie Ideen von ihnen abprallen ließen. Dies war die kürzeste Option, gab ihnen aber dennoch die Möglichkeit zu sehen, wie ich Probleme bewältige und wie sehr ich die notwendige Arbeit tatsächlich erledigen kann.
3. Während des technischen Vorstellungsgesprächs (für eine Junior-Stelle in der Webentwicklung von Ruby on Rails) gaben sie mir die Aufgabe, eine Webanwendung von Grund auf neu zu erstellen, die zu einer Website navigiert, mehrere Formulare ausfüllt, wenn sie angezeigt werden, Daten von der resultierenden Seite kratzt und präsentiert das für den Benutzer. Sie sagten, dies sollte eine schnelle Übung sein, und es könnte für einen hochrangigen Webentwickler gewesen sein, aber nachdem ich zu diesem Zeitpunkt nur ein Jahr Berufserfahrung hatte, verbrachte ich vier Stunden damit, alles zum Laufen zu bringen, bevor ich aufgab und ging zu Hause (alle Interviewer waren Stunden vor mir gegangen, weil es ein Nachmittagsinterview war, sie sagten, ich solle das fertige Programm einfach speichern, wenn ich fertig bin). Dies ist eine lächerliche Aufgabe für die aufgeführte Position, die ihnen keine Ahnung von meinen Programmierfähigkeiten gab, und schien mir, als wollten sie nur versuchen, kostenlose Arbeit aus dem Deal zu bekommen. Unnötig zu sagen, dass ich den Job nicht einmal wollte, als ich an diesem Tag ging.
4. Bevor sie überhaupt ein technisches Interview hatten, gaben sie mir den Auftrag, eine Webanwendung zu erstellen, die eine API nutzen würde, die ihr Unternehmen verwendet, um „etwas Interessantes zu tun“. Das war genau so umfassend, wie es sich anhört. Dazu musste ich Folgendes tun, bevor ich überhaupt versuchte, die Anwendung zu erstellen: Erstellen Sie ein Entwicklerkonto für die API, laden Sie das API-Entwicklungskit herunter, erstellen Sie eine öffentlich zugängliche Webanwendung (mit einem anderen Entwicklerkonto), lernen Sie die API kennen und erstellen Sie Daten Repository, auf das mit der API zugegriffen werden soll. Dies dauerte natürlich viele Stunden, nur um loszulegen, und kurz nachdem ich mit der Webanwendung selbst begonnen hatte, bekam ich ein anderes Vorstellungsgespräch und kurz darauf ein Jobangebot, sodass ich die Arbeit an der Aufgabe abbrach.

Um Ihre Frage direkter zu beantworten, sollten Sie eine Programmierübung machen? Ja, aber stellen Sie sicher, dass es darauf zugeschnitten ist, das zu testen, was Ihnen wirklich wichtig ist, und dass es dem Befragten nicht viel zusätzliche Arbeit abverlangt. Möchten Sie mehr über ihr algorithmisches Denken erfahren? Geben Sie ihnen ein Algorithmusproblem. Möchten Sie mehr über ihren Programmierstil erfahren? Geben Sie ihnen ein Codierungsproblem. Möchten Sie mehr über ihren Entwicklungsprozess erfahren? Besprechen Sie mit ihnen ihren Prozess, während sie ein Problem lösen.

Lassen Sie mich beginnen mit:

• Mir wurden Tests gegeben, die ich zu Hause absolvieren musste und die zwischen 15 Minuten und 10 Stunden dauerten.
• Ich habe Online-Tests zum Durchlaufen bekommen.
• Ich wurde damit beauftragt, die Antwort auf FizzBuzz und andere modische Internettests auf Whiteboards zu schreiben.
• Ich wurde nach den quadratischen vs. runden Kanaldeckeln gefragt.

Kurz gesagt, ich habe mich mit so ziemlich allen unterschiedlichen Methoden befasst, mit denen Entwickler Interviews führen möchten. Um ganz ehrlich zu sein – ich bezweifle ernsthaft, dass die überwiegende Mehrheit der Leute, die mich interviewten, überhaupt verstanden haben, was die potenziellen Ergebnisse jedes dieser Tests waren, und letztendlich nur Leute eingestellt haben, ob sie ihnen „gefallen“ haben oder nicht.

Bevor Sie überhaupt eine Stellenanzeige aufgeben, sollten Sie sich hinsetzen und genau durchgehen, was Sie einzustellen versuchen, und „Entwickler“ ist keine Antwort, zumindest ist es keine richtige. Eine gute Antwort darauf wäre so etwas wie "Hypothekendomain-Experte".

Jemanden zu finden, der ein bisschen Code schreiben oder bei Google nach der Anwendung eines bestimmten Musters suchen kann, ist trivial im Vergleich dazu, jemanden zu finden, der in dem Geschäft, in dem Sie tätig sind, tätig war und dieses Wissen nutzen kann. Mit anderen Worten, wenn ich für eine Hypothekendokumentationsfirma einstellen würde, würde ich jemanden nehmen, der über den Unterschied zwischen einem 15-jährigen Festkredit und einem ARM-Darlehen sprechen kann, und jemandem, der einen Bubble-Sort-Algorithmus in 2 Minuten schreiben könnte. Der Grund dafür ist, dass "normale" Geschäftsleute alle möglichen seltsamen Anforderungen stellen und Domänenexperten leichter auf den Punkt kommen, was benötigt wird, während jemand, der nichts weiß, gerne Dinge hinzufügt, die nutzlos sind oder die App wirklich schlecht machen.

Um auf die Fragen zurückzukommen, stellen Sie nur Go-/No-Go-Fragen .

Ist es wichtig, dass die Person Ihnen den Unterschied zwischen einer virtuellen und einer abstrakten Methode erklären kann? Kann sein, ist es normalerweise nicht. Ich würde wetten, dass ein guter Teil der Entwickler kaum weiß, wann sie diese Schlüsselwörter verwenden sollen, aber sie sind nicht Ihre Superstars, sie sind die Basis, die ohne die visuellen Designer nicht programmieren kann.

Ist es wichtig zu erkennen, wann eine Abfrage für die SQL-Injektion geöffnet ist? Für eine Sr-Position - absolut; für eine Jr. Position Nr. Dies ist etwas, das leicht trainiert und über Code-Review gehandhabt werden kann. Daher der Grund, warum Sie die sr wollen. sie in- und auswendig zu kennen - damit sie den Nachwuchs ausbilden können.

Ist es wichtig, dass sie den genauen Maximalwert eines Int32Datentyps kennen? Normalerweise nicht - für dieses Niveau an trivialem Wissen ist Google da; aber vielleicht ist Ihre Anforderung das Codieren 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 das Scoring automatisiert werden muss, ist es trivial zu spielen. Ich fordere die Kandidaten nicht auf, die Antwort auf Fizzbuzz aufzuschreiben – fast jeder hat diesen Test gesehen und sollte die Antwort auswendig kennen; alle anderen sind im letzten jahr ins feld eingestiegen und sind sowieso jr.'s. Ich stelle auch keine Trivia-Fragen - die Antwort aufsagen zu können, bedeutet normalerweise nur, dass Sie die Frage schon einmal gehört haben.

Was ich tue, um Leute zu interviewen:

• Ich bitte sie, ein oder zwei frühere Projekte zu beschreiben. Alles, worum es mir an dieser Stelle geht, ist, es ihnen bequem zu machen und sie zum Reden zu bringen. Dies ist ein Go/No Go, denn wenn ich nicht verstehe, was sie sagen, kann ich nicht mit ihnen arbeiten.

• Ich stelle ihnen ein paar spezifische Fragen in der Technologie, die sie verwenden müssen. Wenn es sich um einen SQL-Server handelt, frage ich nach der Aktualisierung bei einem Join. Wenn es sich um HTML handelt, gebe ich ihnen eine 10-zeilige HTML-Datei mit ein paar CSS-Klassen und frage sie, was die Ausgabe ist. Dies sind triviale Fragen für Leute mit Erfahrung in diesen Bereichen und sondert Anwärter schnell aus.

• Wenn ich nach einem Sr.-Entwickler suche, stelle ich Fragen zum Domänenwissen. Keine Grenzfälle, sondern Kernprinzipien. Wenn ich Sie brauche, um ein Projekt für ein Buchhaltungs-Backend zu leiten, sollten Sie sich besser mit den grundlegenden Buchhaltungsprinzipien auskennen.

• Wenn ich nach einem Jr.-Entwickler suche, frage ich nach Lieblingsprojekten. Alles, was ich wissen möchte, ist die Art der verwendeten Technologie. Dies sollte Ihnen einen Hinweis darauf geben, was sie wirklich tun wollen. Mit anderen Worten, ein C#-Entwickler wird wahrscheinlich keine Lieblingsprojekte in PHP durchführen. Ich erwarte ehrlich gesagt nicht zu viel von einem Junior-Entwickler, außer dass er trainierbar ist. Wenn sie aktiv an einem Lieblingsprojekt arbeiten, kann ich sie schulen. Wenn sie der Typ sind, der Leute braucht, die ihnen sagen, was sie tun sollen, gibt es weitaus größere Unternehmen, in denen diese Leute arbeiten können.

Ich denke mir diese Fragen nicht spontan aus, die möglichen Antworten werden im Voraus berücksichtigt und passen zu einem Go / No Go-Muster. Wenn eine Frage nicht dazu passt, ist sie nicht relevant. Ich frage auch jeden Kandidaten die gleichen, es sei denn, ich bin zu 100 % davon überzeugt, dass ich ihn nicht einstellen werde. An diesem Punkt werde ich das Vorstellungsgespräch abbrechen.

Wenn Sie aus irgendeinem Grund immer noch darauf bestehen, einen Test nach Hause zu schicken, stellen Sie sicher, dass die Fähigkeiten, die erforderlich sind, um diesen Test in angemessener Zeit erfolgreich abzuschließen, tatsächlich Fähigkeiten sind, die Ihnen wichtig sind.

Ich hatte ein Unternehmen, das mir einen Take-Home-Test gab, bei dem es darum ging, einen benutzerdefinierten Kryptografiedienstanbieter zu schreiben. Ich habe den Test gemacht, weil er irgendwie interessant war; sie haben mich eingestellt. Zu keinem Zeitpunkt meiner Zeit dort habe ich irgendetwas getan, das auch nur im Entferntesten mit Sicherheit, Kryptographie oder sogar Mathematik zu tun hatte, als ein paar Zahlen hinzuzufügen. Ich frage mich, wie viele Leute sie mit diesem Test vertrieben haben?

Aus Sicht einer Person, die einen Job sucht, vermeide ich im Allgemeinen Orte, deren Codierung länger als 1 Stunde dauert. Einmal ging ich an diesen Ort, der ein fast 3-tägiges Java-Codierungsprojekt erforderte. Ich habe alles gemacht und der Typ war sogar beeindruckt davon, aber sie haben mir gesagt, dass sie nach der zweiten Interviewphase jemand anderen eingestellt haben. Wenn ich danach zu einem Unternehmen komme, würde ich jedes Projekt ignorieren/übergeben, das mehr als ein paar Stunden zur Fertigstellung benötigt. Meine Zeit ist genauso wertvoll wie ihre und ich verschwende sie lieber nicht mit Dingen, die mich nicht weiterbringen.

Wenn Ihre Codierungsübung zu lang ist, sind die Leute vielleicht nicht bereit, die Zeit zu investieren. Ich würde versuchen, sie so zu reduzieren, dass sie höchstens eine Stunde dauert, aber gleichzeitig ein Verständnis für Codierung und vielleicht demonstriert Setzen Sie eine Frist darauf wie "Bitte bis COB morgen abschließen" oder so etwas. Sie können immer noch etwas online „kopieren und einfügen“, machen es sich aber schwer, indem sie spezifisch sind und nicht etwas, das Sie online lesen.

Früher habe ich fest an Codierungstests und Whiteboard-Codierung geglaubt, aber ich habe angefangen zu erkennen, dass sie ziemlich nutzlos sind, weil

Was testest du überhaupt?

Ein Whiteboard-Test oder kurzer Programmiertest gibt Ihnen einen Einblick in das Individuum, 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 willst du ?

Sie wollen jemanden, der:

• leidenschaftlich
• bereit zu lernen
• Probleme lösen können*
• recht technisch
• wird Ihrem Team helfen, sich zu verbessern

* _{Beachten Sie, dass die meisten Entwickler ihre Probleme lösen, indem sie wissen, nach welchen Begriffen sie in Google suchen müssen.}

Das Letzte , was Sie einstellen möchten, ist jemand, der nicht gut zu Ihrem Team passt, weil er es nach unten ziehen wird.

Wie können Sie diese testen?

• Fragen Sie sie nach einem Projekt, das ihnen Spaß gemacht hat. Wenn sie nicht bereit sind, darüber zu sprechen, versuchen Sie, sanften Unglauben auszudrücken, z. B. "Sie können X nicht, oder?" Wenn es etwas ist, wofür sie leidenschaftlich sind, werden sie dich korrigieren. Dies wird Ihnen auch helfen zu erfahren, ob sie technisch sind oder nicht.
• Fragen Sie sie nach Dingen, die sie kürzlich gelernt haben. Oder was sie aus dem Projekt gelernt haben, an dem sie gearbeitet haben.
• Fragen Sie sie nach dem letzten Mal (oder einer Zeit), in der ihnen etwas Wissen fehlte. Wie bekamen sie die Informationen, die sie brauchten? Sind sie zu einem Teamkollegen gegangen? Haben sie im Internet gesucht?
• Fragen Sie sie, ob sie Verbesserungen an ihrem aktuellen/letzten Team sehen möchten. Brauchten sie bessere Commit-Nachrichten? Mehr Code-Reviews? Weitere Tests? Mehr Automatisierung?
• Fragen Sie sie, welche Technologie sie begeistert und warum.

Wenn Sie jemanden haben, der technisch kompetent in diesem Gespräch ist, ist es das Einfachste auf der Welt zu sagen, ob diese Person die Schlimmste sein wird. Ein Beispiel: Wir hatten einen Jungen, der zu einem Interview kam – er sagte, dass seine Java-Kenntnisse auf einer Skala von 1 bis 10 wie 7 bis 8 seien. Ich glaube nicht, dass er überhaupt wusste, dass Java in eine JAR-Datei kompiliert wurde, die später von der JVM in Maschinensprache kompiliert wurde. Ich würde mich vielleicht auf 2 oder 3 einstufen und das weiß ich .

Tatsächlich wurde ihm dieselbe Frage von unserem CTO in einem Interview am Vortag gestellt, und unser CTO rief ihn daraufhin an und erklärte ihm, dass er auf keinen Fall ein 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 arbeiteten oder die Tatsache, dass sie Umfragen nutzten, um Warteschleifen zu verhindern. Er konnte nicht eine einzige technische Sache erklären.

Der Typ wurde nicht eingestellt.

Finden Sie heraus, nach welchen Attributen Sie suchen, und finden Sie dann heraus, wie Sie diese testen können

Aber ich muss wirklich sehen, wie sie kodiert!

Okay, das ist in Ordnung – aber wenn sie nicht in einem Silo programmieren wird, ist es das Beste, sie als Auftragnehmerin für ein kleines, klar definiertes Projekt einzustellen. Vielleicht fügen Sie die Möglichkeit hinzu, einige Dateien von einem FTP-Server herunterzuladen und sie dann in Ihrer Datenbank abzulegen. Etwas Einfaches, das nicht viel/kein Domänenwissen erfordert.

Lassen Sie Ihre Kandidaten mit einem oder zwei bestehenden Mitarbeitern zusammenarbeiten 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? Sind 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.

Wie andere angemerkt haben, werden einige Entwickler möglicherweise von einer 1-2-stündigen Programmierübung abgeschreckt, um sich für einen Job zu bewerben. Was besser funktionieren könnte, ist eine Whiteboard-Sitzung, bei der der Kandidat während des Vorstellungsgesprächs ein Problem auf einem Whiteboard löst. Dies gibt Ihnen die Möglichkeit, ein persönliches Vorstellungsgespräch zu führen und gleichzeitig sicherzustellen, dass sie über technische Fähigkeiten verfügen.

Diese Probleme sollten nicht extrem schwierig sein oder einen Entwickler zum Stolpern bringen. Ein klassisches Beispiel ist FizzBuzz . So können Sie sehen, wie sie denken, und wissen auch, dass sie zumindest programmieren können und nicht googeln müssen, wie man eine Schleife macht.

WERDEN SIE DEN CODIERUNGSTEST NICHT LOS!!!!

Wenn Sie Programmierer werden wollen, müssen Sie Code schreiben, der etwas bewirkt. Quizfragen zu beantworten ist nicht so wichtig. Über vergangene Erfahrungen zu plaudern ist gut, aber keinesfalls ein Ersatz dafür, programmieren zu können.

Tun Sie, was nötig ist, um Menschen dazu zu bringen, den Test zu machen und diesen Job zu bekommen. Machen Sie es kürzer oder bezahlen Sie sie. Bringen Sie sie an einem Wochenende vorbei, damit jeder Zeit hat, diese Person in Aktion zu beobachten.

Dies hängt wirklich davon ab, ob es Personen gibt, die die Ergebnisse der Tests/Beobachtungen interpretieren können. Möglicherweise möchten Sie einen Dritten mit diesem Screening beauftragen, wenn Sie nicht wissen, wie es geht. Nur die richtige Antwort zu finden, ist nur die halbe Miete. Entwickler brauchen Google-Kenntnisse, aber es gehört noch viel mehr dazu. Wenn ein Programmierer den Test schneller durchführen kann, ist das ein Plus.

Abhängig von Ihrem Projekt bevorzugen Sie möglicherweise eine fließende Sprache, damit der Entwickler sofort effizient arbeiten kann. Auf der anderen Seite könnten Sie auf lange Sicht leiden, wenn Sie sich für den weniger erfahrenen Programmierer entscheiden, der mit einem Schlüsselmerkmal Ihrer App hängen bleibt, oder er baut eine so schlechte Struktur auf, dass es schwierig ist, sie zu ändern und zu warten. Vielleicht wären Sie mit einem guten Programmierer besser dran gewesen, der bereit ist, sich anzupassen und die erforderliche Sprache zu lernen. Es gibt viele Entwickler, die vor bestimmten Stacks, Frameworks, Sprachen, Tools und Betriebssystemen absolut davonlaufen werden.

Entwickler sind kritische Positionen, deren Besetzung sehr teuer ist. Ich verstehe Ihre Sorge, dass Sie zu viele gute verjagen, aber Sie brauchen nur einen. Sparen Sie nicht.

Meiner Meinung nach ist das Problem, das Sie hier haben, nicht unbedingt der Programmiertest. Zuerst haben Sie das telefonische technische Interview und dann einen Heimarbeitstest vor einem persönlichen Interview. Es klingt, als würden Sie Ihre Kandidaten auf Distanz halten und es bis zur letzten Minute belassen, bevor Sie sie treffen. An welchem ​​Punkt erwarten Sie, dass sich Kandidaten entscheiden, für Sie zu arbeiten?

Ich gehe davon aus, dass Ihre Stellenanzeige den meisten ähnlich ist und sich daher auf den Standort, das Gehalt und eine (Wunsch-)Liste mit Fähigkeiten konzentriert. Die Kandidaten wissen nicht wirklich, woran sie arbeiten würden, irgendetwas über die Umgebung oder die Menschen, mit denen sie interagieren müssten. Sie haben ihnen den Job noch nicht verkauft, hier fordern Sie sie auf, ihre technischen Fähigkeiten zweimal unter Beweis zu stellen, bevor sie eine einzige Frage zu der Arbeit stellen dürfen.

Ich schlage vor, dass Sie versuchen, das Format des technischen Telefoninterviews in ein 30- bis 45-minütiges Gespräch über den Job zu ändern, einschließlich zahlreicher Gelegenheiten für Fragen von den Kandidaten, dann 15 Minuten mit technischen Fragen als Bildschirm, damit Sie immer noch die Möglichkeit haben, auszuwählen die besseren Bewerber, ohne es zu beschwerlich zu machen.

Ich würde auch in Betracht ziehen, die Programmierherausforderung vor den Vorstellungsgesprächen vor Ort durchzuführen. Es würde den Kandidaten machbarer erscheinen, ihnen einen Anreiz geben, mit dem Prozess auf Kurs zu bleiben, und Sie würden den Vorteil haben, die tatsächliche Zeit zu beobachten, die für die Herausforderung aufgewendet wird (ich denke, Sie werden überrascht sein).

Ich mag Take-Home-Tests im Rahmen von Vorstellungsgesprächen aus vielen der bereits genannten Gründe nicht – verlängert den Einstellungsprozess, entwertet die Zeit des Bewerbers, bekomme 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, ob dieser Ort gut zu ihm passt, einschließlich der Kultur, wie das Team Probleme angeht und löst. Sie suchen in erster Linie auch nach Eignung, einschließlich ihrer Arbeitsweise und ob sie über die richtigen Fähigkeiten verfügen. Ein Take-Home-Test bietet einem Bewerber keine Gelegenheit, die weichen Qualitäten eines Arbeitsplatzes zu bewerten, und Arbeitgeber erfahren nicht, wie der Bewerber das Problem angegangen 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. Sie könnten es sogar auf die Sprache X beschränken. Anstatt es per E-Mail einzusenden, laden Sie sie zurück, um es sich selbst und dem oberen Management zu präsentieren. Es gibt ihnen Autonomie und Anreiz, gute Leistungen zu erbringen, weil es ein weiteres Vorstellungsgespräch verspricht und zeigt, dass es Ihnen wichtig ist, ihre Meinung zu erfahren.

Wenn Sie einen Test verwenden müssen, um zu überprüfen, welche Kandidaten es zu einem Vorstellungsgespräch mit dem oberen Management schaffen, würde ich den Test in das Vorstellungsgespräch aufnehmen, damit Sie ihren Denkprozess gemeinsam besprechen können.

Möchten Sie Programmierer einstellen , die nicht programmieren können ?

Ich wage zu behaupten, dass Sie dies nicht tun.

Programmierer einzustellen, die nicht wirklich Probleme lösen und Code schreiben können, ist eine gute Möglichkeit, ein Technologieunternehmen zu ruinieren. Und Sie werden nicht erfolgreich darin sein, die Programmierer auszusortieren, die nicht wirklich programmieren können (und davon gibt es viele da draußen), wenn Ihr Einstellungsprozess nicht eine Art Programmiertest beinhaltet.

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

Vielleicht bist du es, aber ich denke nicht, dass du es sein solltest. Wie in den Kommentaren und Antworten erwähnt, gibt es Kandidaten, die sich nicht die Mühe machen, Programmierübungen als Teil eines Vorstellungsgesprächs zu machen, weil sie das einfach nicht brauchen, um einen Job zu bekommen .

Aber sind das wirklich die Leute, die Sie einstellen wollen? Diejenigen, die den Weg des geringsten Widerstands gehen, tun, was für sie kurzfristig am vorteilhaftesten ist, und sich nicht wirklich genug um Ihr Unternehmen kümmern, um eine einfache Programmierübung zu absolvieren? Das scheinen keine positiven Attribute zu sein, und sie geben nicht viel Vertrauen in die Fähigkeit, diese Kandidaten langfristig zu halten (was auch für ein Technologieunternehmen wichtig ist, da die Lernkurven in der Regel steil sind und die Kosten dafür hoch sind der Austausch von bestehendem Personal ist sehr hoch).

Also lassen Sie diese anderen Unternehmen die Programmierer haben, die nicht einmal gestört werden können. Sie wollen sie sowieso nicht einstellen. Im Gegensatz zu ihnen haben Sie einen Plan. Eine, die nicht auf dem Trugschluss „Ein Programmierer ist ein Programmierer“ basiert. Ihr Fokus sollte auf Qualität und Nachhaltigkeit liegen, nicht auf Bodycount.

Ist es ein Problem, Kandidaten abzuschrecken?

Generell nein, solange sie aus gutem Grund abgeschreckt werden. Sie wollen keine Leute einstellen, die nicht auf dem neuesten Stand sind. Und einige der Leute, die sagen, dass sie aufgrund der hohen Nachfrage "nicht gestört werden", könnten dies tatsächlich als Ausrede benutzen, um zu vertuschen, dass sie "nicht wirklich gut im Programmieren sind und die ganze Woche brauchen würden, um eine 1-stündige Übung zu absolvieren". Lage.

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

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

Wie kann ich unseren Einstellungsprozess verbessern?

Überprüfen Sie den Inhalt Ihrer Programmierübung. Ist es sinnvoll und angemessen für einen Interviewkontext?

Sie wollen nichts, was Tage (oder sogar Stunden) dauern wird, um fertig zu werden. Was Sie wollen, ist etwas Einfaches, um die Leute auszusortieren, die einfach nicht programmieren können , idealerweise mit genügend Raum für Nuancen, damit sich die Leute, die wirklich gut programmieren können, von anderen abheben können. Denken Sie daran, was Sie erreichen möchten (Aussortieren ungelernter und nicht seriöser Kandidaten) und stellen Sie sicher, dass Ihre Inhalte auf dieses Ziel zugeschnitten sind. Gehen Sie nicht über Bord.

Wenn Sie bereits technisches Personal haben, können Sie es verwenden, um Ihre Übung zu überprüfen (und/oder bei der Gestaltung zu helfen).

Überlegen Sie auch, wie Sie die Übung durchführen. Wenn Sie ihnen einfach eine Dokumentation geben und sagen "Hier, machen Sie das in der nächsten Woche und mailen Sie es mir", wird das wahrscheinlich nur minimal effektiv sein.

Besser wäre es, wenn Sie die Übung über ein Webportal durchführen können, bei dem die Kandidaten einchecken und die Übung starten können, und sobald sie beginnen, beginnt ein Timer von 1 Stunde herunterzuzählen. Dann reichen sie entweder innerhalb dieser Stunde etwas ein oder nicht. Das ist weniger offen, behält den Fokus des Kandidaten besser bei und bietet eine klare Deadline/Timebox, sodass 1) Sie nicht die ganze Woche auf ein Ergebnis warten müssen, das niemals kommen wird, und 2) unqualifizierte Kandidaten dies nicht tun Verschwenden Sie eine Woche ihrer Zeit mit dem Versuch, Ihre Programmierübung abzuschließen. Sie bekommen 1 Stunde, sie lösen entweder das Problem oder sie tun es nicht, und Sie kennen das Ergebnis sofort.

Und noch besser wäre es, sie zu einem Vorstellungsgespräch vor Ort einzuladen. 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/weichen Interviewfragen beginnen und dann mit dem Kandidaten paarweise 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, viele zusätzliche Informationen zu sammeln, die Sie einfach nicht erhalten, wenn Sie sich einen Haufen Code ansehen, den ein Kandidat geschrieben und Ihnen dann per E-Mail geschickt hat.

Endeffekt

Nein, Sie wollen Ihre Programmierübung nicht loswerden. Vielleicht möchten Sie es jedoch auf geeignete Inhalte überprüfen, sicherstellen, dass die Lösung nicht zu lange dauert, und auch prüfen, wie Sie es in Ihren übergreifenden Interviewprozess einfügen.

Eine selbstgesteuerte Übung zum Mitnehmen ist wahrscheinlich nicht der beste Ansatz. Aber die Lösung dafür ist nicht, die Übung ganz abzuschaffen. Jedenfalls nicht, es sei denn, Sie sind damit einverstanden, beschissene Programmierer einzustellen.

Es ist besser, viele schlechte und eine Handvoll gute Kandidaten abzuschrecken, als die Schleusen zu öffnen und ein paar schlechte einzustellen.

Als direkte Antwort auf Bobos Antwort (was die akzeptierte Antwort ist, weil der Typ sie geschrieben und selbst akzeptiert hat, was ich ehrlich gesagt ein bisschen erbärmlich finde):

Sie kommen von einer völlig falschen Prämisse. Ich will nicht für dich arbeiten . Woher kommt Ihnen die Idee, dass jemand für Sie arbeiten möchte ? Sie sind nur eines von vielen Unternehmen, die einen Job anbieten. Ich will nicht für dich arbeiten. Ich möchte Ihr Unternehmen bewerten, und wenn Sie sich von allen anderen durchsetzen, dann möchte ich für Sie arbeiten.

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

Mit Ihrem Take-Home-Test stehen Sie ganz am Ende der Warteschlange. Um dies zu kompensieren, müssten Sie eine Gehaltsspanne angeben, die 10.000 £ höher ist als andere. Einen Job zu finden ist sowieso zeitaufwändig; jemand, der es zehnmal zeitaufwändiger 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, raten Sie mal, was ich tun werde.

Sie finden also Kandidaten, die für Sie arbeiten wollen, weil sie woanders keine Stelle bekommen .

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

Wenn Sie auf der Grundlage ihrer vorhandenen veröffentlichten Arbeit nach guten Leuten suchen, müssen Sie den Test nicht mit ihnen durchführen .

Wenn Sie nur über Personalvermittler und Filter geschickt werden, 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 dir platzieren. Sie wollen einen Top-Level-Ingenieur. Wenn sie einen Top-Level-Ingenieur finden, ist das großartig, weil Sie zu ihnen zurückkehren werden, aber wenn sie es nicht können (und Top-Level-Ingenieure neigen dazu, Dinge am Laufen zu haben, die wenig Zeit für Interviews lassen), werden sie sich damit zufrieden geben Platzierung eines moderaten Ingenieurs mit einem schönen Anzug. Der Verlust für sie ist ein bisschen langfristiger Ruf, aber das ist gering im Vergleich zum Verfehlen ihrer Ziele. Wenn dies in Ihrem Fall nachweislich nicht zutrifft, halten Sie an diesem Personalvermittler fest und lassen Sie ihn niemals gehen (*),

Was Sie tun möchten, ist nachweislich interessante Kandidaten zu finden. Suchen Sie in StackOverflow und GitHub nach Top-Ingenieuren (ich habe gehört, dass StackOverflow ein Tool hat, das dabei hilft ), suchen Sie nach technisch interessanten Unternehmen, die gute Software produziert haben, aber ihre Finanzen oder Monetarisierung vermasselt haben und gerade 10 Top-Level-Ingenieure entlassen haben. Verbringen Sie Zeit damit, an Universitäten zu arbeiten und bei Abschlussprojekten zu helfen. Identifizieren Sie gute potenzielle Kandidaten und freunden Sie sich mit ihnen an, vorzugsweise persönlich, alternativ per Fernzugriff; Selbst wenn sie Angebote haben, treffen sich gute Ingenieure mit guten Ingenieuren. Außerdem können sie Ihnen sagen, wie sie über Ihren Einstellungsprozess denken.

Klingt nach viel Arbeit? Es sollte . Einer der Gründe, warum die Einstellung so „schwer“ erscheint, ist, dass Sie versuchen, sie so effizient wie möglich zu gestalten. Je mehr Zeit, Intelligenz und Ressourcen Sie darauf verwenden, desto einfacher ist es. Ob diese Ressourcen besser für den Versand von Produkten ausgegeben werden sollten, ist die ewige Managementfrage. Aber wenn Sie viel Zeit mit "Mist-Programmierer-Filtration" verbringen, verbrennt das Geld. Zumindest die oben beschriebenen Schritte haben über den Einstellungsprozess hinaus einen inhärenten Wert.

(*): Verdammt, stellen Sie sie ein .

Ich denke, Sie haben Ihre Frage etwas falsch formuliert, aber die Art und Weise, wie Sie sie formuliert haben, spiegelt ein weit verbreitetes Missverständnis über die Einstellung von Programmierern wider. Werden die Kandidaten durch die Programmieraufgabe „abgeschreckt“ oder filtern sie wegen der Aufgabe Ihr Unternehmen aus der eigenen Betrachtung heraus?

Eine Anekdote, um meinen Standpunkt zu verdeutlichen: Bei der Jobsuche vor nicht allzu langer Zeit sah ich eine Stelle in einem Unternehmen, die durchschnittlich erschien. Die Art und Weise, wie sie ihren Programmierprozess beschrieben, ließ es ziemlich gut klingen, aber es gab nur sehr wenige Details, also war ich skeptisch. Vielleicht waren sie ein guter Arbeitsplatz, vielleicht auch nicht. Aber ich dachte, ich würde mich darum kümmern, zu einem Telefonbildschirm zu gelangen, damit ich die Details herausfinden und sehen könnte, ob sie so gut sind, wie sie scheinen.

Ich klickte auf die Stellenausschreibung und wurde sofort gebeten, ein Anschreiben zu verfassen. Pfui. Ich denke, jeder Kandidat hasst Anschreiben. Ich kannte diese Firma nicht oder benutzte ihre Produkte nicht, also was könnte ich über sie sagen? Ich habe sie gegoogelt, ihre Website und Produktangebote gelesen, herausgefunden, wo ich wahrscheinlich in ihr Organigramm passen würde, wenn ich eingestellt werde, und mir ein paar Absätze einfallen lassen, in denen ich mich selbst „verkaufe“.

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 in meinem Lebenslauf. Es war lächerlich, dreimal dieselben Informationen angeben zu müssen. Ich habe den Browser-Tab geschlossen. 5 Minuten später bewarb ich mich bei einem anderen Unternehmen, das einige wirklich coole Vorteile bot, die das erste nicht hatte. Ich könnte mich tatsächlich schneller bei einem anderen Unternehmen mit besseren Leistungen bewerben, als ich durch die Reifen springen könnte, die das erste Unternehmen von mir wollte.

Sie müssen sicher sein, dass Ihre Kandidaten insbesondere in Ihr Unternehmen investiert sind, bevor Sie ihnen irgendwelche Reifen präsentieren, durch die sie springen müssen, sonst springen sie nicht. Machst du das?

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

1. Fernarbeit.
2. Kostenlose Computer/Monitore als Unterzeichnungsbonus.
3. Das Unternehmen trägt zu angesehenen Open-Source-Projekten bei.
4. Kostenerstattung für professionelle Schulungen und/oder Konferenzen.
5. Gelieferte Mittagessen.
6. Flexible Arbeitszeiten.
7. Möglichkeit, mit neuen oder unbekannten Technologien zu arbeiten.
8. „Startup-Kultur“ – auch bekannt als Politik-/Bürokratiemangel.
9. Eigenkapital des Unternehmens.
10. Bekanntheitsgrad: Ihr Unternehmen oder Ihr Produkt ist bekannt. Kandidaten erwähnen gerne, wo sie arbeiten, und hören, wie die Leute antworten: „Oh, toll! Ich mag ihre Produkte.“
11. Gemeinnützige oder revolutionäre Unternehmensziele/Vision. Menschen schreiben gerne Code, der das Leben der Menschen verbessert.
12. Überdurchschnittliche Bezahlung. Geld deckt eine Vielzahl von organisatorischen Sünden ab.
13. Jährliche Firmenrückzüge an kühle Orte.

Diese Liste ist nicht vollständig, aber wenn Ihr Unternehmen ein oder mehrere Dinge nicht wie die Artikel auf dieser Liste anbietet, dann könnte jedes Hindernis in Ihrem Einstellungsprozess einen Kandidaten dazu bringen, nach einem zu suchen, das dies tut.

Nehmen wir also an, dass Sie Ihren Kandidaten aus irgendeinem Grund keine Anreize wie die oben genannten anbieten oder anbieten können, um sie davon zu überzeugen, kostenlos Code für Sie zu schreiben. Was kannst du dann tun? Ich habe zwei Alternativen, die die meisten Kandidaten gegenüber arbeitsintensiven Programmieraufgaben bevorzugen werden:

Alternative Nr. 1 – Zahlen Sie ihnen einen Stundensatz, um Ihre Programmieraufgabe zu erledigen, als ob sie ein Auftragnehmer wären. Das ermutigt sie, es ernst zu nehmen, sowohl aus beruflichen Gründen als auch weil... sie bezahlt werden. Das kostet Sie Geld, aber jede Form des Recruitings auch. Wenn Sie wirklich gut sind, können Sie sogar einen Weg finden, einen tatsächlichen Fehler in Ihrem Code zu diagnostizieren und zu beheben. In diesem Fall erhalten Sie etwas Nützliches für Ihr Geld.

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

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

Was ist Ihr geschäftliches Problem?

Abgesehen von allen Argumenten für oder gegen bestimmte Tests läuft alles auf einen Kompromiss hinaus - mehr Filter werden einige gute Kandidaten abschrecken, weniger Filter werden schlechte Kandidaten durchlassen, die Sie möglicherweise bald nach der Einstellung ersetzen müssen.

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

Haben Sie derzeit ein Problem, bei dem Ihnen qualifizierte Kandidaten fehlen und Sie nicht so schnell einstellen können, wie Sie Ihre Geschäftsziele erreichen müssen? Sie müssen diese anfängliche Programmieraufgabe fallen lassen.

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 Probleme und sind beide gleich schmerzhaft? Herzlichen Glückwunsch, Sie haben die richtige Balance für diesen Kompromiss gefunden.

Ich denke wirklich, dass es helfen kann festzustellen, wer die in seinem Lebenslauf aufgeführten Sprachen wirklich beherrscht.

Wenn das wirklich Ihr Ziel ist, würde ich einen anderen Ansatz in Betracht ziehen. Wie andere Antworten zeigten, JA, Sie sollten immer eine Codierungsfrage haben, aber Codierungsfragen gehen selten auf Details der Sprache ein. Einige Fragen, die ich gesehen habe und die zum Testen nützlich sind:

1. Vergleichen und kontrastieren Sie Java und C (oder was auch immer zwei Sprachen relevant sind, im Lebenslauf des Kandidaten stehen usw.)
2. Welche Funktionen sollten Ihrer Meinung nach der Sprache hinzugefügt werden? (Oder noch besser, was denken Sie über diese spezielle vorgeschlagene/kürzliche Änderung der Sprache?)

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

IMHO besteht eine Chance von fast 0%, dass ein frischgebackener Hochschulabsolvent einen schwierigen Programmiercode auf Einstiegsebene ausführen kann. Wenn Ihr Codierungstest eine Woche dauert, sollten Sie in Ihrer Anforderung deutlich erwähnen, dass Sie nach Programmierern mit mindestens 2 Jahren Erfahrung suchen, da meiner Meinung nach viel Erfahrung erforderlich sein sollte, um eine Codierungsarbeit abzuschließen, die eine erfordert Woche zu absolvieren. Und ich denke, wenn Sie nach frischen Absolventen suchen, dann gestalten Sie Ihren Test entsprechend und Sie können viele Ideen im Internet finden, oder Sie können erfahrene Programmierer, die für Sie arbeiten, bitten, einen geeigneten Test für frische Absolventen zu entwerfen.

Dachte, dass ich diese Frage beantworten werde, es ist ein Jahr her, seit sie gepostet wurde, und wir haben uns daran gehalten.

ERGEBNISSE

Positive Ansätze

1) Take-Home-Test sortiert die demotivierten Kandidaten aus und ersetzt sie durch Kandidaten, die wirklich für Sie arbeiten wollen. Alleine dafür lohnt es sich, denn motivierte Menschen = produktive Mitarbeiter. Wenn sie sich nicht die Mühe machen können, eine 1-stündige Aufgabe zu erledigen, sagt das viel über ihre Einstellung zur Stellenbesetzung aus.

2) Ich stimme anderen zu, dass der Take-Home-Test nicht länger als eine Stunde dauern sollte – meiner ist sehr einfach. Ich habe die folgenden Ergebnisse erzielt, nachdem ich es in den Rekrutierungsprozess aufgenommen habe:

a) Einige Kandidaten schließen es nicht ab. Lohnt sich nicht einzustellen.

b) Einige Kandidaten versuchen es, schließen es aber schlecht ab. Lohnt sich nicht einzustellen.

c) Einige Kandidaten schummeln, an diesem Punkt lohnt es sich, nachzufragen zu ihrer Aufgabe. Wir haben dies mit einem neuen Kandidaten gemacht, der sich dann nicht die Mühe gemacht hat, auf unsere E-Mail bezüglich des Auftrags zu antworten. Lohnt sich nicht einzustellen.

d) Einige Kandidaten ziehen plötzlich ihre Bewerbung zurück, wenn sie hören, dass es einen technischen Auftrag gibt, wo sie zuvor VIEL Interesse gezeigt haben. Wahrscheinlich einer Kugel ausgewichen.

e) Einige Kandidaten schneiden sehr gut ab, kommentieren ihren Code und stellen bei ein oder zwei Gelegenheiten eine Dokumentation zur Verfügung. Mieten lohnt sich.

Negative der Annäherung

1) Bewerbungsabbrüche von Kandidaten, die von der Take-Home-Aufgabe abgeschreckt werden, verlängern die Suche nach einem geeigneten Kandidaten. ABER auf der anderen Seite positiv für das Unternehmen, da es die Wahrscheinlichkeit einer gefährlichen Fehlbesetzung verringert.

2) Kann nicht immer sagen, ob jemand geschummelt hat, aber deshalb wird es oft durch ein technisches Telefoninterview unterstützt.

Ergebnis dieses Ansatzes

Einer unserer Mitarbeiter, den ich auf diese Weise eingestellt habe, hat sich als Starmitarbeiter entpuppt. 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 es zu einem Unterschied in der Kompetenz kommt. Außerdem erfordert eine vollständige Anwendung oft eine Menge Boilerplate-Code, für dessen Eingabe ein Entwickler möglicherweise nicht genug Zeit hat oder sich nicht einmal daran erinnert. Eine neue App komplett von Grund auf neu zu starten, ist eigentlich eine sehr seltene Aufgabe; Die meiste Arbeit konzentriert sich auf die Erweiterung oder Verbesserung des bestehenden Codes.

Daher schlage ich vor, im Vorstellungsgespräch nur sehr kurze und sorgfältig vorbereitete Aufgaben zu stellen. Am besten ist es, eine Funktion zu schreiben, die bestimmte Parameter annehmen und das erklärte Ergebnis zurückgeben muss, und ich würde raten, dies auf Papier zu tun und Computer überhaupt zu vermeiden.

Ich würde sie zu einem Online-Quiz schicken, wo Sie Leute herausfiltern können, die keine Ahnung haben. Zumindest hättest du ein Gefühl dafür, ob sie wissen, wovon sie reden.

Zu Beginn meiner Karriere sagten mir Headhunter: "Sie haben es mit Leuten zu tun, die die Box lesen und eine Bewerbung in ihren Lebenslauf schreiben." Ich nehme an, das kann den Jungen und Naiven immer noch passieren, aber wenn man in ein paar Interviews verarscht wird, lernt man, dass das ein schlechter Rat ist ...

Ich habe vor kurzem einen Take-Home-Test bekommen. Es war 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 irgendwie Sockets lernen, da ich darüber nachdenke, sie für einen Pokerserver zu verwenden, an dem ich schreibe.

Ich wollte XMLreader und XMLwriter lernen.

Zuerst dachte ich, vergiss es. Aber dann habe ich es als Chance gesehen, zu beweisen, was ich kann. Ich habe keinen Informatik-Abschluss, also vermisse ich einige theoretische Sachen. Sie fragten, was die 3 Säulen von OOP seien, und wollten sagen, wen es interessiert.

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