Qual è il problema con i linguaggi di programmazione come requisiti di lavoro rigorosi? [chiuso]

Recentemente sono andato a una "fiera del lavoro" e sono stato sorpreso di vedere quanta enfasi i posti di lavoro sembrano mettere sui linguaggi di programmazione con cui i candidati hanno familiarità.

Dalla mia esperienza (ammessa limitata), mentre la padronanza reale di un linguaggio di programmazione può richiedere anni, impararlo a un livello ragionevole è una faccenda abbastanza semplice per qualcuno che ha già esperienza con altre lingue e può sicuramente rientrare nel periodo di tempo in cui i datori di lavoro normalmente assegnano il ramp-up iniziale.

Penserei che un datore di lavoro si preoccuperebbe di più di quante lingue / paradigmi conosco, o qual è la mia esperienza di progettazione algoritmica / software, al contrario della specifica tecnologia con cui sono abile in questo momento.

Supponiamo che io conosca già Java, C ++, Smalltalk e Prolog ... un posto di lavoro che si basa su Objective-C dovrebbe davvero considerarmi non qualificato perché non ho esperienza in quella lingua? È questo un difetto nelle metodologie di reclutamento e, se lo è, cosa posso fare per convincere quel posto di lavoro che la mia mancanza di esperienza con Objective-C non dovrebbe avere importanza? Sto chiedendo ipoteticamente, non specificamente sui linguaggi di programmazione menzionati.

In alternativa, la mia esperienza è limitata e ammetto che mi potrebbe mancare qualcosa. L'esperienza precedente con un linguaggio di programmazione è più cruciale di quello che penso che sia? Fa differenza se è una posizione junior o senior? Dovrebbe fare la differenza?

Contrariamente ai comunicati stampa, al momento è il mercato di un datore di lavoro .

Ciò significa che possono semplicemente essere pignoli su quali siano i loro requisiti. Significa che possono richiedere esperienza .NET 4.0 e non solo 3.5 ... Significa che possono richiedere esperienza con Django e non solo piloni, ecc ...

Certo, potresti imparare tutto ciò che devi sapere su Ruby in un paio di settimane e Rails potrebbe impiegare un paio di mesi (solo indovinando) per diventare esperto con ...

Ma il datore di lavoro può scegliere tra curriculum di persone già competenti con Ruby & Rails.

TL; DR: Econ 101 ... Non credere all'hype sulla carenza di programmatori .

Il problema principale è che nessuno sa davvero come assumere buoni programmatori. Il problema secondario è che i lavori di programmazione attirano molti candidati.

Dato un gran numero di curriculum, sarebbe molto bello poterli sfogliare e scegliere i bravi programmatori, ma nessuno sa come farlo. Nel modo in cui lavora la maggior parte delle aziende, l'ordinamento iniziale è in genere per risorse umane. La persona delle risorse umane non conosce nulla di Smalltalk o C ++, ad eccezione di quelli elencati nell'elenco dei requisiti, a differenza di una persona software che potrebbe pensare "C ++ E Smalltalk - questo ragazzo non avrà problemi con Objective-C".

Anche quando lo stack va al responsabile delle assunzioni, è molto probabilmente troppo denso per intervistare tutti, quindi il responsabile delle assunzioni deve buttare fuori i curricula per un motivo o per l'altro. Se si tratta di un lavoro in C ++ e ci sono più persone con 5+ anni di C ++ che il manager trova pratico da intervistare, il manager può anche lanciare tutti i curriculum che non hanno C ++ su di loro. Non è il modo di ottenere le persone migliori in assoluto, ma nessuno sa come assumere le persone migliori in assoluto, e se sei limitato nel processo decisionale da ciò che è nel curriculum, le persone con esperienza in C ++ sono almeno leggermente migliori scommesse.

Giriamolo indietro: se conoscessi l'obiettivo C, saresti utile come programmatore C ++? Direi che no, le lingue sono troppo diverse. Anche per linguaggi semplici come C, vorrei vedere 6 mesi di esperienza prima di assumere qualcuno, per C ++ diversi anni.

Alcuni anni fa mi sono insegnato a PHP. Direi che ci sono voluti diversi mesi prima che riuscissi a capire qualcosa, potevo orientarmi in biblioteca, capire idiomi comuni, ecc. E conoscevo già molte lingue.

Dipende da vari aspetti del contesto. Non solo il livello del ruolo, ma anche lo stato del progetto e dell'azienda.

Al livello più semplice, qualsiasi linguaggio imperativo di parentesi graffe è praticamente uguale a qualsiasi altro.

