Come gestire test tecnici di colloquio che sono assurdi (ad esempio un compito irragionevolmente grande con un limite di tempo breve)?

Allontanandosi da loro.

GS (Goldman Sachs) una volta ha voluto un piccolo campione di codice da me, che è sceso fino a un simulatore di libro degli ordini di scambio. Niente di troppo particolare, Fatta eccezione per la copertura completa del test e la QUALITA’ 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 mandato al reclutatore un'offerta e gli ho detto che se non pagano - non si gioca.

Alcune aziende hanno idee stupide e mettono in piedi test ridicoli. Il tuo esempio è simile - non c'è un modo maledetto per farlo in 2 ore, se non l'hai già preparato. Oserei dire che questa è una frode al limite. Probabilmente è solo un segno di comica incompetenza.

Ricordate che questo è l'IT - e l'IT è un mercato di venditori. Tonnellate di posti di lavoro - niente specialisti. Comportatevi in questo modo. Non trattare con gli idioti. Rifiuto qualsiasi lavoro di codifica senza interviste PRIOR, perché c'è un altro lato: Tutti quei progetti “interessanti e impegnativi” sono comunque sempre gli stessi stupidi. Voglio sapere prima di tutto se voglio sprecare il mio tempo, perché mi piace fare progetti che mi piacciono, e i reclutatori non hanno la minima idea di cosa siano i progetti di questi tempi.

Ricordate che quando un'azienda vi fa un colloquio, lo fate anche voi.

Usate i test inane come strumento di screening.

Se il TEST vi dà obiettivi e scadenze irragionevoli, indovinate cosa potete aspettarvi sul lavoro.

Non prendetela sul personale, un cattivo test non è una misura utile delle vostre capacità. Se dicono che il tuo lavoro non è stato abbastanza buono, e tu sai che lo è stato, allora ovviamente non ti apprezzeranno nemmeno sul lavoro.

Anche in questo caso, non sei tu, sono loro.

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

“Come regola generale, non faccio nessun compito a casa se prima non parlo con il cliente”.

“Sei tu il cliente? No, allora collegatemi 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 io costruisca un'applicazione relativa alle Risorse Umane)”

“Ok, cosa fa questa persona per la tua azienda? Sarà la persona a cui farò rapporto nel caso in cui la vostra azienda mi assumesse? Ok, sì. Voglio parlare con quella persona”

Una volta che finalmente parli con quella persona, poi dici qualcosa del tipo:

“Ok, hai letto il mio curriculum? Pensi che possiamo saltare l'intero progetto take-home?”

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

“Il problema è che sono già stato bruciato in passato.

Per prima cosa, non so se dovrei costruire il progetto da zero, o solo riutilizzare un po’ del codice che ho in giro? Una volta, ho costruito il progetto da zero in un paio d'ore, ma sono stato criticato per non avere un'applicazione pronta per la produzione.

E un'altra volta, c'è stato un piccolo disallineamento di versione, e il loro IT non sapeva come modificare il file di configurazione per far funzionare il mio progetto”.

Ma qualsiasi cosa tu faccia, non dare questa spiegazione al reclutatore. Non dare spiegazioni e non giustificarti con il reclutatore. È inutile cercare di spiegarsi con un guardiano. Più informazioni si danno a un gatekeeper, più è probabile che egli le usi contro di te, dato che, di norma, un gatekeeper molto raramente ha il potere di fare concessioni, ma d'altra parte, il suo ruolo è più che altro quello di cercare delle ragioni per escludere i candidati. Quindi, supponendo che tu abbia parlato con il vero responsabile delle decisioni, il responsabile delle assunzioni a cui farai effettivamente rapporto, e supponendo che tu stia ricevendo buone vibrazioni da questa persona, potresti dire:

“Ok, sono disposto a fare il progetto take-home, ma preferirei essere lì quando il mio progetto sarà installato e valutato.

