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

MODIFICARE

Dopo una buona dose di riflessione e di auto-riflessione sull'argomento, mi sono reso conto che la maggior parte dei problemi sollevati in questa domanda proveniva solo da una prospettiva personale, piuttosto che professionale. Quindi i moderatori mettono in dubbio questa domanda a causa della natura altamente personale e soggettiva del problema di cui ho cercato di parlare. Stavo pensando di riformulare la domanda, ma non riuscivo davvero a trovare un modo possibile per manifestare la domanda in modo più oggettivo, in modo che potesse essere oggetto di una discussione in cui le risposte possono essere sostenute con una sorta di prova o riferimento.

Per il bene di coloro che sono ancora interessati, sto cercando di fornire un riassunto della discussione emersa da questa domanda:

• un test di programmazione fuori sede pre-intervista di 4 ore non è normale ma
• molte persone hanno sottolineato che per alcune aziende intervisterai molto più a lungo di tutto questo insieme
• è una nostra decisione personale se eseguiamo un test o meno e possiamo valutarlo in base alle nostre circostanze e ai benefici percepiti di essere assunti per l'azienda
• tutte le società sono diverse, come lo sono le persone, e può essere perfettamente ragionevole per un'azienda impiegare un test fuori sede pre-colloquio più lungo, se è quello che si adatta alle loro esigenze o circostanze

Volevo che la mia domanda originale fosse su quanto ragionevole aspettarmi 4 ore da me e su come etico dare un problema in modo che la soluzione (non il codice, ma il design) possa essere eventualmente utilizzata per l'azienda. Come posso ora vedere, entrambe queste domande possono essere esplorate (nella migliore delle ipotesi) solo in una discussione nel forum, piuttosto che utilizzare uno strumento di comunità di tipo domanda-risposta come stackexchange.

Tuttavia, ho trovato tutte le tue risposte utili e grazie per la condivisione.

POSTO ORIGINALE

Sto intervistando per diverse posizioni e la maggior parte di esse include una fase di pre-screening in cui devo presentare un test di codifica prima che avvenga l'intervista telefonica o l'intervista in loco. Mi sono praticamente abituato a questa idea e trovo abbastanza ragionevole che le aziende si aspettino che io lo faccia in modo che possano controllare quale tipo di lavoro posso produrre da solo.

In generale, la mia esperienza è che questo tipo di esercizi di codifica sono per lo più piccoli compiti di programmazione. Fai un po 'di logica, magari implementa un piccolo algoritmo, apri un file e leggi / scrivi dati, cose del genere. Anche il compito più semplice può essere implementato con una buona separazione di logica, componenti testabili, ecc., Per vedere come il candidato sta codificando, in generale quanto è preparato per il tipo di lavoro che un'azienda vuole svolgere.

Di recente mi sono imbattuto in una società che mi ha inviato un test di codifica con una lunga pagina di descrizione del loro esercizio, chiedendomi di risolvere un problema di vita reale della loro attività (non voglio dire dettagli per proteggere l'azienda, ma il test era praticamente quello che fanno). Hanno descritto un sistema piuttosto complesso da implementare, includendo dati reali e alla fine hanno concluso che il test di codifica non dovrebbe richiedere più di 4 ore .

È ragionevole da un'azienda aspettarsi che passi 4 ore a lavorare nel loro compito fittizio nel mio tempo libero, anche prima che mi salutino? (il reclutatore mi ha inviato il test di codifica)

Non fraintendetemi, sono motivato a trovare un nuovo lavoro e nuove sfide, ma la maggior parte delle aziende si aspetta che io trascorra un massimo di 1-2 ore in un compito del genere e tali compiti sono sempre stati molto meno complicati.

Quello che mi è venuto in conclusione con questa azienda è che:

1) La mia motivazione non è buona e probabilmente stanno cercando qualcun altro

2) Non rispettano i loro futuri dipendenti che si aspettano un test di codifica così lungo da fare anche senza salutarli

3) Vogliono solo dare uno dei problemi su cui lavorano e vedere se c'è un giovane entusiasta che lo risolverebbe per loro gratuitamente (di nuovo, non fraintendermi, non sono un teorico della cospirazione ma ho sentito storie del genere ...)

