🥇Superiamo la paura del primo impiego

Scena dal film "Harry Potter e il prigioniero di Azkaban"

Il problema di questo mondo è che le persone educate sono piene di dubbi, mentre gli idioti sono pieni di certezze
Charles Bukowski

Di recente ho tenuto un altro incontro individuale di programmazione. A differenza delle lezioni abituali, il tema non è stata la sintassi del linguaggio né un problema di risoluzione. Lo studente ha condiviso le sue preoccupazioni riguardo al futuro impiego. Il ragazzo era abbastanza intelligente. Uno di quelli che partecipano ai corsi, completano il programma più velocemente di tutti e con soluzioni originali, ma che si sottovaluta sinceramente. A mio parere, tali dubbi nascono solo da una mancanza di informazioni. Ho cercato di colmare questa lacuna improvvisando durante la lezione.

Le domande erano più o meno queste:

Ogni anno molte università laureano numerosi studenti e tutti cercano lavoro. Sono davvero molte persone. Sicuramente prenderanno i migliori, e a me non rimarrà posto.
E se faccio un errore e mi licenziano subito?
E se, durante il lavoro, capiscono che sono stupido e mi mandano via?

Questo studente non è stato il primo a cui ho risposto a domande simili. Queste preoccupazioni sorgono in molti e di solito devo raccontare senza preparazione. Questa volta ho deciso di scrivere il mio monologo su un quaderno. Pensavo che sarebbero venuti fuori un paio di paragrafi e invece ne è venuto fuori un intero articolo.

Nell'articolo è descritto il mio punto di vista e basato sulla mia esperienza. Tuttavia, il nostro mondo è molto vario e accadono cose sorprendenti. Se non sei d'accordo con qualcosa o la tua esperienza è diversa, ti prego di lasciare un commento.

L'articolo è stato scritto da un sviluppatore per sviluppatori. Tuttavia, se intendi occuparti di testing, amministrazione o altro nel settore IT, alcuni consigli ti saranno utili.

Non assumeranno affatto

Quando immagini che ogni anno molte università laureano centinaia di studenti, ci si sente a disagio. Come può un singolo competere con una folla così enorme?

Purtroppo, non tutti i laureati hanno una preparazione tecnica sufficiente. Prova a chiedere a qualche studente che conosci dell'università: come fanno le persone nel suo gruppo a ottenere il permesso di sostenere esami in materie come "basi di dati" o "fondamenti di algoritmi e programmazione"? In un gruppo di 30 persone, nel migliore dei casi ci sono 3-5 ragazzi "avanzati" che hanno fatto tutto da soli. Gli altri semplicemente copiano da loro, memorizzano le risposte alle domande e si presentano.

È stato così anche quando studiavo io. Tuttavia, la mia esperienza potrebbe non essere rappresentativa. Per questo motivo, ho posto questa domanda a diversi studenti. La risposta è stata più o meno la stessa. Coloro che hanno risposto provenivano da diversi atenei e college. Non mi dilungherò sulle ragioni, lascerò questo argomento al di fuori di questo articolo. Non ho il tempo per una ricerca completa, quindi tirerò le mie conclusioni dai fatti a disposizione.

Tra centinaia di laureati, solo una manciata è di interesse per i datori di lavoro.

Pochi laureati possono rappresentare una vera concorrenza per uno studente capace con una buona preparazione. Tuttavia, anche se hai studiato diligentemente, dopo il primo colloquio probabilmente non verrai assunto. Probabilmente nemmeno dopo il secondo. Tutto può andare bene, ma è meglio prepararsi non per un attacco, ma per un assedio. Un tentativo di assunzione fallito è solo un'occasione per riflettere sugli errori e riprovare. Non parlerò della preparazione ai colloqui. Su internet è già stato scritto molto al riguardo. Dirò solo che ci sono delle sfumature nei colloqui, per spiegarle alle quali nel tuo programma di studi difficilmente è stato dedicato del tempo. Cerca queste informazioni da solo, potrebbe ridurre il numero di tentativi.

