Quali domande o test educati (non eccessivamente dispendiosi in termini di tempo) chiederesti per trovare qualcuno interessato e disposto a mantenere e migliorare il codice?

In generale, trovo che la chiave è fare più domande aperte, piuttosto che domande a cui si può rispondere con un semplice Sì o No, o una risposta molto breve.

Qualcosa di più sulla falsariga di "Parlami del tipo di lavoro che ti piace fare" ti darebbe indizi migliori. Se si tratta solo di creazione / invenzione e niente di miglioramento / test / perfezionamento, allora il candidato potrebbe non essere contento di ricoprire il ruolo che hai.

Una volta superata la domanda, puoi approfondire con qualcosa di simile "Raccontami di una volta in cui hai dovuto approfondire e mantenere un codice difficile."

Ad un certo punto del processo di intervista, vuoi rendere chiari i dettagli del ruolo. E vuoi essere chiaro per quanto tempo durerà quel ruolo e cosa potrebbe portare. Sarebbe sciocco stabilire aspettative sbagliate per un nuovo assunto.

Come altri hanno sottolineato, una buona descrizione del lavoro aiuterà ad attrarre il giusto tipo di candidato e permetterà agli altri di auto-selezionarsi. Una descrizione del lavoro che incorpori i pensieri di "le persone che riconoscono che un buon codice è più che righe di codice scritte al giorno e che anche il design, la documentazione e il test fanno parte dell'essere un programmatore" potrebbe aiutare.

Nella mia esperienza, l'atteggiamento degli ingegneri di solito non è il motivo per cui il codice legacy non vede miglioramenti. Se sei in grado di promuovere un ambiente in cui la manutenzione, il refactoring e il miglioramento del codice esistente sono apprezzati e incoraggiati, otterrai i risultati che stai cercando.

In genere vedo pressioni da parte dell'azienda per fornire funzionalità o critiche da parte del management (Roger ha trascorso tutto questo tempo in codebase X e non c'è differenza funzionale! Perché abbiamo speso tutto questo tempo / denaro?).

La maggior parte degli ingegneri con cui ho lavorato odia essere ostacolata dall'infrastruttura legacy e la rifattorizzerà o la sostituirà felicemente nell'ambiente giusto. Prova i seguenti passaggi:

• Incoraggia il refactoring mentre procedi
• Discuti regolarmente il valore della manutenzione
• Riconosci il successo dei progetti di manutenzione, sia agli ingegneri e gestione
• lotta per il tempo di manutenzione del tuo team, anche se devi calcolarlo in stime per nuove funzionalità

Una volta che hai creato un ambiente che valorizza il miglioramento continuo, puoi elencarlo come un vantaggio nella descrizione del lavoro. "La nostra azienda apprezza i test, il refactoring, CI / CD e il miglioramento continuo. Non lasciamo che il codice si decomponga e non ti lasceremo neanche marcire."

Quindi, direi che alcune cose ti aiuteranno in questo:

• Sii disposto ad assumere sviluppatori più esperti (e quindi più costosi ), in quanto questi avranno spesso superato la fase "ooh nuova tecnologia brillante" della loro carriera
• Creare un pacchetto di benefici rivolto maggiormente a questo gruppo (pensa più pensioni, retribuzioni, atmosfera lavorativa e meno tennis da tavolo, fussball e X-box)
• Dato che vuoi che le persone facciano un bel po 'di lavoro su codice legacy, miglioramenti, attività come al solito, ecc., prova a introdurre opportunità per fare un po' di lavoro più all'avanguardia per una piccola porzione di tempo. Consentire alle persone di dedicare del tempo a progetti personali è un buon modo per farlo. Ricorda che se hai bisogno che i tuoi sviluppatori utilizzino la tecnologia attuale o meno recente, rimarranno indietro con la tecnologia che farà progredire la loro carriera nel loro prossimo lavoro, quindi lascia che anche loro continuino.

Avere un - senza offesa - un progetto più noioso per cui hai bisogno di sviluppatori, è una delle sfide più grandi nel reclutamento IT, perché non puoi evidenziare tutte le parole d'ordine di cui hai bisogno, quindi la maggior parte del modo in cui puoi ottenere un buon personale è avere altre cose da fare appello a loro.

Aggiungerò una nuova dimensione alle risposte già fornite. In poche parole, il mio consiglio su questa domanda è: Considera seriamente i lavoratori anziani per questo particolare ruolo.

