coding test

[Booze]

Di recente ho fatto un test preliminare su test gorilla.

Vi racconto molto brevemente la follia che ho trovato, ditemi se sono io o cosa.

Allora si parte con un tot di domande per principianti su java e spring e ok.

Poi si passa sulla seconda sezione di domande. Qui non capisco che il timer e' per tutta la sezione invece che per singola domanda, colpa mia dovevo leggere meglio e quindi riesco a farne la meta'.
Il tenore delle domanda, pero', e' quello che mi lascia interdetto: il test si fa fullscreen e con webcam puntata. Non e' concesso googlare o cercare da nessuna parte. Le domande sono mnemoniche su Spring, tipo se per abilitare Aop l'annotazione si chiama EnalbeAspect o EnableAspectJSarcazzo. Poi domande su JdbcTemplate tipo se il secondo parametro per mappare una entity e' entitymapper o qualcosaltro.

E vabbeh, fortunato chi ha di recente usato JDBCTemplate che se le ricordera'.

Fin qui e' ridicolo, ma arriviamo alla chicca finale. Mi si presenta un codice da sistemare che lavora con stringhe, tutto su un metodo solo. Richiede alcune decina di righe, forse 100, non proprio fizz buzz.

Da programmatore quasi saggio, io avrei cominciato a splittare il codice e mettere i metodi sotto test per vedere dove fallano, come consiglia di fare Michael Feathers nel suo libro. Poi li avrei fatti andare e magari fatto un po' di refactory per presentarli decentemente.

Beh, finestra su cui avrei dovuto lavorare era minuscola, quindi di riorganizzare li codice mi e' subito passata la voglia.
E non c'era possibilta' di scrivere test ovviamente.

Perche' non mi lasciano usare l'ambiente di sviluppo che voglio??

Ma soprattutto, cosa diavolo stanno assumendo? Gente che programma su finestrelle senza internet?

[Mirko]

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.
Vi racconto molto brevemente la follia che ho trovato, ditemi se sono io o cosa.
Allora si parte con un tot di domande per principianti su java e spring e ok.
Poi si passa sulla seconda sezione di domande. Qui non capisco che il timer e' per tutta la sezione invece che per singola domanda, colpa mia dovevo leggere meglio e quindi riesco a farne la meta'.
Il tenore delle domanda, pero', e' quello che mi lascia interdetto: il test si fa fullscreen e con webcam puntata. Non e' concesso googlare o cercare da nessuna parte. Le domande sono mnemoniche su Spring, tipo se per abilitare Aop l'annotazione si chiama EnalbeAspect o EnableAspectJSarcazzo. Poi domande su JdbcTemplate tipo se il secondo parametro per mappare una entity e' entitymapper o qualcosaltro.
E vabbeh, fortunato chi ha di recente usato JDBCTemplate che se le ricordera'.
Fin qui e' ridicolo, ma arriviamo alla chicca finale. Mi si presenta un codice da sistemare che lavora con stringhe, tutto su un metodo solo. Richiede alcune decina di righe, forse 100, non proprio fizz buzz.
Da programmatore quasi saggio, io avrei cominciato a splittare il codice e mettere i metodi sotto test per vedere dove fallano, come consiglia di fare Michael Feathers nel suo libro. Poi li avrei fatti andare e magari fatto un po' di refactory per presentarli decentemente.
Beh, finestra su cui avrei dovuto lavorare era minuscola, quindi di riorganizzare li codice mi e' subito passata la voglia.
E non c'era possibilta' di scrivere test ovviamente.
Perche' non mi lasciano usare l'ambiente di sviluppo che voglio??
Ma soprattutto, cosa diavolo stanno assumendo? Gente che programma su finestrelle senza internet?

ti risponde uno che non programma più ( e poco in java) da diversi anni
ma che a volte seleziona.

le parti mnemoniche serve per identificare quanto conosci il linguaggio
o il framework di riferimento in pratica quale è la tua seniority (anche
perchè tutti son capaci a googlare)

sul concetto del codice da sistemare, non ti si è richiesto di
reinventare la ruota o reigegnerizzare ma mi identificare e risolvere un
eventuale bug.

quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

sul perchè non ti fanno usare lo strumento preferito è per mettere tutti
i candidati sullo stesso piano ma sopratutto perchè in un organizzazione
ci sono standard e strumenti, non è che utilizzi quello che vuoi.


si cerca di assumere non il più bravo programmatore in un determinato
linguaggio (quello lo si impara, alla fine è uno strumento che nel tempo
può anche cambiare), ma di assumere persone che hanno una certa
predisposizione al problem solving e trubleshooting, e che siano
"affamati" di imaparare e di conoscere.

[Booze]

Post by Mirko

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.
Vi racconto molto brevemente la follia che ho trovato, ditemi se sono io o cosa.
Allora si parte con un tot di domande per principianti su java e spring e ok.
Poi si passa sulla seconda sezione di domande. Qui non capisco che il timer e' per tutta la sezione invece che per singola domanda, colpa mia dovevo leggere meglio e quindi riesco a farne la meta'.
Il tenore delle domanda, pero', e' quello che mi lascia interdetto: il test si fa fullscreen e con webcam puntata. Non e' concesso googlare o cercare da nessuna parte. Le domande sono mnemoniche su Spring, tipo se per abilitare Aop l'annotazione si chiama EnalbeAspect o EnableAspectJSarcazzo. Poi domande su JdbcTemplate tipo se il secondo parametro per mappare una entity e' entitymapper o qualcosaltro.
E vabbeh, fortunato chi ha di recente usato JDBCTemplate che se le ricordera'.
Fin qui e' ridicolo, ma arriviamo alla chicca finale. Mi si presenta un codice da sistemare che lavora con stringhe, tutto su un metodo solo. Richiede alcune decina di righe, forse 100, non proprio fizz buzz.
Da programmatore quasi saggio, io avrei cominciato a splittare il codice e mettere i metodi sotto test per vedere dove fallano, come consiglia di fare Michael Feathers nel suo libro. Poi li avrei fatti andare e magari fatto un po' di refactory per presentarli decentemente.
Beh, finestra su cui avrei dovuto lavorare era minuscola, quindi di riorganizzare li codice mi e' subito passata la voglia.
E non c'era possibilta' di scrivere test ovviamente.
Perche' non mi lasciano usare l'ambiente di sviluppo che voglio??
Ma soprattutto, cosa diavolo stanno assumendo? Gente che programma su finestrelle senza internet?

ti risponde uno che non programma più ( e poco in java) da diversi anni
ma che a volte seleziona.
le parti mnemoniche serve per identificare quanto conosci il linguaggio
o il framework di riferimento in pratica quale è la tua seniority (anche
perchè tutti son capaci a googlare)

Sono d'accordo che le cose super basiche tipo @Autowired, @Entity tutte le debbano sapere a memoria se no significa che non ci stai lavorando.
Ma se comincia ad esplorare angoli del framework che uno potrebbe usare come no, oppure che ha utilizzato in passato diversi anni fa ma che non ha piu' toccato, non stai identificando la seniority ma solo il culo del candidato.

Sarebbe il caso invece di fare domande di concetto, ad esempio qual'e' il lifecycle di un entity, o mettere in piedi una domanda che richieda la conoscenza dei concetti di questo tipo. E' li' che vedi la differenza tra senior e junior, non sulle cose imparate a memoria.
Per quanto riguarda googlare, starebbe a recruiter fare un esercizio dove googlare non sia sufficiente.

Post by Mirko
sul concetto del codice da sistemare, non ti si è richiesto di
reinventare la ruota o reigegnerizzare ma mi identificare e risolvere un
eventuale bug.

