Een software engineering survivalgids

Bronnen die u aan het begin van uw carrière helpen

De eerste paar jaar van mijn carrière waren een tijd van intensief leren.

Ik kwam de realiteit van een software-ingenieur tegen en moest veel vaardigheden leren waarvan ik niet wist dat ik die nodig had. Terugkijkend zou het zeker leuk geweest zijn om de dingen te weten die ik nu weet.

Dus schreef ik deze gids om anderen te helpen op basis van de ervaringen van ontwikkelaars die ik in hun eerste paar jaar als professionals begeleidde, en die van mijzelf en sommige van mijn collega's.

Ik zal het volgende behandelen:

  • Hoe het beste uit interviews te halen,
  • Hoe te overleven (en gedijen) in je werk als software-ingenieur,
  • En welke middelen om naar te kijken bij het overwegen van continue verbetering.

Sollicitatiegesprekken

Wanneer je je carrière in Software Engineering begint, moet je een onbetwistbaar feit onder ogen zien. Interviews zuigen.

Ze kunnen vreselijk zijn voor alle betrokkenen. Omdat ik zowel een interviewer als een geïnterviewde was, kan ik bevestigen dat interviews een grote tijdverspilling zijn, extreem stressvol en een echt slechte indicator voor toekomstige functieprestaties. Niettemin zijn ze een noodzakelijk kwaad waarop jij en je CV beter voorbereid moeten zijn.

Battle voorbereiden

Als u een carrière in software-engineering overweegt, moet u enkele van de meestgestelde vragen over programmeerinterviews leren, zoals ‘FizzBuzz’:

“Schrijf een programma dat de getallen van 1 tot 100 print. Maar voor veelvouden van drie druk‘ Fizz ’in plaats van het nummer en voor de veelvouden van vijf druk‘ Buzz ’. Voor getallen die veelvouden zijn van zowel drie als vijf afdrukken ‘FizzBuzz’. "
(Coding Horror)

Klinkt eenvoudig genoeg, toch?

Welnu, de overgrote meerderheid van de geïnterviewden slaagt niet voor deze eenvoudige test, laat staan ​​voor de meer complexe varianten.

Ik heb persoonlijk gezien dat veel kandidaten voor hogere functies deze test niet doorstaan ​​terwijl ze volledige internettoegang hadden. Zorg er dus voor dat als er een programmeertaal op je CV staat, je weet hoe je er tenminste FizzBuzz in kunt doen. Anders verspil je gewoon ieders tijd, inclusief die van jou.

Natuurlijk moet je meer weten dan alleen FizzBuzz om je interviews te overleven. Je moet er ook voor zorgen dat je weet:

  • Basisgegevensstructuren en algoritmen: zoals gekoppelde lijsten, arrays, bomen en soorten.
  • Veelgebruikte "gotchas" in de door u gekozen taal, zoals of strings onveranderlijk zijn en hoe geheugen wordt beheerd.
  • Object Oriented Programming concepten zoals klasse versus object en overerving.

Aan het begin van je carrière moet je op dit soort vragen schijnen, omdat je niet de ervaring hebt om te bewijzen dat je goed bent in je werk. Er zijn twee bronnen die ik altijd aanbeveel bij het voorbereiden van interviews:

  • "Cracking the Coding Interview", een fantastisch boek dat veel coderingsproblemen en hun oplossingen bevat, evenals samenvattingen van wat u moet weten om ze op te lossen
  • CodeWars, een website met een grote verzameling coderingsproblemen die u in de browser kunt oplossen met behulp van een brede selectie talen. Het handigste is om te zien hoe andere gebruikers hetzelfde probleem hebben opgelost. Je krijgt verschillende benaderingen voor hetzelfde probleem te zien en leert nieuwe tools in de taal van je keuze.

Geef jezelf die extra voorsprong

Er zijn verschillende dingen die je kunt doen die je net dat beetje extra zullen geven.

Leer eerst uw ervaringen te communiceren. Je moet een elevator pitch hebben die je CV samenvat in een samenhangend en boeiend verhaal.

Ken bovendien je eigen CV! Het klinkt gek, maar ik heb veel geïnterviewden zien worstelen om een ​​bepaald item op hun CV uit te leggen. Je zou in staat moeten zijn om vragen te beantwoorden over elke ervaring die je in je cv opsomt en uit te leggen hoe je hierdoor een betere kandidaat voor de functie bent geworden.

Laat vervolgens codevoorbeelden zien op GitHub (of een andere openbare repository).

Zien is geloven, en interviewers die je code kunnen zien, zullen wonderen doen. Bovendien laat het zien dat u inzicht hebt in versiebeheersystemen.