La follia è la ripetizione esatta della stessa azione. Ancora e ancora, nella speranza di un cambiamento.
Albert Einstein

Affinché il processo di superamento dei colloqui non diventi follia, dopo ogni nuovo tentativo è necessario migliorare. Annotate o scrivete le domande che vi sono state poste durante il colloquio. Una volta tornati a casa, rivedete questa lista e verificate voi stessi utilizzando internet. In questo modo capirete dove avete sbagliato voi, dove invece l'intervistatore. Può accadere anche questo. Ripetete o studiate gli argomenti in cui avete avuto difficoltà e riprovate.

Inoltre, esiste una netta stagionalità nel mercato del lavoro. Le aziende ben gestite pianificano le assunzioni tenendo conto delle date di laurea. In primavera ci sono più offerte di lavoro per i principianti rispetto ad altri periodi. Tuttavia, la concorrenza in questo periodo è anche più alta.

Se sei incapace, ti licenzieranno

Quando si assume una persona senza esperienza, ci sono aspettative corrispondenti.

Da un principiante sul lavoro ci si aspetta:

Competenze di base su argomenti tecnici
Studio delle peculiarità del settore dell'azienda
Apprendimento degli strumenti e delle pratiche utilizzate

In alcune organizzazioni, vengono organizzati corsi di formazione per i nuovi arrivati sulle tecnologie, sugli strumenti e sulle procedure locali. Ad esempio, le regole di buona condotta nell'uso della posta aziendale, le modalità di modifica dei documenti su wiki, le peculiarità locali nel lavoro con il VCS e il bug tracker.

Ci sono anche corsi introduttivi tecnici, ma la loro utilità è discutibile. Se si è arrivati all'impiego, significa che i datori di lavoro hanno verificato che si possiede un livello di conoscenze sufficiente. È meglio considerare questi corsi come una formalità da completare diligentemente. Potrebbero anche contenere qualcosa di utile.

Quando inizierai a lavorare, ricorda che non verrà probabilmente assegnato a un principiante il compito di risolvere un problema urgente, complesso e allo stesso tempo importante. Probabilmente ci sarà solo una di queste caratteristiche. O un compito semplice ma urgente: sistemare il layout, inviare a qualcuno un certo file, riprodurre un problema. O un compito complesso ma senza nessuna speranza di completamento — solo per far sì che il principiante accumuli esperienza. O un compito importante ma sperimentale. Ad esempio, un progetto che tutti desiderano da tempo ma non possono dedicare tempo per la realizzazione.

I compiti per apprendere gli strumenti saranno "complessi" e artificiali. Probabilmente sarà una versione semplificata del sistema principale. In questi compiti si utilizzerà lo stesso stack tecnologico e gli stessi termini del settore, proprio come nel resto del progetto. Tuttavia, il risultato finale non sarà consegnato all'utente finale. Questo può demotivare, ma è meglio resistere a questa sensazione. Un compito artificiale deve essere svolto con serietà, come se dipendesse il destino del progetto.

Il risultato della soluzione del tuo primo compito darà la prima impressione di te ai colleghi che non erano presenti al colloquio.

Un'altra opzione per padroneggiare gli strumenti è "avviare un progetto sulla macchina locale / ambiente di test". A volte questo processo è descritto in una guida. Ma di solito sono obsolete e in parte non aggiornate. Può essere utile al progetto scrivere una nuova guida con chiarimenti sui problemi emersi. Sicuramente, all'università hai dovuto scrivere relazioni per alcuni corsi. Qui è quasi la stessa cosa. Il documento deve riflettere le azioni da compiere per l'avvio.

Di solito, le azioni per avviare un prodotto nell'ambiente di test sono più o meno le seguenti:

clonare il repository, passare a un ramo o a un tag
preparare un file di configurazione
preparare la struttura del database
popolarlo con dati di test
eseguire la build o la compilazione del progetto,
avviare una serie di script console in una sequenza specifica

Nel processo di avvio del sistema in locale, sorgere inevitabilmente problemi imprevisti.

