Ohjelmistotekniikan selviytymisopas

Resurssit, jotka auttavat sinua uran alussa

Fabian Grohs “päälle kannettavan tietokoneen” Unsplash-ohjelmassa

Urani ensimmäiset vuodet olivat intensiivisen oppimisen aikaa.

Tutkin ohjelmistoinsinöörin todellisuuden ja piti hankkia monia taitoja, joita en tiennyt tarvitsevani. Taaksepäin katsottuna olisi varmasti ollut kiva tietää asiat, jotka tiedän nyt.

Joten kirjoitin tämän oppaan auttaaksemme muita perustuen kehittäjien kokemuksiin, joita mentoroin heidän parin ensimmäisen vuoden ajan ammattilaisina, sekä itselleni ja joillekin kollegoilleni.

Aion kattaa:

  • Kuinka hyödyntää haastattelut parhaalla mahdollisella tavalla,
  • Kuinka selviytyä (ja menestyä) työstään ohjelmistosuunnittelijana,
  • Ja mitä resursseja on syytä tutkia jatkuvaa parantamista harkittaessa.

haastattelut

Kun aloitat uran ohjelmistosuunnittelussa, joudut kohtaamaan yhden kiistattoman tosiasian. Haastattelut imevät.

Ne voivat olla kauheita kaikille osallistujille. Olen ollut sekä haastattelija että haastattelija, ja voin todistaa, että haastattelut ovat suuri aika-uppoaja, erittäin stressaava ja todella huono indikaattori tulevasta työsuorituskyvystä. Siitä huolimatta, ne ovat välttämätöntä pahaa, johon sinun ja kokoelmasi on paremmin varauduttava.

Valmistaudu taisteluun

Jos harkitset uraa ohjelmistosuunnittelussa, muista oppia joitain yleisimmin kysytyistä ohjelmointihaastattelukysymyksistä, kuten 'FizzBuzz':

"Kirjoita ohjelma, joka tulostaa numerot 1 - 100. Mutta kolmen kerrannaisiksi tulosta" Fizz "luvun sijasta ja viiden kerrannaisiksi" Buzz ". Niille numeroille, jotka ovat sekä kolmen että viiden kerrannaisia, tulostetaan 'FizzBuzz'. "
(Koodaava kauhu)

Kuulostaa riittävän yksinkertaiselta, eikö niin?

No, suurin osa haastateltavista epäonnistuu tässä yksinkertaisessa testissä, puhumattakaan sen monimutkaisemmista muodoista.

Olen henkilökohtaisesti nähnyt, että monet johtaviin virkaehdokkaat epäonnistuvat tässä testissä, kun heillä on täysi Internet-yhteys. Joten varmista, että jos ohjelmointikieli on luettelossa, tiedät miten tehdä ainakin FizzBuzz siinä. Muutoin tuhlaat vain kaikkien, myös sinun, aikaa.

Tietysti sinun on tiedettävä enemmän kuin vain FizzBuzz selviytyäksesi haastatteluistasi. Sinun on myös varmistettava, että tiedät:

  • Perustietorakenteet ja algoritmit: kuten linkitetyt luettelot, taulukot, puut ja lajittelut.
  • Yleinen valitsemallasi kielellä "gotchas", kuten merkkijonot ovat muuttumattomia ja miten muistia hallitaan.
  • Kohteeseen suuntautuneet ohjelmointikäsitteet, kuten luokka tai esine, ja perintö.

Uran alussa sinun on loistettava tällaisille kysymyksille, koska sinulla ei ole kokemuksia todistaaksesi, että olet hyvä työssä. On olemassa kaksi resurssia, joita suosittelen aina haastatteluihin valmistautuessa:

  • ”Cracking the Coding Interview”, upea kirja, joka sisältää paljon koodausongelmia ja niiden ratkaisuja sekä yhteenvetoja siitä, mitä sinun on tiedettävä niiden ratkaisemiseksi
  • CodeWars, verkkosivusto, jolla on suuri kokoelma koodausongelmia, jotka voit ratkaista selaimessa laajan kielivalikoiman avulla. Hyödyllisin osa on nähdä, kuinka muut käyttäjät ratkaisivat saman ongelman. Näet erilaisia ​​lähestymistapoja samaan ongelmaan ja opit uusia työkaluja valitsemallasi kielellä.