Quanto ritieni ragionevole per un'azienda aspettarsi che i candidati trascorrano del tempo nei loro test di codifica fittizi senza parlare con loro? Qual è la tua esperienza in generale?

Consentitemi di schierarmi dalla parte dell'azienda per un momento, poiché le altre risposte non sono state così lontane. Sarebbe quasi impossibile costruire una base di codice utilizzabile da un conglomerato di invio di test di codifica di 4 ore da parte di persone le cui qualifiche sono completamente sconosciute. La creazione di una specifica sufficientemente dettagliata, il controllo delle risposte e l'integrazione con il resto del codice richiederebbero più di 4 ore. Per non parlare dei progetti software più utili a livello aziendale che richiedono migliaia di ore lavorative. Il pensiero di costruire un business dividendolo in incrementi di 4 ore con settimane di tempo di consegna ciascuno è francamente ridicolo.

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

Se valga la pena un test di 4 ore per te è una decisione personale. Mi è sempre stato insegnato a trattare la ricerca del 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 di 4 ore non è niente. Ho speso molto più tempo di quello in attività come ripassare lingue arrugginite, scrivere programmi di portfolio e personalizzare curriculum per posizioni specifiche.

D'altra parte, alcuni dei migliori lavoratori sono già impiegati in modo proficuo 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 discernere cosa significhi in merito all'atteggiamento dell'azienda nei confronti dei propri dipendenti, non credo che si possa davvero dire nulla in entrambi i modi, tranne che sono probabilmente stanchi di trattare con candidati non qualificati, a un livello che sono disposti a lanciare un po 'di buono con il cattivo.

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

1 ora è tipica per un test di programmazione. In passato il nostro test di programmazione era di 4 domande. Le prime 3 domande hanno richiesto 1/2 ora, l'ultima un'ora e mezza. Abbiamo anche fornito il test agli assunti esistenti all'interno dell'azienda per assicurarci di rispettare i tempi previsti e che il test fosse corretto e adeguato in modo concorde.

Le prime domande erano del tipo "Fizz Buzz" per eliminare le persone che non possono programmare. Divennero progressivamente più difficili. L'ultima domanda era un esercizio di risoluzione dei problemi. Generalmente abbiamo cercato di limitare la quantità di codice scritto a circa alcune centinaia di righe (in totale) e di non richiedere trucchi intelligenti. Abbiamo anche valutato le persone sulla gestione degli errori, sullo stile, sulla sintassi, sull'organizzazione, ecc. Le domande non riguardavano la nostra attività, ma piuttosto le competenze e la tecnologia in cui era scritta la piattaforma attuale.

In genere, i grandi candidati hanno terminato in meno tempo di quanto non fosse stato assegnato. A volte le persone hanno richiesto un tempo extra che ci è stato concesso a causa dello stress coinvolto nel fare un test, ma abbiamo limitato tutti a un certo limite. Il quiz era 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.

Un tempo discutevamo di incorporare la nostra base di codice (mondo reale) nel quiz, ma alla fine l'abbiamo scartata a causa delle preoccupazioni che il codice copiato / rubato / ecc. (Il nostro capo era un po 'paranoico). Alla fine siamo appena andati con un separato quiz.slnin una macchina di sviluppo isolata.

Alla fine, abbiamo scoperto che era difficile elaborare un test che fosse giusto, ma né troppo difficile né troppo facile. Abbiamo sempre chiesto ai nostri candidati il ​​quiz dopo averlo preso e raccolto il loro feedback per perfezionarlo per i futuri candidati.

Trovo che i test di codifica durante il colloquio siano comunque un sacco di tosh. Nessuno codifica nient'altro che la routine più semplice sotto pressione senza il solito ambiente e gli strumenti, quindi i risultati ottenuti sono nella migliore delle ipotesi dubbi.