Le soluzioni trovate ai problemi devono essere aggiunte alla guida di implementazione. In questo modo, la prossima volta che seguirai la guida, questi problemi non si presenteranno più. Quando compili i file di configurazione e chiami gli script, presta attenzione a quali valori vengono utilizzati e con cosa devono corrispondere. Ad esempio, se il progetto viene compilato utilizzando un sistema CI e poi eseguito tramite uno script, è importante capire dove scrivere il nome del ramo o il numero del commit. A volte, lo script prevede la trasmissione Indirizzi IP o del nome DNS del database, il suo nome utente e la password. In tal caso, è necessario sapere quale indirizzo utilizzare per l'ambiente di test, quali nomi utente sono disponibili e quali password devono essere specificate per essi.

Alcuni compiti possono sembrare semplici per sviluppatori esperti e difficili per gli stagisti. È un fenomeno normale.

Gli sviluppatori devono affrontare quotidianamente problemi tecnici. I dipendenti esperti hanno già risolto molti problemi in passato, mentre i nuovi arrivati devono ancora affrontarli. La migliore tattica è annotare tutti gli errori riscontrati nel documento "soluzione dei problemi con ${название задачи}". Per ogni problema è necessario formulare un'ipotesi sulla causa, cercare online le possibili soluzioni e provarle a turno. Bisogna registrare anche i risultati di ogni tentativo.

Presentare le tue ricerche sotto forma di documento ti permetterà di:

scaricare dalla mente i dettagli minori. Ad esempio, i parametri di configurazione, gli indirizzi DNS/IP, i comandi da console e le query SQL.
ricordare "cosa ho fatto ieri" quando un compito si protrae per diversi giorni
non vagare in cerchio. Potrai sempre leggere cosa hai fatto in precedenza e capire che sei tornato al problema iniziale.
rispondere chiaramente alla domanda: "cosa hai fatto oggi?" anche se non c'è ancora una soluzione pronta.

Devi saper comunicare lo stato dei tuoi compiti ai colleghi.

Periodicamente, i colleghi saranno interessati ai tuoi progressi e condivideranno i loro. Ogni giorno o ogni settimana si dedica un po' di tempo a questo.

Se non monitori i problemi riscontrati e risolti, la tua descrizione dei progressi sembrerà: "Ho cercato di completare il compito, ma non ci riesco. Al momento sto cercando una soluzione." Da questo racconto non è chiaro se il tirocinante ha fatto qualcosa o se è rimasto a leggere su Habra. Ha bisogno di aiuto? La situazione è cambiata rispetto a ieri?

Se tieni un documento con la ricerca delle soluzioni, potrai dire: "Sto cercando di completare questo compito. Ho riscontrato tali errori. Ne ho risolti alcuni in questo modo. Con questo non ce l'ho ancora fatta. Ho alcune ipotesi e opzioni di soluzione. Ora le sto verificando."

Se il compito può essere misurato in qualche modo, lo stato dovrebbe includere dei numeri. Ad esempio, per il compito "scrivere test unitari per il modulo" puoi dire "ho in programma di fare 20 test, ne ho già scritti 10."

Più dettagli fornisci, meglio i tuoi colleghi comprenderanno cosa hai fatto. Questo formerà nei colleghi una percezione positiva nei tuoi confronti e permetterà loro di capire se hai bisogno di aiuto o meno.

Non esitare a chiedere aiuto.

In precedenza ho scritto che, quando si presenta un problema, è necessario formulare un'ipotesi sulle sue cause e opzioni di soluzione. Tuttavia, a volte le ipotesi non si rivelano corrette e le soluzioni trovate autonomamente non funzionano. In tal caso, è meglio chiedere aiuto. Per non abusare dell'attenzione dei colleghi, è opportuno riflettere su ogni problema da soli. Se dopo un paio d'ore non si trova una soluzione, è il momento di cercare consiglio da colleghi più esperti.

È meglio iniziare con la domanda: «qualcuno ha già affrontato questo problema?» accompagnata da una breve descrizione del problema. È consigliabile allegare un estratto del messaggio di errore o uno screenshot. Questo messaggio è meglio inviarlo per la prima volta in una chat di lavoro comune. In questo modo non interrompi chi è veramente occupato. I colleghi disponibili vedranno il tuo messaggio e potranno aiutarti.