Anna itsellesi se lisäreuna

Voit tehdä useita asioita, jotka antavat sinulle vähän jotain ylimääräistä.

Opi ensin kommunikoimaan kokemuksesi. Sinulla tulisi olla hissikorkeus, joka tiivistää ansioluettelosi yhtenäiseksi ja kiinnostavaksi kertomukseksi.

Lisäksi tiedä oma yhteenveto! Se kuulostaa typerältä, mutta olen nähnyt, että monet haastateltavat pyrkivät selittämään tietyn kohteen heidän yhteenvedossaan. Sinun pitäisi pystyä vastaamaan kysymyksiin kaikista kokemuksistasi, jotka olet lukenut yhteenvetoosi, ja selittämään, kuinka se on tehnyt sinusta paremman ehdokkaan työhön.

Seuraavaksi on koodinäytteitä näytettäväksi GitHubissa (tai toisessa julkisessa arkistossa).

Näkeminen on uskovaa, ja haastattelijat voivat nähdä koodisi tekevät ihmeitä. Lisäksi se osoittaa, että sinulla on ymmärrys versionhallintajärjestelmistä.

Koodinäytteiden ei tarvitse olla mitään liian monimutkaisia, mutta niiden on oltava puhtaita ja osoitettava hyviä koodauskäytäntöjä. Tämä on tilaisuutesi näyttää, kuinka koodaat ilman koodaushaastattelun aikapainetta.

Kun olet tehnyt kaikki yllä olevat, on aika harkita osallistumista avoimen lähdekoodin projektiin. Se näyttää, että voit työskennellä jo olemassa olevassa koodikanavassa ja tehdä yhteistyötä muiden ohjelmoijien kanssa.

Tämä on lähin, jonka voit saada ohjelmointiin teollisuusympäristössä ilman, että olet itse teollisuusympäristössä. Tämä on ylivoimaisesti vaikein ja aikaavievin esine tähän mennessä, joten varaa se, kunnes olet valmis viimeistellyt alemmat hedelmät, joista olen puhunut yllä.

Haastattele haastattelijasi

Useat ehdokkaat unohtavat työnhaun kiireessä ja stressissä, että haastattelu on kaksisuuntainen katu. Kun yritys yrittää selvittää, oletko oikea henkilö tähän työhön, sinun tulee selvittää, sopiiko yritys sinulle.

Varmista, että kysyt joitain alla olevista kysymyksistä, vaikka ne olisivat seurannasähköpostiviestissä. Huomaa, että usein yritykset voivat yrittää pyörittää seuraamatta parhaita tekniikan käytäntöjä hankkimiseksi, joten lue rivien välillä.

Tässä on esimerkkejä kysymyksistä, joita voit kysyä:

"Miltä tyypillinen työpäivä näytti minulle?"

On tärkeää tietää, mitä tietyltä paikalta voi odottaa, koska Software Engineering -työt vaihtelevat melko vähän. Saatat odottaa ylläpitävän esimerkiksi palvelimia tai keskustelemaan suoraan asiakkaiden kanssa.

Punainen lippu: “En ole varma.” → Tarkoittaa, että haastattelemasi ihmiset eivät ole joukkueessasi tai heillä ei ole selvää käsitystä miksi he palkkaavat sinua.

"Kuinka testaat ohjelmistosi?"

Ihannetapauksessa tulisi käyttää yksikkötestauksen, manuaalisen testauksen ja automaattisen testauksen yhdistelmää koodin laadun tarkistamiseksi.

Punainen lippu: ”Emme vain kirjoita virheitä, haha.” → Ne ihmiset ovat juuri niitä, jotka kirjoittavat virheitä.

"Mitä versionhallintajärjestelmää käytät?"

Versioiden hallintajärjestelmät ovat erittäin hyödyllisiä yhteistyölle, ja ei ole mitään syitä olla käyttämättä niitä ammatillisessa ympäristössä.

Punainen lippu # 1: “Eikö, versionhallintajärjestelmä?” → Suorita kaukana, kaukana.

Käytä aina versionhallintaa.

Punainen lippu nro 2: “” → Ilmaisee, että he todennäköisesti eivät noudata aikoja eivätkä ole päivittäneet infrastruktuuriaan pitkään.

