"Assumere solo i migliori" è davvero un consiglio pratico per la normale programmazione di applicazioni desktop? [chiuso]

Per lo sfondo, stiamo realizzando applicazioni di ingegneria desktop, con un'interfaccia utente di AutoCAD come qualcosa di simile a etabs .

Una cosa che mi infastidisce davvero è: c'è bisogno di assumere i migliori sviluppatori? Per cominciare, stiamo riscontrando grandi difficoltà nel reclutamento; la maggior parte dei curriculum che vediamo fanno o semplici app CRUD, o la personalizzazione di SharePoint che non credo coinvolga davvero molta programmazione hardcore. Anche quelli che chiamiamo per un colloquio, la maggior parte non può fare la sequenza di Fibonacci e una semplice ricerca binaria, e siamo abbastanza gentili da dare suggerimenti e sillabare esplicitamente i problemi in modo che i candidati non debbano cercare un dizionario per controllare cosa significa "sequenza di Fibonacci".

Questo mi ha fatto pensare: Sì, abbiamo bisogno di un certo livello di attitudine alla programmazione quando facciamo geometria computazionale / roba di programmazione lineare, e abbiamo bisogno di un certo livello di attitudine alla programmazione quando progettiamo l'architettura del software / o decidiamo quale modello software usare, ma oltre quello , molto del nostro codice è solo codice idraulico (penso), che può essere fatto da qualcuno che abbia una certa familiarità con la programmazione.

Dato che ora abbiamo davvero bisogno di talenti di programmazione e dato che assumere sviluppatori di superstar è molto difficile, voglio abbassare il mio standard e assumere solo quelli così, in diretta contraddizione con ciò che Joel predica .

Cosa ne pensi?

Modifica: non è necessario riscrivere l'intera libreria di programmazione lineare / geometria computazionale; tutto ciò che devi fare, per quanto riguarda la mia applicazione, è saper saper incanalare i problemi in termini di programmazione geometrica / lineare computazionale appropriati e sapere quando / come utilizzare le librerie esistenti. Quindi non è così difficile come sembra.

Ti suggerisco di smettere di leggere Joel troppo. Ciò che ha scritto nel suo blog è in contraddizione con le sue risposte su questo sito, quindi non prenderei la sua parola per molto.

Ciò che rende una superstar e perché è necessario averne una apre una discussione lunga e inesistente. È elitarismo e non è pratico.

Ciò di cui hai bisogno è una persona che:

1. Mi piacerebbe fare quello che stai facendo
2. Sarebbe un programmatore entusiasta appassionato
3. Avrebbe il potenziale per imparare cosa serve per fare bene il tuo lavoro

Il resto non ha importanza.

Non crederesti a quanti giovani laureati sono là fuori che non vogliono altro che immergersi in questo tipo di progetto CS e non guardare mai al codice delle applicazioni CRUD. Qualche tempo fa ero uno di loro, praticamente sognavo di unirmi a un progetto sullo sviluppo del compilatore ma non riuscivo a trovarne uno. Perché non dare la possibilità a uno di loro?

Non credo che AutoCAD sia stato scritto da superuomini. La maggior parte dei progetti di successo sono stati realizzati da persone che volevano semplicemente fare le cose e lo volevano davvero.

la maggior parte dei curriculum che vediamo stanno eseguendo semplici app CRUD o personalizzazione di SharePoint

Cosa aspettarsi se la maggior parte dei lavori lo richiede? Le persone avrebbero potuto studiare CS all'università e addirittura essere state davvero brave a farlo, ma non puoi aspettarti che se lo ricordino se non lo hanno mai usato nella programmazione pratica in 10 anni. Ovviamente nessuno leggerà i vecchi libri CS ogni anno solo per mantenerlo aggiornato se questa conoscenza non viene utilizzata da nessuna parte.

