Vedo molte aggiunte di lavoro che richiedono almeno x anni di esperienza. La domanda è: come fai a sapere quando un candidato ha gli anni di esperienza richiesti? Cosa ti aspetti da una persona con x anni di esperienza (modifica: efficacemente come controlli se il CV non sta mentendo senza fare affidamento sul controllo delle competenze)? Cosa può fare una persona con x anni di esperienza che una persona con y anni (con y <x) non può fare (modifica: supponendo che abbiano abilità simili)?

Ci possono essere casi con un programmatore appassionato con anni di esperienza che ha una vasta conoscenza e ha lavorato su più progetti e altri programmatori con esperienza x anni (x> y) che ha lavorato su pochi progetti e non ha molta esperienza.

Perché non può essere ridotto a qualcosa del genere "se conosci questa tecnologia e sai come fare quelle cose (che si tratti di progettazione, comunicazione, stime ecc.) Allora sei adatto per il nostro lavoro"?

So che non puoi assumere un nuovo laureato con 1 anno di esperienza per il posto di architetto aziendale, ma vedo anche un problema con i fatti che quasi tutti gli annunci richiedono esperienza. In primo luogo la passione di IMHO dovrebbe essere presa in considerazione.

Innanzitutto non sapevo se la domanda fosse adatta a questo sito, ma dato che esiste un tag per il reclutamento e l'esperienza, credo che abbia un posto qui.

La tua domanda può essere gestita dividendo in due sotto-domande.

Perché usare anni di esperienza come requisito?

Perché è una metrica facilmente verificabile correlata positivamente con la competenza di programmazione . La risposta di Snagulus elabora già i dettagli della correlazione, quindi mi concentrerò sul "perché".

La dura verità è che di solito c'è più di un candidato per una determinata posizione. Inoltre, le interviste sono piuttosto dispendiose in termini di risorse, soprattutto se eseguite "correttamente", ovvero le interviste tecniche sono condotte da personale tecnicamente competente (in questo caso i programmatori).

Pertanto, è necessario utilizzare alcuni criteri per vagliare inizialmente i CV in entrata , e preferibilmente uno che può essere verificato da personale non tecnico - in caso di dubbio, le persone delle risorse umane possono sempre chiamare precedenti datori di lavoro e verificare che sì, John Smith abbia lavorato per X anni con loro.

Perché non usare "passione" come requisito invece?

Ci sono almeno due problemi con questo:

come misurare la "passione"?

KLOC registrati? Buona fortuna scoprendo che, anche nella programmazione (e in altre discipline), più profuse non equivalgono a "meglio".

Progetti open source / hobby completati? Non facilmente controllabile dalle risorse umane, e molti programmatori competenti hanno motivi legittimi per essere inattivi a tale riguardo - altri obblighi che richiedono tempo, lunghe ore di lavoro con il desiderio di rilassarsi, semplice adempimento professionale durante le ore di lavoro ecc.

Anni di esperienza? Oh, aspetta ...

la "passione" è davvero una buona metrica per la competenza?

Come afferma Robert Harvey nel suo commento, la passione non è realmente indicativa di una programmazione competente. Rispetto all'esperienza, è una qualità per lo più ortogonale , cioè esiste:

• programmatori appassionati e competenti e
• programmatori spassionati e tecnicamente competenti e
• programmatori appassionati e tecnicamente incompetenti e
• programmatori appassionati e non tecnicamente incompetenti,
• ecc ecc.

L'ultimo esempio è importante nel nostro contesto: anni di esperienza dimostrano anche che un determinato programmatore è riuscito in qualche modo a funzionare nel suo lavoro, mentre un programmatore appassionato disfunzionalmente potrebbe, ad esempio, rifiutare categoricamente di partecipare anche al più semplice sistema di gestione delle attività (diciamo, Scrum Post-it notes), perché "mi rallenta".

Disclaimer finali

Prima di tutto, e fortunatamente, gli "anni di esperienza" sono spesso valutati "vagamente" - vale a dire se stai facendo domanda per un lavoro con il linguaggio X, ma hai solo un'esperienza "commerciale" con il linguaggio Y, simile a X, che è spesso preso in considerazione.