"Teetkö vertaisarviointeja?"

Vertaisarvioinnit tai jonkun muun tarkasteleminen koodiasi ennen kuin se menee koodikantaan, on loistava tapa havaita typerä virheitä ja on elintärkeä koulutusmahdollisuus uran alkaessa.

Punainen lippu: ”Luotamme vain toisiimme!” → Todennäköisesti vanhemmat kehittäjät suojelevat koodiaan hyvin ja eivät ole hyviä palautteen vastaanottamisessa.

"Mitä ohjelmia sinulla on jatkuvaa koulutusta varten?"

Ohjelmistosuunnittelijana oleminen tarkoittaa jatkuvaa oppimista, kun tekniikat ilmestyvät, kypsyvät ja vanhentuvat huimaavalla nopeudella. Sellaisenaan monilla yrityksillä on koulutusbudjetti, jonka avulla he maksavat yliopisto- ja verkkokursseista, konferensseista tai sisäisistä keskusteluista.

Punainen lippu: ”Tarkoitatko lukemassa juttuja verkossa vapaa-ajallasi?” → Yhtiö on joko rahattu käteen tai pitää kehittäjiä korvattavana eikä pitkäaikaisina sijoituksina.

"Mikä on käyttämäsi ohjelmistokehitysprosessi?"

Prosessi on elintärkeä ohjelmistosuunnittelulle todellisista yksityiskohdista riippumatta. Optimaalisen prosessin yksityiskohdista käydään tiivistä keskustelua, mutta pelkästään sovitun projektityöskentelytavan olemassaolo minimoi kaaoksen ja varmistaa, että kaikki ovat samalla sivulla.

Punainen lippu: ”Prosessiamme inspiroi vapaamuotoinen jazz.” → Todennäköisesti koko osasto on palontorjuntatilassa, siirtymässä hätätilanteesta hätätilaan ilman selkeää tavoitetta.

"Kuinka käsittelet teknistä velkaa?"

Tekninen velka on vanhentuneiden tekniikoiden ja nopea, mutta likaisten ratkaisujen kertyminen koodikantaan. Sen käsitteleminen on tärkeää säännöstön pitkän aikavälin terveydelle, ja sitä tulisi tehdä jatkuvasti.

Punainen lippu: ”Olemme keskittyneet yksinomaan uusiin ominaisuuksiin.” → Heidän koodinsa on sotku tai se tulee pian.

"Millainen on yrityskulttuurisi?"

Yrityskulttuuri voi olla erittäin epämääräinen käsite, mutta jopa pienet asiat, kuten avoin toimisto vs. kaapit, muuttavat päivittäistä vuorovaikutusta kollegoidesi kanssa merkittävällä tavalla. Punaisia ​​lippuja ei ole, mutta varmista, että heidän vastauksensa on sellainen, josta voit elää yli 40 tuntia viikossa vuosien ajan.

Työskentely ohjelmistosuunnittelijana

Jos esiintyit tässä haastattelussa hyvin ja pidit siitä, kuinka haastattelijat vastasivat kysymyksiisi, sinut todennäköisesti palkataan.

Onnittelut, olet virallisesti insinööri!

Mitä nyt? No, on aika kertoa paljon asioita koodauksesta ja työskentelystä. Ja koska olemme ohjelmoijia, aloitetaan keskustelemalla koodista.

Hyvä teollisuuskoodi

Hyvällä teollisuuskoodilla on seuraavat ominaisuudet siinä järjestyksessä:

  • Luettavissa, koska koodi luetaan ja ylläpidetään useammin kuin kirjoitetaan. Koodin tarkoituksen on oltava selkeä muille kehittäjille vuosia sen jälkeen, kun olet kirjoittanut sen.
  • Puolustava, kuten seuraaessaan puolustuskoodauksen parhaita käytäntöjä. Puolustava koodaus on aihe itsessään, mutta sen ydin on: Sinun on varmistettava, että kirjoittamasi luokkien ja menetelmien väärinkäyttö ei johda siihen, että koodi kaatuu ohjelmistoon.
  • Optimoitu, mikä on viimeinen tässä luettelossa, koska suurimman osan ajasta sinun ei todellakaan tarvitse huolehtia siitä. Tämä ei tarkoita, että sinun pitäisi kirjoittaa huono koodi, joka tekee jotain otsikossa (n³), kun lineaarinen ratkaisu on olemassa. Mutta kehittäjät ovat yleensä innokkaita yrittämään ja optimoidakseen liikaa, kun sitä ei tarvita, usein koodin luettavuuden ja puolustettavuuden vahingoksi. Sinun tulisi aina pystyä todistamaan, että tietty optimointi, joka uhraa nämä ominaisuudet, todella tarvitaan.