Se è possibile codificare in imperativo, è possibile codificare in imperativo. Che si tratti di Java, C #, C, C ++ o persino javascript. Dato un libro di consultazione decente (e forse un po 'di piastra di cottura), dovresti essere in grado di mettere fine a un piccolo programma in uno degli altri in un pomeriggio.

Qualunque sia la tua storia, conosci i rami e le funzioni dei loop e la sintassi è praticamente la stessa per tutti. Se la tua storia è OO, conosci anche oggetti, classi e interfacce.

Tuttavia, ho visto troppi programmatori di soli imperativi che lottano per scrivere semplici programmi in linguaggi dichiarativi o funzionali. Se gestissi un negozio Erlang, preferirei fortemente qualcuno con Erlang, o almeno Prolog, esperienza rispetto a qualcuno con C ++.

Come dipende dal livello del ruolo:

Reclutamento per un ruolo junior:

Se dovessi scegliere un programmatore per un lavoro in C ++, ci sono alcune insidie ​​che vorrei essere abbastanza certo che il candidato è in grado di evitare, come la necessità di prestare attenzione alla memoria o alla lunghezza degli array, semplicemente in modo che non spararsi (e io) ai piedi. Se non hanno mai fatto C o C ++, allora dovrei risolverlo nell'intervista.

E per un ruolo senior:

Una delle chiavi per programmare in modo efficiente è sapere cosa non dovresti scrivere tu stesso. La chiave di ciò sono le librerie standard (e di fatto standard). La chiave di ciò, è l'esperienza. Non puoi semplicemente sederti con "Insegnati a Java" per una settimana e trasformarti istantaneamente da un programmatore C ++ di 10 anni in un programmatore Java di 10 anni.

Come dipende dallo stato del progetto / azienda

Dato un progetto Java che è praticamente una lavagna pulita. Vorrei che un nuovo assunto senior avesse molte conoscenze sull'ecosistema Java ed essere in grado di fornire consulenza sulle diverse tecnologie disponibili.

Dato un progetto Java maturo, sarei felicemente considerato uno sviluppatore C ++ esperto, con poca o nessuna esperienza Java per un ruolo Java senior. La maggior parte delle decisioni sugli ecosistemi sarà già stata risolta e il nuovo assunto sarà in grado di acquisire esperienza con le librerie Java mentre la società sfrutta l'esperienza del programmatore nello sviluppo di software OO.

Dipende dal posto di lavoro. Se sono molto occupati, potrebbero non avere il tempo di aspettare che tu raggiunga un punto in cui puoi funzionare in Objective-C - potrebbero desiderare qualcuno che possa colpire il terreno correndo.

Alcuni luoghi di lavoro potrebbero essere disposti a correre dei rischi se vedono che hai familiarità con altre lingue, oltre a disporre di solidi fondamenti e conoscenza del dominio aziendale. Questo dipenderà davvero da quanto sono aperti e da quanto sei bravo a convincere il recruiter ad assumersi quel rischio.

Assumere è difficile; assumere brave persone è ancora più difficile. Ho fatto l'assunzione dove mi trovavo di fronte a una pila di oltre 500 curriculum. Ovviamente abbiamo filtrato le persone con la minima esperienza in ciò che volevamo ridurre lo stack a dimensioni ragionevoli. È giusto per l'eccellente candidato a cui non capita di conoscere quella lingua, probabilmente no? Ma se riesco a trovare 100 persone che hanno le qualifiche che sto cercando, non passerò molto tempo sui 400 che non lo hanno fatto, non importa quanto siano bravi.

Ora assumendo, potrei avere un lungo elenco di requisiti, ma di solito solo uno o due sono rompicapo. E se non trovi nessuno con l'elenco iniziale delle qualifiche che vuoi intervistare (o successivamente se falliscono tutte l'intervista che ho visto accadere), di solito torneranno indietro e guarderanno le persone a cui mancano alcuni delle qualifiche o persone meno critiche che hanno qualcosa di simile ma non uguale. In quei casi stai spesso cercando qualcosa sull'esperienza della persona che li renderà migliori per il tuo lavoro rispetto a qualcuno con tutte le qualifiche tecniche. Ad esempio, considererei un analista di dati con esperienza in un diverso database aziendale se avesse esperienza nel mio dominio aziendale (in effetti quella persona probabilmente farebbe il mio primo taglio se vedessi tutti i curriculum). Stessa cosa con qualcosa come C # e Java. Se la persona sta svolgendo un lavoro con un livello di complessità simile e soprattutto in un settore commerciale simile, potrebbe essere un ottimo candidato anche se ha un'altra lingua.