Il settore IT è stato a lungo colpito dal problema dell ' età / a>, preferendo le giovani menti veloci dei giovani rispetto alle menti leggermente più lente dei lavoratori più anziani. Detto questo, quelle menti leggermente più lente hanno una ricchezza di esperienza e disciplina che spesso manca a molti giovani lavoratori e la codifica di manutenzione richiede proprio tale disciplina.

Assumere nuovi programmatori richiede raramente molta esperienza perché insegnerai loro tutte le idiosincrasie della base di codice e dei metodi di lavoro della tua azienda. Un "ragazzo" appena uscito dal college potrebbe conoscere i modi più recenti e migliori per (come dici tu) inseguire il nuovo e brillante ma non puoi insegnare l'istinto di trovare bug o la mentalità necessaria per arrancare miglia di codice sconosciuto. L'esperienza è ciò che fornisce questi attributi e l'esperienza richiede tempo, quindi anni quindi età.

Prenditi 2 minuti e fai clic sulle seguenti due query di Google. Quindi, per ciascuna di queste due query, scorri rapidamente il contenuto di 3 hit qualsiasi (6 articoli in totale):

• Query n. 1: miti sull'assunzione di lavoratori anziani
• Domanda n. 2: miti sull'assunzione di programmatori anziani

Inoltre sappiamo tutti che una volta un programmatore ha imparato una lingua particolare, raramente ha problemi ad apprenderne di nuove. Controlla se la loro storia lavorativa mostra che si adattano bene ai nuovi ambienti. Guarda quante lingue hanno questi lavoratori anziani, non se conoscono quelle più all'avanguardia o forse anche quella esatta di cui hai bisogno. Se la loro esperienza è vicina, impareranno e prospereranno su quell'apprendimento. Li stai assumendo per lavori legacy, esattamente l'opposto di essere all'avanguardia.

Quindi fai la tua due diligence. Non usare mai l'età da sola come motivo per assumere o non assumere, ma in un caso come questo considera che l'età e l'esperienza sono risorse reali e qualsiasi preconcetto che potresti avere sull'assunzione di qualcuno che forse ha 50 anni o più dovrebbe essere esaminato attentamente perché potresti semplicemente perdere esattamente le abilità e le attitudini che hai chiesto nel tuo PO.

Oh e un'ultima cosa. Non sorprenderti se ricevi un respingimento evasivo dal tuo dipartimento delle risorse umane. Per ragioni complicate (ma errate) basate su questi miti, i reparti delle risorse umane sono spesso inclini a cercare di filtrare i candidati più anziani nei reparti IT. Quindi tieni presente che potresti dover istruire il tuo manager e il dipartimento delle risorse umane a rifiutare questi miti, fornire loro alcuni degli studi che troverai facilmente online da quei link sopra e insistere sul fatto che non lo sono respingere le cosiddette persone in cerca di lavoro "troppo qualificate" ma piuttosto inviarle ai colloqui.

Penso che le altre risposte siano buone, ma aggiungerei un'ulteriore enfasi sul fatto che una buona descrizione / annuncio del lavoro consentirà alle persone di auto-selezionarsi. Dovresti quindi essere in grado di utilizzare le domande dell'intervista per giudicare chi l'ha effettivamente letto correttamente e lo capisce chiaramente.

Penso che ti stia avvicinando a questo dalla prospettiva sbagliata. Non è un problema di reclutamento, è un problema di leadership. Praticamente ogni lavoro di programmazione è un mix di scrittura di codice nuovo e mantenimento di codice vecchio.

Il modo in cui sono guidati e motivati ​​sarà la chiave per ottenere buoni risultati dalla stragrande maggioranza degli sviluppatori.

Il loro manager comunica loro chiaramente le priorità dell'azienda? La maggior parte degli sviluppatori è motivata e felice di fare ciò che è più importante per il successo dell'azienda.

Ti assicuri che siano ricompensati per i loro contributi e fatti sentire che l'azienda si prende cura di loro e dei loro sforzi?

Le priorità dell'azienda hanno senso? Spostare gli sviluppatori da un progetto all'altro o seppellirli in infinite operazioni di correzione di bug su problemi banali è un ottimo modo per demotivare i tuoi sviluppatori. La tua organizzazione rende regolarmente "urgenti" programmi e problemi e richiede agli sviluppatori di lavorare costantemente nel tempo per risolverli?

