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

Ti suggerisco di smettere di leggere troppo Joel. Ciò che ha scritto nel suo blog è in contraddizione con le sue risposte su questo sito, quindi non mi prendo molto sul serio.

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

Ciò di cui hai bisogno è una persona che:

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

Il resto non ha importanza.

Non crederesti quanti giovani neolaureati sono là fuori che non vogliono nient'altro che tuffarsi in questo tipo di un progetto CS-strong e non guardare mai le applicazioni CRUD di codifica. Qualche tempo fa ero uno di loro, ho praticamente sognato di unirmi a un progetto sullo sviluppo del compilatore ma non sono riuscito a trovarne uno. Perché non dare una 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 portare a termine il lavoro e lo volevano davvero.

most resumes we see are either doing simple CRUD apps, or SharePoint customization

Cosa c'è da aspettarsi se la maggior parte dei lavori richiede proprio questo? Le persone potrebbero aver studiato CS all'università e sono anche state davvero brave a farlo, ma non puoi aspettarti che le ricordino se non l'hanno mai usato nella programmazione pratica in 10 anni. Ovviamente nessuno leggerà più vecchi libri di CS ogni anno solo per tenerlo fresco se questa conoscenza non viene usata da nessuna parte.

Un libro che mi piace davvero Prima interrompi tutte le regole . Ha un sacco di informazioni sulle differenze tra manager medi e buoni manager. Una delle intuizioni chiave che i buoni manager hanno ripetuto più e più volte è stata riassunta da uno di loro nella frase, Non ho mai aspettato troppo a lungo per trovare l'affitto giusto, e non ho mai licenziato il noleggio sbagliato abbastanza. Sì, è frustrante impiegare molto tempo per assumere, ma ne vale la pena.

Un secondo punto che dovresti tenere a mente è che quando misurato sulla velocità del progetto, c'è un picco di produttività per gruppi di 5-8 persone. Non si torna alla stessa produttività finché non si ha una squadra di oltre 20 persone. Sii molto, molto cauto nel far crescere una squadra oltre le dimensioni in cui lavorano le piccole dinamiche di squadra. E se hai intenzione di rimanere al di sotto di questa soglia, allora vuoi davvero che quelle 5-8 persone siano brave.

Entrambi i punti parlano con fermezza per ottenere il noleggio giusto.

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

In effetti le organizzazioni costituite esclusivamente da tali persone sarebbero altamente instabili. Troppo ego, troppe idee contrastanti. Sarebbe crollare perché ognuno fa la sua stessa cosa, impantanarsi in discussioni teoriche senza fine sui relativi meriti di tutto, o evolvere in una costante corrispondenza urlante, mentre i sentimenti divampano ogni volta che una decisione deve essere presa.

La prima cosa che devi chiedere è perché stai ottenendo curriculum che non sono all'altezza degli standard che desideri. Ho lavorato con molte brave persone, quindi sono là fuori e l'applicazione mi sembra molto interessante. Se non riesci a ottenere persone che possono fare sequenze di Fibonacci e ricerca binaria (il che è più difficile di quanto sembri, secondo Knuth erano diversi anni tra la sua prima pubblicazione e la sua prima pubblicazione corretta), stai facendo qualcosa per guidare la quelli buoni.

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