E i bug si identificano e risolvono nel modo che ho indicato sopra, non con il ninja programming su finestrelle che sono un terzo dello schermo e senza possibilita' di fare quello che voglio con il codice.

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

Cioe' voi cercate gente che abbia le skill di sistemare un bug in pochi minuti con il clock ticking? Magari hai ragione tu e la posizione era per questo tipo di lavori da batteria.
Per inciso, sono notoriamente veloce nel scrivere codice e risolvere bug, solo mi piace farlo nell'ambiente a cui sono abituato, potendo usare le techniche piu' consone e senza un timer che mi conta i secondi.

Post by Mirko
sul perchè non ti fanno usare lo strumento preferito è per mettere tutti
i candidati sullo stesso piano ma sopratutto perchè in un organizzazione
ci sono standard e strumenti, non è che utilizzi quello che vuoi.

Ma cosa c'entra. Se ad esempio io fossi abituato a IntelliJ e l'azienda lavora su Eclipse, avrei cmq tempo di abituarmi al nuovo IDE prima di dover risolvere un bug.
Li' invece era come lavorare su una finestrella di notepad senza esserci abituato.

Post by Mirko
si cerca di assumere non il più bravo programmatore in un determinato
linguaggio (quello lo si impara, alla fine è uno strumento che nel tempo
può anche cambiare), ma di assumere persone che hanno una certa
predisposizione al problem solving e trubleshooting, e che siano
"affamati" di imaparare e di conoscere.

Probabilmente invece finiranno per assumere programmatori con ore e ore di esperienza su Test gorilla.
Auguri.

[Luca Menegotto]

Post by Mirko
le parti mnemoniche serve per identificare quanto conosci il linguaggio
o il framework di riferimento in pratica quale è la tua seniority (anche
perchè tutti son capaci a googlare)

Qui però ci vedo una fallacia non da poco, in due parti.
La prima: pensare che ricercare corrisponda a non sapere. Giusto ieri ho cercato nella documentazione online (che non solo Google esiste) quale dei 7 overload di un metodo specifico facesse più al caso mio. E credi, di esperienza in C# e in .NET ne ho parecchia.
La seconda: l'illusione che una persona, per quanto esperta, abbia una conoscenza immediata e precisa di un mondo che è diventato con gli anni sconfinato.

Post by Mirko
sul concetto del codice da sistemare, non ti si è richiesto di
reinventare la ruota o reigegnerizzare ma mi identificare e risolvere un
eventuale bug.

Su codice che non ho scritto io? E che devo comprendere per vedere come è stato pensato?
E che è eterno e per la definizione data scritto coi piedi? Se ci metto poco, non è bravura, è c...

[rootkit]

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

non sono mica tanto d'accordo eh.

gli incident in produzione si risolvono velocemente costruendo una buona
knowledge base, non con la smartitudine delle persone. cioè le persone
sono veloci se per ogni casistica sanno cosa fare.

poi di solito risolvere l'incident e fixare il problema sono cose diverse.
se c'è un problema bloccante di notte non è che puoi metterti a fare
analisi, sviluppo e test. nell'immediato si risolve l'incident (rollback
di versione, update nel database, eccetera) poi con tempi diversi e fuori
dall'emergenza si pensa alla fix. poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

[Luca Menegotto]

Post by rootkit
poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

Basta, io non ti leggo più. E' noioso continuare a essere d'accordo!
Troviamo modo di baruffare su qualcosa?

[Mirko]

Post by rootkit

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

non sono mica tanto d'accordo eh.
gli incident in produzione si risolvono velocemente costruendo una buona
knowledge base, non con la smartitudine delle persone. cioè le persone
sono veloci se per ogni casistica sanno cosa fare.
poi di solito risolvere l'incident e fixare il problema sono cose diverse.
se c'è un problema bloccante di notte non è che puoi metterti a fare
analisi, sviluppo e test. nell'immediato si risolve l'incident (rollback
di versione, update nel database, eccetera) poi con tempi diversi e fuori
dall'emergenza si pensa alla fix. poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

non sto dicendo che è giusto
ho espresso un concetto

ci sono posti di lavoro (dove sono ora) dove alcuni bug bloccanti in
prod (parliamo del settore finanziario) devono essere gestiti entro la
giornata lavorativa (gmt+2)
il cliente (world wide) apre un incident e se di tipo bloccante e in
pochi minuti non si arriva ad un workaround il defect deve essere
risolto entro fine giornata o al più nella giornata successiva

un esempio è stato il crollo di credit-suisse, una transazione
finanziaria con un paese (stato sovrano) che era fortemente esposto
verso il credisuisse su titoli derivati ed il sistema indicava come data
valuta il giorno dopo causa piccolo bug sulla funzione calendario (in
pratica nel paese risultava giorno festivo, per una ricorrenza non più
festiva da diversi anni)
questo fu l'apertura dell'incident, ma il danno sarebbe stato più esteso

questo comportava il ritardo di un giorno sul calcolo degli interessi,
la cocnlusione dei contratti, la chiusura delle transazioni ecc, e
tutto quello che comporta un bug che impatta tutto il sistema, non solo
uno specifico punto ,potete immaginare le ingenti perdite che si
avrebbero avute.

in quei casi si richiede di fixare il problema, non di fare la cosmesi
alla funzione in errore.
con tutta la pressione che hai addosso (tra meeting, cliente,
resposnabili, ecc) e il "normale" rimpallo tra un team e l'altro su chi
è l'owner della funzione in errore

la cosmesi è giusto che venga fatta ma non in quel frangente.

e purtroppo ti devo dar ragione che dove lavoro emergenze di questo tipo
passano almeno 1 o 2 volte alla settimana (gestiamo qualche centinaio di
banche worldwide)
e il fatto che c'è un forte turnover (scappare a gambe levate) non
aiuta, si perde knowldge e chi arriva dopo a volte fa più danni che bugfix

un problema è anche il prodotto, in quanto viene fortemente customizzato
in base alle esigenze del cliente (e ne gestiamo qualche centinaio).
ma da contratto il cliente deve prendere almeno 1 volta l'anno ,
l'aggiornamento di versione, andando ad avere delle regressioni o di
dover mettere mano al codice per renderlo nuovamente compatibile.
questo comporta un continuo rework della parte custom o l'apertura di
bugfix del prodotto stesso.

per farvi un esempio stupido
e come se ti acquisti una macchina, chiedi una forte personalizzazione
della plancia, del motore, dei sedili, della centralina, implementi
nuove feature ecc
ed ogni anno prendi la nuova versione della macchina che non è detto sia
compatibile con tutte le funzioni custom che hai creato (agganci diversi
dei sedili, connettori diversi della centralina o non compatibilità
della stessa in quanto ora la macchina è passata da benzina ad elettrica
ecc).

[LutherBlissett]

Post by Mirko
un esempio è stato il crollo di credit-suisse, una transazione
finanziaria con un paese (stato sovrano) che era fortemente esposto
verso il credisuisse su titoli derivati ed il sistema indicava come data
valuta il giorno dopo causa piccolo bug sulla funzione calendario (in
pratica nel paese risultava giorno festivo, per una ricorrenza non più
festiva da diversi anni)
questo fu l'apertura dell'incident, ma il danno sarebbe stato più esteso
questo comportava il ritardo di un giorno sul calcolo degli interessi,
la cocnlusione dei contratti, la chiusura delle transazioni ecc,   e
tutto quello che comporta un bug che impatta tutto il sistema, non solo
uno specifico punto ,potete immaginare le ingenti perdite che si
avrebbero avute.
in quei casi si richiede di fixare il problema, non di fare la cosmesi
alla funzione in errore.
con tutta la pressione che hai addosso  (tra meeting, cliente,
resposnabili, ecc) e il "normale" rimpallo tra un team e l'altro su chi
è l'owner della funzione in errore
la cosmesi è giusto che venga fatta ma non in quel frangente.

Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio
vuol dire che cerchi un disgraziato che sarà sottoposto a questo
genere di scenari in continuazione.