De codevoorbeelden hoeven niet te ingewikkeld te zijn, maar ze moeten wel schoon zijn en goede coderingsmethoden vertonen. Dit is je kans om te laten zien hoe je codeert zonder de tijdsdruk van een coderingsinterview.

Als je al het bovenstaande hebt gedaan, is het tijd om te overwegen om deel te nemen aan een open source-project. Het laat zien dat je in een bestaande codebasis kunt werken en met andere programmeurs kunt samenwerken.

Dit komt het dichtst in de buurt van programmeren in een industriële omgeving zonder daadwerkelijk in een industriële omgeving te zijn. Dit is tot nu toe verreweg het moeilijkste en meest tijdrovende item, dus reserveer het totdat je het lager hangende fruit hebt voltooid dat ik hierboven heb besproken.

Interviewen met je interviewer

In de haast en stress van de zoektocht naar een baan vergeten veel kandidaten dat sollicitatiegesprekken tweerichtingsverkeer is. Omdat het bedrijf probeert te achterhalen of u de juiste persoon voor de baan bent, moet u erachter komen of het bedrijf geschikt is voor u.

Zorg ervoor dat u enkele van de onderstaande vragen kunt stellen, zelfs als het in een vervolg-e-mail staat. Houd er rekening mee dat bedrijven vaak proberen te draaien en de beste technische werkwijzen niet als een voordeel volgen, dus lees tussen de regels door.

Hier zijn enkele voorbeeldvragen die u zou kunnen stellen:

"Hoe zou een typische werkdag er voor mij uitzien?"

Het is belangrijk om te weten wat je van een bepaalde functie kunt verwachten, omdat de taken van Software Engineering nogal verschillen. Van u wordt bijvoorbeeld verwacht dat u servers onderhoudt of rechtstreeks met klanten spreekt.

Rode vlag: "Ik weet het niet zeker." → Betekent dat de mensen die u interviewen niet in uw team zullen zitten, of dat ze geen duidelijk idee hebben waarom ze u inhuren.

"Hoe test je je software?"

Idealiter zou een combinatie van unit-testen, handmatig testen en geautomatiseerd testen moeten worden gebruikt om de kwaliteit van de code te verifiëren.

Rode vlag: "We schrijven gewoon geen bugs, haha." → Die mensen zijn precies degenen die bugs schrijven.

"Welk versiebeheersysteem gebruikt u?"

Versiebeheersystemen zijn uiterst nuttig voor samenwerking en er zijn nul redenen om er geen in een professionele omgeving te gebruiken.

Rode vlag # 1: "Uh, versiebeheersysteem?" → Ren ver, ver weg.

Gebruik altijd versiebeheer.

Rode vlag # 2: "" → geeft aan dat ze de tijden waarschijnlijk niet bijbenen en hun infrastructuur al lang niet hebben bijgewerkt.

"Doe je peer reviews?"

Collegiale recensies of iemand anders je code laten bekijken voordat deze de codebasis ingaat, is een fantastische manier om dwaze fouten te ontdekken en is een essentiële trainingsmogelijkheid bij het starten van je carrière.

Rode vlag: "We vertrouwen elkaar gewoon!" → Zeer waarschijnlijk dat de senior ontwikkelaars hun code zeer beschermen en niet geweldig zijn in het ontvangen van feedback.

"Welke programma's heb je voor permanente educatie?"

Software-engineer zijn betekent constant leren wanneer technologieën verschijnen, volwassen worden en in een duizelingwekkend tempo verouderd raken. Als zodanig hebben veel bedrijven een opleidingsbudget dat ze gebruiken om te betalen voor universitaire en online lessen, conferenties of interne gesprekken.

Rode vlag: "Je bedoelt dingen online lezen in je vrije tijd?" → Het bedrijf zit vast voor geld of ziet ontwikkelaars als vervangbaar en niet als langetermijninvesteringen.

"Wat is het softwareontwikkelingsproces dat u gebruikt?"

Proces is van vitaal belang voor software engineering, ongeacht de feitelijke details. De bijzonderheden van wat een optimaal proces vormt, zijn onderwerp van intens debat, maar alleen al het bestaan ​​van een afgesproken manier van werken aan een project minimaliseert chaos en zorgt ervoor dat iedereen op dezelfde pagina zit.

Rode vlag: "Ons proces is geïnspireerd op free-form jazz." → Hoogstwaarschijnlijk bevindt de hele afdeling zich in de brandweermodus en springt van nood naar nood zonder duidelijk doel.

"Hoe pak je technische schulden aan?"