Nyt kun osaat kirjoittaa hyvän teollisuuskoodin:

Et voi tehdä paljon koodausta

Se voi tulla yllätyksenä, mutta et kirjoita uutta koodia, vaan sinä olet:

  • virheenkorjaus
  • Lukee olemassa olevaa koodia
  • Kokouksissa tai sähköpostien kirjoittamisessa
  • Kun tutkit mitä tehdä, et kirjoita koodia

Siksi muut taidot kuin koodaus ovat yhtä tärkeitä urallesi.

Virheenkorjaus ja lukeminen

  • Tarvitset paljon muutakin kuin virheenkorjauksen käyttämällä tulostettavia lausuntoja. Kaikilla laajalti käytetyillä kielillä ja teknisillä pinoilla on useita tehokkaita työkaluja. Opi käyttämään niitä, koska ne tekevät vianetsinnästä helppoa ja säästät lukemattomia tunteja.
  • Ymmärrä koodikanta. Useimmissa tekniikan pinoissa on jonkinlainen koodigrafiikan luontityökalut, jotka auttavat ymmärtämään koodikannan rakennetta. Enterprise IDE -yrityksissä tämä toiminto on yleensä sisäänrakennettu. Voit tutkia koodia myös työkaluilla, kuten ReSharper, grep tai Sourcegraph.
  • Ymmärrä tuote. Olet yllättynyt, kuinka monet kehittäjät eivät tiedä kuinka ohjelmiston on tarkoitus toimia ennen kuin he yrittävät korjata sen. Lue vain ohjeet.

Järjestä ajatuksesi

Koska suuri osa ajasta vietetään viestintään, tutkimukseen ja monitehtäviin, tarvitset työkaluja kaiken pitämiseksi kunnossa.

  • TODO-luettelot / tehtävät: Yritykselläsi pitäisi jo olla jonkinlainen tehtäväohjelmisto, mutta se auttaa myös henkilökohtaisen järjestelmän luomisessa. Käytä post-it-muistiinpanoja tai ohjelmistoja, kuten Trello tai Todoist.
  • Huomautuksia: Tee muistiinpanoja kokouksissa, paranna olemassa olevaa dokumentaatiota ja luo henkilökohtainen tietopohja. Käytä Evernote-, OneNote- tai muistikirjaa, kuten vanhanaikaisesti. Se voi tuntua ylenmääräiseltä, mutta kiität itseäsi vuotta myöhemmin, kun tarkistat hämärtävää rakennusprosessia, joka kesti 3 päivää selvittääksesi ensimmäisen kerran. En ole koskaan tavannut hyvää ohjelmistosuunnittelijaa, joka ei ole tehnyt laajoja muistiinpanoja.
  • Kaaviot / visualisoinnit: Ihmiset ovat visuaalisia olentoja, ja prosessien ja arkkitehtuurien kaavioiden luominen auttaa sinua ja muita ymmärtämään monimutkaisia ​​aiheita. Kaaviot ovat erityisen hyödyllisiä yhteydenpidossa muiden kuin teknisten kollegoiden kanssa. Käytä Lucidchartia, Visioa tai tavallista taulua.

Tiedä milloin kirjastoja käytetään

Lyhyt vastaus: Melkein koko ajan.

Pitkä vastaus: 99% ajasta, sinun ei pitäisi keksiä pyörää uudelleen. Useimmissa ohjelmistotekniikan tehtävissä tietyn tyyppisen tyypin toteuttaminen on täydellinen ajanhukkaa. Se ei tarkoita, että sinun ei pitäisi tietää, miten käyttämäsi algoritmit ja tietorakenteet toimivat, koska se auttaa sinua päättämään, mitä ja milloin käyttää.