[Mirko]

Post by LutherBlissett

Post by Mirko
un esempio è stato il crollo di credit-suisse, una transazione
finanziaria con un paese (stato sovrano) che era fortemente esposto
verso il credisuisse su titoli derivati ed il sistema indicava come
data valuta il giorno dopo causa piccolo bug sulla funzione calendario
(in pratica nel paese risultava giorno festivo, per una ricorrenza non
più festiva da diversi anni)
questo fu l'apertura dell'incident, ma il danno sarebbe stato più esteso
questo comportava il ritardo di un giorno sul calcolo degli interessi,
la cocnlusione dei contratti, la chiusura delle transazioni ecc,   e
tutto quello che comporta un bug che impatta tutto il sistema, non
solo uno specifico punto ,potete immaginare le ingenti perdite che si
avrebbero avute.
in quei casi si richiede di fixare il problema, non di fare la cosmesi
alla funzione in errore.
con tutta la pressione che hai addosso  (tra meeting, cliente,
resposnabili, ecc) e il "normale" rimpallo tra un team e l'altro su
chi è l'owner della funzione in errore
la cosmesi è giusto che venga fatta ma non in quel frangente.

Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio
vuol dire che cerchi un disgraziato che sarà sottoposto a questo
genere di scenari in continuazione.

per la legge dei grandi numeri quello che è un evento raro su un singolo
cliente su un singolo software, lo moltiplichi per un centinaio di
clienti su un sistema come può essere un sistema bancario formato da una
cinquantina di moduli complessi (che spaziano dal trading, tasse, forex,
stex, accounting, derivati, credit, loans, crm, risk
managment,monitoring, credit card, atm managment, bank operation,
crypto, ecc) su diverse tecnologie e diverse piattaforme quell'evento
raro diventa quasi pane quotidiano.

[rootkit]

Post by Mirko

Post by LutherBlissett
Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio vuol
dire che cerchi un disgraziato che sarà sottoposto a questo genere di
scenari in continuazione.

per la legge dei grandi numeri quello che è un evento raro su un singolo
cliente su un singolo software, lo moltiplichi per un centinaio di
clienti su un sistema come può essere un sistema bancario formato da una
cinquantina di moduli complessi (che spaziano dal trading, tasse, forex,
stex, accounting, derivati, credit, loans, crm, risk
managment,monitoring, credit card, atm managment, bank operation,
crypto, ecc) su diverse tecnologie e diverse piattaforme quell'evento
raro diventa quasi pane quotidiano.

ho capito, ma se il numero di persone è adeguato al numero di clienti e
moduli l'evento relativamente raro resta relativamente raro per quella
singola persona.

e comunque oh, per risolvere rapidamente casi come quello che hai
descritto serve sì attitudine al problem solving, ma soprattutto una
profonda conoscenza del dominio. hai voglia essere smart se non sai dove
mettere le mani.

[Mirko]

Post by rootkit

Post by Mirko

Post by LutherBlissett
Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio vuol
dire che cerchi un disgraziato che sarà sottoposto a questo genere di
scenari in continuazione.

per la legge dei grandi numeri quello che è un evento raro su un singolo
cliente su un singolo software, lo moltiplichi per un centinaio di
clienti su un sistema come può essere un sistema bancario formato da una
cinquantina di moduli complessi (che spaziano dal trading, tasse, forex,
stex, accounting, derivati, credit, loans, crm, risk
managment,monitoring, credit card, atm managment, bank operation,
crypto, ecc) su diverse tecnologie e diverse piattaforme quell'evento
raro diventa quasi pane quotidiano.

ho capito, ma se il numero di persone è adeguato al numero di clienti e
moduli l'evento relativamente raro resta relativamente raro per quella
singola persona.
e comunque oh, per risolvere rapidamente casi come quello che hai
descritto serve sì attitudine al problem solving, ma soprattutto una
profonda conoscenza del dominio. hai voglia essere smart se non sai dove
mettere le mani.

rispondo come ultimo post su questo argomento (in quanto non è la sede
per discutere nello specifico dell'azienda e dei suoi processi)
il mio post iniziale era generico sul modo di procedere per selezionare
un candidato in base anche alle esigenze dell'azienda

non tutte hanno quel tipo di clienti/processi/pressioni ecc (e dico per
fortuna)

quando indicavo che diventa pane quotidiano mi riferisco al fatto che
emergenze di questo tipo lavorando come release manager, le vedo tutti i
giorni
poi sicuro non avviene sempre allo stesso sviluppatore, ma spalmate su
un organico di 500 sviluppatori (solo nella nostra business unit).

poi ci sono team più impattati rispetto ad altri (per una questione dei
volumi di operazioni bancarie e dei moduli che devono gestire una
moltitudine di casistiche rispetto ad altri, esempio trading rispetto a
mutui), o che va a periodi (ad esempio il team delle tasse si trova a
gestire emergenze più pressanti nei periodi di chiusira trimestrale o
annuale)

la conoscenza del dominio è fondamentale ma quella la acquisici con il
tempo e con studi universitari (in genere si assume come business
analist dei laureati in economia finanziaria)

in riferimento al mio post iniziale
quando si assume si cerca tra le varie candidature quello che è
predisposto al problem solving e che sia relativamente smart nel trovare
soluzioni anche non convenzionali (rimanendo negli standard aziendali)

ci capita (e non durano tanto) che vengano prese persone che "se la sono
giocata bene" in fase di colloquio ma che all'atto pratico dopo 6-12
mesi ancora non riescono a entrare nel "ritmo" di lavoro

un esempio che ho avuto davanti (scrivania) è stato di 2 ragazzi svegli
(motlo bravi tecnicamente e con un buon grado di conoscenza del dominio)
assunti a distanza di 3 mesi l'uno dall'altro, dopo quasi un anno, 1
(quello asssunto dopo) era gia produttivo ed era capace di gestire 3-5
incident giornalieri e le varie priorità, l'altro ha faticato molto nel
trovare il ritmo (per lui era necessario non essere distratto da call o
colleghi e concentrarsi) mentre l'ambiente è molto caotico, open space,
continue interruzioni con chiamate o meeting, colleghi che ti si
avvicinano, gestire le priorità durante la giornata (essere in grado di
capire che ,se arriva una priorità smetti di fare quello che stai
facendo ti occupi della priorità e poi riprendi) ecc

il primo è diventato in pochi anni il responsabile del team (oltre
all'essere bravo tecnicamente ha anche una notevole spigliatezza nel
parlare e coordinare), il secondo ha abbandonato dopo 2 anni.

e ci si è ritrovati nuovamente con un team in sofferenza (1 diventato
responsabile e 1 dimesso) e in cerca di personale tecnico. :)

[Mirko]

Post by Mirko

Post by rootkit

Post by Mirko

Post by LutherBlissett
Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio vuol
dire che cerchi un disgraziato che sarà sottoposto a questo genere di
scenari in continuazione.

per la legge dei grandi numeri quello che è un evento raro su un singolo
cliente su un singolo software, lo moltiplichi per un centinaio di
clienti su un sistema come può essere un sistema bancario formato da una
cinquantina di moduli complessi (che spaziano dal trading, tasse, forex,
stex, accounting, derivati, credit, loans, crm, risk
managment,monitoring, credit card, atm managment, bank operation,
crypto, ecc) su diverse tecnologie e diverse piattaforme quell'evento
raro diventa quasi pane quotidiano.

