Una guida di sopravvivenza di ingegneria del software

Risorse che ti aiuteranno all'inizio della tua carriera

I primi anni della mia carriera sono stati un periodo di intenso apprendimento.

Ho incontrato la realtà di essere un ingegnere del software e ho dovuto acquisire molte competenze di cui non sapevo di aver bisogno. Guardando indietro, sarebbe stato bello conoscere le cose che so adesso.

Quindi, ho scritto questa guida per aiutare gli altri sulla base delle esperienze degli sviluppatori che ho seguito nei loro primi anni come professionisti, e di me e di alcuni miei colleghi.

Tratterò:

  • Come trarre il meglio dalle interviste,
  • Come sopravvivere (e prosperare) nel tuo lavoro di ingegnere del software,
  • E quali risorse esaminare quando si considera il miglioramento continuo.

interviste

Quando inizi la tua carriera nell'ingegneria del software, dovrai affrontare un fatto indiscutibile. Le interviste fanno schifo.

Possono essere terribili per tutti i soggetti coinvolti. Essendo stato sia un intervistatore che un intervistato, posso attestare che le interviste sono un grande spreco di tempo, estremamente stressante e un pessimo indicatore delle prestazioni lavorative future. Tuttavia, sono un male necessario per cui è meglio che tu e il tuo curriculum siate preparati.

Prepararsi alla battaglia

Se stai prendendo in considerazione una carriera in Ingegneria del Software, assicurati di imparare alcune delle domande più frequenti sul colloquio di programmazione, come "FizzBuzz":

"Scrivi un programma che stampa i numeri da 1 a 100. Ma per multipli di tre stampa" Fizz "invece del numero e per multipli di cinque stampa" Buzz ". Per i numeri multipli di tre e cinque, stampa "FizzBuzz". "
(Coding Horror)

Sembra abbastanza semplice, giusto?

Bene, la stragrande maggioranza degli intervistati fallisce questo semplice test, per non parlare delle sue varianti più complesse.

Ho visto personalmente molti candidati per posizioni senior fallire questo test pur avendo accesso completo a Internet. Quindi assicurati che se un linguaggio di programmazione è elencato sul tuo curriculum, sai come fare almeno FizzBuzz in esso. Altrimenti, stai solo sprecando il tempo di tutti, incluso il tuo.

Naturalmente, per sopravvivere alle tue interviste dovrai conoscere più di FizzBuzz. Devi anche assicurarti di sapere:

  • Strutture di dati e algoritmi di base: come elenchi collegati, array, alberi e specie.
  • "Gotcha" comuni nella tua lingua preferita, ad esempio se le stringhe sono immutabili e come viene gestita la memoria.
  • Concetti di programmazione orientata agli oggetti come classe contro oggetto ed ereditarietà.

All'inizio della tua carriera, dovrai brillare su questo tipo di domande, poiché non hai le esperienze per dimostrare che sarai bravo nel lavoro. Ci sono due risorse che consiglio sempre quando mi preparo per le interviste:

  • "Cracking the Coding Interview", un libro fantastico che include molti problemi di codifica e le loro soluzioni, oltre a riassunti di ciò che devi sapere per risolverli
  • CodeWars, un sito Web che presenta una vasta raccolta di problemi di codifica che è possibile risolvere nel browser utilizzando un'ampia selezione di lingue. La parte più utile è vedere come gli altri utenti hanno risolto lo stesso problema. Vedrai approcci diversi allo stesso problema e apprenderai nuovi strumenti nella lingua che preferisci.

Concediti quel vantaggio in più

Ci sono diverse cose che puoi fare che ti daranno quel qualcosa in più.

Innanzitutto, impara a comunicare le tue esperienze. Dovresti avere un pitch dell'ascensore che riassuma il tuo curriculum in una narrazione coerente e coinvolgente.

Inoltre, conosci il tuo curriculum! Sembra sciocco, ma ho visto molti intervistati fare fatica a spiegare un particolare argomento nel loro curriculum. Dovresti essere in grado di rispondere alle domande su qualsiasi esperienza che elenchi sul tuo curriculum e spiegare come ti ha reso un candidato migliore per il lavoro.

Quindi, avere esempi di codice da mostrare su GitHub (o su un altro repository pubblico).

Vedere è credere e gli intervistatori che sono in grado di vedere il tuo codice faranno miracoli. Inoltre, mostra di avere una comprensione dei sistemi di controllo della versione.

