Welche Fragen oder höflichen (nicht zu zeitaufwändigen) Tests würden Sie stellen, um jemanden zu finden, der interessiert und bereit ist, Code zu pflegen und zu verbessern?

Im Allgemeinen finde ich dass der Schlüssel darin besteht, mehr offene Fragen zu stellen, als Fragen, die mit einem einfachen Ja oder Nein oder einer sehr kurzen Antwort beantwortet werden können.

Etwas mehr im Sinne von "Erzählen Sie mir von der Art der Arbeit, die Sie gerne machen" würde Ihnen bessere Hinweise geben. Wenn es nur um Kreation / Erfindung und überhaupt nicht um Verbesserung / Test / Verfeinerung geht, ist der Kandidat möglicherweise nicht glücklich, die Rolle zu übernehmen, die Sie haben.

Wenn Sie diese Frage hinter sich gelassen haben, können Sie sich mit so etwas beschäftigen "Erzählen Sie mir von einer Zeit, in der Sie sich mit schwierigem Code befassen und ihn pflegen mussten."

Irgendwann im Interviewprozess möchten Sie die Details der Rolle klarstellen. Und Sie möchten klarstellen, wie lange diese Rolle dauern würde und wozu sie führen könnte. Es wäre dumm, die falschen Erwartungen für eine neue Einstellung zu setzen.

Wie andere bereits betont haben, hilft eine gute Stellenbeschreibung dabei, die richtige Art von Kandidaten zu finden und andere sich selbst auswählen zu lassen. Eine Stellenbeschreibung, die die Gedanken in "Menschen, die erkennen, dass guter Code mehr als nur pro Tag geschriebene Codezeilen umfasst und dass Design, Dokumentation und Tests ebenfalls Teil eines Codierers sind" enthält, könnte helfen.

Nach meiner Erfahrung ist die Einstellung der Ingenieure normalerweise nicht der Grund, warum Legacy-Code keine Verbesserung erfährt. Wenn Sie in der Lage sind, eine Umgebung zu schaffen, in der Wartung, Refactoring und Verbesserung des vorhandenen Codes geschätzt und gefördert werden, erhalten Sie die gewünschten Ergebnisse.

Normalerweise sehe ich Druck vom Unternehmen, Funktionen bereitzustellen, oder Kritik vom Management (Roger hat die ganze Zeit in Codebasis X verbracht und es gibt keinen funktionalen Unterschied! Warum haben wir all diese Zeit / dieses Geld ausgegeben?).

Die meisten Ingenieure, mit denen ich gearbeitet habe, hassen es, von der alten Infrastruktur behindert zu werden, und werden sie in der richtigen Umgebung gerne umgestalten oder ersetzen. Führen Sie die folgenden Schritte aus:

• Fördern Sie das Refactoring, während Sie fortfahren.
• Besprechen Sie regelmäßig den Wert der Wartung.
• Bestätigen Sie den Erfolg von Wartungsprojekten, beide gegenüber Ingenieuren und Management
• kämpfen um die Wartungszeit Ihres Teams, auch wenn Sie diese in Schätzungen für neue Funktionen einbinden müssen

Sobald Sie dies getan haben Wenn Sie eine Umgebung erstellt haben, in der kontinuierliche Verbesserungen wichtig sind, können Sie diese in der Jobbeschreibung als Vorteil auflisten. "Unser Unternehmen legt Wert auf Tests, Refactoring, CI / CD und kontinuierliche Verbesserung. Wir lassen Code nicht verrotten und wir lassen Sie auch nicht verrotten."

Also, ich würde sagen, ein paar Dinge werden Ihnen dabei helfen:

• Seien Sie bereit, erfahrenere (und damit teurere ) Entwickler zu beschäftigen Diese haben oft die Phase ihrer Karriere hinter sich gebracht.
• Erstellen Sie ein Leistungspaket, das sich mehr an diese Gruppe richtet (denken Sie an mehr Renten, Vergütungen, Arbeitsatmosphäre und weniger Tischtennis, Fussball) , und X-Boxen)
• Angesichts der Tatsache, dass Sie die Leute dazu bringen möchten, einiges an Legacy-Code, Verbesserungen, Business-as-usual usw. zu tun, versuchen Sie, Möglichkeiten einzuführen, um ein bisschen zu tun von mehr innovativer Arbeit für einen kleinen Teil der Zeit. Es ist eine gute Möglichkeit, Menschen Zeit für persönliche Projekte zu lassen. Denken Sie daran, dass Ihre Entwickler, wenn Sie aktuelle oder ältere Technologien verwenden müssen, mit Technologien zurückfallen, die ihre Karriere in ihrem nächsten Job vorantreiben. Lassen Sie sie also auch Schritt halten.

Haben Sie eine - nichts für ungut - langweiligeres Projekt, für das Sie Entwickler benötigen, ist eine der größeren Herausforderungen bei der IT-Rekrutierung, da Sie nicht alle Schlagworte hervorheben können, die Sie benötigen. Daher können Sie gute Mitarbeiter hauptsächlich durch andere Aufgaben gewinnen appelliere an sie.

Ich werde den bereits gegebenen Antworten eine neue Dimension hinzufügen. Kurz gesagt, mein Rat zu dieser Frage lautet: Betrachten Sie ältere Arbeitnehmer ernsthaft für diese besondere Rolle.

Die IT-Branche ist seit langem vom Thema Ageismus , wobei die schnellen jungen Köpfe der Jugend den etwas langsameren Köpfen älterer Arbeitnehmer vorgezogen werden. Diese etwas langsameren Köpfe verfügen jedoch über eine Fülle von Erfahrungen und Disziplinen, die vielen jüngeren Arbeitnehmern häufig fehlen, und die Wartungscodierung erfordert genau diese Disziplin.

Die Einstellung neuer Codierer erfordert selten viel Erfahrung, da Sie ihnen alle Besonderheiten der Codebasis und der Arbeitsmethoden Ihres Unternehmens beibringen. Ein "Kind", das gerade das College abgeschlossen hat, kennt vielleicht die neuesten und besten Möglichkeiten, um (wie Sie sagen) das Neue und Glänzende zu jagen, aber Sie können nicht den Instinkt lehren, Fehler zu finden, oder die Denkweise, die zum Durchstapfen erforderlich ist Meilen von unbekanntem Code. Erfahrung ist das, was diese Attribute liefert, und Erfahrung erfordert Zeit, also Jahre und Alter.

Nehmen Sie sich 2 Minuten Zeit und klicken Sie auf die folgenden beiden Google-Abfragen. Dann überfliegen Sie für jede dieser beiden Abfragen den Inhalt von 3 Treffern (insgesamt 6 Artikel):

• Abfrage Nr. 1: Mythen über die Einstellung älterer Arbeitnehmer
• Frage 2: Mythen über die Einstellung älterer Programmierer

Auch das wissen wir alle einmal Ein Programmierer beherrscht eine bestimmte Sprache, bei der er selten Probleme hat, neue zu lernen. Überprüfen Sie, ob ihre Arbeitshistorie zeigt, dass sie sich gut an neue Umgebungen anpassen. Schauen Sie sich an, wie viele Sprachen diese älteren Arbeitnehmer haben, nicht wenn sie die neuesten oder möglicherweise sogar genau die Sprachen kennen, die Sie benötigen. Wenn ihre Erfahrung nahe ist, werden sie lernen und von diesem Lernen leben. Sie stellen sie für Legacy-Arbeiten ein, genau das Gegenteil von modernster Arbeit.

Machen Sie auch Ihre Due Diligence. Verwenden Sie niemals das Alter allein als Grund für die Einstellung oder Nichteinstellung. In einem solchen Fall sollten Sie jedoch berücksichtigen, dass Alter und Erfahrung ein echtes Kapital sind und dass Sie Vorurteile haben sollten, jemanden einzustellen, der vielleicht 50 Jahre oder älter ist sorgfältig geprüft, da Ihnen möglicherweise genau die Fähigkeiten und Einstellungen fehlen, nach denen Sie in Ihrem OP gefragt haben.