ho capito, ma se il numero di persone è adeguato al numero di clienti e
moduli l'evento relativamente raro resta relativamente raro per quella
singola persona.
e comunque oh, per risolvere rapidamente casi come quello che hai
descritto serve sì attitudine al problem solving, ma soprattutto una
profonda conoscenza del dominio. hai voglia essere smart se non sai dove
mettere le mani.

rispondo come ultimo post su questo argomento (in quanto non è la sede
per discutere nello specifico dell'azienda e dei suoi processi)
il mio post iniziale era generico sul modo di procedere per selezionare
un candidato in base anche alle esigenze dell'azienda
non tutte hanno quel tipo di clienti/processi/pressioni ecc (e dico per
fortuna)
quando indicavo che diventa pane quotidiano mi riferisco al fatto che
emergenze di questo tipo lavorando come release manager, le vedo tutti i
giorni
poi sicuro non avviene sempre allo stesso sviluppatore, ma spalmate su
un organico di 500 sviluppatori (solo nella nostra business unit).
poi ci sono team più impattati rispetto ad altri (per una questione dei
volumi di operazioni bancarie e dei moduli che devono gestire una
moltitudine di casistiche rispetto ad altri, esempio trading rispetto a
mutui), o che va a periodi (ad esempio il team delle tasse si trova a
gestire emergenze più pressanti nei periodi di chiusira trimestrale o
annuale)
la conoscenza del dominio è fondamentale ma quella la acquisici con il
tempo e con studi universitari (in genere si assume come business
analist dei laureati in economia finanziaria)
in riferimento al mio post iniziale
quando si assume si cerca tra le varie candidature quello che è
predisposto al problem solving e che sia relativamente smart nel trovare
soluzioni anche non convenzionali (rimanendo negli standard aziendali)
ci capita (e non durano tanto) che vengano prese persone che "se la sono
giocata bene" in fase di colloquio ma che all'atto pratico dopo 6-12
mesi ancora non riescono a entrare nel "ritmo" di lavoro
un esempio che ho avuto davanti (scrivania) è stato di 2 ragazzi svegli
(motlo bravi tecnicamente e con un buon grado di conoscenza del dominio)
assunti a distanza di 3 mesi l'uno dall'altro, dopo quasi un anno, 1
(quello asssunto dopo) era gia produttivo ed era capace di gestire 3-5
incident giornalieri e le varie priorità, l'altro ha faticato molto nel
trovare il ritmo (per lui era necessario non essere distratto da call o
colleghi e concentrarsi) mentre l'ambiente è molto caotico, open space,
continue interruzioni con chiamate o meeting, colleghi che ti si
avvicinano, gestire le priorità durante la giornata (essere in grado di
capire che ,se arriva una priorità smetti di fare quello che stai
facendo ti occupi della priorità e poi riprendi) ecc
il primo è diventato in pochi anni il responsabile del team (oltre
all'essere bravo tecnicamente ha anche una notevole spigliatezza nel
parlare e coordinare), il secondo ha abbandonato dopo 2 anni.
e ci si è ritrovati nuovamente con un team in sofferenza (1 diventato
responsabile e 1 dimesso) e in cerca di personale tecnico. :)

per completezza
i due avevano un approccio completamente diverso

uno stava con il pdf del modulo su un monitor a leggersi la
documentazione, l'altro su reddit o stackoverflow a cercare la soluzione

uno stava in call con la casa madre per capire la tal funzione, l'altro
stava con l'editor aperto e decine di file sorgenti a fare su e giu

uno al telefono direttamente in call con il cliente, l'altro a scrivere
mail chilometriche al cliente per chiedere ulteriori info o per la
risoluzione del ticket,

uno era uno scassaxxxx ma portava a casa il risultato, l'altro era
migliore tecnicamente e anche più preciso ma meno produttivo


ecco quando parlo di persona che abbia attitudine di problem solveing e
smart mi riferisco al primo.

[CBM64]

Post by Mirko
per completezza
i due avevano un approccio completamente diverso
ecco quando parlo di persona che abbia attitudine di problem solveing e
smart mi riferisco al primo.

cioe' al rompic**** oppure all'altro?

[Mirko]

Post by CBM64

Post by Mirko
per completezza
i due avevano un approccio completamente diverso
ecco quando parlo di persona che abbia attitudine di problem solveing
e smart mi riferisco al primo.

cioe' al rompic**** oppure all'altro?

al rompicxxxx, ad uno che non bada alla forma ma all'obiettivo

[Mirko]

Post by CBM64

Post by Mirko
per completezza
i due avevano un approccio completamente diverso
ecco quando parlo di persona che abbia attitudine di problem solveing
e smart mi riferisco al primo.

cioe' al rompic**** oppure all'altro?

al rompicxxxx, ad uno che non bada alla forma  ma all'obiettivo

"uno stava con il pdf del modulo su un monitor a leggersi la
documentazione, l'altro su reddit o stackoverflow a cercare la soluzione"

il primo dopo 2 mesi aveva gia imparato il modulo, l'altro ancora a
gironzolare su reddit/stackoverflow (e spesso chiedeva al primo perchè e
per come il software si comportava così)


"uno stava in call con la casa madre per capire la tal funzione, l'altro
stava con l'editor aperto e decine di file sorgenti a fare su e giu"

il primo in poche ore era in grado di capire se aveva centrato il
problema o cercare da un altra parte, l'altro passava l'intera giornata
inconcludente a fare su e giu tra i sorgenti

"uno al telefono direttamente in call con il cliente, l'altro a scrivere
mail chilometriche al cliente per chiedere ulteriori info o per la
risoluzione del ticket,"

il primo in pochi minuti aveva tutte le info direttamente dal cliente,
l'altro a volte aspettava giorni prima di ricevere un email.

"uno era uno scassaxxxx ma portava a casa il risultato, l'altro era
migliore tecnicamente e anche più preciso ma meno produttivo"

il primo rompeva le p... a mezza azienda per fare le cose il prima
possibile e chiudere il ticket (a volte l'incident è trasversale su più
moduli), la filosofia dell'altro era "la mia parte l'ho fatta".

[Luca Menegotto]

Post by Mirko
il primo rompeva le p... a mezza azienda per fare le cose il prima
possibile e chiudere il ticket (a volte l'incident è trasversale su più
moduli), la filosofia dell'altro era "la mia parte l'ho fatta".

Beh, se il primo è come lo hai descritto, anch'io avrei puntato sul primo, senza nemmeno pensarci.

[LutherBlissett]

Post by Mirko

Post by LutherBlissett
Ecco appunto, ottimo esempio, e dovrebbe essere un accadimento
relativamente raro. Ma se ci basi la selezione ad un colloquio
vuol dire che cerchi un disgraziato che sarà sottoposto a questo
genere di scenari in continuazione.

per la legge dei grandi numeri quello che è un evento raro su un singolo
cliente su un singolo software, lo moltiplichi per un centinaio di
clienti su un sistema come può essere un sistema bancario formato da una
cinquantina di moduli complessi (che spaziano dal trading, tasse, forex,
stex, accounting, derivati, credit, loans, crm, risk
managment,monitoring, credit card, atm managment, bank operation,
crypto, ecc) su diverse tecnologie e diverse piattaforme quell'evento
raro diventa quasi pane quotidiano.

E già, è quello che dicevo, un ambiente di merda
sottodimensionato dove il disgraziato saròà destinato a finire.
Siamo perfettamente d'accordo.

[Booze]

Post by Mirko

Post by rootkit

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

