Wie kann ich Codierer, die kopiert und eingefügt werden, schnell aussortieren? [geschlossen]

15

Geschlossen. Diese Frage ist nicht zum Thema . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage so dass es beim Thema für Software Engineering Stapel Börse.

Geschlossen vor 4 Jahren .

Ich brauche eine Möglichkeit, Lebensläufe von Leuten herauszufiltern, die nur Code kopieren und einfügen und dann hoffen, dass er funktioniert. All dies geschieht, ohne den Rest des Codes im System zu verstehen (oder zu verstehen).

Sicher, ich weiß, dass das Kopieren und Einfügen von Code Teil des Lernens eines neuen Objekts, einer neuen Steuerung usw. ist. Aber wie kann man feststellen, ob dies 70% (oder mehr) ihrer Entwicklungskarriere ausmacht?

Ich bin auf einige hochrangige Leute gestoßen, deren Fähigkeiten für das Projekt vielleicht so veraltet oder irrelevant sind, dass sie nur noch googeln, Code kopieren und dann einfügen, ohne über die Lösung als Ganzes nachzudenken. Infolgedessen kommt es im selben Projekt zu einem Missverhältnis zwischen JSON, AJAX, Callbacks, ASMX, WCF und Postbacks. Es ist klar, dass hinter jeder Technologie keine Konsistenz oder Logik steckt.

Im schlimmsten Fall erzeugt dieser Entwicklertyp Sicherheitsprobleme und Vektoren für Angriffe.

Frage

Wie würden Sie mir empfehlen, Leute herauszufiltern, die einen schlechten Programmierhintergrund haben? Kann ich es auf der Ebene des Lebenslaufs machen? Wenn nicht, wie mache ich das während des Interviews?

code-quality management skills

— goodguys_activate
quelle

Klingt so, als bräuchten Sie einen Technologiearchitekten für Ihr Projekt. Jemand muss das Gesetz WRT auf die verwendeten Standards und Technologien festlegen und es von der Haustieridee der Woche entfernen.

— quick_now

47

Ich bin auf einige hochrangige Leute gestoßen, deren Fähigkeiten für das Projekt vielleicht so veraltet oder irrelevant sind, dass sie nur noch googeln, Code kopieren und dann einfügen, ohne über die Lösung als Ganzes nachzudenken. Infolgedessen kommt es im selben Projekt zu einem Missverhältnis zwischen JSON, AJAX, Callbacks, ASMX, WCF und Postbacks. Es ist klar, dass hinter jeder Technologie keine Konsistenz oder Logik steckt.

Ich denke nicht, dass die Fähigkeiten Ihrer Entwickler das Problem sind. Ihr Problem liegt anderswo, vielleicht bei einem Teamleiter oder Architekten, der nicht das Selbstvertrauen hat, bessere Programmierdisziplinen zu "ermutigen", oder bei einem Management-Team, das die Bedeutung des Managements technischer Schulden nicht versteht und ihre nicht angibt Entwickler die Zeit und Ressourcen, um dies zu tun. Hat Ihr Unternehmen Code Reviews?

Leadership kann das Problem sein, nicht Copy-Paste-Entwickler.

— Robert Harvey
quelle

16

+1 Leadership may be the problem, not copy-paste developers. Das war genau meine Interpretation.

— George Marian

Ernsthaft. In der Kommunikationsabteilung ist etwas schwer zu beanstanden.

— MIA

+1: Das Gleiche gilt für George Marians Kommentare. Sehr gut gesagt, Robert.

— Jim G.

das ist gut so Hoffe, es erreicht so viel wie Interviewer, Rekrutierungsmanager.

— Saar

Es scheint eine Menge Konsens über diese Antwort zu geben, aber "Senior" -Level-Leute schreiben die Funktionalität nicht vor, und die Implementierung bleibt dann den Programmierern überlassen, oder? Ich meine, der Senior-Typ könnte sagen "Hey, benutze keine Horde von Technologien, benutze einfach <diese beiden>", aber die Entwickler von Copy Paste werden Copy Paste machen! Liege ich falsch ?

— Chani

13

Um Programmierer auszusortieren, die nicht programmieren können, müssen sie eine praktische Programmierübung als Teil der Screening- oder Interviewphase durchführen. (Letzteres ist wahrscheinlich besser, weil Sie die Umgebung kontrollieren können, um Betrug zu verhindern.)