Technische schuld is een opeenstapeling van verouderde technologieën en snelle maar vuile oplossingen in de codebasis. De aanpak ervan is belangrijk voor de gezondheid van de code op de lange termijn en moet op een continue basis worden gedaan.

Rode vlag: "We zijn exclusief gericht op nieuwe functies." → Hun codebasis is een puinhoop of het wordt binnenkort.

"Hoe ziet uw bedrijfscultuur eruit?"

Bedrijfscultuur is misschien een heel vaag concept, maar zelfs kleine dingen zoals een open kantoor versus cabines zullen uw dagelijkse interactie met collega's op belangrijke manieren veranderen. Er zijn geen algemene rode vlaggen, maar zorg ervoor dat hun antwoord iets is waarmee je jarenlang meer dan 40 uur per week kunt leven.

Werken als Software Engineer

Als je in dit stadium goed hebt gepresteerd in je interviews en het leuk vond hoe de interviewers je vragen beantwoordden, word je waarschijnlijk aangenomen.

Gefeliciteerd, je bent officieel een ingenieur!

Wat nu? Nou, het is tijd om veel dingen opnieuw te leren over coderen en werken. En omdat we programmeurs zijn, laten we beginnen met het bespreken van code.

Goede industriecode

Goede industriecode heeft de volgende eigenschappen, in die volgorde:

  • Leesbaar, omdat code vaker wordt gelezen en onderhouden dan geschreven. De bedoeling van de code moet duidelijk zijn voor andere ontwikkelaars, jaren nadat u deze hebt geschreven.
  • Defensief, zoals bij het volgen van best practices van defensieve codering. Defensieve codering is een onderwerp op zich, maar de kern ervan is: je moet ervoor zorgen dat oneigenlijk gebruik van klassen en methoden die je hebt geschreven er niet toe leidt dat je code de software crasht.
  • Geoptimaliseerd, wat als laatste op deze lijst staat, omdat u zich meestal geen zorgen hoeft te maken. Dat betekent niet dat je slechte code moet schrijven die iets doet in O (n³) wanneer er een lineaire oplossing bestaat. Maar ontwikkelaars willen over het algemeen graag proberen te overoptimaliseren wanneer dat niet nodig is, vaak ten koste van de leesbaarheid en verdedigbaarheid van de code. U moet altijd kunnen bewijzen dat een bepaalde optimalisatie die deze eigenschappen opoffert, daadwerkelijk nodig is.

Nu je weet hoe je goede industriecode moet schrijven:

U zult niet veel coderen

Het komt misschien als een verrassing, maar meestal schrijf je geen nieuwe code, maar in plaats daarvan zul je:

  • debugging
  • Bestaande code lezen
  • In vergaderingen of e-mails schrijven
  • Onderzoekend wat te doen zodat u geen code schrijft

Daarom zijn andere vaardigheden dan codering net zo belangrijk voor je carrière.

Code debuggen en lezen

  • U hebt veel meer nodig dan foutopsporing met behulp van afdrukafschriften. Alle veelgebruikte talen en technische stacks hebben verschillende krachtige tools. Leer ze te gebruiken omdat ze debuggen een fluitje van een cent maken en u talloze uren besparen.
  • Begrijp de codebasis. De meeste technische stacks hebben een soort codegrafiek-generatietools die u helpen de structuur van de codebasis te begrijpen. Enterprise IDE's hebben over het algemeen die functionaliteit ingebouwd. U kunt de code ook verkennen met tools zoals ReSharper, grep of Sourcegraph.
  • Begrijp het product. Het zal je verbazen hoeveel ontwikkelaars niet weten hoe de software zou moeten werken voordat ze het proberen te "repareren". Lees gewoon de documentatie.

Organiseer uw gedachten

Omdat veel van je tijd wordt besteed aan communicatie, onderzoek en multitasking, heb je een aantal tools nodig om alles op orde te houden.

  • TODO-lijsten / Taken: Uw bedrijf zou al een soort tasking-software moeten hebben, maar het helpt ook om een ​​persoonlijk systeem te hebben. Gebruik post-it notes of software zoals Trello of Todoist.
  • Notities: maak altijd notities tijdens vergaderingen, werk aan het verbeteren van bestaande documentatie en maak een persoonlijke kennisbasis. Gebruik Evernote, OneNote of een notebook, zoals vroeger. Het lijkt misschien overkill, maar je bedankt jezelf een jaar later wanneer je dat obscure bouwproces opnieuw bezoekt dat je 3 dagen kostte om er de eerste keer achter te komen. Ik heb nog nooit een goede Software Engineer ontmoet die geen uitgebreide aantekeningen heeft gemaakt.
  • Grafieken / visualisaties: mensen zijn visuele wezens en het creëren van grafieken van processen en architecturen zal u en anderen helpen complexe onderwerpen te begrijpen. Diagrammen zijn met name handig bij communicatie met niet-technische collega's. Gebruik Lucidchart, Visio of een gewoon whiteboard.

