🥇Come liberarsi dalla paura del primo lavoro

Un'immagine dal film "Harry Potter e il prigioniero di Azkaban"

Il problema di questo mondo è che le persone istruite sono piene di dubbi, mentre gli idioti sono pieni di sicurezza.
Charles Bukowski

Di recente ho tenuto un'altra lezione privata di programmazione. A differenza delle mie solite lezioni, l'argomento non era la progettazione del linguaggio o una sfida di problem-solving. Lo studente ha espresso le sue preoccupazioni riguardo al futuro impiego. Lo studente stesso era piuttosto intelligente. Uno degli studenti che frequenta il corso completa l'intero programma più velocemente di tutti gli altri e propone soluzioni originali, eppure si sottovaluta sinceramente. A mio parere, tali dubbi nascono solo dalla mancanza di informazioni. Ho cercato di colmare questa lacuna con idee estemporanee durante la lezione.

Le domande erano più o meno queste:

Ogni anno, molti studenti si laureano e vanno tutti a cercare lavoro. Sono tanti. Probabilmente prenderanno i migliori, ma io non troverò un posto.
Cosa succede se faccio un errore e vengo licenziato subito?
E se durante il lavoro si accorgessero che sono stupido e mi licenziassero?

Questo studente non era il primo a cui rispondevo a domande simili. Capita a molte persone e di solito devo presentarle senza preparazione. Questa volta ho deciso di scrivere il mio monologo su un quaderno. Pensavo che sarebbe stato un paio di paragrafi, ma alla fine è bastato per un intero articolo.

Questo articolo presenta il mio punto di vista e le mie esperienze. Tuttavia, il nostro mondo è molto vario e accadono cose straordinarie. Se non siete d'accordo con qualcosa o la vostra esperienza è diversa, lasciate un commento.

Questo articolo è stato scritto da uno sviluppatore per sviluppatori. Tuttavia, se intendi lavorare nel testing, nell'amministrazione o in qualsiasi altro ambito IT, alcuni suggerimenti ti saranno utili.

Non ti assumeranno affatto

Immaginare che ogni anno centinaia di studenti si laureano in innumerevoli università diventa inquietante. Come si può competere con una folla così numerosa?

Purtroppo, non tutti i laureati hanno una formazione tecnica sufficiente. Provate a chiedere a qualsiasi studente universitario che conoscete come fanno i suoi studenti a superare gli esami in materie come "Database" o "Fondamenti di Algoritmi e Programmazione". In una classe di 30 studenti, al massimo, ci sono da tre a cinque studenti "avanzati" che hanno fatto tutto da soli. Gli altri si limitano a copiare, memorizzare le risposte e superare l'esame.

Questo è stato il caso quando ho studiato me stesso. Tuttavia, la mia esperienza potrebbe non essere rappresentativa. Quindi ho posto questa domanda a diversi studenti. Le risposte sono state più o meno le stesse. Gli intervistati provenivano da università e college diversi. Lascerò le ragioni di ciò al di fuori dello scopo di questo articolo. Non ho le risorse per uno studio completo, quindi trarrò conclusioni dalle prove disponibili.

Tra centinaia di laureati, solo un paio di dozzine sono di interesse per i datori di lavoro

Pochi laureati possono davvero competere con uno studente capace e ben preparato. Tuttavia, anche se hai studiato con diligenza, probabilmente non verrai assunto dopo il primo colloquio. Lo stesso vale probabilmente per il secondo. Le cose possono andare bene, ma è meglio prepararsi a un assedio piuttosto che a un assalto. Un tentativo di assunzione fallito è solo un'opportunità per imparare dai propri errori e riprovare. Non mi addentrerò nella preparazione al colloquio; molto è già stato scritto sull'argomento online. Dirò semplicemente che ci sono sfumature nei colloqui a cui il tuo programma probabilmente non dedica tempo. Fai delle ricerche su queste informazioni; potrebbero ridurre il numero di tentativi.

La follia è la ripetizione esatta della stessa azione, più e più volte, nella speranza di un cambiamento.
Albert Einstein