Un libro che mi piace davvero è In primo luogo infrangere tutte le regole . Ha molte informazioni sulle differenze tra gestori medi e buoni manager. Una delle intuizioni chiave che i bravi manager hanno detto più volte è stata riassunta da uno di loro nella frase, non ho mai aspettato troppo a lungo per trovare il noleggio giusto e non ho mai licenziato il noleggio sbagliato abbastanza in fretta. Sì, è frustrante assumere molto tempo per assumere, ma vale la pena.

Un secondo punto che dovresti tenere a mente è che, quando misurato sulla produttività del progetto, c'è un picco di produttività per team di 5-8 persone. Non torni alla stessa produttività fino a quando non avrai un team di oltre 20 persone. Sii molto, molto cauto nel far crescere un team oltre le dimensioni in cui lavorano le dinamiche di piccoli team. E se stai per rimanere al di sotto di quella soglia, allora vuoi davvero che quelle 5-8 persone siano buone.

Entrambi i punti parlano in modo deciso di cercare il giusto noleggio.

Tutti affermano di "assumere solo il primo percentile". Se ciò fosse vero, il 100% delle persone occupate si troverebbe nel "primo 1 percentile" di tutte le persone, quindi il 99% di tutte le persone sarebbe disoccupato (in un determinato campo). Dato che questo non è chiaramente il caso, e tutti abbiamo sperimentato persone che chiaramente non fanno parte di quel gruppo (perché altrimenti fai questa domanda a tutti ...) sappiamo che questo non è vero.

In effetti, le organizzazioni composte esclusivamente da tali persone sarebbero altamente instabili. Troppo ego, troppe idee contrastanti. O cadrebbe a pezzi mentre ognuno fa le proprie cose, impantanandosi in discussioni teoriche senza fine sui meriti relativi di tutto, o evolverebbe in una costante partita di urla mentre i sentimenti divampano ogni volta che deve essere presa una decisione.

La prima cosa che devi chiedere è perché stai ricevendo curriculum che non sono all'altezza degli standard che desideri. Ho lavorato con un sacco di brave persone, quindi sono là fuori e l'applicazione mi sembra molto interessante. Se non riesci a trovare persone in grado di eseguire sequenze di Fibonacci e ricerca binaria (il che è più difficile di quanto sembri; secondo Knuth ci sono voluti diversi anni tra la sua prima pubblicazione e la prima corretta), stai facendo qualcosa per guidare il quelli buoni via.

Stai chiedendo più abilità di quelle che sei disposto a pagare? Stai pubblicizzando nei posti sbagliati? La tua azienda non è attraente per posizione o reputazione? Questo è il tuo primo e più basilare problema, e quello che devi risolvere con urgenza. Tu e i tuoi colleghi conoscete senza dubbio alcune brave persone che non lavorano per voi. Mostra loro quello che hai e chiedi loro se sarebbero tentati, e se no perché no. Potresti essere troppo vicino al problema per capirlo senza aiuto.