non sono mica tanto d'accordo eh.
gli incident in produzione si risolvono velocemente costruendo una buona
knowledge base, non con la smartitudine delle persone. cioè le persone
sono veloci se per ogni casistica sanno cosa fare.
poi di solito risolvere l'incident e fixare il problema sono cose diverse.
se c'è un problema bloccante di notte non è che puoi metterti a fare
analisi, sviluppo e test. nell'immediato si risolve l'incident (rollback
di versione, update nel database, eccetera) poi con tempi diversi e fuori
dall'emergenza si pensa alla fix. poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

non sto dicendo che è giusto
ho espresso un concetto
ci sono posti di lavoro (dove sono ora) dove alcuni bug bloccanti in
prod (parliamo del settore finanziario) devono essere gestiti entro la
giornata lavorativa (gmt+2)
il cliente (world wide) apre un incident e se di tipo bloccante e in
pochi minuti non si arriva ad un workaround il defect deve essere
risolto entro fine giornata o al più nella giornata successiva
un esempio è stato il crollo di credit-suisse, una transazione
finanziaria con un paese (stato sovrano) che era fortemente esposto
verso il credisuisse su titoli derivati ed il sistema indicava come data
valuta il giorno dopo causa piccolo bug sulla funzione calendario (in
pratica nel paese risultava giorno festivo, per una ricorrenza non più
festiva da diversi anni)
questo fu l'apertura dell'incident, ma il danno sarebbe stato più esteso
questo comportava il ritardo di un giorno sul calcolo degli interessi,
la cocnlusione dei contratti, la chiusura delle transazioni ecc, e
tutto quello che comporta un bug che impatta tutto il sistema, non solo
uno specifico punto ,potete immaginare le ingenti perdite che si
avrebbero avute.
in quei casi si richiede di fixare il problema, non di fare la cosmesi
alla funzione in errore.
con tutta la pressione che hai addosso (tra meeting, cliente,
resposnabili, ecc) e il "normale" rimpallo tra un team e l'altro su chi
è l'owner della funzione in errore
la cosmesi è giusto che venga fatta ma non in quel frangente.
e purtroppo ti devo dar ragione che dove lavoro emergenze di questo tipo
passano almeno 1 o 2 volte alla settimana (gestiamo qualche centinaio di
banche worldwide)
e il fatto che c'è un forte turnover (scappare a gambe levate) non
aiuta, si perde knowldge e chi arriva dopo a volte fa più danni che bugfix
un problema è anche il prodotto, in quanto viene fortemente customizzato
in base alle esigenze del cliente (e ne gestiamo qualche centinaio).
ma da contratto il cliente deve prendere almeno 1 volta l'anno ,
l'aggiornamento di versione, andando ad avere delle regressioni o di
dover mettere mano al codice per renderlo nuovamente compatibile.
questo comporta un continuo rework della parte custom o l'apertura di
bugfix del prodotto stesso.
per farvi un esempio stupido
e come se ti acquisti una macchina, chiedi una forte personalizzazione
della plancia, del motore, dei sedili, della centralina, implementi
nuove feature ecc
ed ogni anno prendi la nuova versione della macchina che non è detto sia
compatibile con tutte le funzioni custom che hai creato (agganci diversi
dei sedili, connettori diversi della centralina o non compatibilità
della stessa in quanto ora la macchina è passata da benzina ad elettrica
ecc).

Ma dai e' ridicolo cercare candidati usando come funzione obiettivo il tempo di risoluzione di bug su codice mai visto.
Cercate piuttosto gente che capisca i concetti, il codice e ne prenda dimestichezza.
Poi il bug fix, una volta che padroneggi il codice del progetto, viene veloce.

Non ha senso massimizzare la velocita' di bug fixing su codice mai visto prima.

[M C]

Post by Booze
Non ha senso massimizzare la velocita' di bug fixing su codice mai visto prima.

é uno dei test che la mia azienda propone ai candidati
piú che bug fix é code review

[Mirko]

Post by Booze

Post by Mirko

Post by rootkit

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

non sono mica tanto d'accordo eh.
gli incident in produzione si risolvono velocemente costruendo una buona
knowledge base, non con la smartitudine delle persone. cioè le persone
sono veloci se per ogni casistica sanno cosa fare.
poi di solito risolvere l'incident e fixare il problema sono cose diverse.
se c'è un problema bloccante di notte non è che puoi metterti a fare
analisi, sviluppo e test. nell'immediato si risolve l'incident (rollback
di versione, update nel database, eccetera) poi con tempi diversi e fuori
dall'emergenza si pensa alla fix. poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

non sto dicendo che è giusto
ho espresso un concetto
ci sono posti di lavoro (dove sono ora) dove alcuni bug bloccanti in
prod (parliamo del settore finanziario) devono essere gestiti entro la
giornata lavorativa (gmt+2)
il cliente (world wide) apre un incident e se di tipo bloccante e in
pochi minuti non si arriva ad un workaround il defect deve essere
risolto entro fine giornata o al più nella giornata successiva
un esempio è stato il crollo di credit-suisse, una transazione
finanziaria con un paese (stato sovrano) che era fortemente esposto
verso il credisuisse su titoli derivati ed il sistema indicava come data
valuta il giorno dopo causa piccolo bug sulla funzione calendario (in
pratica nel paese risultava giorno festivo, per una ricorrenza non più
festiva da diversi anni)
questo fu l'apertura dell'incident, ma il danno sarebbe stato più esteso
questo comportava il ritardo di un giorno sul calcolo degli interessi,
la cocnlusione dei contratti, la chiusura delle transazioni ecc, e
tutto quello che comporta un bug che impatta tutto il sistema, non solo
uno specifico punto ,potete immaginare le ingenti perdite che si
avrebbero avute.
in quei casi si richiede di fixare il problema, non di fare la cosmesi
alla funzione in errore.
con tutta la pressione che hai addosso (tra meeting, cliente,
resposnabili, ecc) e il "normale" rimpallo tra un team e l'altro su chi
è l'owner della funzione in errore
la cosmesi è giusto che venga fatta ma non in quel frangente.
e purtroppo ti devo dar ragione che dove lavoro emergenze di questo tipo
passano almeno 1 o 2 volte alla settimana (gestiamo qualche centinaio di
banche worldwide)
e il fatto che c'è un forte turnover (scappare a gambe levate) non
aiuta, si perde knowldge e chi arriva dopo a volte fa più danni che bugfix
un problema è anche il prodotto, in quanto viene fortemente customizzato
in base alle esigenze del cliente (e ne gestiamo qualche centinaio).
ma da contratto il cliente deve prendere almeno 1 volta l'anno ,
l'aggiornamento di versione, andando ad avere delle regressioni o di
dover mettere mano al codice per renderlo nuovamente compatibile.
questo comporta un continuo rework della parte custom o l'apertura di
bugfix del prodotto stesso.
per farvi un esempio stupido
e come se ti acquisti una macchina, chiedi una forte personalizzazione
della plancia, del motore, dei sedili, della centralina, implementi
nuove feature ecc
ed ogni anno prendi la nuova versione della macchina che non è detto sia
compatibile con tutte le funzioni custom che hai creato (agganci diversi
dei sedili, connettori diversi della centralina o non compatibilità
della stessa in quanto ora la macchina è passata da benzina ad elettrica
ecc).

Ma dai e' ridicolo cercare candidati usando come funzione obiettivo il tempo di risoluzione di bug su codice mai visto.
Cercate piuttosto gente che capisca i concetti, il codice e ne prenda dimestichezza.
Poi il bug fix, una volta che padroneggi il codice del progetto, viene veloce.
Non ha senso massimizzare la velocita' di bug fixing su codice mai visto prima.