Gli esempi di codice non devono essere nulla di troppo complesso, ma devono essere puliti e mostrare buone pratiche di codifica. Questa è la tua occasione per mostrare come si codifica senza la pressione del tempo di un'intervista di codifica.

Dopo aver fatto tutto quanto sopra, è tempo di prendere in considerazione la possibilità di partecipare a un progetto open source. Mostrerà che puoi lavorare in una base di codice esistente e collaborare con altri programmatori.

Questo sarà il più vicino possibile alla programmazione in un ambiente industriale senza trovarsi effettivamente in un ambiente industriale. Questo è di gran lunga l'articolo più difficile e che richiede tempo, quindi prenotalo fino a quando non avrai completato il frutto sospeso più basso di cui ho discusso sopra.

Intervistare il tuo intervistatore

Nella fretta e nello stress della ricerca di lavoro, molti candidati dimenticano che il colloquio è una strada a doppio senso. Mentre la società sta cercando di capire se sei la persona giusta per il lavoro, dovresti capire se la società è la soluzione giusta per te.

Assicurati di poter porre alcune delle domande seguenti, anche se si trova in un'email di follow-up. Tieni presente che spesso le aziende potrebbero provare a girare non seguendo le migliori pratiche di ingegneria come vantaggio, quindi leggi tra le righe.

Ecco alcune domande di esempio che potresti porre:

"Come sarebbe una tipica giornata lavorativa per me?"

È importante sapere cosa aspettarsi da una posizione particolare perché i lavori di ingegneria del software variano abbastanza. Ad esempio, è possibile che tu debba mantenere i server o parlare direttamente con i client.

Bandiera rossa: "Non ne sono sicuro." → Significa che le persone che ti intervistano non faranno parte della tua squadra, o non hanno un'idea chiara del perché ti stanno assumendo.

"Come testate il vostro software?"

Idealmente, una combinazione di test unitari, test manuali e test automatici dovrebbe essere utilizzata per verificare la qualità del codice.

Bandiera rossa: "Non scriviamo solo bug, haha." → Quelle persone sono esattamente quelle che scrivono bug.

"Quale sistema di controllo versione usi?"

I sistemi di controllo della versione sono estremamente utili per la collaborazione e ci sono zero motivi per non usarne uno in un ambiente professionale.

Bandiera rossa n. 1: "Uh, sistema di controllo versione?" → Corri lontano, molto lontano.

Usa sempre il controllo versione.

Bandiera rossa n. 2: "" → Indica che molto probabilmente non stanno al passo con i tempi e non hanno aggiornato la loro infrastruttura da molto tempo.

"Fai delle revisioni tra pari?"

Le revisioni tra pari, o il fatto che qualcun altro guardi il tuo codice prima che entri nella base di codice, è un modo fantastico per individuare errori sciocchi ed è un'opportunità di formazione vitale quando inizi la tua carriera.

Bandiera rossa: "Ci fidiamo solo degli altri!" → Molto probabilmente gli sviluppatori senior sono molto protettivi nei confronti del loro codice e non sono bravi a ricevere feedback.

"Quali programmi hai per l'istruzione continua?"

Essere un ingegnere del software significa imparare costantemente come le tecnologie appaiono, maturano e diventano obsolete a un ritmo vertiginoso. Pertanto, molte aziende dispongono di un budget per la formazione che utilizzano per pagare corsi universitari e online, conferenze o conferenze interne.

Bandiera rossa: "Intendi leggere materiale online nel tuo tempo libero?" → L'azienda è a corto di soldi o vede gli sviluppatori come sostituibili e non come investimenti a lungo termine.

"Qual è il processo di sviluppo del software che usi?"

Il processo è vitale per l'ingegneria del software, indipendentemente dai dettagli effettivi. I dettagli di ciò che costituisce un processo ottimale sono soggetti a un intenso dibattito, ma la semplice esistenza di un modo concordato di lavorare su un progetto minimizza il caos e assicura che tutti siano sulla stessa pagina.

Bandiera rossa: "Il nostro processo è ispirato al jazz in forma libera". → Molto probabilmente l'intero dipartimento è in modalità antincendio, saltando da un'emergenza all'altra senza alcun obiettivo chiaro.

"Come affrontare il debito tecnico?"

Il debito tecnico è un accumulo di tecnologie obsolete e soluzioni veloci ma sporche nella base di codice. Affrontarlo è importante per la salute a lungo termine del codice e dovrebbe essere fatto su base continua.

