Test di codifica pre-screening - Quanto è ragionevole? [chiuso]

Permettetemi di prendere la parte della compagnia per un momento, dal momento che le altre risposte non hanno finora. Sarebbe quasi impossibile costruire una base di codice utilizzabile da un conglomerato di richieste di test di codifica della durata di 4 ore da parte di persone le cui qualifiche sono completamente sconosciute. La creazione di una specifica sufficientemente dettagliata, la verifica delle risposte e l'integrazione con il resto del codice richiederebbero più di 4 ore. Per non parlare dei progetti software di livello aziendale più utili richiedono migliaia di ore di lavoro. Il pensiero di creare un'impresa dividendolo in incrementi di 4 ore con settimane di tempo di consegna è francamente ridicolo.

Dare un vero problema alla vita aziendale è uno dei modi migliori per determinare se qualcuno sarà bravo a risolvere i problemi della vita reale dell'azienda. Lo faccio spesso nelle interviste (anche se chiedo i principi generali di progettazione e non le 4 ore di codice), e ogni volta è stato un problema che ho già risolto. Se non l'avessi già risolto, il test perderebbe quasi tutto il valore probatorio.

La validità di un test di 4 ore è una decisione personale. Mi è sempre stato insegnato a trattare il lavoro a tempo pieno come un lavoro a tempo pieno. Quando sei disoccupato o sottoccupato e trascorri 8 ore al giorno in cerca di lavoro, un test di codifica della durata di 4 ore non è nulla. Ho speso molto più tempo rispetto a compiti come spazzolare le lingue arrugginite, scrivere programmi di portfolio e personalizzare i curriculum per posizioni specifiche.

D'altro canto, alcuni dei migliori lavoratori sono già impiegati in modo redditizio e cercano solo casualmente opportunità migliori. È improbabile che le persone in quella situazione passino attraverso il rigamarole di un test di 4 ore, a meno che l'opportunità non sia stellare. Tuttavia, questo è il problema dell'azienda, non il tuo.

Per quanto riguarda il discernimento su cosa significhi l'atteggiamento della compagnia nei confronti dei propri dipendenti, non credo che si possa davvero dire qualcosa in ogni caso, a parte il fatto che sono probabilmente stanchi di trattare con candidati non qualificati, in misura disposto a buttar fuori parte del bene con il cattivo.

No, non tipico , perché stai risolvendo i loro problemi gratuitamente? (4 ore)

1 ora è tipico per un test di programmazione. In passato il nostro test di programmazione era composto da 4 domande. Le prime 3 domande hanno richiesto 1/2 ora, l'ultima 1/2 ora. Abbiamo anche sottoposto il test alle assunzioni esistenti in loco per assicurarci che fossimo nei tempi previsti e il test fosse equo e adeguato in modo conforme.

Le prime domande riguardavano il tipo "Fizz Buzz" per eliminare le persone che non possono programmare. Sono diventati progressivamente più difficili. L'ultima domanda era un esercizio di risoluzione dei problemi. In generale abbiamo cercato di limitare la quantità di codice scritto a poche centinaia di righe (totale) e non richiedere trucchi intelligenti. Abbiamo anche valutato le persone sulla gestione degli errori, lo stile, la sintassi, l'organizzazione, ecc. Le domande non erano legate alla nostra attività, ma piuttosto alle abilità e alla tecnologia su cui è stata scritta la piattaforma attuale.

In genere, i grandi candidati finivano in meno tempo di quanto era stato assegnato. A volte le persone hanno richiesto un tempo extra che ci è stato concesso a causa dello stress richiesto per fare un quiz, ma abbiamo limitato tutti a un certo limite. Il quiz si trovava nell'attuale ambiente di sviluppo e le persone avevano accesso a Internet per informazioni di riferimento. Abbiamo anche superato le aspettative del quiz per ogni candidato.