se leggi bene il mio primo post

"si cerca di assumere non il più bravo programmatore in un determinato
linguaggio (quello lo si impara, alla fine è uno strumento che nel tempo
può anche cambiare), ma di assumere persone che hanno una certa
predisposizione al problem solving e trubleshooting, e che siano
"affamati" di imaparare e di conoscere. "

non si misura la bravura in termini di tempo, ma si cercano persone che
abbiano la capacità di lavorare in un contesto altamente dinamico (e
aime stressante) che richiedono persone smart che approcciano al
problema anche in maniera non convenzionale (ma rimanendo negli
standard) con una forte capacità di problem solving, persone che abbiano
una certa elasticità in termini analitici più che tecnici.

[LutherBlissett]

Post by rootkit

Post by Mirko
quel test serve per identificare quanto sei smart nel trovare soluzioni
in poco tempo.
a volte si lavora con SLA di poche ore, ci sono casi di SLA a 4 o 8 ore
dalla apertura del problema alla sua risoluzione in prod, passando per
analisi/sviluppo/test e burocrazia varia interna all'organizzazione e un
test del genere mi identifica se il candidato è abbastanza spigliato da
identificare in poco tempo il problema e abbozzare una soluzione.

non sono mica tanto d'accordo eh.
gli incident in produzione si risolvono velocemente costruendo una buona
knowledge base, non con la smartitudine delle persone. cioè le persone
sono veloci se per ogni casistica sanno cosa fare.
poi di solito risolvere l'incident e fixare il problema sono cose diverse.
se c'è un problema bloccante di notte non è che puoi metterti a fare
analisi, sviluppo e test. nell'immediato si risolve l'incident (rollback
di versione, update nel database, eccetera) poi con tempi diversi e fuori
dall'emergenza si pensa alla fix. poi possono esistere casi in cui bisogna
fixare a cuore aperto ma se questi casi escono dalla assoluta
eccezionalità c'è da scappare a gambe levate!

Certo, cioe', se cercano gente che sarà costretta a tappullare
di continuo, in fretta, e dunque a cazzo, va benissimo quel test
da disperati, e va altrettanto bene per capire in che merdaio
di situazione lavorativa si andrebbe finire...

[rootkit]

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.

premetto che attualmente la mia attività di developer è quasi
esclusivamente ausiliaria ad altre attività, principalmente gestione
infrastruttura e automazione it. premetto anche che non conosco quella
piattaforma.

detto questo: sì, da quello che descrivi non ha senso. mi sembrano
progettati per selezionare code monkey a batteria e senza troppo sforzo
intellettuale del selezionatore.

in genere noi (ma ripeto, è un ambito diverso) prepariamo dei problemi che
diamo come compito a casa al primo colloquio tecnico, la soluzione la
discutiamo approfonditamente al secondo colloquio generalmente dopo una
settimana. giusto o sbagliato che sia oltre al code review valutiamo tutta
una serie di cose, per esempio come consegna il "compito" (non gli diciamo
niente, ma certo ce lo aspettiamo su un repository github o simila e non
su una chiavetta), come illustra la soluzione e come risponde alle domande
a sorpresa. va detto il candidato potrebbe essere anche tecnicamente più
preparato in alcuni ambiti di chi gli fa il colloquio tecnico e bisogna
essere pronti a questo, non è un esame alunno-insegnante ma si deve
valutare se una persona può ricoprire una certa figura in azienda.

[Luca Menegotto]

Post by rootkit
in genere noi (ma ripeto, è un ambito diverso) prepariamo dei problemi che
diamo come compito a casa al primo colloquio tecnico, la soluzione la
discutiamo approfonditamente al secondo colloquio generalmente dopo una
settimana. giusto o sbagliato che sia oltre al code review valutiamo tutta
una serie di cose, per esempio come consegna il "compito" (non gli diciamo
niente, ma certo ce lo aspettiamo su un repository github o simila e non
su una chiavetta), come illustra la soluzione e come risponde alle domande
a sorpresa.

Applausi! QUESTO è il modo corretto per selezionare un tecnico!

[LutherBlissett]

Post by rootkit

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.

premetto che attualmente la mia attività di developer è quasi
esclusivamente ausiliaria ad altre attività, principalmente gestione
infrastruttura e automazione it. premetto anche che non conosco quella
piattaforma.
detto questo: sì, da quello che descrivi non ha senso. mi sembrano
progettati per selezionare code monkey a batteria e senza troppo sforzo
intellettuale del selezionatore.
in genere noi (ma ripeto, è un ambito diverso) prepariamo dei problemi che
diamo come compito a casa al primo colloquio tecnico, la soluzione la
discutiamo approfonditamente al secondo colloquio generalmente dopo una
settimana. giusto o sbagliato che sia oltre al code review valutiamo tutta
una serie di cose, per esempio come consegna il "compito" (non gli diciamo
niente, ma certo ce lo aspettiamo su un repository github o simila e non
su una chiavetta), come illustra la soluzione e come risponde alle domande
a sorpresa. va detto il candidato potrebbe essere anche tecnicamente più
preparato in alcuni ambiti di chi gli fa il colloquio tecnico e bisogna
essere pronti a questo, non è un esame alunno-insegnante ma si deve
valutare se una persona può ricoprire una certa figura in azienda.

Il compitino a casa, se lo chiedi ad un senior, a mio avviso
ti dovrebbe mandare a cagare o emettere fattura per il tempo speso
alla consegna del codice.

Se è per selezionare un profilo junior ok, molto meglio del modo
di interrogare riportato dall'OP.

[Booze]

Post by LutherBlissett

Post by rootkit

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.

premetto che attualmente la mia attività di developer è quasi
esclusivamente ausiliaria ad altre attività, principalmente gestione
infrastruttura e automazione it. premetto anche che non conosco quella
piattaforma.
detto questo: sì, da quello che descrivi non ha senso. mi sembrano
progettati per selezionare code monkey a batteria e senza troppo sforzo
intellettuale del selezionatore.
in genere noi (ma ripeto, è un ambito diverso) prepariamo dei problemi che
diamo come compito a casa al primo colloquio tecnico, la soluzione la
discutiamo approfonditamente al secondo colloquio generalmente dopo una
settimana. giusto o sbagliato che sia oltre al code review valutiamo tutta
una serie di cose, per esempio come consegna il "compito" (non gli diciamo
niente, ma certo ce lo aspettiamo su un repository github o simila e non
su una chiavetta), come illustra la soluzione e come risponde alle domande
a sorpresa. va detto il candidato potrebbe essere anche tecnicamente più
preparato in alcuni ambiti di chi gli fa il colloquio tecnico e bisogna
essere pronti a questo, non è un esame alunno-insegnante ma si deve
valutare se una persona può ricoprire una certa figura in azienda.

Il compitino a casa, se lo chiedi ad un senior, a mio avviso
ti dovrebbe mandare a cagare o emettere fattura per il tempo speso
alla consegna del codice.
Se è per selezionare un profilo junior ok, molto meglio del modo
di interrogare riportato dall'OP.

Non sarei contrario al compitino. A mio avviso deve essere piuttosto semplice e casomai potrebbe essere usato come spunto per una discussione librea durante "l'orale".

[LutherBlissett]

Post by Booze
Non sarei contrario al compitino. A mio avviso deve essere piuttosto semplice e casomai potrebbe essere usato come spunto per una discussione librea durante "l'orale".

E' un mio modo di vedere, in effetti capisco che dipenda
dal sentire personale. Ad un senior, da inquadrare comunque
come una figura prettamente tecnica, tanto varrebbe allora
chiedere di presentare una parte di codice sviluppata
in passato(*) che il candidato ritenga significativa
per poi discuterne insieme.