In secondo luogo, personalmente non sono un fan di "N anni di esperienza" e non sono l'unico. C'è una semplice alternativa: specificare "esperienza in" . Questo di solito è sufficiente come filtro, poiché i candidati sono costretti a documentare quell'esperienza nei loro CV - se ottieni un candidato per una posizione di programmazione che in precedenza ha solo fatto aspettare (e questo accade!) Sai che qualcosa potrebbe essere sbagliato.

"Anni di esperienza" è più una scala di probabilità che una misura di qualcosa di concreto. Con più anni, hai una maggiore possibilità che una persona abbia incontrato cose come:

• Ha partecipato a un evento simile alla crisi.
• Ha visto un progetto dall'inizio alla fine.
• Ha visto l'inizio o la fine di un progetto.
• Ha lavorato sul codice legacy.
• Ha lavorato su una lavagna vuota e ha realizzato qualcosa.
• Ha implementato le decisioni di progettazione.
• Ha progettato un sistema.
• Ha scritto un bug, rilasciato una correzione errata, rimosso un server; Si è rovinato, essenzialmente.
• Ha risolto un problema.
• Ha trovato gli strani casi limite nella lingua in cui lavora e ha visto un posto dove conta.
• Ha imparato che le cose attualmente nella base di codice potrebbero essere stupide.
• Nota, queste cose sono un piccolo esempio non obbligatorio e includono anche dozzine di piccole cose che si possono trovare lavorando in un ambiente live.

Ancora una volta, è una cosa casuale, e dipende interamente da / dove / hanno avuto quegli anni di esperienza. Una persona avrebbe potuto lavorare in un unico progetto in un team di diverse centinaia di persone e diventare altamente specializzata. Un altro avrebbe potuto essere in una piccola bottega di prova e diventare un generalista mentre si occupano di server / installazione / codifica / QA / DBA / gestione dei progetti. Ci sono anche persone che si ritrovano a ripetere lo stesso anno di esperienza.