Bandiera rossa: "Siamo concentrati esclusivamente su nuove funzionalità". → La loro base di codice è un casino o lo sarà presto.

"Com'è la cultura della tua azienda?"

La cultura aziendale potrebbe essere un concetto molto vago, ma anche piccole cose come un ufficio aperto rispetto ai cubetti cambieranno la tua interazione quotidiana con i colleghi in modi significativi. Non ci sono bandiere rosse generali, ma assicurati che la loro risposta sia qualcosa con cui puoi vivere per oltre 40 ore alla settimana per anni.

Lavorare come ingegnere del software

A questo punto, se ti sei comportato bene nelle tue interviste e ti è piaciuto il modo in cui gli intervistatori hanno risposto alle tue domande, verrai probabilmente assunto.

Complimenti, sei ufficialmente un ingegnere!

E adesso? Bene, è tempo di riapprendere molte cose sulla programmazione e il funzionamento. E poiché siamo programmatori, iniziamo discutendo il codice.

Buon codice industriale

Un buon codice di settore ha le seguenti proprietà, in questo ordine:

  • Leggibile, perché il codice viene letto e gestito più spesso di quanto non sia scritto. L'intento del codice deve essere chiaro agli altri sviluppatori anni dopo averlo scritto.
  • Difensivo, come nel seguito delle migliori pratiche di codifica difensiva. La codifica difensiva è un argomento a sé stante, ma l'essenziale è: devi assicurarti che l'uso improprio delle classi e dei metodi che hai scritto non porterà al blocco del codice del software.
  • Ottimizzato, che è l'ultimo in questo elenco perché la maggior parte delle volte, non dovrai davvero preoccupartene. Ciò non significa che dovresti scrivere un codice errato che fa qualcosa in O (n³) quando esiste una soluzione lineare. Ma gli sviluppatori sono generalmente ansiosi di provare e ottimizzare eccessivamente quando non ce n'è bisogno, spesso a scapito della leggibilità e della difendibilità del codice. Dovresti sempre essere in grado di dimostrare che una certa ottimizzazione che sacrifica quelle proprietà è effettivamente necessaria.

Ora che sai come scrivere un buon codice di settore:

Non farai molto codice

Potrebbe essere una sorpresa, ma la maggior parte delle volte non scriverai un nuovo codice, ma invece sarai:

  • Debug
  • Lettura del codice esistente
  • Nelle riunioni o scrivendo e-mail
  • Cercando cosa fare in modo da non scrivere codice

Pertanto competenze diverse dalla codifica saranno altrettanto vitali per la tua carriera.

Codice di debug e lettura

  • Avrai bisogno di molto più del debug utilizzando le istruzioni di stampa. Tutte le lingue e gli stack tecnologici ampiamente utilizzati dispongono di una varietà di potenti strumenti. Impara a usarli perché renderanno il tuo debug un gioco da ragazzi e ti faranno risparmiare infinite ore.
  • Comprendi la base di codice. La maggior parte degli stack tecnologici ha una sorta di strumenti per la generazione di grafici di codici che ti aiuteranno a comprendere la struttura della base di codice. Gli IDE aziendali hanno generalmente quella funzionalità integrata. Puoi anche esplorare il codice usando strumenti come ReSharper, grep o Sourcegraph.
  • Comprendi il prodotto. Sarai sorpreso da quanti sviluppatori non sanno come dovrebbe funzionare il software prima di provare a "ripararlo". Leggi la documentazione.

Organizza i tuoi pensieri

Poiché molto del tuo tempo sarà dedicato alla comunicazione, alla ricerca e al multitasking, hai bisogno di alcuni strumenti per aiutarti a mantenere tutto in ordine.

  • Elenchi / attività TODO: la tua azienda dovrebbe già disporre di un software di tasking di qualche tipo, ma aiuta anche ad avere un sistema personale. Usa post-it o software come Trello o Todoist.
  • Note: prendere sempre appunti durante le riunioni, lavorare per migliorare la documentazione esistente e creare una base di conoscenza personale. Usa Evernote, OneNote o un notebook, come ai vecchi tempi. Potrebbe sembrare eccessivo, ma ti ringrazierai un anno dopo quando stai rivisitando quell'oscuro processo di costruzione che ti ha impiegato 3 giorni per capire la prima volta. Non ho mai incontrato un buon ingegnere del software che non ha preso appunti approfonditi.
  • Grafici / visualizzazioni: gli esseri umani sono creature visive e la creazione di grafici di processi e architetture aiuterà te e gli altri a comprendere argomenti complessi. I diagrammi sono particolarmente utili quando comunicano con colleghi non tecnici. Usa Lucidchart, Visio o una lavagna semplice.