(*) deconstestualizzato quel tanto da essere regionevolmente
isolato e senza ledere proprietà intellettuali.

[rootkit]

E' un mio modo di vedere, in effetti capisco che dipenda dal sentire
personale. Ad un senior, da inquadrare comunque come una figura
prettamente tecnica, tanto varrebbe allora chiedere di presentare una
parte di codice sviluppata in passato(*) che il candidato ritenga
significativa per poi discuterne insieme.
(*) deconstestualizzato quel tanto da essere regionevolmente
isolato e senza ledere proprietà intellettuali.

guarda che se ce l'ha, ben venga. se uno ha dei progetti che può mostrare
e che gli fanno gioco sta a lui dirlo, mica al selezionatore chiederlo. sa
una sega lui.

[rootkit]

Post by Booze

Se è per selezionare un profilo junior ok, molto meglio del modo di
interrogare riportato dall'OP.

Non sarei contrario al compitino. A mio avviso deve essere piuttosto
semplice e casomai potrebbe essere usato come spunto per una discussione
librea durante "l'orale".

ma guarda che in genere è così. sono esempi che impegnano un paio d'ore al
massimo e se si tratta di un senior che non millanta competenze si diverte
pure.

cioè per dire se nel cv dici di avere esperienza di monitoring e a me
interessa questa cosa, posso chiederti di scrivere un exporter che esporta
alcune metriche del tuo pc nel linguaggio che preferisci, per esempio. se
sai di che si parla è un gioco da ragazzi e ti diverti anche a fare il
secchione :-)

[rootkit]

Il compitino a casa, se lo chiedi ad un senior, a mio avviso ti dovrebbe
mandare a cagare o emettere fattura per il tempo speso alla consegna del
codice.

per carità, se il signore non gradisce non ha che da dirlo.

[Luca Menegotto]

Post by LutherBlissett
Il compitino a casa, se lo chiedi ad un senior, a mio avviso
ti dovrebbe mandare a cagare o emettere fattura per il tempo speso
alla consegna del codice.

Mi consenta di non essere d'accordo.
Dal mio punto di vista il senior che si avvicina a un posto di lavoro specifico è una persona che ha interesse per quello specifico posto di lavoro (se non sa capirlo, che senior è?). E dal momento che una collaborazione è quasi un matrimonio, questo consente alle alle parti di conoscersi. La parte rilevante, infatti, non è il compitino a casa, quella è la base di partenza. La parte rilevante ai fini della collaborazione è la successiva, dove root dice: "valutiamo tutta una serie di cose, per esempio come consegna il "compito" (non gli diciamo niente, ma certo ce lo aspettiamo su un repository github o simila e non su una chiavetta), come illustra la soluzione e come risponde alle domande a sorpresa...". Questo consente anche al candidato di valutare la controparte e verificare se quanto aveva presunto corrisponde in effetti alla realtà.

[LutherBlissett]

Post by Luca Menegotto

Post by LutherBlissett
Il compitino a casa, se lo chiedi ad un senior, a mio avviso
ti dovrebbe mandare a cagare o emettere fattura per il tempo speso
alla consegna del codice.

Mi consenta di non essere d'accordo.
Dal mio punto di vista il senior che si avvicina a un posto di lavoro specifico è una persona che ha interesse per quello specifico posto di lavoro (se non sa capirlo, che senior è?). E dal momento che una collaborazione è quasi un matrimonio, questo consente alle alle parti di conoscersi. La parte rilevante, infatti, non è il compitino a casa, quella è la base di partenza. La parte rilevante ai fini della collaborazione è la successiva, dove root dice: "valutiamo tutta una serie di cose, per esempio come consegna il "compito" (non gli diciamo niente, ma certo ce lo aspettiamo su un repository github o simila e non su una chiavetta), come illustra la soluzione e come risponde alle domande a sorpresa...". Questo consente anche al candidato di valutare la controparte e verificare se quanto aveva presunto corrisponde in effetti alla realtà.

Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore
io faccio lo stesso con loro, e cosi' tutti i candidati a cui
scassano il cazzo.

Ok, io vi sviluppo questo esercizietto, e voi mi fate vedere
come lavorate facendo sviluppare quest'altro proposto da me
cosi' vedo come lavorate.