Aber ich glaube nicht, dass das wirklich Ihr Problem angehen wird.

... wir haben ein Missverhältnis zwischen JSON, AJAX, Callbacks, ASMX, WCF und Postbacks im selben Projekt. Es ist klar, dass hinter jeder Technologie keine Konsistenz oder Logik steckt.

Das eigentliche Problem dabei ist, dass Ihr Team nicht genügend interne Codeüberprüfungen durchführt und kein "Spielbuch" mit bevorzugten Lösungen für bekannte Probleme erstellt. Dies ist teilweise ein Kulturproblem, teilweise ein Kommunikationsproblem und (wahrscheinlich) teilweise ein Problem mit Projektfristen.

Ein weiteres Problem ist, dass das Projekt in der Regel eine lange Lebensdauer hat und dass während dieser Lebensdauer neue Technologien / Techniken auftauchen und alte wahrscheinlich in Ungnade fallen. Wenn Sie die Verwendung von Technologien / Techniken zum "Hundefrühstück" vermeiden möchten, müssen Sie entweder:

Aufstellung und Durchsetzung einer Liste von Technologien / Techniken, die pro Projekt verwendet werden können, oder
Investieren Sie Aufwand in die Aktualisierung der von einem Projekt verwendeten Technologien.

— Stephen C
quelle

1

Wenn Sie während des Interviews keinen schriftlichen Test geben, könnten Sie sich selbst in den Fuß schießen. Ich hatte sie bei meinen letzten vier Arbeitgebern und war oft überrascht, wie einfach einige der Fragen waren. An einem Ort wurde mir gesagt, dass ein anderer Kandidat ohne Abschluss des Tests gegangen sei und geweint habe.

— Adrian J. Moreno

1

Ich stimme voll und ganz zu, dass ein schriftlicher Test während des Interviews der einzige Weg ist, um sicherzustellen, dass Ihre Rekruten wirklich gute Programmierkenntnisse haben. Aber der Hauptschwerpunkt meiner Antwort ist, dass Entwicklerfähigkeiten allein nicht ausreichen , um das Problem des SO anzugehen.

— Stephen C

Wurde vom Bearbeitungs-Timer erwischt. Ich stimme voll und ganz zu, dass Standards und Überprüfungen notwendig sind. Wir haben kürzlich ein neues Dokument mit Codierungsstandards veröffentlicht und in Kombination mit einigen neuen Codeüberprüfungsprozessen deutlich weniger Fehler bei der Qualitätssicherung festgestellt. Eines meiner nächsten Ziele ist es, ein internes Trainingsteam zu gründen.

— Adrian J. Moreno

10

Stellen Sie Leute mit einer dreimonatigen Probezeit ein. Feuern Sie sie ab, wenn sie saugen.

Wenn Sie nicht INSPEKTIEREN, können Sie nicht ERWARTEN. Code-Überprüfungen, Audit-Tools. Ein CI-Server kann diese automatisch ausführen.

Stellen Sie in Ihren Interviews echte Fragen, ebenso wie in Fragen aus echtem Code.

Bringen Sie sie dazu, Code auf das Whiteboard zu schreiben.

Wenn Sie kein technischer Manager sind, können Sie dies nicht beurteilen.

Wenn Sie nicht qualifiziert sind, lassen Sie die Tests von einem seriösen, professionellen Berater durchführen. Fragen Sie Ihre bestehenden Mitarbeiter und Ihre Wettbewerber, ob sie eine 100-fach produktive Person kennen. Bezahle sie für das Interview.

Wenn Sie ein Krankenhaus ohne OP-Leiter betreiben möchten, gehen Sie direkt vor.

— Tim Williscroft
quelle

redest du über erfahrene? Warum sollte man seine Arbeit aufgeben und sich einem Ort anschließen, an dem sie 3 Monate brauchen, um zuzulassen, dass sie saugen oder nicht :) Warum gibt es Humanressourcen?

— Saar

Ich spreche von erfahrenen, kompetenten Leuten. Sie sind auf lange Sicht billiger. Humanressourcen verhindern, dass Sie wegen Verstoßes gegen das Arbeitsrecht angeklagt werden. Ursprünglich für die numerischen Manager von Henry Ford da, um heikle Dinge zu erledigen. Wahre Geschichte, schau nach. Wenn Sie bereits wissen, dass die Person gut trainieren wird, sind Sie besser darin als ich. Die Person wird den Job wechseln, weil es so toll ist, für Sie zu arbeiten, es gibt ein großartiges Arbeitsumfeld, und nach der Probezeit erhalten sie einen fetten Bonus. Wenn sie als unbefristet entlassen werden, zahlt Ihr Unternehmen zusätzliche drei Monate aus. So etwas wie das

