Allontanandoci da loro.

GS (Goldman Sachs) una volta voleva da me un piccolo esempio di codice, che arrivò a un simulatore di libro ordini di scambio. Niente di troppo particolare, TRANNE che hanno specificato una copertura completa dei test e QUALITÀ DEL CODICE DI PRODUZIONE. Per qualcosa di così critico si riduce a una settimana di lavoro per testare ogni singolo caso limite, perché questo tipo di codice è estremamente critico.

Ho inviato un'offerta al reclutatore e gli ho detto che se non paga - nessun gioco.

Alcune aziende hanno idee stupide e mettono a disposizione test ridicoli. Il tuo esempio è simile: non c'è modo di farlo in 2 ore oltre a averlo già preparato. Oserei dire che questa è una frode borderline. Probabilmente è solo un segno di comica incompetenza.

Ricorda che questo è IT e IT è un mercato di venditori. Tantissimi posti di lavoro, niente specialisti. Comportati così. Non trattare con gli idioti. Rifiuto qualsiasi lavoro di codifica senza interviste PRECEDENTI, perché c'è un altro aspetto: tutti quei progetti "interessanti e stimolanti" sono sempre gli stessi stupidi sempre e comunque. Voglio prima sapere se voglio sprecare il MIO tempo, perché mi piace realizzare progetti che mi piacciono e i reclutatori non hanno assolutamente idea di cosa siano i progetti in questi giorni.

Ricorda, quando un'azienda ti sta intervistando, stai intervistando anche lei.

Usa test insensati come strumento di screening.

Se il TEST ti dà obiettivi e scadenze irragionevoli, indovina cosa puoi aspettarti dal lavoro .

Non prenderla sul personale, un brutto test non è un indicatore utile delle tue capacità. Se dicono che il tuo lavoro non era abbastanza buono, e tu sai che lo era, allora ovviamente non ti apprezzeranno neanche sul lavoro.

Di nuovo, non sei tu, sono loro.

Il senno di poi è 20/20. Questo è ciò che dovresti dire la prossima volta:

"Come regola generale, non svolgo i compiti a casa a meno che non parli prima con il cliente".

"Sei il cliente? No, allora mettimi in contatto con il responsabile delle assunzioni del cliente. E no, se lavori per le risorse umane (non sei il cliente a meno che tu non voglia che crei un'applicazione correlata alle risorse umane ). "

" Ok, cosa fa questa persona per la tua azienda? Sarà la persona a cui riferirò se la tua azienda mi assumesse? Ok, sì. Voglio parlare con quella persona. "

Quando finalmente parli con quella persona, allora dici qualcosa come:

" Ok, hai letto il mio curriculum? Pensi che possiamo saltare l'intero progetto da portare a casa? "

Supponendo che il responsabile delle assunzioni non voglia ancora saltarlo, allora potresti dire:

"Il problema è che sono già stato masterizzato in passato.

Per prima cosa, non so se dovrei semplicemente costruire il progetto da zero o semplicemente riutilizzare parte del codice che ho Una volta ho creato il progetto da zero in un paio d'ore, ma sono stato criticato per non avere un'app pronta per la produzione lication.

E un'altra volta, c'era una piccola mancata corrispondenza della versione e il loro IT non sapeva come modificare il file di configurazione per far funzionare il mio progetto. "

Ma qualunque cosa tu faccia, non dare questa spiegazione al reclutatore. Non spiegare e non giustificarti al reclutatore. È inutile cercare di spiegarti a un gatekeeper. Più informazioni fornisci a un gatekeeper, più è probabile che / lei userà queste informazioni contro di te, poiché per impostazione predefinita, un gatekeeper molto raramente ha il potere di fare concessioni, ma d'altra parte, il loro ruolo è più di cercare motivi per escludere i candidati.

Quindi, supponendo che tu abbia parlato con il vero decisore, il responsabile delle assunzioni a cui riferirai effettivamente, e supponendo che tu stia ricevendo buone vibrazioni da questa persona, potresti dire:

"Ok, sono disposto a fare il progetto da portare a casa, ma preferirei essere presente quando il mio progetto sarà installato e valutato.

Pensi che potremmo organizzare un momento in cui io potrebbe entrare con il mio codice e potremmo configurarlo insieme su una delle macchine del tuo sviluppatore? "

" Che ne dici di questo mercoledì prossimo? [...] Ci sarai? Uno degli sviluppatori esserci anche tu? "