Se dopo il messaggio nella chat comune nessuno ha offerto aiuto, prova a contattare un collega esperto durante una pausa: pranzo, pausa tè/caffè, una partita a tennis o una sigaretta. Se non riesci a farlo, allora menziona le tue difficoltà in una riunione o in un stand-up.

Nel caso di problemi noti, qui può finire tutto. Se il problema è nuovo, inizierà un'indagine, e sarà necessario agire in base alle circostanze.

Le «importanti» attività dei nuovi arrivati, che sono necessarie per l'utente finale, saranno noiose e di piccola entità. Ad esempio, «aggiungere una colonna aggiuntiva al rapporto» o «correggere un refuso nel modulo di stampa» o «implementare un metodo del modello per caricare gli attributi del cliente dal DBMS». L'obiettivo di tali compiti è che il nuovo arrivato prenda confidenza con l'argomento e si integri nel lavoro quotidiano.

È importante non solo risolvere il compito tecnicamente, ma anche ampliare le conoscenze relative all'argomento.

Nella descrizione del compito, nelle chat e nelle conversazioni si incontreranno termini. Possono sembrare sostantivi familiari. Tuttavia, nel contesto di un sistema informatico, acquisiscono un significato speciale e più preciso. È meglio registrare il significato dei termini scoperti in un documento specifico: un glossario di termini. Quando si aggiunge un termine al glossario, è sufficiente scrivere la propria comprensione della parola, mentre per una vera spiegazione è meglio rivolgersi a un analista. Se non è disponibile, allora a chi ha più esperienza nel progetto. Tenere un glossario di termini è uno dei modi più semplici per avvicinarsi al dominio del progetto.

Non appena troverete un linguaggio comune con i colleghi, inizieranno a vedervi non come un tirocinante alle prime armi, ma come un professionista alla pari.

Ci sono compiti particolari, come "scrivere test unitari per il modulo". È improbabile che ci si possa fermare a lungo a cercare soluzioni per questo. È comunque un compito piuttosto serio e non è destinato solo alla formazione del tirocinante. I test scritti aumentano la stabilità del progetto riducendo i bug nell'applicazione e diminuendo il tempo di test da parte delle persone. In un mondo ideale, i test unitari vengono scritti contemporaneamente allo sviluppo, ma la realtà è sempre diversa. A volte, lo sviluppatore del modulo tiene tutto in mente e non vede la necessità di scriverli. "È tutto ovvio, cosa c'è da testare qui?" A volte i moduli vengono scritti in modalità frenetica e non c'è tempo per i test unitari. Quindi, nel mondo reale, i test unitari potrebbero non esserci. Pertanto, il compito di scrivere test unitari viene assegnato a un novizio. In questo modo, il tirocinante può ambientarsi più rapidamente nel progetto, mentre il progetto può risparmiare tempo per specialisti più pagati.

A volte, ai tirocinanti e ai principianti viene assegnato il ruolo di tester a pieno titolo. Di solito, prima di ciò, è necessario installare il prodotto localmente e leggere i requisiti. Come risultato, ci si aspetta dal nuovo dipendente:

domande come "se faccio così, ottengo questo. Non c'è nulla di scritto nei requisiti. Come dovrebbe essere?"
compiti nel sistema di tracciamento dei bug "nei requisiti è scritto così, ma in realtà è diverso".

Il test è un'area di attività estremamente ampia per questo articolo. Se vi è stata assegnata una simile attività, cercate su Internet il modo migliore per eseguirla.

Se commetti errori, ti licenziano.

In un'organizzazione normale, se succede che un dipendente inesperto ottiene accesso a qualcosa di critico e provoca dei danni, la colpa è di chi ha permesso tale situazione. Perché un principiante, di default, non ha accesso all'infrastruttura critica. Con una guida adeguata, non verranno dati la colpa a un tirocinante inesperto.