Non assumere le persone perché sono le migliori che si applicano. Assumi le persone perché saranno in grado di fare qualcosa che desideri. Se assumi mediocri perché è tutto ciò che si applica, allora perderai lentamente persone buone e finirai con persone la cui algebra è traballante nel tentativo di fare le cose con la geometria computazionale. (Assumere mediocri perché hai un lavoro per un paio di programmatori mediocri è un'altra cosa, ma devi essere in grado di assumere persone di qualità dove ne hai bisogno.)

"la maggior parte non può fare la sequenza di Fibonacci e una semplice ricerca binaria"

I tuoi criteri sono sicuramente sbagliati. Nel mio gruppo siamo tutti fisici o ingegneri. Scommetto che nessuno poteva fare la ricerca binaria perché non frequentavamo i corsi CS e nella vita reale usiamo una libreria per quello. Direi anche: qualcuno che scrive se stesso binsearch non sa come concentrarsi su cose importanti.

È molto più importante se il candidato è intelligente e si inserisce nel gruppo. Se vuoi controllare il suo talento di programmazione, dagli un lavoro da svolgere a casa. Nota quanto tempo ha impiegato lui / lei e discutere i risultati per scoprire se è il lavoro genuino dei candidati.

Penso che "assumere il meglio" stia diventando troppo cult.

La maggior parte del lavoro di programmazione è di routine e non creativa. Anche quando si lavora su nuovi progetti davvero creativi. Gran parte di esso è umido, e spesso basato su schemi. questo è particolarmente vero per l'interfaccia utente.

La maggior parte dei sistemi moderni richiede anche che così tante persone li scrivano, che intrinsecamente non possono essere i migliori. La maggior parte delle persone sono nella media, anche se non lo sono, devono comunque svolgere molti compiti "medi".

Detto questo, richiedere competenze di base e requisiti minimi sensati non è irragionevole e non si deve scendere a compromessi.

Pensa alla chirurgia di routine: a seconda della tua tolleranza al rischio, probabilmente preferiresti farla eseguire da un medico medio piuttosto che aspettare 10 anni affinché il Preside della facoltà di medicina abbia il tempo di farlo. Ciò non significa che si dovrebbe consentire all'ordinato di eseguire l'intervento chirurgico.

"Assumere il meglio" tende a significare "assumere il meglio che sono attualmente disponibili all'incirca dove siamo" comunque, e significa cose diverse per aziende diverse. Alcuni vogliono programmatori rockstar, altri vogliono meticolosi ingegneri del software e il prossimo in fondo alla strada vuole esperti artigiani del software. Non esiste un "migliore universale", quindi tienilo a mente, e forse le tue specifiche di lavoro suggeriscono che stai cercando un tipo di programmatore e l'intervista dice che stai cercando un altro programmatore di tipo. All'improvviso, non ottieni partite.

Detto questo, non mi piace lavorare con programmatori così così. Quindi non ha nulla a che fare con l'esperienza (potrebbero aver programmato per 20 anni e non sono ancora molto bravi), ma tutto ha a che fare con attitudine ed entusiasmo. Se il così influisce su uno di questi due, hai un problema. Inoltre, non ha senso assumere qualcuno i cui contributi devono essere rielaborati da altri membri del team perché il loro codice non è abbastanza buono. Più bum nei posti non è sempre nella risposta, più bum nei posti possono purtroppo significare anche più lavoro per i membri migliori della squadra mentre stanno cercando di fare il loro lavoro e ripulire il caos che il programmatore ha consegnato .

Alcune persone non si presentano come rockstar, ma sono solidi programmatori di medio livello. Sono bravi ad avere nella squadra e non è quello che intendo con "così programmatore". Quest'ultimo è qualcuno che a malapena evita di essere licenziato ogni anno al momento della revisione delle prestazioni.

Come tipo di Manager, sono d'accordo che assumere "il primo 1%" non è pratico e non è necessario. Il mio consiglio sarebbe di assumere il team giusto per costruire e mantenere il tuo prodotto (potrebbero essere due team molto diversi, dato che build vs maintain sono molto diversi nelle loro esigenze)

Suggerirei vivamente di identificare le persone che hai attualmente nella tua squadra che sono "persone chiave" (ad es. Fare cose, avere buone attitudini, lavorare bene con requisiti di incertezza / alto livello, ecc.) E quindi assumere persone che hanno ha lavorato in passato (e rispetto, ovviamente). Ciò elimina molte incertezze nel processo di intervista e aiuta a gelificare il team.

Inoltre, più "a lungo termine" - investi molto in un programma di tirocinio. Se il tuo team di programmazione è composto da 20 persone, ricevi 5 stagisti all'anno e offri loro un vero lavoro. Riporta l'uno o due che ti piacciono ogni anno e aggiungi altre 5 variabili casuali. Questo è probabilmente il modo migliore per mantenere la tua squadra piena di buoni programmatori. È quindi possibile assumere all'esterno opportunisticamente e alzare l'asticella per quei candidati.

Come già accennato, presta attenzione al processo di intervista. Fai scrivere ai candidati il ​​codice (o meglio, segui la loro soluzione al problema "1 ora portare a casa") facendoli pranzare con la squadra. Conosci le loro abilità tecniche e interpersonali. E non aver mai paura di dire "no" anche quando sei alla disperata ricerca di altre 20 persone per un grande progetto che inizierà la prossima settimana.

Nella mia esperienza Paretto Principle si applica anche alla programmazione: l'80% del lavoro è realizzato dal 20% degli sviluppatori e viceversa. OK, i numeri potrebbero essere esagerati. In realtà avrai qualcosa come il 20% degli impiegati che svolgono il 50% del lavoro (per lavoro intendo un buon lavoro, non semplicemente linee di codice). In realtà è più simile a una curva a campana. Quindi in una squadra di 10, avrai 1 eroe, 2 ragazzi fantastici, 4 medi e 2-3 patetici.

Molte aziende utilizzano la curva Bell per valutare le valutazioni. Quindi praticamente non importa quanto siano brillanti i tuoi candidati che cadranno nei loro livelli. Non puoi avere una squadra in cui tutti siano allo stesso livello. Non succede

Ci sono già un sacco di risposte qui, ma penso che ci sia ancora un punto che deve essere discusso: l'impatto che l'assunzione dei ragazzi così ha sulla qualità del tuo software e come rende la tua vita da manager molto più difficile.

La risposta a "c'è bisogno di assumere i migliori sviluppatori?" è sempre un grosso grasso SÌ. Certo, in realtà, questo non è sempre possibile. Il pericoloso errore che penso tu stia facendo anche considerando questa domanda è pensare "il nostro software è così semplice che anche un ragazzo così può farlo". Questo è sbagliato.

Il tuo software verrà eseguito, non dubitare, ma aspettati risultati molto diversi da un team eccellente rispetto a un team così così. Avrai più bug, più problemi di prestazioni, più manutenibilità e problemi di scalabilità e così via. Dovrai fare da babysitter ai tuoi ragazzi così attraverso problemi più complessi. Dovrai fare da babysitter ai ragazzi così, anche se le decisioni sull'architettura adeguate.

Se lo accetti e sei pronto a gestirlo, va bene. Preparati al processo e ai risultati.

Penso che non sia davvero un problema assumere grandi sviluppatori. La vera sfida è farli desiderare di lavorare per te.

C'è bisogno di assumere i migliori?
Credo di sì. Il grande sviluppatore non è solo quello che fa tutto in tempo. Non solo un tale individuo è molto più produttivo di altri. Anche il grande sviluppatore sta dando l'esempio e ispirando semplicemente altri membri del team. Altri potrebbero avanzare notevolmente lavorando con loro.

OK, quindi abbasserai i tuoi standard. È bello, probabilmente cambierai idea dopo aver assunto un individuo davvero schifoso. Quello che risponderà perfettamente a tutte le tue domande CS ma che non può davvero scrivere una sola riga di codice di produzione. Buona fortuna :)

