Molti datori di lavoro che pubblicizzano "2-3 anni di esperienza" non sono necessariamente alla ricerca di qualcuno che possa utilizzare una particolare tecnologia (si cita Java EE), ma per qualcuno che ha acquisito i tipi di soft capacità che possono essere acquisite solo lavorando su progetti reali con altri ingegneri, con pressioni reali, rispettando scadenze reali.
Per quanto possa sembrare un cliché, probabilmente avrai bisogno di una ricchezza sproporzionata di conoscenze tecniche per compensare ciò. La mia ipotesi sarebbe che se non sapessi nulla di Java EE, ma avessi diversi progetti per il tuo nome di qualche altro tipo (forse anche progetti non di programmazione), accompagnato da tutti gli errori e le realizzazioni che ottieni lavorando su di loro, tu? Ho una migliore possibilità in quei particolari posti di lavoro perché molti datori di lavoro tendono ad essere più interessati ad assumere qualcuno che capisca le pressioni e le priorità e chi sarà in grado di apprendere tecnologie specifiche lungo il percorso.
-
Ad esempio, il primo progetto a cui ho lavorato mi ha messo in una posizione in cui dovevo lavorare con un altro ingegnere junior con la supervisione del project manager; Entrambi abbiamo sviluppato le nostre rispettive parti senza problemi. Più tardi, abbiamo attraversato una fase di integrazione con il sistema esistente, per cui entrambi avevamo presunto che tutto avrebbe "solo funzionato" - come si è scoperto, l'integrazione è risultata estremamente dolorosa, noiosa, lenta, difficile e ha portato a un enorme numero di difetti e problemi di regressione che si presentano.
Ci siamo anche imbattuti in problemi di "processo di squadra", in cui sono stati trascurati passaggi particolari che hanno causato un'interruzione della comunicazione tra ingegneri e altri stakeholder del progetto - I tester di QA sul progetto erano fuori dal giro e un intero gruppo di problemi non sono stati elevati al responsabile del progetto in tempo per la loro gestione. Alla fine, ci siamo posizionati in una curva di apprendimento ripida con tutti gli strumenti dell'azienda e abbiamo scoperto come funzionava il grande database esistente.
Il risultato finale è stato un ritardo nel progetto e settimane di frustrante rielaborazione mentre abbiamo trascinato decine di migliaia di righe di codice per capire dove avevamo sbagliato e risolto i problemi imprevisti. Questi sono i tipi di errori che ti danno forma come ingegnere e ti rendono molto più bravo nel lavoro di progetto. Sfortunatamente, a nessuno può essere insegnato questo tipo di esperienza da un libro o in un'aula, può essere appresa solo nel modo più duro; e davvero l'unica opportunità di fare qualcosa di simile è coinvolgersi in progetti reali.
Inoltre, il lavoro prevedeva di sporcarsi con script di compilazione, programmi di installazione, strumenti di tracciamento del progetto, creazione di documentazione, ecc. L'intero progetto probabilmente richiedeva meno del 10% di tempo per "creare codice", con l'altro 90% che eseguiva tutto il sostenere il lavoro per assicurarsi che tutto sia giusto. Questo non è raro, ma è qualcos'altro che la maggior parte dei laureati tendono a non essere preparati per quando iniziano per la prima volta (Ogni studente che cammina nel suo primo lavoro in attesa di spendere 7,5 ore al giorno di programmazione ha sempre uno shock quando viene loro chiesto di sedersi e risolvere il loro primo problema "difficile" sepolto da qualche parte tra un milione di righe di codice)
Ci sono certamente un sacco di datori di lavoro là fuori che assumono laureati / junior, e quei datori di lavoro capiscono la necessità di imparare attraverso gli errori (probabilmente saranno anche più che felici di assumere un ingegnere con uno stipendio significativamente più basso di quelli che hanno già avuto diversi anni di continuo apprendimento del "mondo reale"). È una questione di trovare il lavoro giusto e di cogliere l'opportunità giusta per imparare tutte le lezioni difficili per te stesso.