Ma ancora una volta, fallo solo se stai ricevendo buone vibrazioni da questa persona. Fidati dei tuoi sentimenti viscerali. Se per qualsiasi motivo, ritieni che stiano utilizzando questo progetto da portare a casa come un modo pigro per selezionare molte dozzine di candidati. Oppure, se per qualsiasi motivo, senti che stanno cercando di estrarre un po 'di lavoro gratuito da te, in modo che possano metterlo in produzione, non accettare i compiti.

Lo stesso vale se ti presenti e non vogliono installare / rivedere il tuo progetto quando sei lì. Se vogliono che tu faccia i compiti, devono investire del tempo anche in te. È uno spettacolo di rispetto reciproco.

E se per qualsiasi motivo, non ottieni quel rispetto. Ad esempio, se hanno scambiato l'ingegnere, avresti dovuto incontrare una persona delle risorse umane all'ultimo minuto. Sii educato, ma fermo. Non dare loro il tuo progetto da portare a casa. Di 'loro che sarai felice di riprogrammare il colloquio e andartene.

Non mi piace fare riferimento ad altre risposte nelle mie risposte, poiché le risposte dovrebbero essere in grado di essere comprese da sole. Tuttavia, la risposta più votata si riduce sostanzialmente a "L'azienda è un branco di idioti. Scappa da loro". Questo non dà all'OP nulla da migliorare su se stesso e nulla da cambiare in futuro. Vedo aree che il PO potrebbe migliorare, indipendentemente dal fatto che l'azienda abbia fatto qualcosa di sbagliato o meno, che noi come rispondenti non conosciamo in realtà, poiché abbiamo ascoltato solo un lato della storia.

Come per quanto posso vedere, non hai comunicato prima di aver iniziato l'attività che credevi fermamente che non potesse essere eseguita in due ore.

Ecco la sequenza di eventi in cui ho guardalo:

1. Ti è stato chiesto di completare una sfida di codifica
2. Quando hai ricevuto la sfida, invece di comunicare le tue preoccupazioni, hai iniziato a scrivere codice
3. Hai affrettato la sfida, tagliando gli angoli
4. Hai presentato un progetto di bassa qualità che non ha funzionato senza troppe difficoltà
5. Dopo aver ricevuto il feedback, hai iniziato a giustificare il tuo lavoro

Ecco come immagino l'azienda l'ha visto:

1. Il candidato ha accettato tutte le condizioni della sfida
2. Il candidato ha presentato il progetto in tempo
3. Il progetto non ha funzionato
4. Il nostro sviluppatore principale ha detto che il cod La qualità era molto scarsa
5. Il candidato ha iniziato a trovare scuse per il proprio lavoro

Immagina di essere in una situazione lavorativa e il tuo manager / team leader ti chiede di completare un compito in una quantità di tempo irragionevole. Se non comunichi immediatamente che non puoi fare così tanto lavoro in così poco tempo, qualsiasi fallimento è colpa tua se accetti le condizioni iniziali. Tu sei l'esperto, non loro, e loro si affidano a te per comunicare con loro.

Non posso sottolineare quanto sia importante che entrambe le parti abbiano una visione comune della situazione. Hai avuto un divario di comprensione insormontabile perché hai perso l'opportunità di affrontarlo. La prossima volta che hai un problema, comunicalo subito o l'altra parte penserà che va tutto bene! Non comunicare informazioni importanti è mentire per omissione e qualsiasi forma di menzogna non è professionale. Il modo in cui reagiscono alle informazioni è una loro responsabilità, non tua.

Consiglio di leggere The Clean Coder: A Code of Conduct for Professional Programmers di Robert C. Martin (Uncle Bob) , in particolare:

• Capitolo 2: Dire di no
• Capitolo 3: Dire di sì
• Capitolo 10: Stima
• Capitolo 11: Pressione

Se l'azienda rifiuta la tua domanda perché hai chiesto feedback e chiarimenti prima di iniziare l'attività, non ti ha filtrato, tu hai filtrato loro come azienda per cui non vuoi lavorare.

Ho incontrato alcuni test intelligenti e alcuni stupidi (SQL / BI) e ne sono uscito attivamente da uno che era stupido, spiegando che quello che volevano era l'approccio sbagliato.

Ho anche visto test che erano in realtà tentativi di un progetto gratuito, con un "lavoro campione" che era essenzialmente una nuova soluzione. Ancora una volta, ho rifiutato di completarli.

Succede, lo dedico per sperimentare e andare avanti. Pianifico sempre i colloqui fuori orario, quindi non c'è nessuna vera perdita da parte mia.