— Tim Williscroft

9

Ich habe in den letzten Jahren Menschen interviewt und festgestellt, dass 90% der Kandidaten einfach nicht programmieren können. Meine Interviewtechnik zur Bestimmung der Programmierung besteht darin, dem Kandidaten eine übermäßig einfache Anweisung zu geben und sie mit einem Marker und einem Whiteboard lösen zu lassen.

Fehlermodi umfassen:

Ein Design entwerfen und dann etwas anderes implementieren. Diese Kandidaten werden abgelehnt, weil sie in einem Team gefährlich sind. Nicht den Spezifikationen folgen, Fehler schreiben usw.

Nicht in der Lage sein, ein Design zu erfinden. Eine überraschende Anzahl von "erfahrenen" Kandidaten benötigt eine Spezifikation, um das Implementierungsdesign einzubeziehen.

Ich kenne die Programmiersprache nicht, obwohl mein Lebenslauf Erfahrung beansprucht.

Keine zusätzlichen Fragen stellen, um umfassendere Spezifikationen zu extrahieren.

Konstruktionsentscheidungen nicht erklären können. Dieser ist groß. Wenn jemand nicht erklären kann, warum, dann wird es jedes Mal anders gemacht und die Konsistenz geht verloren.

Das Endergebnis war, dass ich viel Zeit damit verbracht habe, Interviews zu führen und nicht sehr oft zu rekrutieren. Das Entwicklerteam war jedoch sehr gut und hatte den vollen Respekt des gesamten Unternehmens und es lieferte!

— Michael Shaw
quelle

Deine Erfahrung klingt ziemlich normal.

— quick_now

5

Ich würde FizzBuzz vorschlagen, das Jeff Atwood in dem Beitrag unter http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html erwähnt .

Schreiben Sie ein Programm, das die Zahlen von 1 bis 100 ausgibt. Bei einem Vielfachen von drei wird jedoch "Fizz" anstelle der Zahl und bei einem Vielfachen von fünf "Buzz" ausgegeben. Bei Zahlen, die ein Vielfaches von drei und fünf sind, wird "FizzBuzz" gedruckt.

— Jetti
quelle

9

-1. FizzBuzz erkennt totale Idioten. Wenn Sie kopieren und einfügen möchten, können Sie kein Vollidiot sein.

— back2dos

@ back2dos - Du solltest die "totalen Idioten" bereits ausmerzen, wenn du zu einem persönlichen Interview kommst. FizzBuzz lässt jemanden über das Problem nachdenken und wie man es am besten löst. Es ist nicht schwierig, daher sollte es diejenigen aufdecken, die kopieren und einfügen, da diejenigen, die kopieren und einfügen, das "Warum" hinter den Dingen nicht lernen.

— Jetti

3

+1. FizzBuzz erkennt mehr als nur Idioten. Es erkennt auch Menschen, die einen Mangel an technischen Fähigkeiten durch überdurchschnittliche soziale Fähigkeiten ausgleichen. Diese Menschen haben gute Chancen, einen ersten Screening-Test zu bestehen. Zum Beispiel können sie durchaus legitime Grade besitzen.

— MSalters

1

Nun, du fragst mich Fizzbuzz und ich gehe sofort weg. :) IMO in der Juniorenkategorie ist es nicht wirklich nützlich, da du die Jungs sowieso trainierst, und in der Seniorenkategorie ist es nutzlos + anstößig. Sie sollten in der Lage sein, kluge Leute mit anderen Mitteln zu erreichen. Die Codierung auf den punktuellen Fragen ist eine IME-Angabe von Wieselfarmunternehmen. Wenn ich tatsächlich an den Codierungsfähigkeiten von jemandem interessiert bin, gebe ich eine Frage zur Codeüberprüfung . Und erhalten Sie alle relevanten Antworten ohne Frustration.

— Balog Pal

@BalogPal: Ich würde lachen und anfangen, zwei Minuten lang wie verrückt zu tippen, und dann würde ich mich schämen, wenn es beim ersten Mal nicht kompiliert, ausgeführt und funktioniert.