Weet wanneer u bibliotheken moet gebruiken

Kort antwoord: bijna altijd.

Lang antwoord: 99% van de tijd moet je het wiel niet opnieuw uitvinden. In de meeste functies van Software Engineering is het implementeren van een bepaald soort een complete verspilling van tijd. Dat betekent niet dat je niet moet weten hoe de algoritmen en gegevensstructuren die je gebruikt werken, omdat dat je zal helpen beslissen wat en wanneer te gebruiken.

Om een ​​efficiënte Software Engineer te zijn, moet u de bibliotheken die u tot uw beschikking heeft begrijpen. De standaardbibliotheken van de meest populaire talen zijn uiterst nuttig en zijn groter dan wat u zou verwachten. Bovendien kan de codebasis ook gebruikmaken van aanvullende, gespecialiseerde bibliotheken. Lees hun documentatie en weet wanneer ze te gebruiken.

Je moet ook niet bang zijn om extra bibliotheken voor te stellen als ze tijd besparen. U moet er echter voor zorgen dat u een goede bibliotheek kiest voor industrieel gebruik. Een goede bibliotheek is:

  • Open source, zodat u zelf de kwaliteit van de code kunt verifiëren en mogelijk bugs kunt verhelpen die van cruciaal belang zijn voor uw toepassing.
  • Licentie onder een toegestane licentie zoals MIT en BSD, zodat uw bedrijf geen problemen ondervindt door het te gebruiken. Wees voorzichtig met GPL, anders zou je per ongeluk je hele codebasis openen.
  • Ouder, d.w.z. het is al enige tijd uit en heeft een rijke set functies.
  • Onderhouden, met nieuwe releases die vaak uitkomen.
  • Gebruikt door andere bedrijven of projecten, die fungeert als een goedkeuringsstempel en ervoor zorgt dat het industrieondersteuning heeft voor voortgezet onderhoud.

Continue verbetering

Naast het leren van de vaardigheden die je beter maken in je dagelijkse werk, moet je ook continu je vaardigheden verbeteren en nieuwe leren om nieuwe carrièremogelijkheden voor jezelf te creëren.

De mogelijkheden om te leren zijn veel en veel van hen zijn redelijk betaalbaar:

  • Online cursussen: de mogelijkheid om in een flexibel formaat van de beste professoren in het veld te leren, mag niet worden gemist. Bekijk Coursera, Udacity en edX (onder vele) voor cursussen die uw bestaande vaardigheden kunnen aanvullen.
  • Online Master's Graden: een recente trend bij de beste universiteiten, online Master's Graden zijn een flexibele manier om uw formele opleiding voort te zetten. Ze zijn over het algemeen ook minder duur dank op de campus graden, met de meeste programma's kost ~ $ 10.000 voor de hele graad. Georgia Tech, UT en UC San Diego zijn enkele van de universiteiten die dergelijke graden aanbieden. Ik raad persoonlijk de online masters van Georgia Tech aan die ik van dit jaar heb gehaald.
  • Blogs: blogs zijn een belangrijk onderdeel van de ontwikkelaarscommunity (geen verrassing hier, want je leest er nu een). Blogs zoals Coding Horror, Joel on Software of zelfs meer humoristische websites zoals The Daily WTF kunnen u een goed idee geven van wat u als Software Engineer niet moet doen. Browsen op Medium, r / programming, HackerNews of andere feeds leidt u ook naar goede artikelen en blogs.
  • Conferenties: last but not least, conferenties zijn een geweldige leermogelijkheid en u moet zeker profiteren van het trainingsbudget van uw bedrijf door er naartoe te gaan. Een zeer onvolledige lijst van goede conferenties om te bekijken (naast hun onderwerp): GOTO; (Algemeen), Strange Loop (Algemeen), PyCon (Python), CPPCon (C ++), DEF CON (Beveiliging), Vloeiend (Web dev). Al deze hebben ook video's van (de meeste) talks op YouTube, zodat je iets kunt leren, zelfs als je niet aanwezig kunt zijn!

Hopelijk heeft dit artikel je gewapend met de kennis van wat je kunt verwachten vanaf het begin van je carrière als Software Engineer en je de tools gegeven om goed te presteren op deze spannende reis! Bedankt voor het lezen! Als je vragen of suggesties hebt, laat dan een reactie of tweet @AlexievValeri.