Se succede qualcosa, non verrà licenziato per un singolo incidente. Le persone imparano dagli errori. Un tirocinante che ha commesso un errore ha ricevuto una lezione preziosa e si distingue notevolmente dagli altri tirocinanti. Se si licenzia chi ha sbagliato, un altro arriverà e commetterà lo stesso errore.

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

Se una persona non trae insegnamenti dai propri errori, allora cercheranno di salutarla. Tuttavia, il mondo è vario. In qualche organizzazione mafiosa, potrebbero buttarlo fuori dalla finestra alla prima sbagliato. Ma è meglio evitare aziende del genere, per cui è consigliabile informarsi in anticipo o saperne di più durante il colloquio.

È meglio non permettere incidenti

Anche se non verrai licenziato per un errore personale, tale incidente porterà problemi indesiderati al tuo team e al progetto nel suo complesso. Pertanto, sii particolarmente attento alle operazioni di eliminazione o creazione di tabelle nel database, file, istanze di servizi e documenti nella base di conoscenze del progetto. Se incontri l'indirizzo di una nuova connessione, verifica almeno con due persone diverse cosa sia consentito fare. Controlla i tuoi diritti negli ambienti non con metodi empirici, ma con i comandi appropriati. Ad esempio, i diritti di eliminazione dei file con il comando `ls`, i diritti di lavoro con le tabelle in mysql con il comando `SHOW GRANTS FOR ‘user’@’host’;` e così via. Praticamente in qualsiasi strumento avrai un'opzione simile.

Quando modifichi file, per precauzione conserva una copia dell'originale.

Tra il tirocinante e il consumatore finale vengono costruiti diversi ostacoli.

Se potessi dare subito il tuo prodotto al consumatore, non avresti bisogno di trovare un lavoro, ma potresti iniziare a navigare in 'libera navigazione'. Ma finché non hai questa possibilità (e la responsabilità), devi passare attraverso diverse fasi di controllo nel progetto.
Il primo è il controllo da parte del tutor. Valuta la soluzione del novizio dal punto di vista tecnico. Se il tutor non è stato assegnato, bisogna trovarlo. A tale scopo, occorre scegliere qualcuno tra i veterani del progetto e, durante la pausa, chiedere di esaminare la soluzione: è stata risolta correttamente? Se inizia a guardare e rispondere, significa che il tutor è stato trovato. Se ignora la richiesta, è il caso di chiedere a qualcun altro.

La fase successiva è il Quality Assurance. In italiano — testatori. In sovietico — controllo qualità e OTK. Devono assicurarsi che il lavoro dell'intern venga soddisfatto rispetto al compito assegnato. Raramente si approfondiranno nel codice. Nella maggior parte dei casi, i testatori verificheranno il progetto raccolto, che lo sviluppatore salva nel sistema di controllo versione.

La terza fase è il manager del rilascio. Potrebbe non esserci una persona dedicata a questo compito, ma il ruolo viene comunque svolto da qualcuno. Controlla che i testatori abbiano confermato che il progetto può essere rilasciato. Dopo di che, esegue le azioni necessarie per consegnare il prodotto agli utenti finali.
Nelle piccole organizzazioni, queste barriere possono mancare per vari motivi. Tuttavia, non sarà assegnato al neofita un compito per modificare qualcosa di importante. Perché questo rischio non è desiderato da nessuno.

Devi prima buttarti nella mischia, e poi si vedrà.
Napoleone Bonaparte

Spero che questo articolo ti aiuti a superare la tua insicurezza e a inviare il tuo primo curriculum. Ovviamente, dovresti prepararti in anticipo. Ma non dovresti procrastinare eccessivamente. Probabilmente hai già studiato per diversi anni all'università o in un college. Quanto ancora vuoi aspettare? Alla fine, è meglio sentire una volta «no» da un esperto e lavorare sugli errori, piuttosto che dire ogni giorno «no» a te stesso e fermarti nella crescita professionale.

Dopo essere stato assunto, devi concentrarti sul diventare un membro a pieno titolo del team. Questa crescita è solitamente accompagnata da un aumento della tua retribuzione.

Ti auguro pazienza e determinazione.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.