— gnasher729

2

Ich stelle drei Interviewfragen

Schreiben Sie eine verknüpfte Liste, in der ein numerischer Typ in Java gespeichert werden kann, ohne etwas aus dem Collections-Framework zu importieren
Schreiben Sie einen Code, der zeigt, wie Sie Knoten zu dieser Liste hinzufügen / daraus entfernen können
Schreiben Sie einen Code, der zeigt, wie Sie das Maximum / Minimum aus dieser Liste ermitteln können

Ich habe gesehen, wie Leute dies in 5 Minuten abgeschlossen haben und 30 Minuten lang gekämpft haben, bevor sie aufgegeben haben.

— sal
quelle

Die erste Anforderung sollte genauer sein. java.util.LinkedList l = new java.util.LinkedList()importiert kein nichts, aber sicherlich nutzt die integrierten Sammlungen.

— Barry Brown

Dies ist eine faire Frage, insbesondere für junge Absolventen. Wenn Sie darauf geachtet haben oder überhaupt Zeit mit Programmieren verbracht haben, sollte dies fast trivial sein. Ich nehme an, es muss nicht genau sein, aber nah genug.

— Bryan Harrington

3

@Bryan, das hat noch niemand ausprobiert. Und es ist mir wirklich egal, ob die Antwort zu 100% richtig ist. Nur dass sie das Problem verstehen und es kompetent angehen können. Das häufigste Problem ist eines, bei dem das Hinzufügen / Entfernen am Anfang oder Ende der Liste nicht funktioniert. Ich habe Leuten empfohlen, eingestellt zu werden, basierend auf ihrer Reaktion darauf.

— Sal

2

Sie können dies nicht auf der Ebene des Lebenslaufs tun, da sie im Wesentlichen unendlich viel Zeit haben, dies zu schreiben. Sie können es jedoch in einem Telefoninterview tun, wenn Sie ein paar Fragen stellen, für die ein technischer Einblick in deren Funktionsweise erforderlich ist. Dies gibt Ihnen die Antwort (gut oder schlecht) und wie lange sie gebraucht haben, um dorthin zu gelangen.

Lassen Sie sie bei einem Vorstellungsgespräch Code schreiben. Nur so können Sie feststellen, ob sie wirklich programmieren können. Machen Sie das Problem einfach, geben Sie ihnen einen Computer mit einer Internetverbindung und die von Ihnen verwendete IDE installiert, lassen Sie sie jede Frage stellen (außer gimme-hte-codez) und beobachten, wie sie funktionieren.

BEARBEITEN: Für die Post-Mortem-Analyse scheint PMD über einen Kopier- / Einfügedetektor zu verfügen: http://pmd.sourceforge.net/cpd.html

Ich habe dir zugestimmt, bis "... und die IDE, die du verwendest." Codierer sind speziell auf unsere Arbeitsumgebungen ausgerichtet und mit $ random-IDE wahrscheinlich nicht vertraut. Ich habe über 20 Jahre lang programmiert und ich würde die ersten 10 Minuten damit verschwenden, herauszufinden, wie eine IDE funktioniert, wenn Sie eine auf mich werfen. Ich benutze einen Editor (Bluefish, wenn ich Webby-Dinge mache, Emacs für alles andere) und Kommandozeilen-Tools für alles andere (Revisionskontrolle, Kompilieren, wenn nötig, etc.). Ich benutze überhaupt keine Debugger. Mir wurde beigebracht, dass man es falsch macht, wenn man einen Debugger braucht: Dafür ist Debug-Code da!

— HedgeMage

@HedgeMage, ich habe nicht gesagt , sie hat es zu benutzen ... Zu sehen , wie eine Person behandelt , die Situation sehr erzählt. Wird Notizblock + Javac ausreichen? Lädt er NetBeans herunter und installiert es? Wird er fragen, wie man X in seiner IDE macht, ein bisschen hackt und nach Y und Z fragt?

@HedgeMage, Debug-Code ist großartig, wenn Sie im Voraus alle möglichen Dinge bestimmen können, die Sie möglicherweise wissen müssen. Debugger sind in Fällen hilfreich, in denen Sie Antworten auf Fragen sehen müssen, um die nächste Frage zu ermitteln, für die mit Debugcode eine neue Binärdatei erforderlich ist. Starten Sie den Computer neu und wechseln Sie erneut zum Speicherort.