Dici loro esattamente quello che diresti al tuo capo se dovessi affrontare quel compito.

O non sanno cosa stanno facendo, imparerai molto sull'azienda, o vogliono vedere che non sprechi tempo (denaro dell'azienda) facendo le cose male invece di parlando con la persona senza le conoscenze tecniche per giudicare questo.

Ci sono due risultati, passi a pieni voti per aver fatto la cosa giusta, o hai schivato il proiettile e non devi tornare in due mesi dicendoci come il tuo capo richiede cose impossibili; )

Ecco il mio approccio:

1. Comunica con il tuo contatto in azienda che non ritieni possibile nel tempo e cosa intendi fare effettivamente.

2. Se c'è tempo per aspettare una risposta, aspetta; in caso contrario, fai quello che volevi e documenta le tue scelte in dettaglio

3. Idealmente fai uno schizzo dove porteresti il ​​resto.

ol >

Nota che pochissimi intervistatori calibrano e verificano che un'attività richieda 2 ore. Se vuoi davvero il lavoro, portalo a un certo livello di completezza in un determinato periodo di tempo.

Come hai scoperto, la qualità di solito prevale sull'adattamento al tempo, a meno che non abbiano meccanismi rigorosi per garantire che tutti i candidati si adattano nel tempo.

È della mia opinione esperta che nessuno avrebbe mai raccontato che questo fosse qualcosa come due ore di lavoro, se fatto correttamente. Vorrei dedicare qualche giorno almeno per ottenere l'architettura giusta, ecc.

Chiedo scusa, ma ti manca il punto.

Pensaci da la prospettiva della squadra. Vogliono qualcuno che abbia familiarità con ASP.NET, MVC, REST, parlando con un database e la funzionalità moderatamente avanzata di una casella di testo a completamento automatico.

Potrei I ottenere queste cose fatto? Sì, alla fine. Dopo tutto, ho sentito di tutte queste cose, quindi potrei andare avanti ed elencarle nel mio curriculum. Un esperto come te sarà in grado di collegare un sistema funzionante entro il limite di tempo perché ti occupi di questo stack tutto il tempo, ma dovrei passare ore a scavare nei manuali.

Un curriculum è un pezzo di carta in cui elencare i punti elenco è banale. Una cattiva assunzione è peggio di una mancata assunzione. Presumo che tu non abbia ricevuto una raccomandazione personale da qualcuno del team, quindi il responsabile delle assunzioni sta cercando una dimostrazione di competenza. È vero, un vero sistema pronto per la produzione richiederebbe molto più tempo, ma il test non richiedeva il pronto per la produzione perché chiedeva cosa avresti fatto con più tempo. Il successo del test dimostra che sei fluente con tutti i livelli e, cosa più importante, sai come stabilire le priorità . Fallo funzionare e poi rendilo carino!

Un test di due ore non è il momento per l'astronautica dell'architettura.

Inoltre, quasi certamente non lo sei il primo candidato a vedere questo test. Il team ha utilizzato e forse ottimizzato il filtro più volte e almeno uno sviluppatore è riuscito a farlo. Alzare il naso - come è diventato molto di moda negli ultimi anni - in giusta indignazione o "istruirli" sul perché è una brutta prova, a loro avviso, ti metterà nella categoria dei bozo. Uff! penseranno, un altro procrastinatore o primadonna con cui non abbiamo a che fare.

Come gestirlo? Guardalo dal punto di vista del tuo potenziale cliente. Piuttosto che liquidare come assurdo, concedi il beneficio del dubbio. Per un test di due ore annota brevemente le tue supposizioni, fai in modo che la giornata di sole funzioni per la semplice demo e nel tempo rimanente documenta come renderesti un vero sistema robusto.

Questo puzza di falsi test per mappare la tua personalità, soprattutto come gestisci eventi assurdi e stressanti. Sei il tipo che

1. si infastidisce e se ne va o
2. quello che cerca silenziosamente di risolverlo o tu
3. provi davvero a discutere e spiega con la direzione quali sono le cose irragionevoli o
4. sei così stressato che non sai cosa fare o
5. sei tu quello che finge di provare a risolverlo ma dai risultati altrettanto assurdi perché questo è esattamente ciò che si meriterebbe chiunque abbia un simile compito?

Questa risposta non indica se questi tipi di test sono una buona cosa o meno (o se li condono), ma si concentra sulla domanda specifica.

Come posso decidere se dovrei affrontare test tecnici che considero assurdi (ad esempio un compito irragionevolmente grande con un limite di tempo breve) in futuro?