Oh und noch eine letzte Sache. Seien Sie nicht überrascht, wenn Sie von Ihrer Personalabteilung einen ausweichenden Rückstoß erhalten. Aus komplizierten (aber fehlerhaften) Gründen, die auf den oben genannten Mythen beruhen, neigen Personalabteilungen häufig dazu, ältere Bewerber in IT-Abteilungen herauszufiltern. Seien Sie sich also bewusst, dass Sie möglicherweise Ihren eigenen Manager und Ihre Personalabteilung darüber informieren müssen, dass Sie diese Mythen ablehnen, ihnen einige der Studien zur Verfügung stellen, die Sie online über die obigen Links leicht finden können, und darauf bestehen müssen, dass sie nicht sind die sogenannten "überqualifizierten" Arbeitssuchenden abzulehnen, sondern sie zu den Interviews durchzuschicken.

Ich denke, die anderen Antworten sind gut, aber ich möchte besonders betonen, dass eine gute Stellenbeschreibung / Anzeige es den Leuten ermöglicht, sich selbst zu überprüfen. Sie sollten dann in der Lage sein, anhand Ihrer Interviewfragen zu beurteilen, wer sie tatsächlich richtig gelesen und klar verstanden hat.

Ich denke, Sie nähern sich dem aus der falschen Perspektive. Es ist kein Problem der Rekrutierung, es ist ein Problem der Führung. Praktisch jeder Programmierjob ist eine Mischung aus dem Schreiben von neuem und dem Verwalten von älterem Code.

Wie sie geführt und motiviert werden, ist der Schlüssel, um die überwiegende Mehrheit der Entwickler zu einer guten Leistung zu bewegen.

Kommuniziert ihr Manager ihnen die Prioritäten des Unternehmens klar? Die meisten Entwickler sind motiviert und tun gerne alles, was für den Erfolg des Unternehmens am wichtigsten ist.

Stellen Sie sicher, dass sie für ihre Beiträge belohnt werden und das Gefühl haben, dass sich das Unternehmen um sie und ihre Bemühungen kümmert?

Sind die Prioritäten des Unternehmens sinnvoll? Entwickler von einem Projekt zum anderen zu bewegen oder sie in endlosen Fehlerbehebungsarbeiten über triviale Probleme zu vergraben, ist eine großartige Möglichkeit, Ihre Entwickler zu desmotivieren. Macht Ihre Organisation regelmäßig Zeitpläne und Probleme "dringend" und verlangt die Entwickler, ständig im Laufe der Zeit zu arbeiten, um sie zu lösen?

Fördern ihr Manager und das Unternehmen eine teamorientierte Atmosphäre? Wenn es Zeit für die Krise ist, helfen ihr Manager und die oberen Führungskräfte dort, oder erwarten sie nur, dass die untergeordneten Entwickler "Todesmärsche" durchführen, um das "dringende" Problem des Tages zu lösen?

Ihre Aufgabe als Personalvermittler ist es, angemessene Erwartungen an das Arbeitsumfeld zu kommunizieren. Wenn es sich hauptsächlich um Wartungsarbeiten handelt, filtern sich Ihre Bewerber gut heraus, wenn sie dies nicht möchten.

In meinen Interviews stelle ich natürlich technische Fragen, insbesondere um unklare Teile des Lebenslaufs herauszufinden oder um mich eingehend mit Themen zu befassen, für die sie Experten sind.