Non assumere persone perché sono le migliori che vengono applicate. Assumi persone perché saranno in grado di fare qualcosa che vuoi fare. Se assumi mediocre perché è tutto ciò che si applica, allora stai lentamente perdendo brave persone e finirai con persone la cui algebra è traballante nel tentativo di fare cose con la geometria computazionale. (Assumere un lavoro mediocre 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 potrebbe fare una ricerca binaria perché non abbiamo frequentato corsi CS e nella vita reale usiamo una libreria per questo. Direi addirittura: qualcuno che scrive se stesso binsearch non sa come focalizzarsi su cose importanti.

È molto più importante se il candidato è intelligente e si inserisce nel gruppo. Se vuoi controllare il suo talento nella programmazione, dagli un lavoro da fare a casa. Nota quanto tempo ci è voluto / a e discuti i risultati per scoprire se è il lavoro vero e proprio dei candidati.

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

La maggior parte del lavoro di programmazione è di routine e non creativa. Anche quando si lavora su nuovi progetti davvero creativi. La maggior parte è monotona e spesso basata 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 tutti i migliori. La maggior parte delle persone è nella media, anche se non lo sono, devono comunque svolgere molti compiti "medi" della persona.

Detto questo, esigere la competenza di base e i requisiti minimi sensibili non è irragionevole e non è qualcosa su cui dovresti scendere a compromessi.

Pensa alla chirurgia di routine: a seconda della tua tolleranza al rischio, probabilmente preferiresti fare eseguire un medico medio piuttosto che attendere 10 anni perché il preside della scuola medica abbia il tempo di farlo. Ciò non significa che dovresti lasciare eseguire l'intervento in modo ordinato.

"Assumere il meglio" tende a significare "assumere il meglio che è attualmente disponibile all'incirca nel punto in cui siamo" in ogni caso, e significa cose diverse per società diverse. Alcuni vogliono programmatori di rockstar, altri vogliono ingegneri software meticolosi e il prossimo in fondo alla strada vuole esperti artigiani del software. Non esiste un "universale migliore", 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 tipi. Improvvisamente, non ottieni le partite.

Detto questo, non mi piace lavorare con i programmatori così così. Quindi non ha nulla a che fare con l'esperienza (potrebbero aver programmato per 20 anni e ancora non sono molto bravi in questo), ma tutto ha a che fare con l'attitudine e l'entusiasmo. Se il così-so colpisce uno di questi due, hai un problema. Non serve nemmeno assumere qualcuno i cui contributi devono essere rielaborati da altri membri della squadra perché il loro codice non è abbastanza buono. La maggior parte dei vagabondi sui sedili non è sempre nella risposta, più barboni sui sedili possono purtroppo anche significare più lavoro per i membri migliori della squadra mentre stanno cercando di fare il loro lavoro e ripulire il casino il programmatore così ha consegnato.

Alcune persone non si presentano come rockstars, ma sono solidi programmatori di medio livello. Sono bravi da avere nella squadra e non è quello che intendo con "così così programmatore". Quest'ultimo è uno che evita a malapena di essere licenziato ogni anno ai tempi di revisione delle prestazioni.

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

Una cosa che mi infastidisce davvero è che c'è bisogno di assumere i migliori sviluppatori? Per i principianti, stiamo vivendo grandi difficoltà nel reclutamento; la maggior parte dei curriculum che vediamo sono sia semplici app CRUD, sia personalizzazioni di SharePoint che non credo implichino davvero molta programmazione hardcore. Anche quelli che chiamiamo per un colloquio, la maggior parte non possono fare la sequenza di Fibonacci e una semplice ricerca binaria, e siamo abbastanza gentili da dare suggerimenti e esplicitare esplicitamente i problemi in modo che i candidati non cercare un dizionario per verificare cosa significa "sequenza di Fibonacci".

Questo mi ha fatto riflettere: Sì, abbiamo bisogno di un certo livello di attitudine alla programmazione quando si eseguono operazioni di programmazione geometrica / di programmazione lineare, e abbiamo bisogno di un certo livello di attitudine alla programmazione quando si progetta l'architettura del software o si decide quale modello software usare, ma oltre a questo, molto del nostro codice è solo un codice idraulico (credo), che può essere fatto da qualcuno con una certa dimestichezza con la programmazione.

Dato che ora abbiamo davvero bisogno di talenti per la programmazione, e dato che gli sviluppatori superstar assoldati sono molto difficili, voglio abbassare il mio standard e assumere solo i così così, in diretta contraddizione con ciò che Joel predica .

Che ne pensi?

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

Ti suggerisco di smettere di leggere troppo Joel. Ciò che ha scritto nel suo blog è in contraddizione con le sue risposte su questo sito, quindi non mi prendo molto sul serio.

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

Ciò di cui hai bisogno è una persona che:

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

Il resto non ha importanza.

Non crederesti quanti giovani neolaureati sono là fuori che non vogliono nient'altro che tuffarsi in questo tipo di un progetto CS-strong e non guardare mai le applicazioni CRUD di codifica. Qualche tempo fa ero uno di loro, ho praticamente sognato di unirmi a un progetto sullo sviluppo del compilatore ma non sono riuscito a trovarne uno. Perché non dare una 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 portare a termine il lavoro e lo volevano davvero.

Cosa c'è da aspettarsi se la maggior parte dei lavori richiede proprio questo? Le persone potrebbero aver studiato CS all'università e sono anche state davvero brave a farlo, ma non puoi aspettarti che le ricordino se non l'hanno mai usato nella programmazione pratica in 10 anni. Ovviamente nessuno leggerà più vecchi libri di CS ogni anno solo per tenerlo fresco se questa conoscenza non viene usata da nessuna parte.

Un libro che mi piace davvero Prima interrompi tutte le regole . Ha un sacco di informazioni sulle differenze tra manager medi e buoni manager. Una delle intuizioni chiave che i buoni manager hanno ripetuto più e più volte è stata riassunta da uno di loro nella frase, Non ho mai aspettato troppo a lungo per trovare l'affitto giusto, e non ho mai licenziato il noleggio sbagliato abbastanza. Sì, è frustrante impiegare molto tempo per assumere, ma ne vale la pena.

Un secondo punto che dovresti tenere a mente è che quando misurato sulla velocità del progetto, c'è un picco di produttività per gruppi di 5-8 persone. Non si torna alla stessa produttività finché non si ha una squadra di oltre 20 persone. Sii molto, molto cauto nel far crescere una squadra oltre le dimensioni in cui lavorano le piccole dinamiche di squadra. E se hai intenzione di rimanere al di sotto di questa soglia, allora vuoi davvero che quelle 5-8 persone siano brave.

Entrambi i punti parlano con fermezza per ottenere il noleggio giusto.

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

In effetti le organizzazioni costituite esclusivamente da tali persone sarebbero altamente instabili. Troppo ego, troppe idee contrastanti. Sarebbe crollare perché ognuno fa la sua stessa cosa, impantanarsi in discussioni teoriche senza fine sui relativi meriti di tutto, o evolvere in una costante corrispondenza urlante, mentre i sentimenti divampano ogni volta che una decisione deve essere presa.

La prima cosa che devi chiedere è perché stai ottenendo curriculum che non sono all'altezza degli standard che desideri. Ho lavorato con molte brave persone, quindi sono là fuori e l'applicazione mi sembra molto interessante. Se non riesci a ottenere persone che possono fare sequenze di Fibonacci e ricerca binaria (il che è più difficile di quanto sembri, secondo Knuth erano diversi anni tra la sua prima pubblicazione e la sua prima pubblicazione corretta), stai facendo qualcosa per guidare la quelli buoni.

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

Non assumere persone perché sono le migliori che vengono applicate. Assumi persone perché saranno in grado di fare qualcosa che vuoi fare. Se assumi mediocre perché è tutto ciò che si applica, allora stai lentamente perdendo brave persone e finirai con persone la cui algebra è traballante nel tentativo di fare cose con la geometria computazionale. (Assumere un lavoro mediocre 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 potrebbe fare una ricerca binaria perché non abbiamo frequentato corsi CS e nella vita reale usiamo una libreria per questo. Direi addirittura: qualcuno che scrive se stesso binsearch non sa come focalizzarsi su cose importanti.

È molto più importante se il candidato è intelligente e si inserisce nel gruppo. Se vuoi controllare il suo talento nella programmazione, dagli un lavoro da fare a casa. Nota quanto tempo ci è voluto / a e discuti i risultati per scoprire se è il lavoro vero e proprio dei candidati.

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

La maggior parte del lavoro di programmazione è di routine e non creativa. Anche quando si lavora su nuovi progetti davvero creativi. La maggior parte è monotona e spesso basata 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 tutti i migliori. La maggior parte delle persone è nella media, anche se non lo sono, devono comunque svolgere molti compiti "medi" della persona.

Detto questo, esigere la competenza di base e i requisiti minimi sensibili non è irragionevole e non è qualcosa su cui dovresti scendere a compromessi.

Pensa alla chirurgia di routine: a seconda della tua tolleranza al rischio, probabilmente preferiresti fare eseguire un medico medio piuttosto che attendere 10 anni perché il preside della scuola medica abbia il tempo di farlo. Ciò non significa che dovresti lasciare eseguire l'intervento in modo ordinato.

"Assumere il meglio" tende a significare "assumere il meglio che è attualmente disponibile all'incirca nel punto in cui siamo" in ogni caso, e significa cose diverse per società diverse. Alcuni vogliono programmatori di rockstar, altri vogliono ingegneri software meticolosi e il prossimo in fondo alla strada vuole esperti artigiani del software. Non esiste un "universale migliore", 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 tipi. Improvvisamente, non ottieni le partite.

Detto questo, non mi piace lavorare con i programmatori così così. Quindi non ha nulla a che fare con l'esperienza (potrebbero aver programmato per 20 anni e ancora non sono molto bravi in questo), ma tutto ha a che fare con l'attitudine e l'entusiasmo. Se il così-so colpisce uno di questi due, hai un problema. Non serve nemmeno assumere qualcuno i cui contributi devono essere rielaborati da altri membri della squadra perché il loro codice non è abbastanza buono. La maggior parte dei vagabondi sui sedili non è sempre nella risposta, più barboni sui sedili possono purtroppo anche significare più lavoro per i membri migliori della squadra mentre stanno cercando di fare il loro lavoro e ripulire il casino il programmatore così ha consegnato.

Alcune persone non si presentano come rockstars, ma sono solidi programmatori di medio livello. Sono bravi da avere nella squadra e non è quello che intendo con "così così programmatore". Quest'ultimo è uno che evita a malapena di essere licenziato ogni anno ai tempi di revisione delle prestazioni.

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à avrete qualcosa come il 20% dei dipendenti che fanno il 50% del lavoro (per lavoro intendo un buon lavoro, non solo linee di codice). In realtà è più simile a una curva a campana. Quindi in una squadra di 10, avrai 1 eroe, 2 fantastici ragazzi, 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, rientreranno 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ì così ha sulla qualità del tuo software e su come rende la tua vita come manager molto più difficile.

La risposta a "c'è bisogno di assumere gli sviluppatori migliori?" è sempre un grosso grasso SI. Certo, in realtà, questo non è sempre possibile. Il pericoloso errore che penso 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à completato, non ne dubito, ma si aspettano 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 così così ragazzi attraverso problemi più complessi. Dovrai fare da babysitter ai ragazzi così così anche se le decisioni di architettura appropriate.

Se accetti questo e sei pronto a gestirlo, va bene. Preparati solo per il processo e per i risultati.

Penso che non sia davvero un problema assumere un grande sviluppatore. La vera sfida è renderli vogliono 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 individuo è molto più produttivo di altri. Un grande sviluppatore sta anche guidando l'esempio e ha semplicemente ispirato gli altri membri del team. Altri potrebbero essere molto avanzati mentre lavorano con loro.

OK, quindi abbasserai i tuoi standard. È bello, probabilmente cambierai idea dopo aver assunto un individuo davvero schifoso. Quello che risponderà in modo impeccabile a tutte le tue domande su CS, ma che non è in grado di scrivere una sola riga del codice di produzione. Buona fortuna con questo:)

Facciamo un passo indietro.

Che cosa stiamo cercando di fare? Scrivi software.

Perché pensiamo di aver bisogno di assumere il migliore? Perché quel ragazzaccio Arnold non è riuscito ad uscire da un sacchetto di carta bagnato e ora l'SQL è tutto rovinato e io posso effettua il login.

Ok, quindi cos'è il migliore ? Non lo so, probabilmente è qualcuno che vuole un sacco di soldi e ha un curriculum lungo sei piedi con un grande portafoglio e ha lavorato su google o qualcosa del genere. Dovrebbe avere una laurea e forse alcune lettere alla fine del suo nome. Sì, sembra il meglio per me, e per la migliore, intendo qualcuno che non è quel ragazzino Arnold. Oh, e lui dovrebbe sapere come fare una cazzata davvero dura di cui ho sentito parlare a scuola come "scrivere una sorta di bolla" o come lo 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 ragazzino Arnold? Vuoi? Sono stanco di avere il codice buggy, ci vuole un tempo infinito per finire, e questi nuovi ragazzi che intervengo mi dicono che devo riscrivere tutto!

Giusto, quindi cosa chiedi al ragazzino Arnold di fare? Creare un sito Web PHP, scrivere un jQuery, fare in modo che il PHP faccia un CRUD di base con MSSQL e cambiare i colori dello sfondo intorno .

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

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

Oh. Sì.

Il titolo della tua domanda menziona una "normale applicazione desktop", ma il tuo testo parla della necessità di applicare la conoscenza della geometria computazionale e della programmazione lineare. Quelle sono aree applicative che hanno generato enormi programmi di ricerca multi-decennio con enormi conseguenze sociali di qualsiasi progresso (richiami, abstract di programmazione lineare allocazione di risorse ). Di conseguenza, ci sono molti approcci sofisticati per risolvere i problemi in queste aree che funzionano molto bene.

Una cattiva assunzione

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

In altre parole, pensa se stai davvero lavorando su qualcosa di pedonale. Se lo sei, ottimo, l'assunzione dovrebbe essere molto più semplice. Se non lo sei, proteggi per qualcuno che possa fare ciò di cui hai bisogno.

Sicuramente non sono un programmatore di superstar secondo gli standard di Joel. Tuttavia ho scritto alcuni progetti di successo nella mia carriera di 20 anni come sviluppatore. Potrei aver risolto le tue domande. Ma meno dalla mia esperienza lavorativa, dove in realtà un sacco di lavoro più complicato è fatto chiedendo al tuo database o una funzione di libreria di farlo.

Ma se decidi di assumere personale meno esperto, dovresti prendere in considerazione l'utilizzo di tecnologie facili da gestire. Ad esempio se hai pianificato di utilizzare C ++ per l'intero progetto, quindi 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. Dal momento che molti programmatori veramente competenti hanno un sistema di valori più elaborato, si asterranno dall'entrare nel tuo team.

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

Comprendi e abbraccia i valori dei tuoi attuali dipendenti e comunicali nelle tue applicazioni 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. Certo un dilettante entusiasta può fare più male che bene ad un codice base, ma è così che imparano - dal correggere i loro errori e discutere della loro esperienza con i loro colleghi più esperti.

Il mio suggerimento sarebbe che piuttosto che cercare di assumere superstar, cerchi di assumere persone che sono ragionevolmente brillanti, si adattano alla tua cultura aziendale, sono desiderosi di apprendere e apprezzare i propri limiti.

Certamente dovresti aspirare ad assumere solo il meglio. Questo non significa automaticamente che avrai successo - c'è solo un sacco di "i migliori" per andare in giro, e ci saranno vincitori e vinti nella battaglia per attirarli. Gran parte di esso verrà dalla tua attitudine e volontà a lavorare sodo per risolvere il problema e le risorse a tua disposizione.

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

La ricerca binaria è un problema interessante perché è risaputo che la maggior parte dei programmatori fatica a scrivere correttamente ( Bently ne parla in Programming Pearls ). Forse non è così male testarlo fino a quando non si escludono i candidati in base alla loro incapacità di risolverlo. Se lo risolvono in modo rapido e corretto, almeno questo suggerisce che tipo di programmatore sono così da avere più informazioni in quel caso particolare.

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

Porsi questa domanda (lo hai già fatto ..): se hai un altro ingegnere nella stessa posizione per 5 anni, ti aspetteresti che ricordasse serie di fibonanci e ricerche binarie?

se la risposta è no, quindi cambia il modello dell'intervista. 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 solo map.get ("");

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

Se davvero non ti interessa la qualità, suggerirei 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 liberarti se non possono.

Tuttavia, mi chiedo se ci sia davvero molto codice 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à il tuo team per gli anni a venire. In generale, i primi assunti per un nuovo progetto sono i più cruciali e daranno il tono all'intero progetto.

Sono totalmente d'accordo con la maggior parte dei commenti sopra 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 normale - il che lo renderà frustrante solo per andarsene rapidamente.
Detto questo, dovresti sempre cercare di assumere per la tua azienda piuttosto che una posizione particolare. Perché questo stesso ragazzo passerà prima o poi tra i contatti personali, ecc. E potrebbe rivelarsi un peso morto da qualche altra parte. Assicurati che la tua azienda abbia linee guida per il trasferimento interne molto rigide e che tu abbia una chiara visione di ciò che farai nella tua squadra per i prossimi due anni prima di assumere una persona che pensi possa non incontrare la società (ma risolverà il problema attuale ). Ho visto troppi casi in cui la mediocrità degli sviluppatori ha fatto sì che la squadra lavorasse molto duramente per adattarsi a loro.

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à avrete qualcosa come il 20% dei dipendenti che fanno il 50% del lavoro (per lavoro intendo un buon lavoro, non solo linee di codice). In realtà è più simile a una curva a campana. Quindi in una squadra di 10, avrai 1 eroe, 2 fantastici ragazzi, 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, rientreranno 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ì così ha sulla qualità del tuo software e su come rende la tua vita come manager molto più difficile.

La risposta a "c'è bisogno di assumere gli sviluppatori migliori?" è sempre un grosso grasso SI. Certo, in realtà, questo non è sempre possibile. Il pericoloso errore che penso 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à completato, non ne dubito, ma si aspettano 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 così così ragazzi attraverso problemi più complessi. Dovrai fare da babysitter ai ragazzi così così anche se le decisioni di architettura appropriate.

Se accetti questo e sei pronto a gestirlo, va bene. Preparati solo per il processo e per i risultati.

Penso che non sia davvero un problema assumere un grande sviluppatore. La vera sfida è renderli vogliono 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 individuo è molto più produttivo di altri. Un grande sviluppatore sta anche guidando l'esempio e ha semplicemente ispirato gli altri membri del team. Altri potrebbero essere molto avanzati mentre lavorano con loro.

OK, quindi abbasserai i tuoi standard. È bello, probabilmente cambierai idea dopo aver assunto un individuo davvero schifoso. Quello che risponderà in modo impeccabile a tutte le tue domande su CS, ma che non è in grado di scrivere una sola riga del codice di produzione. Buona fortuna con questo:)

