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

Perché utilizzare 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 vengono eseguite "correttamente", cioè le interviste tecniche sono condotte da personale tecnicamente competente (in questo caso i programmatori).

Pertanto, deve essere utilizzato un certo criterio per selezionare 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 i precedenti datori di lavoro e controlla che sì, John Smith ha lavorato per X anni con loro.

Perché non utilizzare "passione" come requisito invece?

Ci sono almeno due problemi con questo:

come misurare "passione"?

KLOC registrati? Buona fortuna trovarlo anche nella programmazione (e in altre discipline), più profuso non equivale a "migliore".

Progetti open source / hobbistici completati? Non facilmente controllati dall'ufficio delle risorse umane e molti programmatori competenti hanno motivi legittimi per non essere attivi a tale riguardo - altri obblighi che richiedono tempo, lunghe ore di lavoro con desiderio per rilassarsi, semplice realizzazione professionale durante l'orario di lavoro ecc.

Anni di esperienza? Oh, aspetta ...

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

Come dice Robert Harvey nel suo commento, la passione non è propriamente 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 mostrano anche che un determinato programmatore è in qualche modo riuscito a funzionare nel suo lavoro, mentre un programmatore disfunzionalmente appassionato potrebbe, ad es. rifiuto categorico di partecipare anche al più semplice sistema di gestione delle attività (per esempio, Scrum Post-it notes), perché "mi rallenta".

Dichiarazioni di non responsabilità finali

Prima di tutto, e fortunatamente "anni di esperienza" sono spesso valutati "liberamente" - cioè 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 viene anche spesso preso in considerazione.

In secondo luogo, personalmente non sono un fan di "N anni di esperienza", e non sono l'unico. Esiste una semplice alternativa: specificare "esperienza in" . Questo di solito è sufficiente come filtro, dal momento che i candidati sono costretti a documentare quell'esperienza nel proprio CV - se si ottiene un candidato per una posizione di programmazione che in precedenza ha fatto solo il cameriere (e questo accade!) Si sa che qualcosa potrebbe essere sbagliato.

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

• Ha partecipato a un evento di crisi.
• Ha visto un progetto dall'inizio alla fine.
• Ha visto un progetto non iniziare o terminare.
• Ha lavorato sul codice legacy.
• Ha lavorato su una lavagna vuota e ha creato qualcosa.
• Ha implementato le decisioni di progettazione.
• Ha progettato un sistema.
• Ha scritto un bug, rilasciato una brutta soluzione, rimosso un server; Ha incasinato, essenzialmente.
• Ha risolto un errore.
• Ha trovato gli strani casi limite nella lingua in cui lavorano e ha visto un posto in cui sono importanti.
• Ha appreso che le cose attualmente nella codebase potrebbero essere stupide.
• Nota, queste cose sono un piccolo campione non obbligatorio e includono anche decine di piccole cose che possono essere trovate lavorando in un ambiente live.

Ancora una volta, è una cosa fortuita, e dipende interamente da / dove / hanno avuto quegli anni di esperienza. Una persona avrebbe potuto lavorare in un singolo progetto in una squadra di diverse centinaia di persone e diventare altamente specializzata. Un altro potrebbe essere stato in un piccolo negozio trial-by-fire, e diventare più di un generalista mentre si occupano di server / installazione / codifica / QA / DBA / gestione del progetto. Ci sono anche persone che si ritrovano a ripetere lo stesso anno di esperienza.

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

Risponderò rispondendo a ciascuna delle tue domande nel post.

The question is how do you know when a candidate has the required years of experience?

Questo è normalmente ciò che il processo dell'intervista intende filtrare. Sono condotte interviste multiple e normalmente è possibile valutare l'esperienza di un candidato contro alcuni dei propri sviluppatori interni.

What do you expect from a person with x years experience?

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

"Siamo alla ricerca di uno sviluppatore PHP senior con oltre 10 anni di esperienza nella progettazione di sistemi e architettura per ristrutturare i nostri strumenti di sistema come Chief Architect, gestendo nel contempo la quantità di sviluppatori senior e junior e guidandoli lungo il percorso. il lavoro richiederà anche ... (ecc. ecc.) "