Pensi che potremmo stabilire un momento in cui potrei venire con il mio codice e potremmo configurarlo insieme su una delle macchine del tuo sviluppatore? ”

“Che ne dici di questo mercoledì prossimo? […] Ci sarai? Ci sarà anche uno degli sviluppatori? ”

Ma, ancora una volta, fatelo solo se ricevete buone vibrazioni da questa persona. Fidatevi del vostro istinto. Se per qualche ragione, senti che stanno usando questo progetto take-home come un modo pigro per esaminare molte dozzine di candidati. O se per qualsiasi motivo, senti che stanno cercando di estrarre del lavoro gratuito da te, in modo che possano metterlo in produzione, non sono d'accordo con i compiti a casa.

Lo stesso vale se ti presenti e non vogliono installare/riesaminare il tuo progetto quando sei lì. Se vogliono che facciate i loro compiti, devono investire un po’ di tempo anche su di voi. È una dimostrazione di rispetto reciproco.

E se per qualsiasi motivo, non otterrete quel rispetto. Ad esempio, se hanno scambiato l'ingegnere, avresti dovuto incontrare una persona delle Risorse Umane all'ultimo minuto. Siate educati, ma fermi. Non date loro il vostro progetto da portare a casa. Dite loro che sarete lieti di riprogrammare il colloquio e di andarvene.

Non mi piace fare riferimento ad altre risposte nelle mie risposte, perché le risposte dovrebbero poter essere comprese da sole. Tuttavia, la risposta più votata si riduce fondamentalmente a “L'azienda è un branco di idioti”. Scappa da loro". Questo non dà all'OP nulla da migliorare di se stessi, e nulla da cambiare in futuro. Vedo aree che l'OP potrebbe migliorare, indipendentemente dal fatto che l'azienda abbia fatto qualcosa di sbagliato o meno, cosa che noi, in quanto rispondenti, in realtà non sappiamo, dato che abbiamo sentito solo una parte della storia.

Per quanto posso vedere, non avete comunicato prima di iniziare il compito che credevate fermamente che non si potesse fare in due ore.

Ecco la sequenza degli eventi come la vedo io:

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

Ecco come immagino l'abbia vista l'azienda:

1. Il candidato ha accettato tutte le condizioni della sfida
2. Il candidato ha presentato il progetto nei tempi previsti
3. Il progetto non ha funzionato
4. Il nostro lead developer ha detto che il codice era di qualità molto scadente
5. Il candidato ha iniziato a trovare delle scuse per il suo lavoro

Immaginate di essere in una situazione di lavoro e il vostro manager/team leader vi chiede di completare un compito in un lasso di tempo irragionevole. Se non comunicate immediatamente che non siete in grado di svolgere tutto quel lavoro in quel poco tempo, allora qualsiasi insuccesso è colpa vostra per aver accettato le condizioni iniziali. Tu_ sei l'esperto, non loro, e loro contano su di te per comunicare con loro.

Non riesco a sottolineare quanto sia importante che entrambe le parti abbiano una visione comune della situazione. Lei ha avuto una lacuna insormontabile di comprensione perché ha perso l'opportunità di affrontarla. La prossima volta che avete un problema, comunicatelo subito o l'altra parte penserà che va tutto bene! Non comunicare informazioni importanti è mentire per omissione, e qualsiasi forma di menzogna non è professionale. Come reagiscono alle informazioni è una loro responsabilità, non vostra.

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

• Capitolo 2: Dire No
• Capitolo 3: Dire Sì
• Capitolo 10: Stima
• Capitolo 11: Pressione

Se l'azienda rifiuta la vostra richiesta perché avete chiesto un feedback e un chiarimento prima di iniziare il lavoro, non vi hanno filtrato, li avete filtrati_ come azienda per cui non volete lavorare.

Ho incontrato alcuni test intelligenti e alcuni test stupidi (SQL/BI) e 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 libero, con “lavoro campione” che era essenzialmente una nuova soluzione. Anche in questo caso, ho rifiutato di completarli.