Facciamo un passo indietro.

Che cosa stiamo cercando di fare? Scrivi software.

Perché pensiamo di aver bisogno di assumere il migliore? Perché quel ragazzaccio Arnold non è riuscito ad uscire da un sacchetto di carta bagnato e ora l'SQL è tutto rovinato e io posso effettua il login.

Ok, quindi cos'è il migliore ? Non lo so, probabilmente è qualcuno che vuole un sacco di soldi e ha un curriculum lungo sei piedi con un grande portafoglio e ha lavorato su google o qualcosa del genere. Dovrebbe avere una laurea e forse alcune lettere alla fine del suo nome. Sì, sembra il meglio per me, e per la migliore, intendo qualcuno che non è quel ragazzino Arnold. Oh, e lui dovrebbe sapere come fare una cazzata davvero dura di cui ho sentito parlare a scuola come "scrivere una sorta di bolla" o come lo 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 ragazzino Arnold? Vuoi? Sono stanco di avere il codice buggy, ci vuole un tempo infinito per finire, e questi nuovi ragazzi che intervengo mi dicono che devo riscrivere tutto!

Giusto, quindi cosa chiedi al ragazzino Arnold di fare? Creare un sito Web PHP, scrivere un jQuery, fare in modo che il PHP faccia un CRUD di base con MSSQL e cambiare i colori dello sfondo intorno .

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

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