In una sola volta abbiamo discusso di incorporare la nostra base di codice (mondo reale) nel quiz ma alla fine abbiamo scartato ciò a causa di preoccupazioni che il codice copiato / rubato / etc (il nostro capo era un po 'paranoico). Alla fine siamo andati con un quiz.sln separato in un computer di sviluppo isolato.

Infine, abbiamo scoperto che era difficile trovare un test che fosse equo, ma né troppo difficile né troppo facile. Abbiamo sempre chiesto ai nostri candidati circa il quiz dopo averlo preso e ottenuto il loro feedback per perfezionarlo per futuri candidati.

Trovo che i test di codifica durante l'intervista siano comunque carichi di tosh. Nessuno codifica nulla se non la più semplice routine sotto pressione senza il solito ambiente e strumenti, quindi i risultati che ottieni sono dubbi al meglio.

Quello che ho trovato per essere davvero un buon test dell'abilità di un programmatore è di dargli qualche codice di progetto e chiedergli di rivederlo, funziona molto bene se il codice ha diversi errori evidenti, diversi problemi di codice ovvio e alcuni pratiche discutibili. Un buon programmatore ti dirà tutti loro e si impegnerà con te nella discussione sul perché alcuni codici non sono "sbagliati", ma potrebbero essere fatti meglio per facilitare la manutenzione. Un povero programmatore troverà un bug e si fermerà.

Qualsiasi lavoro che si aspetta che tu faccia un test che impiega più di mezz'ora non ha ancora impiegato così a lungo un test valido e mirato che fornisce loro più di una vaga idea delle tue capacità. (la maggior parte delle aziende trova molto difficile passare il tempo a lavorare sulla configurazione pre-intervista).

Se mi fosse stato dato un test come lo avresti fatto, avrei scritto la risposta in pseudo-codice. Questo dovrebbe essere sufficiente per dimostrare la mia comprensione della codifica e del design, senza passare attraverso l'intera fase di compilazione, compilazione e test di un normale progetto di lavoro.

Potresti non avere 4 ore, ma sicuramente qualcuno più interessato alla loro compagnia lo farà. Sono stato essenzialmente assunto in base a un compito simile che un'azienda mi ha chiesto di fare in anticipo sull'attività da solo. Apparentemente, scrivere codice pulito e comprensibile, casi di test approfonditi e documentazione progettuale comprensibile e coerente è un'anomalia. In realtà vedere qualcuno farlo fa esplodere le persone. Ad ogni modo, tutti quelli con cui ho parlato durante l'intervista mi hanno lodato per quello che ho fatto e ho avuto la sensazione di non aver impressionato nessuno nell'intervista perché avevano già deciso. Era semplicemente una questione di me non dare loro una ragione per dire di no facendo qualcosa di stupido.

Quindi, mentre sono d'accordo, 4 ore sono un investimento di tempo abbastanza grande, significa anche che il compito è di dimensioni sufficienti che hai l'opportunità di mostrare davvero di cosa sei capace. Il tuo lavoro molto bene può parlare più di quanto potresti mai in una situazione di intervista reale.

Come nota a margine: ho provato una cosa simile ultimamente ma usando un problema molto più piccolo e non sono stato soddisfatto dei risultati. Piccoli problemi sono banali per dimostrare abbastanza della conoscenza della persona. Inoltre, problemi banali tendono a richiedere alla persona di riconoscere qualche trucco / dettaglio necessario per risolvere il problema. Quindi, c'è un certo equilibrio tra l'assunzione di troppo tempo di una persona rispetto a non ottenere benefici reali perché il compito è banale. Penserei che un compito di 4 ore è probabilmente la giusta quantità di tempo per essere abbastanza complesso da consentire ai candidati di dimostrare le loro abilità e non essere così lungo che nessuno si preoccuperebbe.

Ho fatto un test di codifica della durata di 6 ore a un certo punto. Quando ho fatto questo test ho avuto abbastanza fiducia che sarei stato assunto - mentre si è avverato, non ero soddisfatto del follow-on.

Ovviamente avere un sacco di datori di lavoro che chiedono quattro ore è eccessivo. Ciò che la persona stava cercando nel test che ho preso è stato il mio stile di codifica: sono stato assunto perché il mio era "il più vicino" al suo. In questo contesto, guarda il problema da questa prospettiva: in primo luogo, è un problema interessante che la soluzione sia utile per te in ogni caso? Dopo tutto, potresti imparare qualcosa di prezioso.

In secondo luogo, se riesci a "passare" il test vuol dire che sei assunto? Se questo non è abbastanza ovvio, allora devi decidere se ci sono altri motivi per farlo comunque.

In terzo luogo, potrebbero stimare che ci vogliono "4 ore", ma potresti scoprirlo in modo diverso. Sanno davvero quanto ci vorrà? Molto probabilmente la risposta è no. Pertanto, continueranno a testare le persone con scadenze di 4 ore fino a quando non si renderanno conto che non si adatteranno in quattro ore. In quel caso stai perdendo tempo. L'approccio migliore è quello di diventare aggressivi con il gestore assumente, e capire se è necessario fermarsi a quattro ore e dare loro ciò che si ha, o continuare fino a quando non è fatto e dire loro quanto tempo ci è voluto. In breve, potrebbe esserci un test del personaggio racchiuso in questo, e il semplice tentativo di accettarlo alle loro condizioni potrebbe rivelare inesperienza.