Codebeispiele und Interviews? [geschlossen]

Seit ich hier bin, habe ich eine Reihe von Fragen gesehen, bei denen in der Antwort jemand behauptet hat, dass er niemals Portfolios oder Codebeispiele verwenden würde, die außerhalb des Interviewprozesses codiert wurden, um einen Kandidaten zu beurteilen, da dies möglich ist Code wurde von jemand anderem geschrieben. Das überrascht mich.

So wie ich das sehe, kann ich nur sehr wenig daraus lernen, wenn ich jemanden auffordere, vor Ort ein einfaches Problem zu lösen. Ich arbeite nicht für ein Unternehmen wie Google, in dem nach Jobs gesucht wird, und ich kann einen Tag von jemandem verlangen. Aber ein umfangreiches Stück Hobby-Code kann mir viel sagen.

Ja, es besteht die Möglichkeit von Plagiaten, aber sie müssen sehr gut geschult sein, um eine Stunde lang über diesen Code zu diskutieren. Und sollte dies der Fall sein, müssen sie sehr schnell lernen, um ihre dreimonatige Probezeit zu bestehen (in der ich sie ohne Grund und ohne Vorankündigung loswerden kann). Wenn sie so schnell, fair genug, gute Programmierer werden, bin ich betrogen worden, aber ich habe immer noch einen guten Programmierer.

Letztendlich sind die Kosten für unser Unternehmen und der Nutzen für den Plagiatkandidaten sehr gering.

Das brachte mich dazu, über andere Branchen nachzudenken. Künstler, Fotografen, Designer nutzen Portfolios und niemand kümmert sich zu sehr um Plagiate. Ein Autor wird für ein Buch finanziert, das auf Kapiteln basiert, die er in seiner eigenen Zeit geschrieben hat. Sie würden keinen Architekten bitten, beim Vorstellungsgespräch die Entwurfsspezifikationen für ein Haus zu zeichnen.

Was unterscheidet uns also? Warum ist es so wichtig, jemanden vor einen Computer zu stellen und ihn zu einer Datenvereinigung oder einem Fakultätsrechner zu machen, manchmal ohne Zugriff auf die Tools, die wir täglich verwenden, wie das Internet? Was ist falsch an der Idee eines Code-Portfolios?

Ich bin aufrichtig daran interessiert zu wissen, ob ich möglicherweise einen großen Fehler mache, der mich noch nicht verbrannt hat.

Mein Einwand gegen ein Portfolio hat nichts mit dem Risiko zu tun, dass das Unternehmen von jemandem getäuscht wird, der Code aus dem Internet kopiert oder, was wahrscheinlicher ist, von einem Entwicklerteam geschriebenen Code als Arbeit weitergibt. Wie Sie zu Recht betonen, können Sie mindestens so viel lernen, indem ein Entwickler eine Stunde lang über ein Projekt spricht, mit dem er im Allgemeinen vertraut ist, wie Sie können, indem er einen Fakultätsrechner von Grund auf neu programmiert.

Mein Einwand gegen ein Portfolio ist, dass das Erfordernis eines Portfolios viele talentierte Entwickler von der Überlegung ausschließt. Da ich im Gegensatz zu einem Künstler oder Fotografen keine Urheberrechte an dem von mir erstellten Code habe - er gehört meinem Arbeitgeber und / oder der Firma, die mit meinem Arbeitgeber einen Vertrag geschlossen hat -, kann ich die große Mehrheit der " interessanter "Code, den ich geschrieben habe. Wenn ich in meiner Freizeit programmiere, wird es im Allgemeinen ein Nebenprojekt bei der Arbeit sein, das mir das Leben erleichtert oder mich nervt, das ich wiederum nicht in einem Portfolio zeigen kann. Ich habe Unmengen von Beiträgen in verschiedenen Foren, aber die meisten davon sind von Natur aus relativ flach. Es gibt eine ziemlich große Anzahl solider Entwickler, die sich in einer ähnlichen Position befinden - ihr interessanter Code gehört jemand anderem. Und wenn Du'

Ein technisches Interview, in dem alle Kandidaten gebeten werden, etwas von Grund auf neu zu kodieren, bietet mindestens gleiche Voraussetzungen. Angenommen, Sie erledigen einen vernünftigen Job auf dem Bildschirm des Telefons und können die Kandidaten auf eine vernünftige Liste eingrenzen. Als Kandidat wäre es mir lieber, ein Problem zu lösen, von dem Sie wissen, dass es 8 Stunden dauern wird als mit einem zusammenhängenden Portfolio von Spielzeug-Apps, die keine Urheberrechtsprobleme haben, zu kommen.