Oh. Sì.

Il titolo della tua domanda menziona una "normale applicazione desktop", ma il tuo testo parla della necessità di applicare la conoscenza della geometria computazionale e della programmazione lineare. Quelle sono aree applicative che hanno generato enormi programmi di ricerca multi-decennio con enormi conseguenze sociali di qualsiasi progresso (richiami, abstract di programmazione lineare allocazione di risorse ). Di conseguenza, ci sono molti approcci sofisticati per risolvere i problemi in queste aree che funzionano molto bene.

Una cattiva assunzione

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

In altre parole, pensa se stai davvero lavorando su qualcosa di pedonale. Se lo sei, ottimo, l'assunzione dovrebbe essere molto più semplice. Se non lo sei, proteggi per qualcuno che possa fare ciò di cui hai bisogno.

Sicuramente non sono un programmatore di superstar secondo gli standard di Joel. Tuttavia ho scritto alcuni progetti di successo nella mia carriera di 20 anni come sviluppatore. Potrei aver risolto le tue domande. Ma meno dalla mia esperienza lavorativa, dove in realtà un sacco di lavoro più complicato è fatto chiedendo al tuo database o una funzione di libreria di farlo.

Ma se decidi di assumere personale meno esperto, dovresti prendere in considerazione l'utilizzo di tecnologie facili da gestire. Ad esempio se hai pianificato di utilizzare C ++ per l'intero progetto, quindi 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. Dal momento che molti programmatori veramente competenti hanno un sistema di valori più elaborato, si asterranno dall'entrare nel tuo team.

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