Tuttavia, a meno che non avessi un programma di formazione abbastanza formale per le persone entry level, avrei meno probabilità di assumere da persone che non soddisfacessero il mio set minimo di lingue. E quasi mai da un gruppo che non aveva nessuna delle cose che cercavo. Le persone senza esperienza hanno meno da mettere in tavola in termini di qualifiche compensative e meno di un track record per dimostrare che possono fare un lavoro di livello professionale in qualsiasi lingua. Hanno abbastanza da imparare con il loro primo concerto professionale senza una certa comprensione della lingua più importante che usiamo. E assumerli è più un rischio che potrebbero passare mesi prima che tu possa ottenere un lavoro utile da loro.

Un ulteriore punto entra in gioco se il funzionario addetto all'assunzione sta trasferendo la squadra in una nuova tecnologia. Se nessuno nel team è veramente esperto nella tecnologia e devo assumere anche qualcuno di nuovo, cercherò di assumere qualcuno con la stessa esperienza che posso trovare in quella tecnologia perché hanno un'idea di dove le "mine di terra "per evitare lo sono.

Infine, fai domanda per i lavori che ti interessano anche se non soddisfi tutti i requisiti dichiarati (ma provi a soddisfarne alcuni, i funzionari di assunzione non amano perdere tempo con persone che non sarebbero mai state assunte). Non sai mai quale competizione avrai per un lavoro o cosa impressionerà di più le persone che guardano i curriculum o fanno le interviste. Ciò che potrebbe farti ottenere un colloquio presso la società A potrebbe essere esattamente ciò che ti impedisce di ottenere un colloquio presso la società B anche se hanno requisiti simliar sulla carta. Inoltre, potrebbero avere un lavoro che soddisfa meglio le tue qualifiche che non hanno ancora pubblicizzato. Ma non verrai mai preso in considerazione per il lavoro se non ti conoscono.

Dovrebbe ? No. Lo fa? Sì, purtroppo. Questa è la sindrome dello "scoiattolo viola": la società vuole avere la loro torta e mangiarla anche, e ottenere un candidato in grado di fare tutto sotto il sole di cui hanno bisogno o di cui potrebbero aver bisogno. Spesso, ma non sempre questo è perché entrambi A) non hanno idea di cosa comporti davvero lo sviluppo e presumono che qualcuno che soddisfi tutti i loro criteri possa fare il lavoro, B) Sono pignoli perché possono cavarsela, o C) Hanno in programma di presentare una H-1B / Green Card / Promuovi dall'interno, ma devono far sembrare che stiano pubblicizzando un vero lavoro.

"Supponiamo che io conosca già Java, C ++, Smalltalk e Prolog ... un posto di lavoro che si basa su Objective-C dovrebbe davvero considerarmi non qualificato perché non ho esperienza in quella lingua?"

Se hai più di 20 anni di esperienza in 3 o 4 lingue che hanno caratteristiche simili a Objective-C, probabilmente ti assumerei per fare Objective-C e mi aspetto che tu sia produttivo in 6-8 settimane. (questo si basa sulla mia esperienza personale con l'apprendimento dell'Obiettivo-C qualche anno fa).

Se sei verde appena uscito da scuola senza alcuna esperienza pratica tangibile in nessuna cosa, probabilmente non verrai assunto per fare qualcosa con cui non hai familiarità.

Objective-C è un uomo di paglia interessante qui. Richiede di conoscere C molto bene, richiede di conoscere molto bene l'analisi e la progettazione orientate agli oggetti, nella maggior parte dei casi richiede di conoscere il C ++ in misura non banale perché ci sono librerie C ++ con cui probabilmente vorrai interfacciarti.

Richiede la comprensione della gestione manuale della memoria, nonché del modo in cui funziona la gestione automatica della memoria / garbage collection e quando utilizzare ciascuna tecnica nello stesso programma.

Non è solo Objective-C che devi conoscere anche Cocoa e POSIX, perché affrontarlo Objective-C è per tutti gli scopi pratici inutile al di fuori degli ambienti Apple e devi conoscere anche Cocoa.

E quando Cocoa non ti riesce, devi essere in grado di sapere quali API POSIX usare quando non puoi fare quello che vuoi con i wrapper Cocoa.

Implica anche che dovresti conoscere Unix anche in misura non banale.

Dipende dalla lingua / individuo.

Se sono un posto C # e qualcuno con esperienza JAVA / J2EE, mi darò una possibilità. La sintassi tra C # e JAVA non è così diversa. La codifica è codifica e immagino che una volta che si abitueranno ad alcune delle differenze andranno bene.

Lo stesso vale per JAVA -> C #.

Ora, se tu fossi una persona C # e ti candidi per un lavoro C ++, voglio vedere l'esperienza. Ci sono troppe differenze.