Zunächst einmal sind wir Ingenieure, keine Künstler. Wir arbeiten in einem Team. In unserer realen Arbeitserfahrung ist "unser" Code oft das Ergebnis von Teamarbeit, denn so wird in der Regel echte Arbeit geleistet. Es gibt nicht so viel Berufsrecht, für das ich das Alleineigentum beanspruchen könnte.

Zweitens wäre der meiste Code in meinem hypothetischen Portfolio Code, den ich niemandem zeigen konnte, weil er vertraulich ist. Code, den ich für meine persönlichen Haustierprojekte erstellt habe, spiegelt nicht unbedingt alle meine Fähigkeiten und mein typisches Arbeitsverhalten wider.

Ich habe während meiner Zeit als Software-Praktiker viele Leute interviewt. Ich habe einen Punkt erreicht, an dem ich glaube, dass Quiz- und Spielzeugprogrammieraufgaben eine Verschwendung von wertvoller Bandbreite sind. Quiz- und Spielzeugprogrammieraufgaben dienen nur dazu, das zu testen, was der Interviewer weiß. Sie sind keine genaue Methode, um zu beurteilen, was ein Kandidat weiß. Zu diesem Zeitpunkt in meiner Karriere akzeptiere ich diese Art von Unsinn nur dann, wenn mir am Ende des Interviews die Möglichkeit gegeben wird, meinen eigenen Test durchzuführen.

Der beste Weg, um die Fähigkeiten eines Software-Anwenders einzuschätzen, besteht darin, mit ihm oder ihr in einer ruhigen, beruhigenden Stimme zu sprechen. Bitten Sie den Kandidaten, seine aktuelle Position zu besprechen. Wenn der Kandidat einen Bereich von Interesse anspricht, bitten Sie ihn, diesen Bereich zu erläutern. Das Ziel hier ist, den Kandidaten dazu zu bringen, seine / ihre Wachsamkeit zu verlieren. Keine Menge an Coaching kann einen Kandidaten auf das "Soft Touch" -Verfahren vorbereiten. Früher oder später wird sich die Schlinge um den Hals eines Bewerbers legen, der versucht, sich durch ein Vorstellungsgespräch durchzusetzen.

Ich bitte um ein Codebeispiel für Bewerber und es wird während des Interviews referenziert. Normalerweise lege ich jedoch mehr Wert auf die Whiteboard-Codierung, die während des Interviews durchgeführt wird.

Bei jedem Entwicklerinterview gehe ich zum Whiteboard, um die Lösung für ein einfaches Problem zu implementieren. Es gibt jedoch Regeln:

Der Antragsteller muss die Implementierung so durchsprechen, wie er es tut.

• Ich kann abschätzen, wie sie sich einem Problem nähern.
• Ich kann sehen, wie gut die kommunizieren können.
• Ich kann messen, wie schnell sie mit einem klaren Ziel sind.

Ich habe drei Probleme, deren Implementierungen alle ähnlich sind, und ich lasse sie wissen, dass sie den Code, den sie geschrieben haben, wiederverwenden oder umgestalten können.

• Ich kann sehen, ob sie sich zurückziehen können, um einen Blick auf das Gesamtbild zu werfen.
• Ich kann sehen, ob sie implementieren und umgestalten oder zur Verallgemeinerung übergehen.
• Ich kann mir sicherer vorstellen, wie gut die Reihenfolge ihrer Gedanken ist.

Bei jedem Bewerbungsgespräch geht es darum, einen guten Überblick über die Fähigkeiten der Bewerber zu bekommen und darüber, wie sie mit dem Job übereinstimmen können. Der "praktische" Teil des Interviews hat meiner Erfahrung nach in dieser Hinsicht sehr geholfen. Es hilft mir auch, den Beispielcode auszuwerten, da ich so viel mehr über die Art und Weise des Programms weiß.

Ein Codebeispiel ist eine ziemlich effiziente Methode, um Kandidaten auszusortieren. Ich kann ein Codebeispiel in 5 bis 10 Minuten beurteilen, aber selbst ein Telefonbildschirm dauert 15 Minuten und muss geplant werden (und ist nicht besonders nützlich, wenn es darum geht, etwas anderes auszusortieren meiner Erfahrung nach der Boden des Stapels).

Ich denke, die wichtigsten Einwände gegen Codebeispiele sind zweifach und lassen sich leicht überwinden:

• Das Erfordernis eines Codebeispiels stellt für einige talentierte Entwickler eine künstliche Barriere dar