Comprendi e abbraccia i valori dei tuoi attuali dipendenti e comunicali nelle tue applicazioni 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. Certo un dilettante entusiasta può fare più male che bene ad un codice base, ma è così che imparano - dal correggere i loro errori e discutere della loro esperienza con i loro colleghi più esperti.

Il mio suggerimento sarebbe che piuttosto che cercare di assumere superstar, cerchi di assumere persone che sono ragionevolmente brillanti, si adattano alla tua cultura aziendale, sono desiderosi di apprendere e apprezzare i propri limiti.

Certamente dovresti aspirare ad assumere solo il meglio. Questo non significa automaticamente che avrai successo - c'è solo un sacco di "i migliori" per andare in giro, e ci saranno vincitori e vinti nella battaglia per attirarli. Gran parte di esso verrà dalla tua attitudine e volontà a lavorare sodo per risolvere il problema e le risorse a tua disposizione.

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

La ricerca binaria è un problema interessante perché è risaputo che la maggior parte dei programmatori fatica a scrivere correttamente ( Bently ne parla in Programming Pearls ). Forse non è così male testarlo fino a quando non si escludono i candidati in base alla loro incapacità di risolverlo. Se lo risolvono in modo rapido e corretto, almeno questo suggerisce che tipo di programmatore sono così da avere più informazioni in quel caso particolare.

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