Per evitare che i colloqui diventino una follia, devi migliorare dopo ogni nuovo tentativo. Memorizza o scrivi le domande che ti sono state poste durante il colloquio. Quando torni a casa, rivedi questa lista e controlla online. In questo modo, capirai dove tu e l'intervistatore avete sbagliato. Succede anche questo. Ripeti o studia gli argomenti a cui hai risposto male e riprova.

Inoltre, il mercato del lavoro è fortemente stagionale. Le aziende più accorte pianificano le assunzioni in base alle date di laurea. In primavera, ci sono più opportunità per i neolaureati rispetto ad altri periodi. Tuttavia, anche la concorrenza è più elevata in questo periodo.

Stupido, verrai licenziato

Quando si assume una persona senza esperienza, ci sono delle aspettative nei suoi confronti.

Cosa ci si aspetta da un nuovo dipendente sul posto di lavoro:

Conoscenza delle basi tecniche generali
Studiare le specificità dell'area tematica dell'azienda
Padroneggiare gli strumenti e le pratiche utilizzate

Alcune organizzazioni offrono corsi di formazione per i nuovi arrivati sulle tecnologie, gli strumenti e le pratiche locali che utilizzano. Ad esempio, trattano il galateo per l'utilizzo della posta elettronica aziendale, la procedura per la modifica dei documenti wiki e le specifiche locali per lavorare con VCS e il bug tracker.

Esistono anche corsi introduttivi tecnici, ma la loro utilità è discutibile. Se hai trovato lavoro, significa che i datori di lavoro sono convinti che tu abbia un certo livello di conoscenza. È meglio seguire questi corsi con coscienza, come una piccola formalità. Potrebbero effettivamente essere utili.

Quando inizi a lavorare, ricorda che a un principiante non verrà assegnato un compito urgente, complesso e allo stesso tempo importante. Molto probabilmente, sarà uno di questi. Potrebbe essere qualcosa di semplice ma urgente: correggere il layout, inviare un file a qualcuno, riprodurre il problema. Potrebbe essere qualcosa di complesso ma senza alcuna speranza di completamento, solo per far commettere più errori al principiante. Oppure potrebbe essere qualcosa di importante ma sperimentale. Ad esempio, un progetto che tutti desiderano completare da tempo ma non trovano il tempo di implementare.

I compiti per padroneggiare gli strumenti saranno "complessi" e artificiali. Molto probabilmente saranno una versione semplificata del sistema principale. Questi compiti utilizzano lo stesso stack tecnologico e la stessa terminologia di dominio del resto del progetto. Tuttavia, i risultati non saranno condivisi con l'utente finale. Questo può essere demotivante, ma è meglio resistere a questa tentazione. Un compito artificiale deve essere completato coscienziosamente, come se da esso dipendesse il destino del progetto.

Il risultato ottenuto risolvendo il tuo primo compito determinerà la prima impressione che i colleghi che non erano presenti al colloquio avranno di te.

Un altro esempio di attività di padronanza del toolkit è "eseguire un progetto su una macchina locale/ambiente di test". A volte questo processo è descritto nelle istruzioni. Ma queste sono solitamente obsolete e talvolta obsolete. Un progetto può trarre vantaggio dalla scrittura di nuove istruzioni che affrontino eventuali problemi emersi. Probabilmente vi sarà capitato di dover scrivere una relazione di progetto per un corso universitario. Qui è quasi la stessa cosa. Il documento dovrebbe riflettere i passaggi necessari per eseguire il progetto.

In genere, i passaggi per lanciare un prodotto in un ambiente di test sono più o meno i seguenti:

clonare un repository, passare a un ramo o taggare
creare un file di configurazione
preparare la struttura del database
riempilo con i dati di prova
costruire o compilare il progetto,
eseguire una serie di script della console in una sequenza specifica

Durante il processo di esecuzione del sistema in locale, inevitabilmente si verificheranno problemi imprevisti.

