🥇Liberati dalla 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 certezza.
Charles Bukowski

Di recente ho tenuto una lezione individuale di programmazione. A differenza delle normali lezioni, l'argomento non era la struttura del linguaggio né un problema da risolvere. Lo studente ha condiviso la sua preoccupazione riguardo al futuro impiego. L'allievo era piuttosto brillante. Uno di quelli che frequenta i corsi, completa il programma più velocemente di tutti e con soluzioni originali, ma continua a sottovalutarsi sinceramente. Secondo me, tali dubbi nascono solo da una mancanza di informazioni. Ho cercato di colmare questa lacuna in modo estemporaneo durante la lezione.

Le domande erano più o meno queste:

Ogni anno le università sfornano un gran numero di studenti e tutti vanno a cercare lavoro. Sono davvero molte persone. Sicuramente prenderanno i migliori, e io non troverò 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 la prima persona a cui ho risposto a domande simili. Questi dubbi sorgono per molti, e di solito bisogna raccontare senza preparazione. Questa volta ho deciso di scrivere il mio monologo in un blocco note. Pensavo sarebbero venuti fuori un paio di paragrafi, ma ne è uscita un'intera articolo.

L'articolo descrive il mio punto di vista e la mia esperienza. Tuttavia, il nostro mondo è molto vario e cose sorprendenti possono accadere. Se non concordate con qualcosa o se la vostra esperienza è diversa, vi prego di scrivere un commento.

L'articolo è stato scritto da uno sviluppatore per altri sviluppatori. Tuttavia, se intendete dedicarvi al testing, all'amministrazione o a qualsiasi altra cosa nel campo IT, parte dei suggerimenti vi sarà utile.

Non assumeranno affatto

Quando si pensa che ogni anno molti università diplomino centinaia di studenti, ci si sente a disagio. Come competere con una folla così grande?

Purtroppo, non tutti i laureati possiedono la preparazione tecnica necessaria. Prova a chiedere a qualche studente universitario che conosci: come ottengono l'accesso agli esami in discipline come "basi di dati" o "fondamenti di algoritmi e programmazione"? In un gruppo di 30 persone, al massimo ci saranno 3-5 ragazzi "avanzati" che hanno davvero fatto tutto da soli. Gli altri semplicemente copiano da loro, memorizzano le risposte alle domande e si presentano agli esami.

È stato così anche quando studiavo io. Tuttavia, la mia esperienza potrebbe non essere rappresentativa. Perciò ho posto questa domanda a diversi studenti. Le risposte sono state abbastanza simili. Gli intervistati provenivano da diversi atenei e college. Le considerazioni sulle cause le lascio fuori da 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 ventina suscitano interesse per i datori di lavoro.

Pochi laureati possono realmente competere con uno studente capace e ben preparato. Tuttavia, anche se hai studiato con impegno, dopo il primo colloquio potresti non essere assunto. E neanche dopo il secondo, probabilmente. Tutto potrebbe andare bene, ma è meglio prepararsi a un assedio piuttosto che a un attacco. Un tentativo di assunzione andato a male è solo un motivo per riflettere sugli errori e riprovare. Non parlerò di come prepararsi ai colloqui. Su questo tema sono già state scritte molte cose online. Dico solo che ci sono sfumature nel superare i colloqui, per cui nel programma di studi difficilmente è stato riservato del tempo. Cerca queste informazioni tu stesso, possono ridurre il numero di tentativi.

La follia è ripetere la stessa azione più e più volte, sperando in un cambiamento.
Albert Einstein

Per evitare che il processo di colloquio diventi un incubo, è necessario migliorare dopo ogni nuova situazione. Ricordatevi o annotate le domande che vi sono state poste durante il colloquio. Al ritorno a casa, rivedete questa lista e verificatevi con l'aiuto di internet. Così capirete dove avete sbagliato e dove ha sbagliato l'intervistatore. Anche questo accade. Ripassate o studiate le tematiche in cui avete risposto male e provate di nuovo.

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

Tu sei un incapace — sarai licenziato.

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

Da un neolaureato ci si aspetta:

Conoscenze di base tecniche generali.
Studio delle peculiarità del settore dell'azienda.
Apprendimento degli strumenti e delle pratiche utilizzate.

In alcune organizzazioni, vengono organizzati corsi di formazione per i neofiti sulle tecnologie, gli strumenti e le procedure locali utilizzati. Ad esempio, le regole di buona condotta nell'uso della posta elettronica aziendale, la procedura per la modifica dei documenti nel wiki, le peculiarità locali nell'utilizzo di VCS e del sistema di tracciamento dei bug.