Succede, lo metto in evidenza per fare esperienza e andare avanti. Pianifico sempre i colloqui dopo l'orario di lavoro, quindi non ci sono perdite reali da parte mia.

Beh, dite loro esattamente quello che direste al vostro capo se vi trovaste di fronte a questo compito.

O non sanno quello che stanno facendo, allora imparereste molto sull'azienda, oppure vogliono vedere che non sprechiate tempo (denaro dell'azienda) facendo le cose male invece di parlare con la persona senza le conoscenze tecniche per giudicare questo.

Ci sono due risultati, si passa a pieni voti per aver fatto la cosa giusta, oppure si evita di schivare il proiettile e non si deve tornare indietro in due mesi dicendoci come il tuo capo pretende cose impossibili ;)

Ecco il mio approccio:

1. Comunicate con il vostro contatto presso l'azienda che non pensate sia possibile nel tempo, e che cosa pensate di fare realmente.

2. 1. Se c'è tempo per aspettare una risposta, aspettate; in caso contrario, fate quello che volevate, e documentate le vostre scelte in dettaglio
3. 1. Idealmente, abbozzate il punto in cui volete portare il resto.

Si noti che molti pochi intervistatori calibrano e testano effettivamente che un compito richiede 2 ore. Se volete davvero il lavoro, portatelo a un certo livello di completezza in un determinato lasso di tempo.

Come avete scoperto, la qualità di solito batte l'adattamento al tempo, a meno che non abbiano meccanismi rigorosi per garantire che tutti i candidati si adattino al tempo.

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

1. si arrabbia e se ne va o
2. quello che cerca silenziosamente di risolvere il problema o
3. cerca di discutere e spiegare con il management quali sono le cose irragionevoli o
4. si stressa così tanto da non sapere cosa fare o
5. sei tu quello che finge di cercare di risolvere il problema ma che restituisce risultati altrettanto assurdi e inventati perché è esattamente quello che chiunque se ne venga fuori con un compito del genere si meriterebbe?

Secondo la mia opinione di esperto, nessuno avrebbe mai detto che si trattasse di due ore di lavoro, se fatto in modo corretto. Io ci metterei almeno qualche giorno per mettere a posto l'architettura ecc.

Chiedo scusa, ma non è questo il punto.

Pensaci dal punto di vista del team. Vogliono qualcuno che abbia familiarità con tutti gli ASP.NET, MVC, REST, che parli con un database, e la funzionalità moderatamente avanzata di una casella di testo autocompleta.

Potrebbe I fare queste cose? Sì, alla fine. Dopotutto, ho sentito di tutte queste cose, quindi potrei andare avanti ed elencarle nel mio curriculum. Un esperto come lei sarà in grado di collegare un sistema funzionante sotto il limite di tempo perché si occupa di questa pila per tutto il tempo, ma io dovrei passare ore a scavare nei manuali.

Un curriculum è un pezzo di carta in cui elencare i punti chiave è banale. Una cattiva assunzione è peggio di una mancata assunzione. Suppongo che lei non abbia avuto una raccomandazione personale da qualcuno del team, quindi il responsabile delle assunzioni è alla ricerca di una dimostrazione di competenza. È vero, un vero sistema pronto per la produzione richiederebbe molto più tempo, ma il test non ha chiesto di essere pronto per la produzione perché chiedeva cosa avreste fatto con più tempo. Il successo del test dimostra che si è fluenti con tutti i livelli e soprattutto che si sa come dare priorità. Fatelo funzionare e allora fatelo bello!

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

Inoltre, quasi certamente non siete i primi candidati a vedere questo test. Il team ha usato e forse modificato il filtro più volte, e almeno uno sviluppatore è riuscito a passare. Alzare il naso - come è diventato di moda negli ultimi anni - con giusta indignazione o “istruirli” sul perché è un cattivo test vi metterà, a loro avviso, nella categoria dei bozzoli. Penseranno, un altro procrastinatore o primadonna con cui non abbiamo a che fare.