Offensichtlich ist das wahr. Jede Hürde bei der Bewerbung oder Einstellung kann potenziell einen gewünschten Kandidaten aussortieren. Das Wichtigste dabei ist, dass Sie Ihr Publikum kennen - wenn Sie 1000 Lebensläufe für Ihre einzige Eröffnung haben, können Sie sich im Dienste der Effizienz einige falsche Negative leisten. Wenn Sie fünf Lebensläufe haben, können Sie sich einige Ineffizienzen im Überprüfungsprozess leisten.

Was ich jedoch für die meisten Leute vermisse, ist, dass Vorstellungsgespräche und Einstellungen im Grunde genommen ein Spiel sind, bei dem man "einen Grund findet , diese Person nicht einzustellen". Für jeden anständigen Job gibt es eine Menge qualifizierter Bewerber - der letzte ist normalerweise derjenige, der auf dem Weg keine roten Fahnen gesetzt hat. Es ist leicht, das Beste in Menschen zu sehen oder unverbindlich zu sein, aber das hilft Ihnen nicht bei der Einstellung, weil Sie am Ende 10 verschiedene Kandidaten haben, mit denen Sie sich wohlfühlen. Das bringt Sie keiner Entscheidung näher.

Jeder Leckerbissen, den Sie während der Überprüfung, Überprüfung, Befragung usw. sammeln, kann möglicherweise eine Entscheidung ohne Anstellung auslösen. Sie müssen die Sensibilität Ihres No-Hire-Triggers mit Ihren aktuellen (und potenziellen) Zukunftsaussichten in Einklang bringen. Wenn Sie sich in einer langweiligen Branche mit viel altem Code, Bürokratie und schlechtem Gehalt befinden (oft Dinge, die Sie nicht kontrollieren können), muss Ihr Auslöser weniger empfindlich sein als beispielsweise Google. Andernfalls laufen Sie Gefahr, niemals jemanden einzustellen.

Ich persönlich finde, der einfachste Kompromiss für mich war, anzufordern, aber nicht zu fordernein Codebeispiel. Wenn ich einen bekomme, ist dies nur ein zusätzlicher Datenpunkt, mit dem der Kandidat bewertet werden kann. Ebenso werde ich, wenn ich zufällig einen Bekannten habe, der in der Vergangenheit mit dem Kandidaten zusammengearbeitet hat, der Meinung dieses Bekannten etwas Gewicht beimessen. Mit niemandem zusammengearbeitet zu haben, den ich kenne, disqualifiziert jedenfalls nicht - es bedeutet nur, dass meine Arbeit bei der Bewertung ein bisschen schwieriger ist (und wahrscheinlich eine Codierungsübung beinhalten wird, wenn sie es zu einem Vorstellungsgespräch schaffen). Wenn Ihre Stichprobe schlecht ist (oder Sie von meinem Bekannten schlecht angesprochen werden), ist dies so gut wie ein No-Hire. Diejenigen, die eine Probe zur Verfügung stellen, haben möglicherweise einen kleinen Vorsprung vor denjenigen, die sich nicht in der Erstprüfung befinden. Abhängig von der Qualität und Quantität des Lebenslaufstapels und der Proben können mehr Informationen besser oder schlechter sein als keine Informationen.

• dass Proben leicht gefälscht werden

Gut ja. Lebensläufe sind es auch - aber wir sammeln sie immer noch. Warum? Aus drei Hauptgründen: Ein schlechter Lebenslauf oder eine schlechte Probe ist ein einfaches Nicht-Anheuern, das Fälschen eines Lebenslaufs oder einer Probe ist ein einfaches Nicht-Anheuern, und sie sind gute Gesprächsthemen in einem Interview. Je schneller ich den Kandidaten herausfinden kann, desto besser für alle.

Wenn Sie klug genug sind, eine gute Probe zu plagiieren, ohne erwischt zu werden, intelligent darüber sprechen und das Interview durchstehen - ich habe kein besonderes Problem damit, wie Sie am Screening vorbeigekommen sind. Hier mag es einige ethische Bedenken geben, aber das ist nicht wirklich mein Fachgebiet, weshalb ich mich nicht bemühe, den moralischen Charakter während eines Interviews zu bewerten. Für mich ist es praktisch dasselbe, als wenn mein Chef mich bittet, jemanden zu interviewen, der den Screening-Prozess nicht als Gefallen durchlaufen hat. Wenn Sie erst einmal im Interview sind, spielt es keine Rolle, wie Sie dorthin gekommen sind, da es so viel mehr und bessere Informationen gibt, die während des Interviews herauskommen.

TL; DR - ein Codebeispiel ist ein großartiges Screening-Tool, aber Sie sollten sorgfältig überlegen, ob Sie es benötigen oder nicht. Wägen Sie das Interview nach dem Screening deutlich höher als eine Stichprobe.