Ci sono anche corsi introduttivi tecnici, ma la loro utilità è discutibile. Se si è arrivati a un colloquio di lavoro, significa che i datori di lavoro hanno verificato che possiedi un certo livello di conoscenze sufficienti. È meglio frequentare questi corsi con diligenza, considerandoli una piccola formalità. Potrebbe esserci davvero qualcosa di utile in essi.

Quando inizierai a lavorare, ricorda che a un principiante difficilmente verrà affidato il compito di risolvere un problema urgente, complesso e allo stesso tempo importante. Probabilmente ci sarà solo una di queste caratteristiche. O sarà qualcosa di semplice ma urgente: correggere il layout, inviare un file a qualcuno, riprodurre un problema. Oppure sarà complicato, ma senza alcuna speranza di completamento, solo per permettere al principiante di accumulare esperienza. O sarà importante ma sperimentale. Ad esempio, un progetto che tutti desiderano da tempo, ma per il quale non possono trovare il tempo per la realizzazione.

Le attività per apprendere gli strumenti saranno 'complesse' e artificiali. Probabilmente sarà una versione semplificata del sistema principale. In tali compiti si utilizzerà lo stesso stack tecnologico e gli stessi termini dell'argomento, come in tutto il progetto. Tuttavia, il risultato non sarà consegnato all'utente finale. Questo può demotivare, ma è meglio resistere a questo stato d'animo. Un compito artificiale deve essere svolto con diligenza, come se il destino del progetto dipendesse da esso.

Il risultato della risoluzione del tuo primo compito darà una prima impressione su di te ai colleghi che non erano presenti all'intervista.

Un'altra opzione per esercitarsi con gli strumenti è "avviare un progetto sulla macchina locale/ambiente di test". A volte questo processo è descritto nelle istruzioni, ma di solito sono obsolete e non del tutto attuali. Puoi dare un vero valore al progetto scrivendo una nuova guida con dettagli sui problemi emersi. Sicuramente all'università hai dovuto scrivere relazioni per vari corsi. Qui è quasi la stessa cosa. Il documento deve riflettere le azioni da compiere per l'avvio.

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

clonare il repository, passare a un certo ramo o tag
creare un file di configurazione
preparare la struttura del database
popolarlo con dati di test
eseguire la build o la compilazione del progetto,
lanciare una serie di script da console in un certo ordine

Durante l'avvio del sistema in locale, sono inevitabili problemi imprevisti.

Le soluzioni ai problemi trovati devono essere annotate nelle istruzioni di distribuzione. In questo modo, la prossima volta che si seguono le istruzioni, questi problemi non si presenteranno più. Durante la compilazione dei file di configurazione e l'invocazione degli script, è importante prestare attenzione a quali valori vengono utilizzati e con cosa devono corrispondere. Ad esempio, se il progetto viene costruito utilizzando un sistema CI e poi eseguito tramite uno script, è fondamentale capire dove inserire il nome del ramo o il numero del commit. A volte, lo script presuppone la trasmissione Indirizzi IP del nome DNS del database, del suo login e della password. In questo caso, è necessario sapere quale indirizzo utilizzare per l'ambiente di test, quali login sono disponibili e quali password devono essere indicate.

Alcuni compiti possono sembrare semplici per gli sviluppatori esperti e creare difficoltà per i tirocinanti. Questo è un fenomeno normale.

Ogni giorno gli sviluppatori devono affrontare problemi tecnici. I membri esperti del team hanno già risolto molti problemi in passato, mentre i nuovi arrivati devono ancora affrontarli. La strategia migliore è annotare tutti gli errori riscontrati nel documento "soluzione dei problemi con ${название задачи}". Per ogni problema, bisogna formulare un'ipotesi sulla causa, cercare online delle soluzioni e provarle una alla volta. È importante annotare anche il risultato di ogni tentativo.

Strutturare le tue ricerche in un documento consente di:

liberare la mente dai dettagli minori. Ad esempio, parametri di configurazione, indirizzi DNS/IP, comandi della console e query SQL.
ricordare "cosa ho fatto ieri" quando un compito si protrae per diversi giorni.
evitare di girare in tondo. Potrai sempre rileggere ciò che hai fatto in precedenza e capire se sei tornato al problema iniziale.
rispondere chiaramente alla domanda: "cosa hai fatto oggi?" anche se non hai ancora trovato una soluzione.

Devi essere in grado di comunicare lo stato delle tue attività ai colleghi.

Periodicamente, i colleghi si interesseranno ai vostri successi e condivideranno i loro. Ogni giorno o settimana si dedica un po' di tempo a questo.

Se non tenete traccia dei problemi incontrati e risolti, la descrizione dei vostri successi suonerà come: «Ho cercato di completare il compito, ma non ci riesco. Sto ancora cercando una soluzione». Da questo racconto non si capisce se il tirocinante stesse facendo qualcosa o semplicemente leggendo Habr. Ha bisogno di aiuto? La situazione è cambiata da ieri?