Porsi questa domanda (lo hai già fatto ..): se hai un altro ingegnere nella stessa posizione per 5 anni, ti aspetteresti che ricordasse serie di fibonanci e ricerche binarie?

se la risposta è no, quindi cambia il modello dell'intervista. 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 solo map.get ("");

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

Se davvero non ti interessa la qualità, suggerirei 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 liberarti se non possono.

Tuttavia, mi chiedo se ci sia davvero molto codice 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à il tuo team per gli anni a venire. In generale, i primi assunti per un nuovo progetto sono i più cruciali e daranno il tono all'intero progetto.

Sono totalmente d'accordo con la maggior parte dei commenti sopra 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 normale - il che lo renderà frustrante solo per andarsene rapidamente.
Detto questo, dovresti sempre cercare di assumere per la tua azienda piuttosto che una posizione particolare. Perché questo stesso ragazzo passerà prima o poi tra i contatti personali, ecc. E potrebbe rivelarsi un peso morto da qualche altra parte. Assicurati che la tua azienda abbia linee guida per il trasferimento interne molto rigide e che tu abbia una chiara visione di ciò che farai nella tua squadra per i prossimi due anni prima di assumere una persona che pensi possa non incontrare la società (ma risolverà il problema attuale ). Ho visto troppi casi in cui la mediocrità degli sviluppatori ha fatto sì che la squadra lavorasse molto duramente per adattarsi a loro.