Sì, da sottoscrivere, a parte il discorso di riempirli di domande, se si intendeva durante i primi colloqui: serve (relativamente) chiedere qualcosa (al colloquio, se era quello che si intendeva), che tanto l’intervistatore risponde con spot pubblicitari (“Gli aumenti non serve chiederli: premiamo tutti gli anni i più produttivi” - come no: il figlio del capo e quello che lavora anche il giorno di natale. Tu quel giorno lì hai mangiato in famiglia? Male, per te niente. O “farai tanti corsi, avrai tutti gli strumenti, non sarai mai da solo”. Primo giorno: conosci il linguaggio ipsilon? No? Va bene, d’altronde è uscito ieri. Guarda: qui c’è un sito con tre slide che ne parla. Leggi e impara a memoria, che tra 20 minuti si va dal cliente e lo devi convincere che tu sei il massimo esperto in materia… Gli dici che ci lavori da 5 anni…) .

Meglio chiedere (e nella guida si dice) a chi è lì intorno, sperando però di non beccare un capo (che se non conosci nessuno, non lo sai con chi stai parlando, e una volta ho fatto anche questo: ho chiesto a un tizio: “dimmi la vertà , come si sta qui?” mi ha risposto “io mi trovo bene”. Era il capo a cui mi avrebbero assegnato, proprio quello delle tre slide e del cliente a cui far credere che ero il dio di una cosa mai vista prima…).

Chiedere anche poi, se si resta, perché nessuno nasce imparato sulle convenzioni e sulle regole locali, e persino gli indirizzi delle macchine, le credenziali di accesso, i percorsi dove stanno le cose che ti servono (dai documenti ai db al codice sorgente) sono cose che non sai se sei appena arrivato. Ma queste sono domande che fai da dentro - okay, nel periodo di prova - e sì, se trovi un muro di gomma, meglio che riprendi subito a fare colloqui. Magari l’autore della guida intendeva proprio questo e non l’avevo capito solo io?

Fondamentale il consiglio di darsi da fare, almeno i primi tempi (=anche quattro anni) frequentando siti di programmazione, capire che problemi (tecnici) incontrano i colleghi e come si risolvono, e poi anche guardare alle nuove tecnologie (o anche alle mode, secondo alcuni) e lanciarsi a sperimentare per imparare a muoversi coi vari strumenti.

Comunque manca una parte:

quando sei un vero junior, ti serve di accettare anche situazioni non bellissime, perché con zero esperienza lavorativa, non troverai facilmente e porte aperte nel gotha o nel nirvana dell’informatica (o comunque, pure lì partiresti come codemonkey).

L’importante è non fermarsi se , dopo 6 mesi/un anno, sei ancora a fare le stesse cose che facevi prima e male allo stesso modo con un ambiente intorno che non ti supporta per nulla.

Allora bisogna cominciare a valutare la situazione presente e anche guardarsi intorno, per capire se lì o da qualche altra parte la situazione potrebbe essere diversa, anche in termini di retribuzione, ma (soprattutto) di qualità del lavoro o di affiatamento del team (che potrei raccontare cose turche su questo e la sua importanza). Il problema del giovanissimo è che certe cose se non le vivi può darsi proprio non te le aspetti e poi, quando ci sei dentro, fai fatica a uscirne.

Il titolo però è classista: non è vero che solo laureandi in informatica e in ingegneria informatica possono fare questo mestiere.

Ora, non vorrei scioccare nessuno, ma ci stanno persone che hanno imparato studiando e facendo anche senza dare esami. E lo hanno fatto pure anni prima.

Cioè, il giovane fresco di studi (che di base son già vecchi di almeno un anno o due) arriva e il senior accanto a lui ha poco più della sua età (ed è pure in gamba, che son 5/7/9 anni che lavora lì).
Guardate che succede davvero.