Tenendo un documento con la ricerca delle soluzioni, si potrà dire «sto cercando di completare questo compito. Ho avuto questi errori. Ho risolto alcuni in questo modo. Questo ancora non l'ho gestito. Ho queste ipotesi e opzioni di soluzione. Adesso le sto verificando».

Se il compito può essere misurato in qualche modo, lo stato dovrebbe contenere dei numeri. Ad esempio, per il compito «scrivere test di unità per il modulo» si può dire «piano di fare 20 test, attualmente ne ho scritti 10».

Più dettagli fornite, meglio i vostri colleghi comprenderanno cosa avete fatto. Questo creerà nei colleghi un atteggiamento positivo verso di voi e permetterà loro di capire se avete bisogno di aiuto o meno.

Non esitate a chiedere aiuto

Come ho scritto sopra, quando si presenta un problema, è necessario formulare un'ipotesi sulle sue cause e possibili soluzioni. Tuttavia, può accadere che le ipotesi non si rivelino valide e che le soluzioni trovate autonomamente non funzionino. In tal caso, è meglio chiedere aiuto. Per non abusare dell'attenzione dei colleghi, è importante riflettere su ogni problema da soli. Se dopo un paio d'ore non si trova una soluzione, è tempo di cercare consigli da colleghi più esperti.

È meglio iniziare ponendo la domanda: «qualcuno ha mai affrontato questo problema prima?» con una breve descrizione del problema. È preferibile allegare un estratto del messaggio di errore o uno screenshot. Questo messaggio è meglio inviarlo per la prima volta in una chat generale di lavoro. In questo modo, non distraete chi è veramente impegnato. I colleghi liberi vedranno il vostro messaggio e potranno aiutare.

Se dopo un messaggio nella chat generale nessuno ha risposto, prova a contattare un collega esperto durante una pausa: pranzo, un giro per un tè/caffè, una partita a tennis o una sigaretta. Se non riesci a farlo, comunica le tue difficoltà durante la riunione o il briefing.

Quando si affrontano problemi noti, potrebbe finire tutto qui. Se si tratta di un problema nuovo, inizierà un'indagine in cui sarà necessario agire secondo le circostanze.

I compiti "importanti" per i principianti, necessari all'utente finale, saranno noiosi e piccoli. Ad esempio, "aggiungere una colonna aggiuntiva al report" o "correggere un errore di battitura nel modulo stampato" o "implementare un metodo del modello per il caricamento degli attributi del cliente dal DBMS". L'obiettivo di questi compiti è che il principiante si familiarizzi con il dominio e si integri nel lavoro quotidiano.

È importante non solo risolvere tecnicamente il problema, ma anche ampliare le conoscenze sul dominio.

Nella descrizione del compito, nei chat e nelle conversazioni, si incontreranno terminologie. Questi possono sembrare sostantivi già familiari. Tuttavia, all'interno del sistema informativo, acquisiscono un significato particolare e più preciso. È consigliabile registrare il significato dei termini trovati in un documento speciale — un glossario dei termini. Quando si aggiunge un termine al glossario, è sufficiente scrivere la propria comprensione della parola; per una vera e propria definizione, è meglio rivolgersi ad un analista. Se non è disponibile, allora è consigliabile contattare i membri esperti del progetto. Tenere un glossario dei termini è uno dei modi più semplici per integrarsi nel 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.

Esistono compiti speciali, come "scrivere test unitari per un modulo". È difficile rimanere bloccati a lungo nella ricerca di soluzioni. Tuttavia, è un compito serio e non è solo per la formazione di un tirocinante. I test scritti aumentano la stabilità del progetto riducendo i bug nell'applicazione e il tempo di testing umano. In un mondo ideale, i test unitari vengono scritti durante lo sviluppo, ma la realtà è sempre diversa. A volte il разработчик del modulo tiene tutto a memoria e non vede la necessità di scriverli. "È ovvio che non c'è nulla da testare qui?" A volte i moduli vengono scritti in modalità di emergenza e non c'è tempo per i test unitari. Quindi, nel mondo reale, i test unitari possono essere assenti. Per questo motivo, il compito di scrivere test unitari viene affidato a un principiante. In questo modo, il tirocinante può ambientarsi più rapidamente nel progetto e quest'ultimo può risparmiare tempo rispetto ai professionisti più pagati.

A volte a tirocinanti e principianti viene assegnato il ruolo di veri e propri testatori. Di solito, prima è necessario configurare il prodotto localmente e leggere i requisiti. Come risultato, dal nuovo dipendente ci si aspetta:

domande come «se facessi così, verrebbe così. Non c'è nulla di scritto nei requisiti. Come dovrebbe essere?»
compiti nel bug tracker «nei requisiti è scritto così, ma in realtà è diverso».

Il testing è un'area di attività eccessivamente vasta per questo articolo. Se ti è stata assegnata una tale task, cerca su Internet il modo migliore per svolgerla.

Se sbagli, verrai licenziato.

In un'organizzazione normale, se mai succedesse che un dipendente inesperto ottiene accesso a qualcosa di critico e causa un danno, la responsabilità ricadrà su chi ha permesso ciò. Perché un neofita di default non ha accesso all'infrastruttura critica. Con una direzione adeguata, non si darà la colpa all'inesperto stagista.

Se succede qualcosa, non licenzieranno per un solo incidente. Dalle errori le persone imparano. Lo stagista che ha sbagliato ha ricevuto una lezione preziosa e si distingue nettamente dagli altri stagisti. Se si licenzia chi ha sbagliato, al suo posto arriverà un altro e sbaglierà nello stesso modo.

La cosa principale è imparare dagli errori e non ripeterli.

Se una persona non impara dai propri errori, il suo percorso potrebbe concludersi. Tuttavia, il mondo è vario. In una certa organizzazione criminale, si potrebbe essere buttati fuori dalla finestra alla prima svista. È meglio evitare tali aziende, per cui è consigliabile raccogliere informazioni in anticipo o chiedere durante il colloquio.

È preferibile evitare gli incidenti

Anche se non verrete licenziati personalmente per un errore, incidenti del genere possono causare problemi indesiderati al vostro team e al progetto nel suo complesso. Pertanto, fate particolare attenzione nelle operazioni di eliminazione o creazione di tabelle nel database, file, istanze di servizi e documenti nella base di conoscenza del progetto. Se voi incontrate un indirizzo per una nuova connessione, verificate con almeno due persone diverse quali operazioni sono consentite. Controllate i vostri diritti negli ambienti non facendo tentativi casuali, ma usando i comandi appropriati. Ad esempio, verificate 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 simili. Praticamente in qualsiasi strumento avrete questa possibilità.

Quando modifichi i file, è consigliabile conservare una copia originale.

Tra il tirocinante e il consumatore finale ci sono diversi ostacoli.

Se potessi consegnare immediatamente il tuo prodotto al consumatore, potresti evitare un lavoro tradizionale e intraprendere un percorso di "libera professione". Ma poiché attualmente non hai questa possibilità (e anche responsabilità), devi passare attraverso diverse fasi di controllo nel progetto.
La prima fase è la revisione da parte di un mentore. Egli valuta la soluzione del neofita dal punto di vista tecnico. Se un mentore non è stato assegnato, è necessario trovarne uno. Per farlo, scegli qualcuno tra i veterani del progetto e chiedi durante una pausa di esaminare la soluzione: la questione è stata risolta correttamente? Se inizia a guardare e a rispondere, significa che hai trovato un mentore. Se ignora, allora è meglio chiedere a qualcun altro.

La fase successiva è il Quality Assurance. In italiano, questo si traduce con 'tester'. In epoca sovietica, si parlava di 'normocontrollo' e 'OTK'. Devono assicurarsi che il risultato del lavoro dello stagista corrisponda al compito assegnato. Raramente si concentreranno sul codice. Più frequentemente, i tester verificheranno il progetto compilato che lo sviluppatore salva nel sistema di controllo versione.

La terza fase è il release manager. Potrebbe non esserci una persona dedicata a questo compito, ma qualcuno ricoprirà comunque il ruolo. Controlla che i tester abbiano confermato che il progetto può essere rilasciato. Dopodiché, esegue le azioni necessarie per consegnare il prodotto agli utenti finali.
In piccole organizzazioni, questi ostacoli potrebbero non esistere per vari motivi. Tuttavia, non verrà mai assegnato a un principiante un compito che comporti modifiche a qualcosa di importante. Perché quel rischio non è accettabile per nessuno.

Bisogna prima lanciarsi 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. Naturalmente, dovresti prepararti in anticipo. Ma non bisogna esagerare con i preparativi. Probabilmente hai già studiato per alcuni anni all'università o in collegio. Quanto tempo puoi ancora perdere? Dopotutto, è meglio ricevere un 'no' da un professionista e lavorare sugli errori piuttosto che dire 'no' a te stesso ogni giorno e fermarti nella tua crescita professionale.

Una volta assunto, devi concentrarti sul passare da stagista a membro a pieno titolo del team. Questo tipo di crescita è solitamente accompagnato da un aumento della tua retribuzione.

Ti auguro pazienza e determinazione.

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