1

@ Thorbjørn: Zugegeben, meine Rechnungen wurden in den letzten Jahren durch Arbeit in interpretierten Sprachen bezahlt, aber selbst in meinen C-Codierungstagen habe ich den Debugger zugunsten eines guten Debug-Codes entlassen. Vielleicht ist es nur ein Vorurteil von meiner Seite: Ich ging mit einer ganzen Reihe von Leuten aufs College, die nie gelernt haben, wie man per se codiert - sie haben einfach etwas zusammengeschlagen und dann das behoben, worüber der Debugger kreischte, bis es "irgendwie" funktionierte. Ich kann diese Art von Slipshod-Codierung nicht ausstehen. Ich wollte nicht implizieren, dass Debugger böse sind, nur dass sie und andere IDE-Funktionen nicht in alle Workflows gehören.

— HedgeMage

@HedgeMage, ich bin damit einverstanden, dass der Ansatz zum Debuggen nicht gut ist, aber die Schlussfolgerung, dass Debugger schlecht sind, ist vielleicht ein wenig zu weit gefasst.

1

Einfach

(1) Schließen Sie sie in einem Raum + Free Oxygen.
(2) Geben Sie ihnen einen PC mit Internetverbindung + IDE Ihrer Wahl + Zugang zu Lebensmitteln.
(3) Wireshark oder eine ähnliche Methode zur Protokollierung des gesamten ein- und ausgehenden Datenverkehrs verwenden.
(4) Gib ihm eine mittlere Aufgabe.
(5) Untersuchen Sie den gesamten HTTP-Verkehr nach Abschluss der Zuweisung.
(6) Wenn der Betreff große Teile des Quellcodes kopiert hat, beenden Sie den Betreff .....

Bearbeiten:

Wie bereits erwähnt7, kann man praktisch eine Videoaufnahme (Bildschirmaufnahme) machen.

— Dunkle Nacht
quelle

Neu, aber letztendlich unpraktisch.

— Robert Harvey

... oder machen Sie einfach eine Videoaufnahme, um den logischen Fortschritt zu sehen. Beobachten Sie, wie sich die Schönheit (oder das Chaos) entfaltet.

— goodguys_activate

1

Betreff beenden ? Durch die Entnahme des freien Sauerstoffs? Unordentlich!

@ Thorbjørn: Nicht so chaotisch, wie sie sich selbst in den Fuß schießen, nachdem sie große Teile des Quellcodes kopiert haben.

— Joe D

1

Wer das Internet nicht zu seinem Vorteil nutzt, ist in den Modi von gestern eingesperrt. Ich gehe IMMER davon aus, dass es einige gute Beispiele gibt, die ich mir ansehen kann, egal wie trivial die Frage ist. Ich kopiere und füge nicht ein, ich schaue mir gute Beispiele an und wende die beste Technik an. Ich bin ein Full-Stack-Programmierer, was bedeutet, dass ich ein Generalist und kein Spezialist bin und mich auf den Rest der Welt verlasse. Offenbar sündig!

— Junky

1

Wenn Sie schlechte Programmierer "aussortieren" wollen, können Sie zum Beispiel Programmer Competency Matrix (nützlich, aber nicht für alle möglichen Bereiche anwendbar - natürlich können Sie eigene erstellen) oder codility.com (die Aufgaben sind sehr gut und das spart viel Zeit).

Im Allgemeinen ist die Einstellung guter Programmierer schwierig und erfordert oft langjährige Übung. Sie können eine eigene Datenbank mit Interviewfragen erstellen, die nicht nur Fragen zum Thema Codierung, sondern auch Mathematik, Logik und Motivationsfragen enthält.

— Wojciech Sroczyński
quelle

0

Ich würde sagen, das Problem bei Ihren Kandidaten ist nicht, dass sie überhaupt nicht programmieren können, sondern dass sie nicht das Gefühl haben, das richtige Werkzeug für den Job zu verwenden. Mein Vorschlag ist eine Frage in einem Aufsatz, in der ihnen hohe Anforderungen an ein neues System gestellt und sie gebeten werden, eine Architektur bereitzustellen und ihre Komponentenauswahl zu rechtfertigen. Behalten Sie den FizzBuzz jedoch für die Kandidaten, die ohne Browser überhaupt nicht codieren können.

— Larry Coleman
quelle