Newsgroup: it.lavoro.informatica
Titolo: coding test

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?

Il 23/05/23 21:35, Booze ha scritto:

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.
 
 

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

 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...
 

 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.

 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! 

 a sorpresa.
 
Applausi! QUESTO è il modo corretto per selezionare un tecnico!

 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?

Il 24/05/23 15:38, rootkit ha scritto:

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).
 
 


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...
 

 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.
 


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.
 


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".

 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.

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

 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 :-)
 
 

      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.

 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

 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

 diamo come compito a casa al primo colloquio tecnico
 
+1
 
  oltre al code review, facciamo cosi anche noi

Il 24/05/23 18:04, LutherBlissett ha scritto:

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.
 
 

Il 24/05/23 18:09, Booze ha scritto:

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.
 
 

 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.

 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à.

 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.
 
 


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.
 
 
 
 
 
 
 

Il 25/05/23 08:37, rootkit ha scritto:

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. :)
 
 

 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. 

Il 25/05/23 12:45, Mirko ha scritto:

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.
 
 
 

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

 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.

Il 26/05/23 06:36, CBM64 ha scritto:

al rompicxxxx, ad uno che non bada alla forma  ma all'obiettivo
 
 

 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.
 
 

 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à... :-)

Il 26/05/23 08:29, Mirko ha scritto:

"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".
 
 
 
 

 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.

 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. 
 

 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.
 

 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?

 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...

 Allora gli piace mettere il culo nelle pedate...
Tu amico mio frequenti trentini di la verità :-)
 
Ciao
   Francesco

 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.


Molto meno di quanto vorrei, purtroppo! :-D

 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.


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.