Come gestirlo? Guardatela dal punto di vista del vostro potenziale cliente. Piuttosto che licenziare come assurdo, date il beneficio del dubbio. Per un test di due ore annotate brevemente le vostre supposizioni, fate in modo che le giornate di sole per la semplice dimostrazione funzionino, e nel tempo rimanente documentate come potreste rendere robusto un sistema reale.

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

1. è ben adattato ai requisiti del lavoro effettivo;
2. è ben adattato ai requisiti del lavoro effettivo;
3. è stato valutato in base alle esigenze del lavoro _effettivo;
4. è stato valutato in base ai requisiti del lavoro. 2. riduce al minimo gli elementi meno importanti;
5. 3. Non è chiaramente un tentativo di ottenere un “lavoro gratuito”; ed eventualmente
6. Viene fornito con almeno alcuni suggerimenti su ciò che i revisori stanno “cercando”.

In un lavoro precedente, ho progettato e amministrato un test di programmazione probabilmente “assurdo”. Si trattava sempre di un lavoro da sviluppatore di livello senior di ASP.NET/SQL Server, e il compito consisteva nel creare un'applicazione web molto semplice 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 all'interno delle due o tre versioni precedenti);
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 specificamente detto ai candidati che erano autorizzati a fare.

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

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

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

Poiché ho scritto il test, potrei 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 motivi:

1. Volevamo vedere se il candidato aveva anche solo una mezza conoscenza dei requisiti del lavoro. Ricordate che si trattava di una posizione di alto livello. (Ben oltre la metà del tempo, la risposta è stata “no”)
2. 2. Il candidato dovrebbe essere in grado di analizzare i requisiti di base e di suddividerli in compiti gestibili e discreti. Estendere il test oltre un'ora richiederebbe più tempo del candidato senza fornire molte, se non molte, informazioni aggiuntive.

Alla fine dell'ora, ho chiesto al candidato di mostrarmi cosa aveva, se aveva qualche parte di una soluzione in corso da dimostrare, ecc. A questo punto, in genere, ci volevano circa cinque minuti per esaminare il lavoro, poi il candidato avrebbe avuto un colloquio uno contro uno con il manager. Durante il colloquio, il team di sviluppo esaminava tutto ciò che il candidato aveva presentato. Se il candidato aveva una soluzione in corsa che si occupava della parte di lavoro che gli spettava, quasi certamente superava questa fase del colloquio. Anche se la soluzione non si fosse ancora candidata, se potessimo vedere progressi sostanziali e prove della competenza del candidato, in genere lo considereremmo comunque. Abbiamo sempre controllato la cronologia del browser del candidato per vedere a quali risorse ha avuto accesso.

Le ragioni per cui i candidati effettivi non hanno avuto successo includono:

1. 2. Letteralmente non ha prodotto nulla dopo un'ora intera. Mi dispiace dire che questa situazione si è verificata più volte.
2. 2. Plagio del codice dell'attuale lavoro del candidato e tentativo (e non riuscita) di modificarlo per soddisfare i requisiti della prova. Quando lo sospettavamo, la cronologia del browser lo rivelava.
3. 3. Impossibilità di formare una stringa di connessione per collegare l'applicazione al database. Questo potrebbe sembrare un po’ ingiusto, ma ricordate che stavamo cercando candidati di livello senior, compresa l'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 velocemente. ConnectionStringBuilder sarebbe stato assolutamente perfetto, ma nessuno l'ha mai usata. Il primissimo esempio di https://www.connectionstrings.com/sql-server/ avrebbe funzionato benissimo.

C'è stata un'altra parte del colloquio con il manager e il team di sviluppo insieme, e ci siamo posti domande sulla soluzione del candidato, su come si sarebbe avvicinato al resto del progetto, ecc.

In sintesi, consiglio di considerare le motivazioni del datore di lavoro per un test “assurdo” prima di licenziarlo a priori.