Quindi sì, dipende dalla situazione

Mentre penso che il PO sia morto su come un programmatore che ha esperienza con molti paradigmi possa facilmente aggiungerne uno in più, tutto dipende dall'avversione del datore di lavoro al rischio. Un potenziale assunto che non ha familiarità con i propri strumenti è un jolly; potrebbero essere davvero fantastici, ma potrebbero anche essere un flop, e sarà più difficile del normale per l'intervistatore dire la differenza se non possono fare domande approfondite sulle tecnologie che usano.

Non sto sicuramente dicendo che questo è il modo corretto di vederlo, ma è come fanno alcuni datori di lavoro. Gli intelligenti lo sfruttano e raccolgono i fantastici programmatori con 30 anni di esperienza in C ++, mentre gli stupidi li rifiutano perché mancano dei 15 anni necessari di esperienza di Ruby on Rails. I programmatori possono sfruttare anche questo, evitando l'occupazione con i datori di lavoro che sono così mal informati. Dopo tutto, chi vuole lavorare in un posto che prende sistematicamente decisioni sbagliate?

In parte si tratta di risorse umane che inseriscono parole d'ordine in una descrizione del lavoro poiché non capiscono davvero il ruolo. È per questo che occasionalmente ti imbatti nella situazione comica di una descrizione del lavoro che specifica 3 anni di esperienza in una tecnologia che esiste solo da 6 mesi.

Se debba o meno fare la differenza, ciò dipende davvero dal ruolo e dalle persone coinvolte. Quasi tutti i manager che assumono (sicuramente tutti quelli intelligenti) istruiranno le risorse umane a passare loro candidati che hanno molta forza nella maggior parte dei settori anche se mancano di uno o due punti elenco nella descrizione del lavoro. Tuttavia ciò generalmente non si applica a un neolaureato; Sto parlando di persone con molta esperienza lavorativa che interagiscono con clienti o team leader o cose del genere.

Penserei che un datore di lavoro si preoccuperebbe di più di quante lingue / paradigmi conosco, o qual è la mia esperienza di progettazione algoritmica / software, al contrario della specifica tecnologia con cui sono abile in questo momento.

Hai mai visto tutti gli elementi che compongono il tuo stack di sviluppo? Ad esempio, quali IDE, framework di test, integrazione continua, controllo di versione, metodologia di sviluppo e paradigmi di codice che compongono un ambiente che qualcuno utilizza per creare software. Questo può essere un numero di strumenti che alcune aziende potrebbero desiderare che qualcuno sappia già piuttosto che dover raccogliere da zero. Il punto di ironcode sul mercato di un datore di lavoro è un altro fattore qui in quanto potrebbero esserci alcuni casi in cui c'è molta concorrenza per una posizione e quindi le aziende possono mirare al cielo e possibilmente ottenerlo.

Giusto per dare un esempio più concreto di quell'ambiente, ecco cosa ho dove lavoro: Visual Studio 2008 facendo ASP.Net usando principalmente C #, nUnit, Cruise Control.Net, Subversion, Agile / Scrum, con una miscela di procedurale, OO e funzionale a seconda di dove si sta guardando. Se volessi passare a Java, questo potrebbe significare abituarsi a nuovi strumenti per molte di queste funzioni che potrebbero non essere ciò che un datore di lavoro vuole assorbire come costo per assumermi in quel ruolo. Ci possono anche essere alcuni punti difficili che quelli con esperienza in quella versione potrebbero conoscere meglio di altri ed evitare alcune insidie ​​che potrebbero altrimenti far andare qualcuno: "Perché l'hanno costruito in quel modo?"

Non guardare. Questi requisiti non sono messi insieme dai ragazzi IT. Sono messi insieme dalle persone delle risorse umane. E il modo in cui i dipendenti delle risorse umane ottengono i requisiti è gridando domande alle persone IT mentre vacillano avanti e indietro verso la macchina da caffè.

Quindi dicono "Di cosa hai bisogno?" e lo shmuck casuale che finisce per rispondere dice "Un programmatore. Ha bisogno di qualche anno di esperienza. Tipo, non lo so, 4? E sarebbe bello se lo sapesse .Net." Una risposta ragionevole

Ma viene tradotto in "4 anni di esperienza in .Net 4" ed è .Net 4 perché, quando si utilizza Google .Net, il primo link vi porterà a una pagina che parla di .Net 4.

C'è anche la possibilità, e ho incontrato alcune volte, che hanno un requisito linguistico specifico perché vogliono spostarsi in quella direzione e pensano che andrà più liscio se hanno una persona esperta nello staff.