Come fareste nel mondo reale:

• Comunica quanto tempo impiegherebbe ragionevolmente l'attività.
• Prepara il tuo piano di cosa fare nel tempo dato (ad esempio, fai di meno o fallo peggio, o entrambe le cose).
• Fai tutto quello che puoi, al minimo livello di qualità che puoi sopportare. Concentrati sull'ottenere una soluzione funzionante prima di una soluzione completa.
• Documenta chiaramente dove tagli gli angoli, quali sono le implicazioni e i TODO risultanti.

Tutto questo sarebbe aiutami molto, come datore di lavoro o cliente, a giudicare se voglio lavorare con te.

A seconda della struttura gestionale del datore di lavoro / cliente, il ragazzo che ti dà lavoro (cioè il tuo capo / cliente diretto) potrebbe benissimo trovarsi in una posizione in cui non può influenzare il tipo di lavoro che ottieni. La gestione delle matrici esiste ... in questo caso preferirei avere qualcuno in grado di gestire tali situazioni con grazia rispetto a un eroe che fornisce il codice più grande di tutti i tempi, ma non è in grado di comunicare sui limiti di tempo / qualità.

La misura esatta se scegliere una maggiore qualità o più contenuti dipende. Ad esempio, nel tuo caso, probabilmente sarai maggiormente interessato a loro visto che puoi fornire un lavoro di qualità. Quindi potresti tagliare alcune funzionalità (usando qualche segnaposto ecc.), Ma mantieni alta la qualità del tuo codice. Allo stesso modo, se il lavoro fosse, diciamo, relativo alla sicurezza, faresti lo stesso. Ma se è una prova del concetto completamente acritica di qualcosa, allora si potrebbe virare maggiormente nella direzione opposta. Documenta tutto questo (succintamente) e sei sulla buona strada.

PS: mi piace evitare giudizi "pazzi o cattivi". Cioè, non dovresti preoccuparti se il cliente è semplicemente pazzo o se vuole prenderti (cioè, fai lavorare gratuitamente), solo a giudicare dalle dimensioni del compito. La quantità reale che conta per te è il tuo tempo e quello è stato risolto. Finché stai bene investendo le due ore in un potenziale nuovo cliente, non dovrebbe importare se il compito è fatto facilmente, o un lavoro ad alta pressione, o solo due ore di chiacchiere nel loro ufficio.

Come altre risposte hanno almeno suggerito, la motivazione alla base del test potrebbe essere ragionevole, in particolare se il test:

1. è ben adattato al effettivi requisiti di lavoro;
2. Riduce al minimo gli elementi meno importanti;
3. Chiaramente non è un tentativo di ottenere "lavoro gratuito"; e possibilmente
4. Viene fornito con almeno alcuni suggerimenti su ciò che i revisori stanno "cercando".

In un lavoro precedente, ho progettato e amministrato un discutibilmente "assurdo "test di programmazione. Il lavoro era sempre un lavoro di sviluppatore di ASP.NET/SQL Server full-stack di livello senior e l'attività prevedeva la creazione di un'applicazione Web di base che comprendeva una pagina e due o tre semplici procedure memorizzate. Il candidato ha eseguito il test in loco utilizzando strumenti standard:

1. Visual Studio (versione a scelta del candidato nelle ultime due o tre versioni);
2. SQL Server Management Studio; e
3. Un browser web, non solo per i test ma anche per la ricerca di documentazione, risorse, ecc., Che ho detto specificamente ai candidati che potevano fare.

Ho fornito al candidato una soluzione "shell" di base (in ciascuna delle versioni consentite di Visual Studio) e ho creato il database e le tabelle in anticipo.

Ho fornito al candidato una descrizione di una pagina e ho detto il candidato che sarei tornato in dieci minuti per rispondere a qualsiasi domanda in merito, dopo di che avrebbe avuto un'ora per completare l'attività.

Quando sono tornato dopo dieci minuti, dopo aver risposto a qualsiasi domanda, ho ha detto al candidato che se non fosse stata sicura di poter completare ogni parte del compito entro un'ora, avrebbe potuto considerare di concentrarsi su una parte del compito che avrebbe potuto completare e iniziare a correre nel tempo assegnato. Ho anche detto che se avesse avuto ulteriori domande durante l'ora, avrebbe potuto trovarmi a due cubicoli di distanza e chiedere.

Poiché ho scritto il test, ho potuto completarlo dall'inizio alla fine in circa quarantacinque minuti. Non mi aspettavo assolutamente che i candidati completassero l'intero test in un'ora. Il limite di tempo "assurdo" era in vigore per tre ragioni:

1. Volevamo vedere se il candidato aveva una comprensione anche solo a metà dei requisiti del lavoro. Ricorda, questo era per una posizione di alto livello. (Ben oltre la metà delle volte, la risposta è stata "no".
2. Il candidato dovrebbe essere in grado di analizzare i requisiti di base e suddividerli in attività gestibili e distinte.
3. Estensione del test l'ultima ora avrebbe richiesto più tempo al candidato senza darci molte informazioni aggiuntive.

Alla fine dell'ora, ho chiesto alla candidata di mostrarmi cosa aveva, se aveva una parte di una soluzione in corso da dimostrare, ecc. Generalmente impiegheremo circa cinque minuti per esaminare il lavoro a questo punto, quindi il candidato avrebbe un colloquio individuale con il manager. Durante quell'intervista, il team di sviluppo avrebbe esaminato tutto ciò che il candidato aveva presentato. davvero attendevamo con impazienza questo compito perché non è mai stato noioso.

Se il candidato aveva una soluzione in corso che gestiva la parte prevista del compito complessivo, il candidato quasi certamente lo superava fase del colloquio. Anche se la soluzione non è stata ancora eseguita, se potessimo vedere progressi sostanziali e prove della competenza del candidato, in genere considereremmo ancora il candidato. Abbiamo sempre controllato la cronologia del browser del candidato per vedere a quali risorse ha avuto accesso.

I motivi per cui i candidati effettivi non sono riusciti sono stati inclusi:

1. Non produrre letteralmente nulla dopo l'ora intera. Mi dispiace dire che questa situazione si è verificata più volte.
2. Plagiare il codice dal lavoro corrente del candidato e tentare (e fallire) di modificarlo per soddisfare i requisiti del test. Quando lo sospettavamo, la cronologia del browser lo rivelava.
3. Impossibilità di formare una stringa di connessione per connettere l'applicazione al database. Questo potrebbe sembrare un po 'ingiusto, ma ricorda che stavamo cercando candidati di livello senior, inclusa esperienza di sviluppo di SQL Server di livello senior. Certamente non ci aspettavamo che il candidato ricordasse come costruire una stringa di connessione, ma ci aspettavamo che il candidato fosse in grado di cercarla rapidamente. Anche ConnectionStringBuilder sarebbe andato benissimo, ma nessuno lo ha mai usato. Il primo esempio da https://www.connectionstrings.com/sql-server/ avrebbe funzionato perfettamente.

C'era un'altra parte dell'intervista con il manager e il team di sviluppo insieme e avremmo posto domande sulla soluzione del candidato, su come avrebbe affrontato il resto del progetto, ecc.

In sintesi, consiglio di considerare le motivazioni del datore di lavoro per un test "assurdo" prima di ignorarlo.

Non c'è assolutamente niente di sbagliato in questo folle test tecnico di 2 ore. Tutti gli altri candidati dovrebbero fare lo stesso test, quindi la tua probabilità che ti venga offerto il lavoro non è diversa da un semplice esercizio di programmazione per principianti. Non c'erano pregiudizi; ti è stato chiesto di farlo semplicemente perché avevi fatto domanda per la posizione.

Sei il venditore nel mercato del lavoro ed è tua responsabilità accogliere gli acquirenti il ​​più possibile. Hai poco potere contrattuale se non per un'altra posizione. Certamente, un test di programmazione che tutti i candidati dovrebbero fare non è irragionevole, indipendentemente dal fatto che tu possa effettivamente competere o meno. Se sei altamente qualificato per il lavoro, ma non sei in grado di completare il test, anche gli altri candidati non saranno in grado di completarlo. Allora qual è il problema?

Fai del tuo meglio. Arrabbiato per non essere stato offerto per la posizione? L'azienda deve assumere qualcuno, quindi qualcun altro potrebbe aver fatto un lavoro migliore. Il punto per un test di programmazione impossibile è trovare il candidato migliore . Se il miglior candidato completa l'esercizio è irrilevante.

come posso decidere se devo sostenere test tecnici che considero assurdi

Dovresti sentirti a tuo agio per qualsiasi prova tecnica se pensi di avere le competenze per il lavoro e tutti gli altri candidati dovrebbero farlo. Non fare mai un test folle se credi che si tratti di un tentativo di lavori di programmazione gratuiti o / e ti viene dato a causa di pregiudizi (ad esempio razzismo).

PS: non ho mai detto che OP non è " abbastanza buono ". @TessellatingHeckler