Ciò che ho scoperto essere davvero buoni test delle capacità di un programmatore è di dargli un po 'di codice di progetto e chiedergli di rivederlo, questo funziona davvero bene se il codice ha diversi bug evidenti, diversi problemi di codice evidenti e alcune pratiche discutibili. Un buon programmatore ti dirà tutti e si impegnerà con te nella discussione del perché un codice non è "sbagliato" ma potrebbe essere fatto meglio per facilitare la manutenzione o giù di lì. Un programmatore scadente troverà un bug e si fermerà.

Qualsiasi lavoro che si aspetta che tu faccia un test che dura più di mezz'ora non ha trascorso nemmeno così tanto tempo a elaborare un buon test mirato che fornisca loro più di una vaga idea delle tue abilità. (la maggior parte delle aziende trova molto difficile passare il tempo a lavorare sulla configurazione pre-colloquio).

Se mi venisse dato un test come avresti avuto, scriverei la risposta in pseudo-codice. Ciò dovrebbe essere sufficiente per dimostrare la mia comprensione della codifica e del design, senza passare per l'intera fase di compilazione, costruzione e test che faresti per un normale progetto di lavoro.

Potresti non avere 4 ore, ma sicuramente qualcuno più interessato alla loro compagnia lo farà. Sono stato essenzialmente assunto sulla base di un compito simile che una società mi ha chiesto di svolgere in anticipo solo sul compito. Apparentemente, scrivere codice pulito e comprensibile, casi di test approfonditi e documentazione di progettazione comprensibile e coerente è un'anomalia. In realtà vedere qualcuno farlo fa esplodere la gente. Ad ogni modo, tutti quelli con cui ho parlato durante l'intervista mi hanno lodato per quello che ho fatto e mi è sembrato di non aver impressionato nessuno durante l'intervista perché avevano già deciso. Era semplicemente una mia questione non dare loro un motivo per dire di no facendo qualcosa di stupido.

Quindi, anche se sono d'accordo sul fatto che 4 ore sono un investimento di tempo abbastanza grande, significa anche che l'attività ha dimensioni sufficienti e che hai l'opportunità di mostrare davvero di cosa sei capace. Il tuo lavoro molto bene può parlare di volumi più che mai in una situazione di intervista reale.

Come nota a margine: ultimamente ho provato una cosa simile ma usando un problema molto più piccolo e non sono stato contento dei risultati. Piccoli problemi sono banali per dimostrare abbastanza delle conoscenze della persona. Inoltre, i problemi banali tendono a richiedere alla persona di riconoscere alcuni trucchi / dettagli necessari per risolvere il problema. Quindi, c'è un certo equilibrio tra occupare troppo tempo di una persona rispetto a non ottenere alcun beneficio reale perché il compito è banale. Penso che un compito di 4 ore sia probabilmente la giusta quantità di tempo per essere abbastanza complesso da consentire ai candidati di dimostrare le proprie capacità e non essere così lungo da non disturbare nessuno.

Ho fatto un test di codifica di 6 ore ad un certo punto. Quando ho fatto questo test avevo abbastanza fiducia che sarei stato assunto - mentre è diventato realtà, non ero così soddisfatto del follow-on.

Ovviamente avere un sacco di datori di lavoro ciascuno che richiede 4 ore è eccessivo. Ciò che la persona stava cercando nel test che ho fatto è stato il mio stile di programmazione: 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 risoluzione sia utile per te in ogni caso? Dopo tutto, potresti imparare qualcosa di prezioso.

Secondo, se riesci a "superare" il test significa che sei assunto? Se questo non è abbastanza ovvio, devi decidere se ci sono altri motivi per farlo comunque.

In terzo luogo, potrebbero stimare che ci vogliono "4 ore", ma potresti scoprirlo diversamente. Sanno davvero quanto dovrebbe durare? Molto probabilmente la risposta è no. Pertanto, continueranno a testare le persone entro le scadenze di 4 ore fino a quando non si renderanno conto che non si adatterà entro quattro ore. In tal caso stai perdendo tempo. L'approccio migliore quindi è quello di diventare aggressivo con il responsabile delle assunzioni e capire se dovresti fermarti a quattro ore e dare loro quello che hai, 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 può rivelare inesperienza.