What can a person with x years experience can do that one with y years (with y < x) cannot do?

In questo caso stai considerando l'esperienza sbagliata. I posti di lavoro non richiedono solo un numero di anni, ma anche esperienza nelle tecnologie che l'azienda utilizza. Come se avessi 10 anni di esperienza nello sviluppo di C ++, e dico che sono un'azienda di giochi alla ricerca di sviluppatori C ++ con 5 anni di esperienza. Non saresti ancora il mio candidato ideale perché non hai mai lavorato nel settore dei giochi prima d'ora. Il mio job post avrebbe effettivamente specificato: X quantità di anni di esperienza in aspetti A, B, C della programmazione.

There can be cases with some passionate programmer with y years experience that has vast knowledge and worked on multiple projects and other programmer with x years experience (x > y) that has worked on few projects and doesn't have that much experience.

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

Why can not it be resumed to something like this "if you know this technology and you know how to do that stuff (be it design, communication, estimates etc.) then you are suitable for our job"?

Questo può e succede. Se riesci a metterti alla prova, l'esperienza degli anni non importa. Per un ragazzo come te, sembri più adatto a un piccolo negozio di sviluppo, in cui l'intervistatore / reclutatore è uno sviluppatore lui / lei. Le aziende più grandi hanno normalmente le risorse umane che fanno questo tipo di cose, motivo per cui rendono i requisiti di lavoro così ampi che basicamente avete bisogno di un dottorato con più di 15 anni di esperienza per scrivere piccole funzioni per il loro sito web (esagerazione eccessiva ma in qualche modo spiega i difetti nel reclutamento di programmatori, soprattutto per le aziende più grandi - anche se non tutti soffrono di questo disturbo

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

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

2 anni o meno - Dovresti essere in grado di svolgere compiti specifici che ti viene chiesto 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 questi compiti.

3 - 5 anni - Dovresti essere in grado di svolgere i compiti che ti viene chiesto di fare, senza troppa impugnatura perché dovresti aver già svolto attività simili nella tua esperienza da 0 a 2 anni. Dovresti anche iniziare a mostrare alcune iniziative "intelligenti" ed essere in grado di gestire attività più piccole che non sono necessariamente definite chiaramente. (ad esempio, puoi progettare moduli dai requisiti, in cui devi tenere traccia di alcuni di questi requisiti da solo).

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 esempio, essere in grado di progettare / implementare / svendere i sottosistemi). Dovresti anche iniziare a guidare i team del sottosistema in questo intervallo di tempo. Fornisci le presentazioni necessarie dei sottosistemi di cui sono responsabili, almeno alla squadra interna.

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

10+ anni - È in grado di gestire praticamente tutte le attività software lanciate contro di 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 al selloff. Comprende la progettazione del sistema e non solo la progettazione di moduli / sottosistemi. È in grado di progettare sistemi affidabili, robusti e manutenibili. È l'interfaccia software per il cliente, comprese le presentazioni dal punto di vista dei sistemi. Può adeguatamente mettere insieme proposte di offerta e programmi.

Sebbene la definizione di anni di esperienza sia vaga, non è solo a beneficio del datore di lavoro, ma è anche una guida per chi cerca lavoro. Quindi, se vieni assunto, sostenendo di avere da 8 a 10 anni di esperienza e di venire a lavoro e aver bisogno di sentirsi dire ogni piccolo compito che devi fare allora, nel migliore dei casi il tuo futuro in azienda è "molto limitato" se anche tu duri molto a lungo a tutti. Le prime impressioni sono difficili da cambiare, quindi anche se diventerai migliore come sviluppatore, le persone continueranno a conservare la loro impressione originale su di te.

Ho visto un buon numero di sviluppatori "senior" essere assunti che erano andati via nel giro di qualche mese o in un paio di anni sono stati inseriti nel programma "sviluppo degli impiegati", che è davvero solo la via più veloce per essere il primo nella lista dei licenziamenti. Se quegli stessi sviluppatori fossero entrati a un livello inferiore (ovviamente questo significa meno retribuzione), allora potrebbero essere stati considerati un buon investimento e considerati adeguatamente performanti.