La ricerca di soluzioni ai problemi dovrebbe essere aggiunta alle istruzioni di distribuzione. In questo modo, la prossima volta che seguirete le istruzioni, questi problemi non si presenteranno. Quando compilate i file di configurazione e chiamate gli script, prestate attenzione a quale valore viene utilizzato, dove e a cosa deve corrispondere. Ad esempio, se un progetto viene creato utilizzando un sistema di CI e poi eseguito da uno script, è importante capire dove inserire il nome del branch o il numero di commit. A volte, lo script richiede il passaggio di Indirizzi IP oppure il nome DNS del database, il suo login e la sua password. In questo caso, è necessario conoscere l'indirizzo specifico da utilizzare per l'ambiente di test, quali login contiene e quali password specificare per ciascuno di essi.

Alcuni compiti possono sembrare semplici per gli sviluppatori esperti, ma impegnativi per gli stagisti. È normale.

Gli sviluppatori affrontano sfide tecniche ogni giorno. Gli sviluppatori esperti ne hanno già risolte molte, mentre i nuovi arrivati devono ancora padroneggiarle. La tattica migliore è registrare tutti gli errori riscontrati in un documento chiamato "Risoluzione dei problemi per ${nome attività}". Per ogni problema, formula un'ipotesi sulla causa, cerca possibili soluzioni online e provale una per una. Anche i risultati di ogni tentativo dovrebbero essere registrati.

Presentare la tua ricerca in un documento ti consentirà di:

Elimina i piccoli dettagli, come parametri di configurazione, indirizzi DNS/IP, comandi della console e query SQL.
ricordare "cosa ho fatto ieri" quando il compito si estende su più giorni
Non girare a vuoto. Puoi sempre rileggere quello che hai fatto prima e vedere se sei tornato al problema originale.
rispondere chiaramente alla domanda: "Cosa hai fatto oggi?" anche se non esiste ancora una soluzione pronta.

Devi essere in grado di comunicare ai tuoi colleghi lo stato dei tuoi compiti.

Di tanto in tanto, i colleghi si informeranno sui tuoi progressi e condivideranno i loro. A questo scopo, viene dedicato un po' di tempo, ogni giorno o ogni settimana.

Se non tieni traccia dei problemi riscontrati e risolti, la tua descrizione dei tuoi successi suonerà più o meno così: "Ho provato a risolvere il problema, ma non ci riesco. Sto ancora cercando una soluzione". Da una narrazione del genere non è chiaro se il tirocinante abbia effettivamente fatto qualcosa o se stesse solo leggendo Habr. Ha bisogno di aiuto? La situazione è cambiata da ieri?

Se dovessi tenere un documento orientato alla soluzione, potresti dire: "Sto cercando di risolvere questo problema. Ho riscontrato questi errori. Li ho risolti in questo modo. Questo non l'ho ancora risolto. Ho queste ipotesi e possibili soluzioni. Le sto testando ora".

Se un'attività può essere misurata in qualche modo, il suo stato dovrebbe includere dei numeri. Ad esempio, per l'attività "scrivere test unitari per un modulo", si potrebbe dire "Ho intenzione di scrivere 20 test, finora ne ho scritti 10".

Più dettagli fornisci, meglio i tuoi colleghi capiranno cosa hai fatto. Questo favorirà un atteggiamento positivo nei tuoi confronti e permetterà loro di capire se hai bisogno di aiuto o meno.

Sentiti libero di chiedere aiuto

Ho accennato sopra che quando si presenta un problema, è necessario formulare un'ipotesi sulle sue cause e sulle possibili soluzioni. Tuttavia, a volte le ipotesi si rivelano infondate e le soluzioni auto-create non funzionano. In questi casi, è meglio chiedere aiuto. Per evitare di abusare dell'attenzione dei colleghi, è consigliabile lavorare su ogni problema da soli. Se non si riesce a trovare una soluzione entro un paio d'ore, è il momento di chiedere consiglio a colleghi più esperti.

È meglio iniziare con la domanda: "Qualcuno ha già riscontrato questo problema?" e una breve descrizione del problema. È consigliabile allegare un frammento del messaggio di errore o uno screenshot. È consigliabile inoltrare questo messaggio iniziale a una chat di lavoro generale. In questo modo, non si interrompe chi è veramente impegnato. I colleghi liberi vedranno il messaggio e potranno aiutarti.