Il loro manager e l'azienda promuovono un'atmosfera orientata al team? Quando è il momento cruciale, il loro manager e i dirigenti superiori sono lì per dare una mano o si aspettano solo che gli sviluppatori di rango inferiore lavorino "marce della morte" per risolvere qualunque sia il loro problema "urgente" del giorno?

Nelle mie interviste, certo, pongo domande tecniche, soprattutto per capire parti poco chiare del CV o per approfondire argomenti in cui dicono di essere esperti.

A parte questo, io dedicare più tempo possibile a parlare semplicemente con loro del nostro campo. Sono aperto e onesto su quale sia l'obiettivo della discussione in corso (cioè, in una telefonata anticipata, direi "questa chiamata è solo per imparare a conoscerci, questo non è un test" ecc. .; oppure in un'intervista in loco potrei dire "parte di questa intervista è scoprire il team esatto della mia azienda in cui puoi iniziare a lavorare, abbinando al meglio i tuoi interessi", e lo dico sul serio).

Questo non è fatto per far abbassare la guardia o ingannarli, ma solo per avviare una discussione onesta. Francamente, questo mi dà le informazioni più utili sulla persona. E come parte di esso, se so che ho bisogno di qualcuno che lavori su software più vecchio (cosa che, in effetti, a volte faccio), descriverò chiaramente e chiaramente ciò di cui ho bisogno. Di solito posso dire dalla loro reazione se a loro piace quel tipo di lavoro, anche se non lo fanno, ma continuano a dire "sì".

Quali domande o test cortesi (non eccessivamente dispendiosi in termini di tempo) chiederesti per trovare qualcuno che sia interessato e disposto a mantenere e migliorare il codice?

Il mio la domanda sarebbe: "Sei interessato e disposto a mantenere e migliorare il codice?" Chiaro e semplice. Onesto e diretto. Tutto il resto sprecherebbe il loro e il mio tempo. Se la loro reazione mi mostra che la risposta è "no", vado avanti da lì. Se è "sì", farò il solito (approfondire, lasciare che spieghino la loro comprensione di questo, ecc.).

La loro reazione va in seguito nella mia valutazione complessiva. Cioè, se non vogliono il lavoro di mantenimento, ma hanno molte altre abilità di cui abbiamo bisogno, e se sono sicuro che l'attuale struttura del team possa gestire qualcuno del genere, allora va tutto bene. Oppure, se lo vogliono, ma in qualche modo non riescono a convincermi che lo intendevano davvero (o lo capivano) e non hanno portato molto altro sul tavolo, allora ci separeremo.

Secondo me non è il punto come le persone si sentono riguardo al refactoring rispetto alla ricreazione del codice. La domanda è perché o quando , una questione di motivi per una decisione in casi particolari. Voglio spiegare perché:

Scrivere nuovo codice che includa la configurazione di un nuovo concetto è spesso vissuto come un lavoro ingrato poiché l'economia di solito mette sotto pressione gli sviluppatori affinché lavorino in modo efficiente allo scopo di generare volume di vendite in tempo più breve.

Non di rado ho avuto un progetto interessante da estendere. Dopo diverse ore di revisione del codice sono rimasto inorridito dalla base di codice mal interpretata. Non era realmente concepito in modo estensibile e presentava diverse vulnerabilità di sicurezza. La creazione di codice aggiuntivo dipendente da quella base aveva portato a un comportamento difficilmente prevedibile.

Ho sperimentato molte situazioni in cui ho dovuto suggerire di fare una rielaborazione completa basata su un nuovo concetto includendo gli algoritmi esistenti del vecchio progetto. E questo non ha suscitato molto entusiasmo nella mia mente di fronte a un compito enorme.

La mia convinzione è che la maggior parte degli sviluppatori ami fare un lavoro facile basato su un framework ben strutturato - finora esiste. Lo voglio. Perché scervellarsi quando esiste un modo molto più comodo per farlo?

Pertanto, quando si cercano nuovi membri del team, dovremmo chiedere ai candidati scenari in cui preferirebbero riscrivere una base di codice esistente prima di refactoring / estensione e per spiegazioni dettagliate delle loro ragioni. Vogliamo sapere se il candidato è in grado di prendere decisioni affidabili in conformità con la nostra politica aziendale.