È una misura approssimativa, ma in media una persona sarà stata esposta a più potenziali eventi di apprendimento più a lungo ha funzionato ed è utile come punto dati preliminare. Il resto del curriculum (e, soprattutto, l'intervista) serve a capire cosa sanno realmente e cosa hanno fatto.

Risponderò a questo rivolgendomi a ciascuna delle tue domande nel post.

La domanda è: come fai a sapere quando un candidato ha gli anni di esperienza richiesti?

Questo è normalmente ciò che il processo di intervista intende filtrare. Vengono condotte interviste multiple e normalmente è possibile valutare un'esperienza dei candidati rispetto ad alcuni dei propri sviluppatori interni.

Cosa ti aspetti da una persona con x anni di esperienza?

Ci si aspetterebbe che soddisfino i requisiti di lavoro specificati in un posto di lavoro. Per esempio:

"Siamo alla ricerca di uno sviluppatore PHP senior con oltre 10 anni di esperienza nella progettazione e nell'architettura del sistema per ristrutturare i nostri strumenti di sistema come architetto capo, gestendo al contempo la quantità di K di sviluppatori senior e junior e guidandoli lungo il percorso. richiedono ... (ecc. ecc.) "

Cosa può fare una persona con x anni di esperienza che una persona con y anni (con y <x) non può fare?

Stai guardando l'esperienza sbagliata in questo caso. I posti di lavoro non solo richiedono un numero di anni, ma anche esperienza nelle tecnologie che l'azienda sta utilizzando. Come se tu potessi avere 10 anni di esperienza nello sviluppo di C ++ e dire che sono una società di giochi alla ricerca di sviluppatori C ++ con anche 5 anni di esperienza. Non saresti ancora il mio candidato ideale perché non hai mai lavorato prima nel settore dei giochi. Il mio posto di lavoro in realtà specifica: X quantità di anni di esperienza negli aspetti A, B, C della programmazione.

Ci possono essere casi con un programmatore appassionato con anni di esperienza che ha una vasta conoscenza e ha lavorato su più progetti e altri programmatori con x anni di esperienza (x> y) che ha lavorato su pochi progetti e non ha molta esperienza.

Leggi la mia risposta precedente. L'esperienza è legata agli strumenti in cui hai vissuto. X quantità di anni negli strumenti A, B, C.

Perché non può essere ripreso a qualcosa del genere "se conosci questa tecnologia e sai come fare quella roba (che si tratti di progettazione, comunicazione, stime ecc.) Allora sei adatto per il nostro lavoro"?

Questo può e succede. Se riesci a provare te stesso, l'esperienza negli anni non ha importanza. Per un ragazzo come te, sembri più adatto a un negozio di sviluppo più piccolo, in cui l'intervistatore / recruiter è uno sviluppatore stesso. Le aziende più grandi di solito hanno risorse umane che fanno questo tipo di cose, motivo per cui rendono i requisiti di lavoro così ampi che in pratica hai bisogno di un dottorato di ricerca con oltre 15 anni di esperienza per scrivere piccole funzioni per il loro sito Web (esagerazione ma spiega in qualche modo i difetti nel reclutamento di programmatori, specialmente per le aziende più grandi, sebbene non tutte soffrano di questo disturbo)

L'esperienza pluriennale è semplicemente un filtro che fornisce una stima "approssimativa" di ciò che ci si aspetta dalla persona che utilizza le competenze desiderate elencate nella descrizione del lavoro.

Qui c'è molto di più di quello che mi aspetterei, ma altri potrebbero avere idee diverse:

2 anni o meno - Dovresti essere in grado di svolgere compiti specifici che ti viene detto di fare, con i datori di lavoro consapevoli che ci sarà una curva di apprendimento con una buona dose di supervisione per la maggior parte di tali compiti.

3 - 5 anni - Dovresti essere in grado di svolgere i compiti che ti viene detto di fare, senza molta presa in mano perché avresti già dovuto svolgere compiti simili nella tua esperienza da 0 a 2 anni. Dovresti anche iniziare a mostrare qualche iniziativa "intelligente" ed essere in grado di gestire compiti più piccoli che non sono necessariamente definiti chiaramente. (ad esempio Essere in grado di progettare moduli in base ai requisiti, in cui è necessario rintracciare alcuni di questi requisiti da soli).

5 - 7 anni - Dovresti essere in grado di lavorare da solo ed essere in grado di decidere quali sono questi "compiti" dall'alto. Dovresti essere in grado di gestire attività di medie dimensioni che non sono chiaramente definite. (ad es. essere in grado di progettare / implementare / vendere sottosistemi). Dovresti anche iniziare a guidare i team del sottosistema in questo intervallo di tempo. Fornire le presentazioni necessarie dei sottosistemi di cui sono responsabili, almeno al team interno.

8 - 10 anni - Si può contare su sottosistemi molto grandi e / o critici del progetto. Esperto residente in diverse tecnologie. Può guidare team di sottosistemi di grandi dimensioni. Fornire al cliente presentazioni dei sottosistemi di cui sono responsabili.

Più di 10 anni - Può gestire praticamente qualsiasi attività software lanciata a loro, entro i confini della descrizione del lavoro E della maggior parte delle altre attività software semi-correlate. Esperto residente in un gran numero di aree software. Può condurre grandi progetti, dai requisiti fino al selloff. Comprende la progettazione del sistema e non solo la progettazione di moduli / sottosistemi. È in grado di progettare sistemi affidabili, robusti e mantenibili. È l'interfaccia software per il cliente, comprese le presentazioni dal punto di vista dei sistemi. È in grado di mettere adeguatamente insieme proposte e programmi di offerta.

Mentre la definizione di anni di esperienza è vaga, non è solo a beneficio del datore di lavoro, ma è anche una guida per chi cerca lavoro. Quindi, se vieni assunto, sostenendo di avere 8-10 anni di esperienza e di venire sul posto di lavoro e di avere bisogno di essere informato su ogni piccolo compito che devi fare, nella migliore delle ipotesi il tuo futuro in azienda è "molto limitato" se anche tu duri molto lungamente a tutti. Le prime impressioni sono difficili da cambiare, quindi anche se migliorerai come sviluppatore, le persone manterranno probabilmente la loro impressione originale di te.

Ho visto un bel numero di sviluppatori "senior" essere assunti che erano spariti nel giro di pochi mesi o in un paio d'anni sono stati inseriti nel programma "sviluppo dei dipendenti", che è davvero solo la strada veloce per essere il primo l'elenco dei licenziamenti. Se quegli stessi sviluppatori fossero entrati a un livello inferiore (ovviamente questo significa una retribuzione inferiore), allora molto bene potrebbero essere stati considerati un noleggio di successo e considerati performanti.