Facciamo un passo indietro.

cosa stiamo cercando di fare? Scrivi software.

Perché pensiamo di dover assumere il meglio? Perché quel fottuto ragazzo di Arnold non è riuscito a uscire da un sacchetto di carta bagnato e ora l'SQL è tutto incasinato e non riesco ad accedere.

Va bene, allora qual è il migliore ? Non lo so, è probabilmente qualcuno che vuole un sacco di soldi e ha un curriculum lungo sei piedi con un ottimo portfolio e ha lavorato su Google o qualcosa del genere. Dovrebbe avere una laurea e forse alcune lettere alla fine del suo nome. Sì, questo suona come il migliore per me, e per il migliore, intendo qualcuno che non è quel ragazzino di Arnold. Oh, e dovrebbe sapere come fare qualche schifo davvero duro di cui ho sentito parlare a scuola come "scrivere una specie di bolla" o come la chiamano. Chiederò a uno degli altri ragazzi di nominare alcune cose difficili che hanno dovuto fare a scuola, sì.

Sembra che tu non voglia quel ragazzo strano di Arnold? Vorresti? Sono stanco di avere un codice errato, le cose impiegano un'eternità a finire e questi nuovi ragazzi che intervisto mi dicono che devo riscrivere tutto!

Bene, allora cosa chiedi al ragazzo strano di Arnold di fare? Crea un sito Web PHP, scrivi jQuery, chiedi a PHP di eseguire alcuni CRUD di base con MSSQL e cambia i colori di sfondo.