Idem per l'idea che proponevo di mostrare codice scritto in passato.
Se richiesto io vi mostro qualcosa di cui sono fiero di aver fatto
e voi mi mostrate una *vostra* porzione di codice che allo stesso
modo mostra come andate fieri di lavorare.
(Capi' rootkit?)

Bisogna finirla di considerarsi sempre la parte debole.

SOPRATTUTTO se si è senior e ancora di piu' SOPRATTUTTO
SE TI CERCANO LORO.

[rootkit]

Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore io
faccio lo stesso con loro, e cosi' tutti i candidati a cui scassano il
cazzo.
Ok, io vi sviluppo questo esercizietto, e voi mi fate vedere come
lavorate facendo sviluppare quest'altro proposto da me cosi' vedo come
lavorate.
Idem per l'idea che proponevo di mostrare codice scritto in passato.
Se richiesto io vi mostro qualcosa di cui sono fiero di aver fatto e voi
mi mostrate una *vostra* porzione di codice che allo stesso modo mostra
come andate fieri di lavorare.
(Capi' rootkit?)

ti ho risposto, se non gradisci non hai che da dirlo.

Bisogna finirla di considerarsi sempre la parte debole.

ma quale parte debole, che c'entra? se ti do un esercizio da fare mica ti
sto chiedendo di lavorare per me, mi ci pulisco il culo con quel codice. è
una opportunità per te di mostrare all'azienda quello che sai fare: sei te
che ti candidi all'azienda per la posizione, non viceversa, se ti
interessa bene altrimenti ciao.

[Luca Menegotto]

Post by LutherBlissett
Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore
io faccio lo stesso con loro, e cosi' tutti i candidati a cui
scassano il cazzo.

Si vede che non sei mai stato dall'altra parte. Allora, fai questo esercizio: in che modo tu selezioneresti un candidato? Sapendo in partenza che, a guardare i curricola, son tutti fisici nucleari?

Dopodiché posso dirti, con buona certezza, che come candidato non sono mai stato né mi sono sentito la parte debole. E sì, ho rifiutato almeno 4 o 5 proposte che non ritenevo adeguate, nella mia carriera. Se poi tu candidato ti senti parte debole, e sia chiaro, quando si è giovani può capitare, è meglio se chiedi qualche consiglio a chi di esperienza di tentativi di inchiappettate ne ha. Però sia chiaro, non esiste che tutto il mondo lì fuori abbia come scopo nella vita fotterti: si tratta di capire chi lo vuol fare ed evitarlo, e QUESTO è il tuo lavoro da candidato-

Post by LutherBlissett
SOPRATTUTTO se si è senior e ancora di piu' SOPRATTUTTO SE TI CERCANO LORO.

Se sei Dio in terra, il prezzo lo fai tu (ma a quel punto non ti candidi nemmeno). In tutti gli altri casi, un'assunzione è un processo di avvicinamento: tu come candidato puoi non andare bene all'azienda, indipendentemente dalle tue competenze, e per converso l'azienda può non andare bene a te.

[LutherBlissett]

Post by Luca Menegotto

Post by LutherBlissett
Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore
io faccio lo stesso con loro, e cosi' tutti i candidati a cui
scassano il cazzo.

Si vede che non sei mai stato dall'altra parte. Allora, fai questo esercizio: in che modo tu selezioneresti un candidato? Sapendo in partenza che, a guardare i curricola, son tutti fisici nucleari?

Ti sbagli, e i "fisici nucleari" li sgamo senza bisogno
di fargli appoggiare penna.

[Luca Menegotto]

Post by LutherBlissett
Ti sbagli, e i "fisici nucleari" li sgamo senza bisogno
di fargli appoggiare penna.

Mi fa piacere, credi. Tuttavia, non è questo il nocciolo del discorso. Pur con la mia 'eccessiva esperienza' (comunque sempre inferiore a quanto vorrei), io da candidato non avrei alcun problema a fare qualche test, dovesse capitare. E sarei un valutatore feroce di chi propone il posto di lavoro, come peraltro in passato qualche volta è accaduto.
Ma non capiterà, ne sono certo, alla mia veneranda età... :-)

[rootkit]

Post by Luca Menegotto

Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore io
faccio lo stesso con loro, e cosi' tutti i candidati a cui scassano il
cazzo.

Si vede che non sei mai stato dall'altra parte. Allora, fai questo
esercizio: in che modo tu selezioneresti un candidato? Sapendo in
partenza che, a guardare i curricola, son tutti fisici nucleari?

ma non è neanche quello. il punto è che a parte le fanfarate dette qui chi
si presenta ad un colloquio è ben contento e ben disposto se gli viene
dato l'opportunità di dare prova di quello che sa fare, è capitato anche a
me da candidato esattamente come l'ho descritto. nessuno si sogna di dire
che l'azienda lo sta facendo lavorare gratis (ma di che? che vuoi se ne
faccia l'azienda?) e di solito si chiede se c'è disponibilità perché uno
per le ragioni più disparate potrebbe non avere tempo. però se non ci
tieni a mostrare le competenze che li fai a fare ai colloqui?

chiaramente non sto parlando di quei test sciocchini che ha descritto l'op
e che imho scremano grossolanamente le candidature.

[LutherBlissett]

Post by rootkit

Post by Luca Menegotto

Ok, allora facciamo che se mi chiedono di lavorare un paio d'ore io
faccio lo stesso con loro, e cosi' tutti i candidati a cui scassano il
cazzo.

Si vede che non sei mai stato dall'altra parte. Allora, fai questo
esercizio: in che modo tu selezioneresti un candidato? Sapendo in
partenza che, a guardare i curricola, son tutti fisici nucleari?

ma non è neanche quello. il punto è che a parte le fanfarate dette qui chi
si presenta ad un colloquio è ben contento e ben disposto se gli viene
dato l'opportunità di dare prova di quello che sa fare, è capitato anche a
me da candidato esattamente come l'ho descritto. nessuno si sogna di dire

Si, ma anche capire dove andrebbe a finire accettando quel lavoro.
E' qui che sembra non la vogliate capire. Anche l'azienda deve
dimostrare quanto bene lavora.

[rootkit]

Post by LutherBlissett

Post by rootkit
ma non è neanche quello. il punto è che a parte le fanfarate dette qui
chi si presenta ad un colloquio è ben contento e ben disposto se gli
viene dato l'opportunità di dare prova di quello che sa fare, è
capitato anche a me da candidato esattamente come l'ho descritto.
nessuno si sogna di dire

Si, ma anche capire dove andrebbe a finire accettando quel lavoro.
E' qui che sembra non la vogliate capire. Anche l'azienda deve
dimostrare quanto bene lavora.

e quando mai qualcuno ha dubitato che fra le prerogative di un candidato
ci sia indagare su come lavora l'azienda? e che non ha piena facoltà di
scartare l'azienda se le risposte che riceve sono insufficienti o
inadeguate?
in ultimo, pensi che le persone non lo facciano?

[Luca Menegotto]

Post by LutherBlissett
Si, ma anche capire dove andrebbe a finire accettando quel lavoro.
E' qui che sembra non la vogliate capire. Anche l'azienda deve
dimostrare quanto bene lavora.

Mi fai vedere dove ho detto che il candidato non possa (dovrei dire debba) fare tutte le domande che sono opportune?
Lo ribadisco, a meno che tu non stia facendo un concorso pubblico - e anche li... - un rapporto di collaborazione è un avvicinamento reciproco.

Che poi, scusa, uno si candida per un posto di lavoro, va a fare un colloquio e non ha la vaga idea di dove sta andando a finire? Anno 2023? con tutte le possibilità di documentarsi che ha oggi (30 anni fa era molto peggio)? Allora gli piace mettere il culo nelle pedate...

[Francesco Da Riva]

Post by Luca Menegotto
Allora gli piace mettere il culo nelle pedate...

Tu amico mio frequenti trentini di la verità :-)

Ciao
Francesco

[Luca Menegotto]

Post by Francesco Da Riva

Post by Luca Menegotto
Allora gli piace mettere il culo nelle pedate...

Tu amico mio frequenti trentini di la verità :-)

Molto meno di quanto vorrei, purtroppo! :-D

[LutherBlissett]

Post by Luca Menegotto
Che poi, scusa, uno si candida per un posto di lavoro, va a fare un colloquio e non ha la vaga idea di dove sta andando a finire? Anno 2023? con tutte le possibilità di documentarsi che ha oggi (30 anni fa era molto peggio)? Allora gli piace mettere il culo nelle pedate...

Vero, ci sono modi di informarsi, ma non arrivano al
dettaglio del singolo ufficio, e neppure della singola BU.
Giustamente scrivi "vaga idea". Si ha l'occasione di capire un
po' di piu' al colloquio.

[Luca Menegotto]

Post by LutherBlissett
Vero, ci sono modi di informarsi, ma non arrivano al
dettaglio del singolo ufficio, e neppure della singola BU.

Ovvio, ma per conoscere l'andazzo, credi, non occorre conoscere il numero di peli del c... del responsabile della BU.

Post by LutherBlissett
Si ha l'occasione di capire un po' di piu' al colloquio.

Ecco, appunto. A te è mai capitato di scappare di corsa? A me una sola volta, per carità, ma è successo.

[rootkit]

Post by Luca Menegotto
Che poi, scusa, uno si candida per un posto di lavoro, va a fare un
colloquio e non ha la vaga idea di dove sta andando a finire? Anno
2023? con tutte le possibilità di documentarsi che ha oggi (30 anni fa
era molto peggio)? Allora gli piace mettere il culo nelle pedate...

Vero, ci sono modi di informarsi, ma non arrivano al dettaglio del
singolo ufficio, e neppure della singola BU. Giustamente scrivi "vaga
idea". Si ha l'occasione di capire un po' di piu' al colloquio.

al colloquio tecnico hai modo di capire parecchio visto che parli con i
potenziali colleghi. basta prepararsi le domande prima e non andare a
braccio.

[M C]

Post by rootkit
in genere noi (ma ripeto, è un ambito diverso) prepariamo dei problemi che
diamo come compito a casa al primo colloquio tecnico

+1

oltre al code review, facciamo cosi anche noi

[M C]

Post by Booze
Di recente ho fatto un test preliminare su test gorilla.

[...]


tutto normale
in qualche modo devono scremare la gente sennó perdono un sacco di tempo
con le mezze seghe

si accollano il rischio di scremare anche quelli bravi che hanno la
memoria di una scimmia ubriaca, evidentemente alla fine i numeri portano
sennó le aziende non li utilizzerebbero questi tool

a parte i vari Codility e IKM mi é capitato di fare un colloquo,
superato, con un'ora di tempo e i due tipi attaccati al collo come
mignatte, a codificare un parser CSV+JSON in una specie di notepad su
browser che aveva il pulsante per lanciare javac + java con output sul
browser. Niente check della sintassi, niente autocompletamente, niente
import automatici, niente librerie fighe, tutto a manella