Se nessuno ti aiuta dopo aver scritto nella chat generale, prova a contattare un collega esperto durante una pausa: pranzo, caffè o tè, una partita a tennis o una sigaretta. Se non funziona, condividi le tue difficoltà durante una riunione o una sessione di stand-up.

Se i problemi noti vengono risolti, la questione potrebbe essere risolta. Tuttavia, se il problema è nuovo, verrà avviata un'indagine e verranno adottate le misure appropriate.

I compiti "importanti" per i principianti, di cui gli utenti finali avranno bisogno, saranno noiosi e di piccole dimensioni. Ad esempio, "aggiungere una colonna aggiuntiva a un report", "correggere un errore di battitura in un modulo stampato" o "implementare un metodo modello per caricare gli attributi client da un DBMS". Lo scopo di tali compiti è familiarizzare il principiante con l'argomento e integrarlo nel lavoro quotidiano.

È importante non solo risolvere tecnicamente il problema, ma anche ampliare la conoscenza dell'argomento.

I termini appariranno nelle descrizioni delle attività, nelle chat e nelle conversazioni. Possono sembrare nomi familiari. Tuttavia, all'interno del sistema informativo, acquisiscono un significato univoco e più preciso. È meglio registrare il significato dei termini scoperti in un documento dedicato: un glossario. Quando si aggiunge un termine al glossario, è sufficiente annotare la propria comprensione del termine, ma per una spiegazione adeguata è meglio consultare un analista. Se non ne è disponibile uno, si consiglia di consultare esperti del progetto. Mantenere un glossario è uno dei modi più semplici per acquisire familiarità con l'area tematica del progetto.

Una volta trovato un terreno comune con i tuoi colleghi, inizieranno a vederti non come un tirocinante alle prime armi, ma come uno specialista alla pari.

Ci sono compiti specifici, come "scrivere test unitari per un modulo". È improbabile che rimarrete bloccati su questo per molto tempo, alla ricerca di soluzioni. Tuttavia, è piuttosto impegnativo e non serve solo a formare il tirocinante. I test scritti aumentano la stabilità del progetto riducendo i bug nell'applicazione e il tempo dedicato ai test umani. In un mondo ideale, i test unitari vengono scritti immediatamente man mano che lo sviluppo procede, ma la realtà, come sempre, è diversa. A volte uno sviluppatore di moduli ha tutto in testa e non vede la necessità di scriverli. "È tutto ovvio, cosa c'è da testare?". A volte i moduli vengono scritti in fretta, non lasciando tempo per i test unitari. Quindi, nel mondo reale, i test unitari potrebbero non esistere. Pertanto, il compito di scrivere i test unitari viene assegnato a un nuovo arrivato. In questo modo, il tirocinante può iniziare a lavorare sul progetto più rapidamente e il progetto può far risparmiare tempo a specialisti più pagati.

A volte, a stagisti e nuovi arrivati viene assegnato il ruolo di tester a pieno titolo. Questo di solito richiede l'implementazione del prodotto localmente e la revisione dei requisiti. Al nuovo dipendente sono richiesti i seguenti requisiti:

Domande come: "Se lo fai in questo modo, verrà fuori così. Questo non è nei requisiti. Come dovrebbe essere?"
attività nel bug tracker "i requisiti sono scritti in questo modo, ma in realtà è diverso."

I test sono un campo troppo vasto per questo articolo. Se ti viene assegnato un compito simile, cerca online il modo migliore per svolgerlo.

Se sbagli, verrai licenziato.

In un'organizzazione normale, se un dipendente inesperto ottiene l'accesso a qualcosa di critico e combina un guaio, la persona che ha permesso che accadesse sarà ritenuta responsabile. Perché un nuovo dipendente non ha accesso alle infrastrutture critiche di default. Con una gestione adeguata, non scaricheranno tutta la colpa su un tirocinante inesperto.