Sembra un compito adatto esclusivamente al meglio? Sono sicuro che il meglio potrebbe farlo, ma probabilmente chiunque abbia il giusto skillset adatto a questo potrebbe farlo.

Quindi, non hai bisogno del meglio? Bene, ho solo bisogno di qualcuno con il skillset che soddisfi i miei obiettivi.

Oh. Si.

Il titolo della domanda menziona una "normale applicazione desktop", ma il testo parla della necessità di applicare la conoscenza della geometria computazionale e della programmazione lineare. Quelle sono aree di applicazione che hanno generato enormi programmi di ricerca pluriennali con enormi conseguenze sociali per qualsiasi progresso (richiamo, la programmazione lineare sottrae l' allocazione delle risorse ). Di conseguenza, esistono molti approcci sofisticati per risolvere i problemi in queste aree che funzionano molto bene.

Un cattivo noleggio

• potrebbe non aver nemmeno sentito parlare di queste classi di problemi,
• potrebbe non avere familiarità con le soluzioni comuni,
• probabilmente non saprebbero delle cose migliori che sono là fuori (suggerimento: la maggior parte degli studenti non ha mai sentito parlare delle cose fantasiose, se sentono dei problemi), e
• quasi certamente ci vorranno anni per implementare tali cose (considerando che ne ho visti alcuni tenere un intero seminario di laurea in strutture di dati, professore incluso).

In altre parole, pensa se stai davvero lavorando su qualcosa di pedonale. Se lo sei, ottimo, assumere dovrebbe essere molto più semplice. Se non lo sei, tieni duro per qualcuno che può fare ciò di cui hai bisogno.

Sicuramente non sono un programmatore superstar per gli standard di Joel. Tuttavia ho scritto alcuni progetti di successo durante i miei 20 anni di carriera come sviluppatore. Avrei potuto risolvere le tue domande. Ma meno dalla mia esperienza sul lavoro, dove in effetti molto del lavoro più complicato viene fatto chiedendo al database o a una funzione di libreria di farlo.

Ma se decidi di assumere persone meno esperte, dovresti prendere in considerazione l'utilizzo di tecnologie facili da gestire. Ad esempio, se hai pianificato di utilizzare C ++ per l'intero progetto, limita la parte C ++ alle librerie scritte dalle persone migliori e lascia che gli altri implementino l'interfaccia utente in Visual Basic.

Annota i valori che cerchi in un dipendente che si unirà ai tuoi ranghi.

Quando l'unico valore apprezzato è la competenza di programmazione ti troverai rapidamente circondato da persone che apprezzano proprio questo. Dato che i programmatori più competenti hanno un sistema di valori più elaborato, si asterranno dal far parte del tuo team.

Tuttavia, è più probabile che tu stia cercando persone innovative, creative, affidabili, erudite, curiose, autoapprendimento, socievoli, competenti e dedicate. Mostra che la tua azienda comprende e rispetta questi valori ed è disposta ad aiutare i suoi dipendenti a svilupparli ulteriormente.

Comprendi e abbraccia i valori dei tuoi dipendenti attuali e comunicali nelle tue domande di lavoro. Le buone aziende, con un sistema di valori sostenibile, attraggono buoni dipendenti.

In qualsiasi organizzazione hai persone con più esperienza e persone con meno. Non solo, ma un esperto in un campo può essere un principiante in un altro. Sicuramente un dilettante entusiasta può fare più male che bene a una base di codice, ma è così che imparano - riparando i loro errori e discutendo della loro esperienza con i loro colleghi più esperti.

Il mio suggerimento sarebbe che piuttosto che cercare di assumere superstar, provi ad assumere persone ragionevolmente brillanti, si adatteranno alla cultura della tua azienda, sono desiderosi di apprendere e apprezzare i propri limiti.

Certamente dovresti aspirare ad assumere solo il meglio. Ciò non significa automaticamente che ci riuscirai - ci sono solo così tanti "i migliori" da aggirare e ci saranno vincitori e vinti nella battaglia per attirarli. Gran parte di ciò verrà dalla tua attitudine e dalla tua volontà di lavorare sodo sul problema e delle risorse a tua disposizione.

Arrendersi prima di iniziare è il modo più sicuro per perdere.

La ricerca binaria è un problema interessante perché è risaputo che la maggior parte dei programmatori ha difficoltà a scriverlo correttamente ( scrive Bently a riguardo in Programming Pearls ). Forse non è così male testarlo finché non si escludono i candidati in base alla loro incapacità di risolverlo. Se lo risolvono rapidamente e correttamente, almeno suggerisce quale tipo di programmatore sono in modo da avere più informazioni in quel caso particolare.

devi assumere il meglio. ma il termine è stato citato fuori contesto molte volte. devi trovare il miglior candidato con le competenze richieste per quella posizione e non il miglior programmatore in senso lato. Lo sviluppo del software è ampio e non tutte le posizioni richiedono le stesse conoscenze tecniche.

Ponetevi questa domanda (avete già fatto ..): Se aveste un altro ingegnere nella stessa posizione per 5 anni, vi aspettereste che si ricordi delle serie di fibonanci e delle ricerche binarie?

se la risposta è no, cambia il modello del tuo colloquio. Potrebbe essere necessario conoscere una dozzina di algoritmi di ricerca se si desidera lavorare su un'applicazione di ricerca come Google o Bing. Tutti gli altri usano semplicemente map.get ("");

indirizza le tue interviste a ciò di cui ha bisogno la posizione, non a un buon programmatore generico da manuale.

Se davvero non ti interessa la qualità, ti suggerisco di utilizzare uno dei siti Web di outsourcing e iniziare con piccoli progetti. Quindi puoi pagarli se possono fare il lavoro e avere un modo semplice per salvare se non possono.

Tuttavia, mi chiedo se ci sia davvero molta codifica di routine in un'applicazione di ingegneria desktop. Possono essere molto complessi e la maggior parte dei programmatori non è così brava a gestire la complessità. Potresti facilmente creare un sacco di codice legacy istantaneo che legherà la tua squadra per gli anni a venire. In generale, i primi assunti per un nuovo progetto sono i più cruciali e daranno il tono per l'intero progetto.

Concordo pienamente con la maggior parte dei commenti sopra riportati che si riferiscono all'adattamento di una persona a un problema. Questo di solito si traduce in una relazione a lungo termine piuttosto che assumere una superstar per lavorare su un problema regolare, il che lo frustrerà a partire rapidamente.
Detto questo, dovresti sempre cercare di assumere per la tua azienda piuttosto che una posizione particolare. Perché questo stesso ragazzo prima o poi passerà da una squadra all'altra con contatti personali ecc. E potrebbe rivelarsi un peso morto da qualche altra parte. Assicurati che la tua azienda abbia linee guida interne molto rigorose per i trasferimenti e che tu abbia una chiara immagine di ciò che farai nel tuo team per i prossimi due anni prima di assumere una persona che ritieni possa non soddisfare la barra dell'azienda (ma risolverà il problema attuale ). Ho visto troppi casi in cui la mediocrità negli sviluppatori ha reso il team molto duro per adattarsi a loro.