Sapere quando utilizzare le librerie

Risposta breve: quasi sempre.

Risposta lunga: il 99% delle volte, non dovresti reinventare la ruota. Nella maggior parte delle posizioni di ingegneria del software, l'implementazione di un particolare tipo di ordinamento è una completa perdita di tempo. Ciò non significa che non dovresti sapere come funzionano gli algoritmi e le strutture di dati che utilizzi, poiché ciò ti aiuterà a decidere cosa usare e quando.

Per essere un ingegnere software efficiente, è necessario comprendere le librerie di cui si dispone. Le librerie standard delle lingue più popolari sono estremamente utili e sono più grandi di quanto ti aspetteresti. Inoltre, la base di codice potrebbe anche utilizzare librerie specializzate aggiuntive. Leggi la loro documentazione e sapere quando usarli.

Non dovresti avere paura di suggerire ulteriori librerie se risparmieranno tempo. Tuttavia, è necessario assicurarsi di scegliere una buona libreria per uso industriale. Una buona biblioteca è:

  • Open source, quindi puoi verificare tu stesso la qualità del codice e potenzialmente correggere bug che sono fondamentali per la tua applicazione.
  • Concesso in licenza con una licenza permissiva come MIT e BSD, quindi la tua azienda non si imbatte in alcun problema utilizzandola. Fai attenzione con GPL, affinché non open source l'intera base di codice per caso.
  • Maturo, ovvero è uscito da un po 'di tempo e ha un ricco set di funzionalità.
  • Mantenuto, con nuove uscite che escono spesso.
  • Utilizzato da altre società o progetti, che funge da timbro di approvazione e garantisce il supporto del settore per la manutenzione continua.

Miglioramento continuo

Oltre ad apprendere le abilità che ti renderanno migliore nel tuo lavoro quotidiano, dovrai anche migliorare continuamente le tue abilità e apprenderne di nuove, al fine di creare nuove opportunità di carriera per te stesso.

Le opportunità di apprendimento sono molte e molte sono abbastanza convenienti:

  • Corsi online: l'opportunità di imparare dai migliori professori sul campo in un formato flessibile non dovrebbe essere persa. Dai un'occhiata a Coursera, Udacity ed edX (tra i tanti) per i corsi che possono integrare le tue abilità esistenti.
  • Master online: una tendenza recente tra le migliori università, i master online sono un modo flessibile per continuare la tua istruzione formale. Sono anche generalmente meno costosi grazie ai titoli universitari, con la maggior parte dei programmi che costano ~ $ 10.000 per l'intero grado. Georgia Tech, UT e UC San Diego sono alcune delle università che offrono tali titoli. Raccomando personalmente il Master online di Georgia Tech di cui mi sono laureato quest'anno.
  • Blog: i blog sono una parte importante della comunità degli sviluppatori (nessuna sorpresa qui, dato che ne stai leggendo uno proprio ora). Blog come Coding Horror, Joel on Software o anche siti Web più divertenti come The Daily WTF possono darti una buona idea di cosa e cosa non fare come Ingegnere del Software. Navigare in mezzo, r / programmazione, HackerNews o altri feed ti porterà anche a buoni articoli e blog.
  • Conferenze: le ultime, ma non meno importanti, le conferenze sono una straordinaria opportunità di apprendimento e dovresti sicuramente trarre vantaggio dal budget di formazione della tua azienda andando a loro. Un elenco molto incompleto di buone conferenze da controllare (insieme al loro argomento): GOTO; (Generale), Strange Loop (Generale), PyCon (Python), CPPCon (C ++), DEF CON (Sicurezza), Fluente (Web dev). Tutti questi hanno anche video di (la maggior parte) discussioni su YouTube in modo che tu possa imparare qualcosa anche se non puoi partecipare!

Spero che questo articolo ti abbia armato con la conoscenza di cosa aspettarti dall'inizio della tua carriera come Ingegnere del Software e ti ha dato gli strumenti per eseguire bene questo entusiasmante viaggio! Grazie per aver letto! Se hai domande o suggerimenti, lascia un commento o tweet a @AlexievValeri.