Abgesehen davon habe ich Verbringen Sie so viel Zeit wie möglich, um einfach mit ihnen über unser Fachgebiet zu sprechen. Ich bin offen und ehrlich in Bezug auf das Ziel der aktuellen Diskussion (dh in einem frühen Telefonanruf würde ich sagen: "Dieser Anruf dient nur dazu, dass wir uns kennenlernen können, dies ist kein Test" usw. oder in einem Vor-Ort-Interview könnte ich sagen: "Ein Teil dieses Interviews besteht darin, das genaue Team in meinem Unternehmen herauszufinden, in dem Sie arbeiten können und Ihren Interessen so gut wie möglich entsprechen", und ich meine es ernst.

Dies ist nicht dazu gedacht, dass sie ihre Wache senken oder sie austricksen, sondern nur, um eine ehrliche Diskussion in Gang zu bringen. Ehrlich gesagt gibt mir dies die nützlichsten Informationen über die Person. Und wenn ich weiß, dass ich jemanden brauche, der an älterer Software arbeitet (was ich manchmal auch tue), dann werde ich klar und deutlich beschreiben, was ich brauche. Normalerweise kann ich an ihrer Reaktion erkennen, ob sie diese Art von Arbeit mögen, auch wenn sie dies nicht tun, aber immer noch "Ja" sagen.

Welche Fragen oder höflichen (nicht zu zeitaufwändigen) Tests würden Sie stellen, um jemanden zu finden, der interessiert und bereit ist, Code zu pflegen und zu verbessern?

Meine Die Frage wäre: "Sind Sie interessiert und bereit, Code zu pflegen und zu verbessern?" Schlicht und einfach. Ehrlich und direkt. Alles andere würde ihre und meine Zeit verschwenden. Wenn ihre Reaktion mir zeigt, dass die Antwort "Nein" ist, gehe ich von dort aus weiter. Wenn es "Ja" ist, mache ich das Übliche (grabe tiefer, lass sie ihr Verständnis dafür erklären usw.).

Ihre Reaktion geht danach in meine Gesamtbewertung ein. Das heißt, wenn sie nicht die Aufrechterhaltung der Arbeit wollen, aber viele andere Fähigkeiten haben, die wir brauchen, und wenn ich sicher bin, dass die aktuelle Teamstruktur mit so jemandem umgehen kann, dann ist alles in Ordnung. Oder wenn sie das wollen, mich aber irgendwie nicht davon überzeugen konnten, dass sie es wirklich meinten (oder verstanden) und nicht viel anderes auf den Tisch brachten, dann werden wir uns trennen.

Meiner Meinung nach geht es nicht darum, wie die Leute Refactoring oder Code neu erstellen. Die Frage ist warum oder wann , eine Frage der Gründe für eine Entscheidung in bestimmten Fällen. Ich möchte erklären, warum:

Das Schreiben von neuem Code einschließlich der Einrichtung eines neuen Konzepts wird oft als undankbar empfunden, da die Wirtschaft normalerweise Druck auf Entwickler ausübt, effizient zu arbeiten, um Umsatzvolumen in zu generieren kürzeste Zeit.

Nicht selten habe ich ein interessantes Projekt erweitert. Nach mehreren Stunden Codeüberprüfung war ich entsetzt über die falsch konzipierte Codebasis. Es war nicht wirklich erweiterbar konzipiert und hatte mehrere Sicherheitslücken. Das Erstellen von zusätzlichem Code, der von dieser Basis abhängt, hatte zu einem kaum vorhersehbaren Verhalten geführt.

Ich hatte viele Situationen, in denen ich vorschlagen musste, eine vollständige Überarbeitung basierend auf einem neuen Konzept durchzuführen, während vorhandene Algorithmen des alten Projekts einbezogen wurden. Und das hat mich bei einer großen Aufgabe nicht sonderlich begeistert.

Ich bin der Überzeugung, dass die meisten Entwickler es lieben, einen einfachen Job auf der Grundlage eines gut strukturierten Frameworks zu erledigen - soweit es ihn gibt. Ich mache. Warum sollte man sich den Kopf zerbrechen, wenn es eine viel bequemere Möglichkeit gibt?

Wenn wir also nach neuen Teammitgliedern suchen, sollten wir Kandidaten nach Szenarien fragen, in denen sie es vorziehen würden, eine vorhandene Codebasis vorher neu zu schreiben Refactoring / Erweiterung und für detaillierte Erklärungen aus ihren Gründen. Wir möchten wissen, ob der Kandidat in der Lage ist, verlässliche Entscheidungen zu treffen, die unseren Unternehmensrichtlinien entsprechen.