Se succede qualcosa, non ti licenzieranno per un singolo incidente. Si impara dagli errori. Il tirocinante che ha sbagliato ha imparato una lezione preziosa e questo lo distingue dagli altri tirocinanti. Se licenzi chi ha sbagliato, qualcun altro prenderà il suo posto e commetterà un errore altrettanto grave.

La cosa principale è imparare dagli errori e non ripeterli più.

Se una persona non impara dai propri errori, probabilmente verrà licenziata. Il mondo, però, è vario. In alcune organizzazioni criminali, potresti essere buttato fuori dalla finestra al primo errore. Ma è meglio evitare questo tipo di aziende, quindi fai prima qualche domanda o scopri di più durante il colloquio.

È meglio evitare incidenti

Anche se non vieni licenziato per il tuo errore, un incidente del genere causerà problemi indesiderati al tuo team e al progetto nel suo complesso. Pertanto, presta particolare attenzione quando elimini o crei tabelle di database, file, istanze di servizio e documenti nella knowledge base del progetto. Se incontri un nuovo indirizzo di connessione, chiedi conferma ad almeno due persone diverse su cosa puoi fare lì. Verifica le autorizzazioni nei tuoi ambienti non per tentativi, ma eseguendo i comandi appropriati. Ad esempio, controlla le autorizzazioni per eliminare file utilizzando il comando ls, le autorizzazioni per lavorare con le tabelle MySQL utilizzando il comando SHOW GRANTS FOR 'user'@'host'; e così via. Quasi tutti gli strumenti offrono questa funzionalità.

Quando modifichi i file, conserva una copia dell'originale per ogni evenienza.

Tra il tirocinante e il consumatore finale si frappongono diverse barriere.

Se potessi consegnare subito il tuo prodotto al consumatore, saresti libero di abbandonare il lavoro e dedicarti alla libera professione. Ma finché non avrai questa opportunità (e questa responsabilità), dovrai affrontare diverse fasi di supervisione del progetto.
La prima è la revisione da parte del mentore. Valuta la soluzione del nuovo arrivato da un punto di vista tecnico. Se non è stato assegnato un mentore, è necessario trovarne uno. Per farlo, scegli un membro di lunga data del progetto e chiedigli di esaminare la soluzione durante una pausa per verificare se il problema è stato risolto correttamente. Se inizia a guardare e a rispondere, hai trovato un mentore. Se ti ignora, devi chiedere a qualcun altro.

La fase successiva è il Controllo Qualità. In russo, si chiamano tester. In Unione Sovietica, si chiamano controllo qualità e controllo qualità. Devono garantire che il lavoro del tirocinante sia conforme al compito assegnato. Raramente leggono il codice. Il più delle volte, i tester controllano il progetto compilato, che lo sviluppatore salva nel sistema di controllo versione.

La terza fase è quella del release manager. Potrebbe non esserci una persona dedicata a questo compito, ma qualcuno ricopre comunque questo ruolo. Verifica che i tester abbiano confermato che il progetto è pronto per il rilascio. Dopodiché, esegue i passaggi per consegnare il prodotto agli utenti finali.
Nelle piccole organizzazioni, queste barriere possono essere assenti per vari motivi. Tuttavia, non imporranno a un nuovo arrivato di cambiare qualcosa di importante. Perché nessuno vuole correre questo rischio.

Dobbiamo prima entrare nel vivo della lotta, poi vedremo.
Napoleone Bonaparte

Spero che questo articolo ti aiuti a superare la tua esitazione e a inviare il tuo primo curriculum. Certo, dovresti fare i compiti. Ma non rimandare troppo. Probabilmente hai già trascorso diversi anni a studiare all'università. Perché aspettare ancora? Dopotutto, è meglio sentirsi dire "no" da uno specialista una volta e poi lavorare sui propri errori piuttosto che dire "no" a te stesso ogni giorno e bloccare la tua crescita professionale.

Una volta assunto, dovresti concentrarti sulla crescita professionale, passando da stagista a membro a pieno titolo del team. Questa crescita è solitamente accompagnata da un aumento di stipendio.

Vi auguro pazienza e perseveranza.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.