Jotta voit toimia tehokkaana ohjelmistosuunnittelijana, sinun on ymmärrettävä käytettäväsi kirjastot. Suosituimpien kielten standardikirjastot ovat erittäin hyödyllisiä ja ovat suurempia kuin mitä odotit. Lisäksi koodikanta saattaa käyttää myös muita erikoistuneita kirjastoja. Lue heidän ohjeet ja tiedä milloin niitä käytetään.

Sinun ei pitäisi myöskään pelätä ehdottaa lisäkirjastoja, jos ne säästävät aikaa. Sinun on kuitenkin varmistettava, että valitset hyvän kirjaston teollisuuden käyttöön. Hyvä kirjasto on:

  • Avoin lähdekoodi, joten voit itse tarkistaa koodin laadun ja mahdollisesti korjata virheitä, jotka ovat kriittisiä sovelluksellesi.
  • Lisensoitu sallitulla lisenssillä, kuten MIT ja BSD, joten yrityksesi ei aiheuta ongelmia sitä käyttämällä. Ole varovainen GPL: n suhteen, ettet avaa lähdekoodia koko koodikantasi vahingossa.
  • Kypsä, ts. Se on ollut poissa jonkin aikaa, ja siinä on rikas ominaisuusjoukko.
  • Ylläpidetty, uusia julkaisuja ilmestyy usein.
  • Käytetään muissa yrityksissä tai hankkeissa, mikä toimii hyväksymismerkkinä ja varmistaa, että sillä on teollisuuden tuki jatkuvalle kunnossapidolle.

Jatkuva parantaminen

Sen lisäksi, että opit taitoja, jotka tekevät sinusta parempia päivittäisessä työssäsi, sinun on myös jatkuvasti parannettava taitojasi ja opittava uusia, jotta voit luoda uusia uramahdollisuuksia itsellesi.

Mahdollisuuksia oppia on paljon, ja monet niistä ovat melko edullisia:

  • Verkkokurssit: Mahdollisuutta oppia alan parhailta professoreilta joustavassa muodossa ei pidä unohtaa. Katso Coursera, Udacity ja edX (monien joukosta) kursseille, jotka voivat täydentää nykyisiä taitojasi.
  • Online-maisterintutkinnot: Viimeaikaisin trendi huippuluokan yliopistoissa, online-maisterintutkinnot ovat joustava tapa jatkaa muodollista koulutusta. Ne ovat myös yleensä halvempia kiitos kampuksella tutkinto, useimmat ohjelmat maksavat ~ 10 000 dollaria koko tutkinto. Georgia Tech, UT ja UC San Diego ovat joitakin yliopistoja, jotka tarjoavat tällaisia ​​tutkintoja. Suosittelen henkilökohtaisesti Georgia Techin online-mestaria, jonka olen valmistunut tänä vuonna.
  • Blogit: Blogit ovat tärkeä osa kehittäjäyhteisöä (ei yllätys täällä, koska luet sitä juuri nyt). Blogit, kuten Coding Horror, Joel on Software, tai jopa humoristisempia verkkosivustoja, kuten The Daily WTF, voivat antaa sinulle hyvän käsityksen siitä, mitä ja mitä ei tehdä ohjelmistosuunnittelijana. Mediumin, r / ohjelmoinnin, HackerNewsin tai muiden syötteiden selaaminen johtaa myös hyviin artikkeleihin ja blogeihin.
  • Konferenssit: Viimeisenä, mutta ei vähäisimpänä, konferenssit ovat hämmästyttävä oppimismahdollisuus, ja sinun tulisi ehdottomasti hyödyntää yrityksesi koulutusbudjettia menemällä heille. Hyvin epätäydellinen luettelo hyvistä konferensseista (aiheensa ohella): GOTO; (Yleinen), Strange Loop (Yleinen), PyCon (Python), CPPCon (C ++), DEF CON (Turvallisuus), Fluent (Web dev). Kaikilla näillä on myös videoita (useimmista) keskusteluista YouTubessa, joten voit oppia jotain, vaikka et voi osallistua!

Toivottavasti tämä artikkeli on aseistanut sinut tietoon siitä, mitä voit odottaa uransa alusta ohjelmistosuunnittelijana, ja antanut sinulle työkalut menestyäkseen tällä jännittävällä matkalla! Kiitos lukemisesta! Jos sinulla on kysyttävää tai ehdotuksia, jätä kommentti tai twiitti @AlexievValeri.