La presente risposta non stabilisce se questo tipo di test sia una buona cosa o meno (o se io li condoni), ma si concentra sulla domanda specifica._

Come posso decidere se devo affrontare test tecnici che considero assurdi (e. Come faresti nel mondo reale:

• Comunica quanto tempo ci vorrebbe ragionevolmente per svolgere il compito.
• Spiega il tuo piano su cosa fare nel tempo stabilito (ad es, fare meno, o farlo peggio, o entrambe le cose).
• Fate tutto quello che potete, al minor livello di qualità possibile. Concentratevi sull'ottenere una soluzione di lavoro prima di una soluzione completa.
• Documentate chiaramente dove avete preso una scorciatoia, quali sono le implicazioni e i TODO risultanti.

Tutto questo mi aiuterebbe molto, come datore di lavoro o cliente, a giudicare se voglio lavorare con voi.

A seconda della struttura di gestione del datore di lavoro/cliente, il ragazzo che vi impiega (cioè il vostro diretto capo/cliente) potrebbe benissimo essere in una posizione in cui non può influenzare il tipo di lavoro che otterrete. La gestione delle matrici esiste… in questo caso preferirei avere qualcuno che sappia gestire queste situazioni con grazia piuttosto che un eroe che consegna il più grande codice di tutti i tempi, ma che non sia in grado di comunicare sui limiti di tempo/qualità.

La misura esatta della scelta tra più qualità o più contenuti dipende. Ad esempio, nel vostro caso, sarete probabilmente più interessati a loro, visto che potete fornire un lavoro di qualità. Quindi potreste tagliare alcune caratteristiche (usando qualche segnaposto, ecc.), ma mantenere alta la qualità del vostro codice. Allo stesso modo, se il lavoro fosse, diciamo, legato alla sicurezza, fareste lo stesso. Ma se si tratta di una prova del tutto acritica del concetto di qualcosa, allora si potrebbe andare nella direzione opposta. Documentate tutto questo (sinteticamente), e siete sulla buona strada.

PS: Mi piace evitare giudizi “pazzi o cattivi”. Cioè, non dovrebbe importarvi se il cliente è solo pazzo, o se è solo per ottenere voi (cioè, farvi svolgere il lavoro gratuitamente), solo a giudicare dalle dimensioni del compito. La quantità reale_ che vi interessa è il vostro tempo, e quello è stato fissato. Finché vi va bene investire le due ore in un potenziale nuovo cliente, non dovrebbe importare se il compito è facile da svolgere, o un lavoro ad alta pressione, o solo due ore di chiacchiere in ufficio.

Non c'è assolutamente nulla di sbagliato con le 2 ore di folle prova tecnica. **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'è stato alcun pregiudizio; le è stato chiesto di farlo semplicemente perché si era candidato per il posto.

Lei è il venditore nel mercato del lavoro, ed è sua responsabilità accogliere il più possibile gli acquirenti. Lei ha poco potere contrattuale se non quello di accettare 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 lei è altamente qualificato per il lavoro, ma non è in grado di completare il test, anche altri candidati non sarebbero in grado di completarlo. Allora qual è il problema?

Fate del vostro meglio. Sei arrabbiato perché non ti è stato offerto il posto? L'azienda deve assumere qualcuno, quindi qualcun altro avrebbe potuto fare un lavoro migliore. Il punto per un test di programmazione impossibile è trovare il migliore candidato che si esibisce. Se il candidato migliore completa l'esercizio è irrilevante.

come posso decidere se devo sostenere test tecnici che considero assurdi

Dovresti sentirti a tuo agio per qualsiasi test tecnico se pensi di avere le capacità per il lavoro e tutti gli altri candidati dovrebbero farlo. Non fate mai un test assurdo se credete che sia un tentativo di programmazione gratuita di posti di lavoro o/e vi è stato dato a causa di pregiudizi (ad es. razzismo).

PS: Non ho mai parlato di OP non è “buono abbastanza”. @TessellatingHeckler