Hvordan jeg landede et fuldt udviklerjob uden en teknisk grad eller erhvervserfaring

For seks måneder siden fik jeg mit første udviklerjob som full stack webudvikler til en opstart. Jeg havde ingen relevant erhvervserfaring, ingen teknisk grad og ikke engang et års aktiv kodningserfaring. Og alligevel lykkedes det mig at lande mit drømmetilbud og kan i dag for første gang i mit liv sige, at jeg elsker mit job. Sådan gjorde jeg det - den lange version.

Del 1: Omfatter kvart-livskrisen

For omkring tre år siden var jeg midt i en voldsom kvart-livskrise. Jeg var uddannet handelshøjskole, fik et attraktivt job inden for investeringsbankvirksomhed og gik derefter op med det samme job bare et par måneder efter jeg indså, at jeg hadede alt ved det.

Helt tabt og ret kliché gik jeg alene i et par måneder for at "finde mig selv". Og selvom jeg troede, at jeg gjorde det, gjorde jeg det ikke. Ikke nok alligevel. Men det hjalp mig faktisk med at finde ud af et par ting.

Den første ting var, at jeg simpelthen ikke kunne fortsætte med at forfølge en finanskarriere. Jeg kunne bare ikke se noget fremtidsscenarie, hvor det ville gøre mig glad.

Den anden ting var, at backpacking og surfing, selvom det var godt og alt sammen, ikke ville hjælpe mig med at finde det "kald", jeg ledte efter. Den eneste rimelige ting at gøre lignede den klassiske prøve-og-fejl-metode.

Så da jeg kom hjem, besluttede jeg at prøve et par ting, som jeg troede både kunne gøre mig lykkelig og samtidig sørge for en slags anstændig levebrød. Og prøve-og-fejl var det.

Først tænkte jeg, at jeg ville give skrivning et seriøst skud. Så jeg begyndte at skrive og redigere deltid til et online forretningsmagasin. Det var temmelig sejt i et stykke tid. Arbejder tre dage om ugen i et tempofyldt redaktionskontor og skriver om noget, der er relateret til forretning, økonomi, teknologi eller bæredygtighed.

Samtidig havde jeg hørt så meget om livet som freelancer under rejsen, at jeg troede, jeg ville prøve det. Så jeg oprettede mit eget firma og snuble snart over et par forretningsanalytikerprojekter. At være min egen chef var selvfølgelig meget spændende i starten, og det at være i stand til at arbejde fra bogstaveligt talt hvor som helst var helt nyt for mig.

Jeg fortsatte sådan i omkring otte måneder og fordoblede mig som forfatter / redaktør og freelancing forretningsanalytiker. Men til sidst begyndte jeg at miste interessen for jobbet i bladet.

Som enhver fornuftig person, der beskæftiger sig med digitalt indhold, ved, kommer clickbait-kulturer på bekostning af kreativitet og kvalitet. Med andre ord, når det vigtigste incitament til dit indhold er klik, vil alle de superlativer, der kræves for at jage disse klik, snart blive båret af alle kreative ambitioner, der var der i første omgang. Desuden kunne jeg ikke ryste følelsen af, at jeg som forfatter / redaktør altid var for langt væk fra den handling, jeg rapporterede om.

Så jeg holdt op. Hvilket var ok ifølge min prøve-og-fejl-aftale med mig selv. Men det føltes stadig skørt, da jeg faktisk havde investeret otte måneder i hele skrivetingen. Men som en klog måske eller måske ikke har sagt: Når en dør lukker, åbnes en anden.

Og jeg havde stadig en ting mere på min prøve-og-fejl-liste for at afkrydse.

Del 2: Frokosten, der ændrede mit liv

Livet er underligt, og nogle gange skjuler det de største, mest livsændrende inspirationer de steder, du mindst forventer. Det var bestemt sådan for mig, da jeg oplevede mit første "træk" mod kodning.

Selvom det var en fiasko at afslutte jobbet i bladet, ville oplevelsen trods alt ikke have været helt forgæves. Efter at have skrevet så meget om tech startups og iværksætternes spændende liv var jeg også død på at give den livsstil et skud.

Og efter omkring en måned med forskning og jobjagt lykkedes det mig at lande et job hos en af ​​de daværende - angiveligt - mest lovende FinTech-virksomheder i Norden. På få år var det vokset til at blive en af ​​Europas største crowdfunding-platforme for egenkapital.

Jeg havde ikke rigtig ansøgt om nogen specifik jobåbning. Men da jeg virkelig troede på virksomhedens mission og var imponeret over deres succes, ville jeg hellere bare komme i kontakt med deres CFO, der fortæller ham netop det. Vi mødtes et par gange, og pludselig arbejdede jeg der i en ganske uklar forretningsudviklingsrolle.

Selvom jeg havde håbet på at komme i gang med strategiske og analytiske projekter, endte jeg med at gøre, hvad fuzzy forretningsudviklere normalt ender med at gøre: salg. Hvilket også var årsagen til, at dette job ikke endte.

Men der er mere.

Ligesom den sidste joberfaring fra magasinet, ville dette job også vise sig ikke at have været alt for forgæves. Faktisk uden det ville jeg sandsynligvis ikke være udvikler i dag. Fordi det var her, jeg mødte Sandra.

Hun var en front-end-udvikler i produktteamet og sad lige i den anden ende af det lille coworking-kontor, vi var trangt på på det tidspunkt.

Teknisk set var vi kolleger, men som enhver, der har arbejdet i et dysfunktionelt techfirma, ved, kan afstanden fra salgsteamet til produktteamet ofte føles som galakser fra hinanden.

Det hjalp ikke, at ledelsen netop havde besluttet at outsource hele dev-teamet til et eksternt team i Ukraine. Betydning Sandra og alle de andre udviklere ville blive sluppet løs og tjente mere eller mindre bare deres to måneders varsel.

På trods af denne afstand endte Sandra og jeg med at spise frokost sammen en dag. Det ville dybest set være min første rigtige samtale med en professionel udvikler, og jeg tror, ​​det var en blanding af ægte nysgerrighed og min accelererende eksistensielle krise, der hurtigt mere eller mindre gjorde frokosten til et interview.

Og vores frokost endte med at blive en helt livsændrende oplevelse for mig. Mere specifikt gjorde tre åbenbaringer det sådan.

  1. Jeg blev chokeret over at høre, at hun ikke havde nogen "rigtig" uddannelse i webudvikling, hvilket for mig på det tidspunkt ikke ville svare til noget mindre end en akademisk grad. Alt hvad hun vidste, havde hun lært af MOOC-platforme (Massive Open Online Courses), som freeCodeCamp og Codecademy.
  2. Hun fortalte mig, at hun havde en baggrund inden for økonomi, ligesom mig. Faktisk havde hun arbejdet som forretningscontroller i flere år indtil for nylig, da hun var medlem af den samme opstart som jeg, bare et par måneder tidligere som en front-end praktikant.
  3. Da hun viste mig den porteføljeside, hun havde bygget med kun seks måneders kodningserfaring, kunne jeg ikke tro det. Det var utroligt.

Denne frokost åbnede en verden af ​​muligheder for mig. Sandras historie gjorde mig sulten efter mere.

Så i flere uger undersøgte jeg de forskellige typer veje, som folk havde taget for at blive udviklere. Jeg endte i alle mulige fora og artikler, hvoraf mange jeg fandt lige her på Medium.

For eksempel angav Stackoverflow's årlige udviklerundersøgelse (100.000 interviewpersoner), at kun halvdelen af ​​alle professionelle udviklere havde en bachelorgrad, og af denne halvdel var en hel tredjedel hovedfag i noget, der ikke var relateret til datalogi og software engineering.

Jo mere jeg læste, jo mere indså jeg, hvor snæver min definition af uddannelse havde været. Hvis du ikke havde brug for en datalogisk grad for at bryde ind i noget så kompliceret som software engineering, hvad havde du brug for en akademisk grad til? Selvom jeg måske ikke havde været i stand til at se det dengang, ser jeg nu tydeligt, hvor brudt det akademiske system er.

Det er designet til industriel alder af arbejdere , hvor du ville specialisere sig i et håndværk, og derefter bruge de samme færdigheder for resten af dit liv. Det var bestemt ikke designet til nutidens vidensamfund, hvor al information om verdenshistorien aldrig er mere end et par klik væk, og hvor tingene ændrer sig så hurtigt, at uddannelse faktisk skal være en livslang proces og ikke læringen -engang-for-evigt engangsoplevelse.

Men det er et emne, der er stort nok til en artikel i sig selv. Det vigtige ved den frokost med Sandra var, at den antændte noget i mig og motiverede mig til at bryde fri fra den destruktive løkke, som jeg fandt min nuværende halvvejs forretningskarriere at være.

Selvom jeg altid havde misundt programmører omkring mig - selv i det omfang jeg havde taget et Python 101-sommerkursus et par år tidligere - havde jeg aldrig betragtet det som en levedygtig karrierevej for mig. I det mindste ikke uden at gå tilbage til universitetet i 3-5 år.

Så hvis du læser denne Sandra, tak! Hvis jeg med denne artikel kun kan inspirere en person, som du inspirerede mig, ville jeg overveje, at bestræbelserne på at skrive den blev tilbagebetalt tusind gange.

Del 3: Teksten der kostede mig $ 6.000

I løbet af de næste par måneder tilbragte jeg hundreder af timer på online platforme som Codecademy og freeCodeCamp. Jeg købte endda et abonnement på den betalte platform Code School.

Jeg er ikke sikker på, at jeg virkelig vidste, hvad mit mål var. Hvad fik mig i gang var desperationen over mine tilbagevendende karriere skuffelser. Men hvad der holdt mig i gang, var hvor latterligt sjovt og givende jeg fandt kodningsøvelserne.

Jeg kunne ikke engang fortælle dig, på hvilket tidspunkt kodningen drejede sig om et afslappet sideprojekt til det døds seriøse "Jeg bliver en professionel udvikler." Men det var sandsynligvis et sted her omkring. Jeg var lige ved at modtage mit front-end certifikat fra freeCodeCamp, da min næste livsændrende begivenhed fandt sted.

Efter at have sagt op mit job som forretningsudvikler, besluttede jeg at undslippe den frysende limbo, der er svensk vinter, for at rejse i Mellemamerika. Jeg regnede med, at hvis jeg skulle bruge hundreder af timer alene på at lære mig selv at kode, kunne jeg lige så godt gøre det et sted varmt, billigt og ikke deprimerende.

Jeg kodede på min bærbare computer på et hostel i El Salvador, da jeg fik en tekst fra min ven Marie.

"Jeg fik jobbet!" den sagde.

Marie lærte også at kode. Jeg huskede, hvordan hun et par måneder tidligere havde fortalt mig om denne kodeskole, hun gik på. En "kodende bootcamp."

På det tidspunkt havde jeg dybest set spottet hende for det - Så. Du betaler $ 5.000 for et 12-ugers kursus? Og du modtager ikke en eneste universitets kredit for det? Og du droppede ud af din top-tier MBA for at gøre dette? Det lyder legitimt.

Og alligevel var hun der. Fire måneder senere, og Marie blev officielt ansat af et af Accentures digitale bureauer som junior back-end-udvikler. Jeg var virkelig glad for hende, men selvfølgelig også ekstremt jaloux.

Jeg stoppede hvad jeg lavede og lavede nogle beregninger. Hvis jeg kunne holde op med mit nuværende tempo, kodende omkring 6 timer om dagen i gennemsnit ca. 5 dage om ugen, ville jeg gøre 30 timer om ugen. Så for at afslutte freeCodeCamps fulde 1.200 timers program, ville det tage mig mindst 8 måneder til. Og det var hvis jeg kunne holde tempoet op. Hvilket jeg bestemt ikke kunne, da mine penge var ved at løbe tør, og jeg snart skulle tilbage til Sverige og få et nyt job.

Jeg sparkede mig selv for ikke at have taget den samme vej som Marie fra starten og brugte mine penge på et bootcamp i stedet for backpacking i 4 måneder. Nå, hvad der er gjort, er gjort, tænkte jeg ved mig selv. Jeg er stadig nødt til at acceptere det faktum, at en bootcamp var den bedste mulighed for at nå et anvendeligt niveau hurtigt nok.

Tilbage til den gode gamle Google-forskning.

På en måde følte jeg, at jeg var lige tilbage, hvor jeg startede efter den frokost med Sandra. Først denne gang kiggede jeg på hele bootcamp-fænomenet med et nyt par øjne. Da jeg kendte Maries historie, vidste jeg, at ikke alle af dem var for gode til at være sande svindel, men faktisk sandsynlige måder at bryde ind i branchen.

Senere forsikrede Stackoverflow's årlige udviklerundersøgelse mig igen med statistikken om, at 88,1% af kodende bootcamp-alumni var ansat inden for et år efter afslutning af bootcampen.

Takket være Switchup og Coursereport tog det ikke lang tid, før jeg opdagede Le Wagon, den franske kodende bootcamp-opstartssucceshistorie med mere end 15 placeringer overalt i verden og top 5-rangeringer på begge placeringer (i skrivende stund faktisk # 1 på begge, med 27 placeringer!).

Efter at have sammenlignet det med alternativer som Hack Reactor, Ironhack, Generalforsamling og NYCDA, fik nogle få hovedårsager mig til at foretrække det frem for de andre:

  • Den relativt lave pris (dengang $ 6.000).
  • Fokus på iværksætteri og produktudvikling.
  • Den globale tilstedeværelse og samfund.

Ikke desto mindre var jeg stadig i tvivl om programmet.

  1. Valget af backend-sprog Ruby og MVC framework Rails. Selvom det så ud som om dette var ret almindeligt blandt andre anerkendte bootcamps, antydede næsten hver artikel, jeg læste om emnet, at Javascript var rigtig varmt, og hvad arbejdsgivere ledte efter. Min ven Maries bootcamp lærte for eksempel en backend-stack baseret på Node.js og Express.js. Begge Javascript-baserede teknologier. Nogle almindelige argumenter syntes at være, at Ruby var et godt sprog til læring, men at Node og Express var færdigheder, som arbejdsgivere værdsatte meget højere. Var Ruby virkelig hesten at satse på?
  2. Kursets 9-ugers varighed virkede lidt kort. De fleste konkurrerende programmer syntes at være mindst 12 uger, hvilket allerede syntes alt for kort til at blive en anvendelig webudvikler.
  3. Le Wagon tilbød ingen egentlig jobjagtassistance efter at have afsluttet bootcampen. Mange konkurrenter tilbød enten ansættelsesgarantier eller tilsyneladende solide karrierefunktioner.

Jeg vil behandle hver af disse tre tvivl en efter en med mine konklusioner efter bootcamp i slutningen af ​​næste afsnit.

På trods af mine bekymringer regnede jeg med, at det var min bedste mulighed, hvorfor jeg besluttede at ansøge om deres skole i Barcelona. Et par dage senere nåede den lokale skoleleder Gus ud til mig til et Skype-interview.

Tilsluttet en skør Wi-Fi på en café i den dovne bydel i El Tunco havde vi en kort snak. Men det var meget mere uformelt, end jeg havde forventet. Jeg følte, at vi var forbundet, hvilket fik mig til at blive optaget endnu mere. Og så, ikke engang 24 timer senere, fik jeg den e-mail, jeg havde ventet på. Gus fortalte mig, at han ville være glad for at have mig med i det næste parti, og at det eneste, jeg skulle gøre, var at betale $ 1.200 depositum for at reservere min plads.

Det var stort set alle de penge, jeg havde tilbage på det tidspunkt, og det skulle betale for mine sidste uger i El Salvador - inklusive den eventuelle hjemrejse. Men hvis jeg bare kunne klare et strammere budget og bestille en tidligere flyrejse hjem end forventet, vidste jeg, at jeg kunne klare det.

Så efter et kort øjeblik af tøven og huskede de bekymringer, jeg stadig havde for Le Wagon, handlede jeg efter intuition og overførte Gus depositum. Bagefter husker jeg, at jeg følte mig lidt akavet. Havde jeg virkelig lige forpligtet mig til at betale næsten $ 6.000 for et 9-ugers kodningskursus? Som svensker, der aldrig nogensinde har betalt en eneste cent for uddannelse, føltes situationen ret bizar.

Det tog dog ikke lang tid, før den bizarre følelse blev til spænding. I det mindste vidste jeg nu, at jeg ikke skulle gå tilbage til at arbejde inden for økonomi, salg eller onlinemedier i nogen nærmeste fremtid. Samme dag begyndte jeg at arrangere tiden frem til bootcampen.

I de tre måneder tilbage, ville jeg på en eller anden måde skulle tjene de resterende $ 4.800 af gebyret. Plus husleje og leveomkostninger. Nå sh * t.

Jeg nåede ud til et af de virksomheder, som jeg tidligere havde rådført mig med, og heldigvis havde de det perfekte forretningsanalytikerprojekt. Da de oprindeligt ikke ville acceptere noget mindre end en 4-måneders kontrakt, måtte jeg overbevise dem om, at jeg kunne udføre jobbet i to. På en eller anden måde fungerede det.

Pis! Bare en uge tidligere havde jeg været en løbende rejsende uden en tanke om nogensinde at gå hjem. Nu skulle jeg starte min nye to-måneders koncert i Stockholm på mindre end to uger og derefter flytte til Barcelona. Spændende ting fremad faktisk.

Del 4: Bootcamp i Barcelona

Spol frem tre måneder .. Det er den 1. maj 2017, og jeg er i et klasseværelse, der deltager i min første Le Wagon-forelæsning.

Omkring mig er omkring 25 mennesker fra alle hjørner af verden. Kilian fra Tyskland, Daniel fra Venezuela, Francesca fra Frankrig, Arbi fra Italien, Courtney fra USA og så videre. Nogle uden nogen kodningserfaring overhovedet, nogle med lidt, og nogle få faktisk halvvejs til at få deres datalogi-grader.

Vi lytter til Gus, den lokale skolechef, og Ruben, en Ruby-lærer, der forklarer strukturen i det kommende program.

Som vi alle skulle lære at lære, var tidsplanen meget systematisk. I løbet af de kommende 9 uger brugte vi mere eller mindre lige meget tid på 6 forskellige moduler, der hver især beskæftiger sig med et eget emne, og afsluttede med to uger brugt på planlægning og udvikling af vores helt egen webapp.

Hele den første uge kan jeg huske, at jeg følte mig meget sikker på kursusindholdet. Efter alle disse hundreder af timer på freeCodeCamp syntes sværhedsgraden af ​​de daglige kodningsudfordringer lidt lavt.

Selvom Ruby stadig var ret ny for mig, så det grundlæggende ud til at være stort set det samme som med Javascript og Python. At lytte til foredrag og udføre øvelser for at lære om variabler, arrays, hashes, grundlæggende funktioner og iterationer føltes ret gentagne. Så jeg blev klodset og spekulerede på, om jeg faktisk ville få noget ud af denne bootcamp-ting. Men ikke engang en uge senere ville alt det ændre sig. Jeg gik fra at føle mig som toppen af ​​klassen til faktisk at kæmpe for at følge med.

Før jeg vidste af det, gik vi videre fra det grundlæggende til objektorienteret programmering, MVC-arkitekturer og databaser, og der var masser af dage, hvor jeg følte, at jeg ikke engang havde forstået begreberne dagen før og allerede var forventet for at gå videre til næste emne.

Så jeg var nødt til at sætte det næste gear. 10 timer om dagen i klasselokalet skar det ikke for mig. Jeg gjorde det til en rutine at lægge et par ekstra timer hver nat og tilbringe det meste af weekender med at gentage de sværeste ting fra den sidste uge. Det sugede lidt for ikke at kunne nyde Barcelona så meget som jeg havde de første par uger, men det faktum, at jeg havde investeret alle mine besparelser i bootcampen, var en stor motivation.

En anden kilde til frustration var den spredte natur af de ting, vi lærte. Det føltes som om, vi havde fået hundrede puslespil, men ingen instruktioner om, hvordan vi kunne sætte dem alle sammen. At vide, hvordan man skriver grundlæggende Ruby, HTML, CSS, Javascript og SQL, var virkelig bemyndigende, men hvordan ville den viden hjælpe mig med at sammensætte en egentlig app?

Og så kom mit store AHA-øjeblik.

Det var uge 6, og vi nåede endelig Ruby on Rails-modulet. Før jeg vidste af det, kiggede jeg på mit Chrome-browservindue og læste ordene “Yay! Du er på skinner! ”. Det var min første webapp, sagde læreren.

Hvad? Alt, hvad jeg havde gjort, var at køre et par enkle kommandoer i min terminal og surfede ind på // localhost: 3000 / i min browser. Hvad så jeg endda på?

Først da jeg åbnede app-biblioteket i teksteditoren, faldt den store søde forståelse på plads. Skinner viste det hele så smukt enkelt.

En mappe til HTML, en til CSS og Javascript, en til controllerne og en til modellerne. Én fil til ruterne. Og en fil til det søde, søde skema, der kortlægger hele databasen, som om den ikke var mere kompleks end en indkøbsliste med købmandsvarer.

Efter endelig at få det store billede af, hvordan alle disse stykker praktisk talt ville passe sammen i en MVC-ramme som Rails, var det ikke meget af en kamp at bruge alle mine nætter og weekender på kodning. Helt modsat ville jeg ofte kæmpe for at komme af min bærbare computer for at gå i seng om natten.

Jeg var ved at rulle og fik massiv ny indsigt hver eneste dag. Og det gav denne berusende virkning, der stadig er svær at sætte ned i ord.

  • Så jeg kan faktisk blande HTML og Ruby i mine erb-filer?
  • Jeg kan få adgang til instansvariabler fra controlleren i den tilknyttede html.erb-fil?
  • Jeg kan importere kode, som andre skrev med denne ting, der hedder Gems?
  • Jeg kan skrive så meget vanille-JavaScript, som jeg vil, i aktiver / javascript-biblioteket?
  • Jeg kan bruge Rails-konsollen i terminalen til stort set at gøre hvad jeg vil med hele databasen?

Det var bare en uendelig strøm af utroligt tilfredsstillende Aha-øjeblikke. Som om du lige havde indset, at styrken faktisk var stærk hos dig, og at du kom et skridt tættere på at gå fuld Jedi med hvert stykke ny viden. Selv nu, ni måneder senere, føles det som om jeg stadig er på den samme højde, og jeg begynder at tro, at det faktisk kan være noget permanent. Hvor dejligt det ville være.

Under alle omstændigheder var bootcamp-toget ikke langsommere, og snart var vi nået de sidste to uger, da vi skulle bygge vores egen app. De to uger ville slutte med en stor demo-dag, hvor hver gruppe pitchede og demonstrerede deres apps foran kameraer og et stort publikum.

Tryk.

Til vores overraskelse viste planlægningen sig at være den langt mest tidskrævende del. Selvom vi forberedte os meget i de sidste par uger - pitching af app-ideer, dannelse af grupper, design af funktioner i Sketch - var det først efter et par dages kodning, at vi indså, at vi havde været alt for ambitiøse.

Den første idé til appen var en slags "Happn for professionelle forbindelser." Mere specifikt at lade brugerne oprette sider til netværksbegivenheder, som andre brugere kunne deltage i og tjekke ind på. ”Men det er Meetup,” tænker du måske. Men vores idé havde et twist: du kunne kun tjekke ind på en begivenhed, hvis du var fysisk på arrangementets placering. Således "Happn for professionelle forbindelser."

Når en bruger er tjekket ind på en begivenhed, kunne han se de professionelle profiler for andre indcheckede brugere ved hjælp af data indsamlet via LinkedIn's API og oprette forbindelse og chatte med dem, der matchede deres interesser, og derved ikke gå glip af potentielt gode forbindelser .

Dette var vores første MVP (minimum levedygtige produkt), og vi besluttede at kalde det Unify. Super corny og Silicon Valley wannabe, ved jeg det. Men i vores forsvar havde vi bedre ting at gøre med vores tid end at tænke på bedre navne.

Ligesom brainstorming om de faktiske funktioner. Men så brainstormede vi faktisk lidt for meget, og funktioner blev tilføjet og fjernet, indtil vi endte med en helt anden app, der

  1. ville aldrig være demo-klar inden for de resterende ti dage, og
  2. var ikke nær så forstyrrende, som vi troede, vores første idé var.

Så vi var nødt til at indsnævre funktionerne til MVP og endte faktisk med næsten nøjagtigt det samme produkt, som Le Wagon-manager Gus havde anbefalet, at vi gik med fra starten.

Stort spild af tid, var hvad vi troede dengang. Men processen lærte mig i det mindste et par virkelig vigtige ting om produktudvikling:

  • Når det er gjort rigtigt, skal det handle meget mere om planlægning end egentlig kodning.
  • At skulle rydde op i gamle kodefejl er meget mere tidskrævende end at planlægge grundigt og gøre ting lige fra starten.
  • MVP'en er altid mindre end man ville tro fra starten.

Nogle ti dage senere, efter mere end 100 timers kodning, design, argumentering, test, databasemigrering og database-tilbageførsel, nåede vi på en eller anden måde mirakuløst Demo-dagen og følte os faktisk ret godt om vores app. Sikker på, det var langt fra perfekt, men alle hovedfunktionerne fungerede faktisk, som vi ville have dem til.

Imidlertid ville vi næsten få et hjerteanfald kun få timer før demoen.

Googles geolocation API reagerede ikke som det skulle på vores anmodninger, så vi kunne ikke tjekke ind på den begivenhed, som vi ville bruge til demoen. Vi prøvede alt. Skifte computere og brugere. Sletning og oprettelse af nye begivenheder. Ændring af gadenavns adresse. Intet fungerede.

Vi tre forsøgte at være rolige og ikke få panik. Det var sandsynligvis bare en fejl, som fyren, der var ansvarlig for geolokaliseringsfunktionen, ville vide, hvordan man let skulle løse.

Men han løb sent, så vi prøvede at ringe til ham.

Intet svar.

Vi prøvede at ringe igen.

Intet svar igen.

Og så blev vi i panik.

Først i sidste øjeblik lykkedes det os, takket være en af ​​vores fantastiske undervisningsassistenter, Antoine, at finde fejlen. Det viser sig, at vi ved et uheld havde indstillet afstandsområdet for lavt, hvorfor appen ikke kunne bekræfte, at vi faktisk var på begivenhedsstedet. Vi øgede simpelthen radius med et par kilometer, forpligtede os og skubbede ændringen til vores produktionsserver.

Og voilà - appen fungerede perfekt. Og det gjorde demo også.

Samlet set var min Le Wagon-oplevelse intet mindre end fantastisk. Jeg har sandsynligvis aldrig lært så meget på så kort tid. Efterfølgende er det faktisk svært at tro, at de fleste af os var i stand til at udvikle komplette webapps med stort set kun 9 ugers udviklingserfaring.

Men nar ikke dig selv, bootcampen gør ikke arbejdet for dig. For at få noget ud af det skal du give det dit fulde engagement. Jeg så selv masser af mennesker komme bagud eller endda falde ud, fordi de

  • havde ikke de rigtige forventninger til sværhedsgraden,
  • ikke var forberedt nok, eller
  • var for travlt med andre ting til at følge med.

Til sidst er en fejl, jeg tror, ​​mange rookies gør, at betragte en datalogi-grad som en erstatning for selvlæring eller et bootcamp som et middel til at blive en web- og / eller mobiludvikler. Baseret på mine erfaringer er dette ikke korrekt.

Selvom du forfølger en computervidenskabelig grad, skal du stadig udfylde masser af praktiske videnhuller for at blive produktive. Jeg så praktisk taget denne første hånd i mine bootcamp-klassekammerater med 2-3 års CS-studier bag sig. Igen skyldes det, at den akademiske model er brudt og forældet og derfor ikke kan følge med i det ekstreme tempo, hvormed den virkelige softwareudvikling ændrer sig.

Fra mit synspunkt, hvis målet er at blive udvikler, vil selvlæring eller et bootcamp på et eller andet tidspunkt være nødvendigt på begge måder. Så en datalogisk grad skal opfattes som et supplement snarere end en erstatning .

Og grunden til, at en (god) bootcamp kan gøre dig til en udvikler hurtigere end selvlæring, er kombinationen af ​​følgende:

  • en grundig, men kortfattet læseplan,
  • en problemfri online platform med tutorials og øvelser, og vigtigst af alt;
  • den menneskelige vagtsupport, når du rammer en mur.

For at afslutte dette afsnit vil jeg gerne tage fat på de tre bekymringer, jeg havde, før jeg forpligtede mig til bootcampen med den indsigt, jeg har fået siden da.

1. At lære Ruby on Rails i stedet for en JavaScript-baseret stak

Hvis du i øjeblikket er i den position, jeg var i, før du tilmeldte mig min Rails bootcamp, overvældet af al JavaScript-hype, der oversvømmer Internettet, kan du spørge dig selv, om Ruby er et dateret sprog, og om Rails er en dateret ramme. Hvis dette er tilfældet, ville mit korte svar være nej.

Det lange svar ville dog være dette.

Det firma, jeg arbejder hos nu, har en webtrafik med høj trafik bygget med Rails på backend og Ember.js frontend-rammen på fronten. At have arbejdet på fuld tid med denne app i omkring seks måneder har nu krævet lige så meget kodning i Javascript fra mig som i Ruby, hvilket har givet mig et indblik i forskellene og lighederne mellem teknologierne.

Og helt sikkert, når det kommer til klientsiden HTML / CSS-gengivelse (eller "visningerne"), er Rails-brugeroplevelsen ikke engang sammenlignelig med de store JavaScript-rammer. At jeg skal give Rails hatere.

Tag f.eks. En grundlæggende kommentarsektion i en artikel eller et blogindlæg. Som bruger kan du forvente, at eventuelle kommentarer, du indsender, vises med det samme på din skærm.

I en moderne JavaScript-ramme er dette simpelthen et spørgsmål om at skubbe de nye data (kommentaren) ind på datalageret på klientsiden og sørge for, at kommentarlisten opdaterer sin tilstand for at vise den nye kommentar. På denne måde behøver du ikke vente på, at den nye post sendes hele vejen til backend, gemmes i databasen og derefter anmodes af klienten igen. I stedet vises den nye kommentar med det samme på din skærm.

Uden JavaScript oven på din Rails HTML-kode skal brugeren opdatere siden for at se nye kommentarer til artiklen. Hvilket bare er forfærdeligt UX. For at undgå dette kan du tage et par forskellige stier.

Før JS-rammens alder var den vigtigste løsning at drysse noget ret ustruktureret AJAX-logik oven på HTML, hvilket ofte bliver meget svært at vedligeholde i det lange løb, når din app bliver større. En anden mulighed, der er gjort tilgængelig for Rails ganske nylig, er pubsub (publish-subscribe) websocket-løsning ved hjælp af noget som Action Cable. For eksempel er det, hvad vi brugte til chatten i den app, vi byggede i bootcampen. Problemet er bare, at uden en indpakning af JavaScript-ramme kan websocket-logikken let blive unødvendigt kompleks og også vanskelig at vedligeholde.

Heldigvis har vi dog i dag den meget bedre mulighed for at bruge JavaScript-rammer til denne type problemer. Og da klientsiden efter min mening er det svageste punkt i Rails, er dette også mit hovedargument til, at Rails ikke skal kasseres som en mulighed for for eksempel Laravel eller MERN-stakken. Smad bare en skarp JavaScript-ramme ovenpå, som React eller Ember, så er du klar til at gå.

Jeg elsker personligt vores integration mellem Rails og Ember, og hvordan de supplerer hinanden. Deres meningsfulde natur, solide track records, visionære lederskab og store bidragydende samfund gør dem stabile, pålidelige og egnede til juniorudviklere som os selv.

Hvis du stadig på trods af min bedste indsats føler dig tøvende med at satse på Ruby som dit første backend-sprog, vil jeg gerne minde dig om, at jeg næsten ikke vidste noget om JavaScript for seks måneder siden (undtagen nogle grundlæggende vanilje JS, React og jQuery-syntaks), og i dag arbejder jeg med og overgår mellem begge disse sprog og rammer problemfrit på daglig basis. Og elske hvert minut af det (billedligt talt).

Så uanset hvad du satser på som dit første sprog, skal du ikke bekymre dig - du kan altid lære den anden på jobbet?

2. Er der ikke 9 uger for korte til at lære noget?

Med hensyn til min bekymring for, at bootcampens varighed - kun 9 uger - måske var for kort til faktisk at lære noget værdifuldt, hjalp Le wagon mig også med at bryde den myte. Efterhånden er det faktisk klart, at jeg foretrækker 9 uger over de 12, som de fleste andre bootcamps tilbyder.

Årsagen er, at selve bootcampen faktisk ikke tager dig til et beskæftigelsesniveau. I det mindste ikke for mig. Snarere gav det mig en solid introduktion til alle de nødvendige værktøjer, som jeg ville have brug for for at nå et produktivt niveau, og hvordan jeg satte dem alle sammen. Så selvom de ville have givet mig yderligere tre uger, ville det bare have betydet et dusin flere værktøjsintroduktioner. Værktøjer, som jeg senere skulle faktisk lære at bruge i dybden. Og denne liste var allerede mere end lang nok.

Først efter bootcampen, efter uges opbygning af mine egne portefølje-apps, forstod jeg, hvordan værktøjerne virkelig fungerede. Så hvis du har besluttet, at du vil gøre bootcamp-ting, men sammenligner muligheder baseret på en forskel på et par uger, ville mit råd være at fjerne den variabel fra ligningen. For hvis du er noget som mig, bliver du stadig nødt til at genlære hvert eneste værktøj alene.

Når jeg ser tilbage, er det faktisk ret bemærkelsesværdigt, hvor nøjagtigt Le Wagons værktøjssæt var. I mit nuværende job bruger jeg de fleste af disse værktøjer dagligt. Nogle eksempler er Postgres, Git, GitHub, Sidekiq, Pundit, Heroku og Cloudinary. De eneste to ting, som jeg ønskede, at mine lærere ville have brugt mere tid på, var, hvordan man bruger en JavaScript-ramme som React, og hvordan man skriver tests med teknologier som Rspec. Fordi at lære disse to på egen hånd senere viste sig at være afgørende for at lande mit første udviklerjob.

3. Ville en jobgaranti og / eller karriereydelser have hjulpet mig?

Som jeg nævnte tidligere, har mange bootcamps en politik "Bliv ansat eller få pengene tilbage". Og mange flere har et karrieretjenesteorgan, der hjælper dig med at komme i kontakt med potentielle arbejdsgivere og coache dig til ansøgninger og interviews.

Og selvom dette sandsynligvis lyder som en sød aftale for mange, tror jeg faktisk ikke, det ville have gjort en forskel for mig. Men så igen havde jeg også tid til at bruge nogle 500 timer på kodning i løbet af de to måneder, der fulgte efter bootcampen, privilegiet at have en eliteskoleeksamen i mit CV og en masse erfaring med at ansøge og interviewe job. Hvis disse ting ikke gælder for dig, er dette måske en faktor, du skal overveje, når du vælger blandt bootcamps. Jeg ved ikke.

Del 5: Opbygning af en portefølje

Den sidste juli denne sidste sommer var bootcampen forbi. Men jeg var lige ved at komme i gang.

At udvikle Unify-appen i bootcampen og tage den over målstregen havde givet mig meget momentum, og jeg var fast besluttet på at få mest muligt ud af det momentum, mens det var der.

Jeg havde stadig nogle penge tilbage i banken, og et par uger tilbage på underudlejningen i Barcelona. Dybest set forlod alle jeg kendte i byen. Så jeg havde slet ingen grund til ikke bare at fortsætte med at spise, sove og drømme kode. Kun halvt bevidst oprettede jeg et par nye rutiner og vaner for mig selv:

  • Jeg ville kode hver eneste dag, indtil jeg nåede mit mål, hvilket naturligvis var at få det første udviklerjob. Betydning mandag til søndag, dag og nat.
  • Jeg ville skubbe hvert stykke kode, som jeg skrev til Github , det største sted for potentielle arbejdsgivere til at inspicere dine kodefærdigheder og ambitionsniveau. Selvom jeg ikke havde lyst til at have produceret noget, der er værd at begå, ville jeg stadig gøre det bare for at bygge videre på den søde grønne begivenhedshistorie, som hele verden kan se.
  • Og jeg ville fordybe mig helt i så meget softwareindhold, som jeg overhovedet kunne . Det betød at lytte til podcasts som Software Engineering Daily og SE Radio, hver gang jeg gjorde noget ærinde, løb ud eller lavede madlavning. Det betød at se kodetaler, tutorials og foredrag fra Youtube-kanaler som Coding Tech, Traversy Media og CS50. Det betød at læse mellemstore publikationer som Hacker Noon, freeCodeCamp og Codeburst og magasiner som Techcrunch og The Next Web. Og det betød at installere Dash på min bærbare computer for altid let at kunne finde den korrekte dokumentation om det syntaksproblem, jeg kæmpede med på et hvilket som helst tidspunkt (for mig så for det meste MDN-webdokumenter, api.rubyonrails.org og RubyDocs) .

Med andre ord var min motivation for at blive udvikler stærkere end nogensinde, og jeg vidste, at jeg hverken sandsynligvis aldrig ville blive kaldt til et jobinterview, medmindre jeg havde en kickass-portefølje, hvis jeg hverken havde nogen akademiske eller faglige fordele. Så det er hvad jeg har tænkt mig at gøre næste gang.

Dagen efter demo-dagen, næppe ædru fra den efterfølgende nat ude, begyndte jeg at bygge min allerførste egen Rails-app (det var så stærkt momentum!). Cocky som jeg var, regnede jeg med, at den første app ville tage et par uger at afslutte, nu hvor jeg allerede havde gennemgået det hele én gang med Unify-appen. Igen tog jeg fejl.

Det ville tage mig næsten to måneder at afslutte det. Der var så mange processer i de sidste to uger af bootcampen, der var gået så hurtigt, uden at jeg helt forstod dem. Jeg sidder fast i flere dage på alle mulige ting, fra pinligt simpelt til noget avanceret. Bare konfiguration af en datetime-picker krævede flere dage brugt på Stackoverflow. For ikke at nævne chatfunktionen ved hjælp af websockets med Action Cable, som det tog mig cirka to uger at få ret.

Men den investerede tid var så det værd. Appen viste sig faktisk ret god: det var faktisk noget, jeg kunne demonstrere for folk og føle mig stolt. Og selvom der havde været mange øjeblikke af desperation, havde jeg lært et ton. Og faktisk, at opleve alt det travlhed gav mig en masse komfort ved, at bootcamp sandsynligvis havde været et godt valg.

Hvis det var så svært at kode disse ting nu, da jeg var bekendt med alt, hvor svært ville det ikke have været, hvis jeg ikke havde haft undervisningsassistenterne, platformen og læseplanen, når jeg gjorde det første gang?

Så engang i slutningen af ​​august sluttede jeg appen. Jeg var hjemme i Stockholm, boede i min fars lejlighed, brød og følte mig ret ynkelig. Jeg prøvede mit bedste for at bruge denne selvmedlidenhed til at fortsætte med at styrke min kodningsindsats. Og det fungerede temmelig ok.

Snart nok kom tiden til at kode det faktiske porteføljeside. Og for en gangs skyld besluttede jeg at holde det enkelt. Så jeg sammensatte en meget minimalistisk statisk webside, hvor jeg kunne samle de ting, jeg havde gjort.Efter afslutningen havde min plan været at begynde at ansøge om job. Men der var noget, der generede mig. Kan du huske, hvordan jeg sagde, at jeg havde været lidt tøvende over for Ruby on Rails, før jeg kom til Le Wagon? Nå, selvom jeg faktisk ville elske Rubys minimalisme og enkelheden ved at bruge Rails, følte jeg stadig, at jeg havde taget en genvej et eller andet sted.

Under afsnittet "Færdigheder" på min porteføljeside kunne man finde Ruby, Rails, SQL, Postgres, HTML / CSS, jQuery, Bootstrap, Sketch, Git og Heroku. Og JavaScript.

Det var den sidste, der generede mig. Det føltes som en løgn.

Hvis jeg begyndte at ansøge om job nu, kunne jeg sandsynligvis lande noget anstændigt som Rails-udvikler. Men hvad hvis alle haderne havde ret, og Rails faktisk var forældet og døende? Og hvad hvis jeg fandt mit drømmejob, kun for at indse, at de brugte avancerede JS-teknologier? Jeg ville ikke have en chance med mine 200 timer på freeCodeCamp og 2-3 jQuery dage + 1 React.js dag på bootcampen.

Hubris-delen af ​​min hjerne talte til mig igen - "Her er en idé: hvad hvis jeg også ville lære MEAN-stakken?" BETYD som i MongoDB, Express.js, Angular.js og Node.js, hvilket er ligesom JavaScript-ækvivalent med hvad Rails er for Ruby. Ifølge søgeresultaterne på LinkedIn og Glassdoor ville det betyde, at jeg mere eller mindre ville fordoble antallet af udviklerjob, som jeg var kvalificeret til.

Jeg huskede, at Gus, bootcamp manager, havde fortalt mig, at det ville tage mig omkring en måned at lære det. Hvor svært kunne det være? Jeg kunne sandsynligvis gøre det om to uger, var min tanke.

Og sådan endte jeg i det, jeg gerne vil kalde tutorialsumpen .

Så endnu en gang henvendte jeg mig til min gamle ven Google for at undersøge læringsstrategier. Men efter et par timer kunne jeg stadig ikke finde et godt online kursus til mine MEAN stack 101 behov. De syntes alle at have fokus på en del ad gangen, hvilket bestemt er den rigtige vej at gå, hvis du vil forstå en ramme i dybden. Men da jeg ville lære så meget som jeg kunne inden for to uger, lige nok til at kunne tilføje et nyt projekt til min portefølje, havde jeg ikke tid til det.

Det var da jeg opdagede en helt ny dimension af udviklingsuddannelse: YouTube-tutorials. Der var så mange derude. For hver teknologi eller stak, jeg kunne tænke på, fandt jeg mindst fem anstændige tutorials.

Til sidst fandt jeg min vej til Traversy Media-kanalen og tutorial-serien MEAN Stack Front To Back. Ti videoer på 20 minutter hver, der viser dig, hvordan du opbygger en grundlæggende RESTful webapp med både brugerregistrering og login-godkendelse. Perfekt.

Jeg startede med det samme og kodede sammen til hver video på min bærbare computer. Og skør nok, efter bare et par dage var jeg færdig. Jeg havde faktisk kodet en fuldt fungerende webapp ved hjælp af helt udenlandske teknologier. Node til backend, Mongo til administration af databasen, Angular til frontend og Express for at binde det hele sammen.

Kunne det virkelig være så let? Vidste jeg disse ting nu? Mens jeg var glad for, at det havde været så meget lettere, end jeg havde troet, løb en kold rystelse af for godt til at være sandt ned ad min rygsøjle.

Da jeg var forud for tidsplanen, regnede jeg med, hvorfor ikke bygge videre på appen lidt længere? Min idé var at gøre det til en mellemklon ved blot at aktivere grundlæggende blogindlæg CRUD-handlinger (oprette, læse, opdatere, slette), som vi havde gjort i et projekt i bootcampen med Rails.

Jeg kom dog ikke meget langt. Jeg regnede med, at jeg bare skulle tilføje et par nye ruter, modeller, controllere og visninger, og det ville være det. Problemet var, at jeg stadig tænkte på "Rails-måde", hvor "konvention over konfiguration" gør funktioner som denne virkelig nemme og hurtige at bygge.

Som jeg havde læst og hørt mange gange, følger MEAN-stakken det modsatte mantra: "konfiguration over konvention", hvilket betyder, at du får en betydeligt mere fleksibel ramme ved at opgive nogle af de "magiske" automatiseringer. Som at få en controllerhandling med et bestemt navn forbundet til en visning med det samme navn lige ud af kassen. Hvilket er et rigtig sødt stykke magi at få, når du er nybegynder.

Så for første gang at indse, hvor meget sværere det var at kode efter "konfiguration over konvention" kom som et stort slag i ansigtet. Fordi det beviste, at min fornemmelse af, at hele tutorialsprocessen havde været for god til at være sand, var rigtig. Men det var først, før jeg begyndte at kode off-script uden de trøstende instruktioner fra Brad Traversy, at jeg indså det.

Så der var jeg, knæ dybt inde i den store mudderpulje, der var den BETEGNEN stak for mig dengang. Appen var ikke nær klar til at blive føjet til min porteføljeside. Det havde bogstaveligt talt ingen funktioner. Bare muligheden for brugere at registrere, logge ind og ikke gøre andet end at se på nogle statiske Bootstrap-design.

En anden mulighed var bare at fortsætte med at prøve og fejle måde. I modsætning til bootcampen havde jeg fjernet mine træningshjul MÅDE for tidligt og ville sandsynligvis skulle bruge uger på Stackoverflow for at kunne afslutte appen som jeg havde planlagt det. Jeg havde ikke uger. Jeg skulle begynde at ansøge om job i går.

Ironisk nok viste det sig, at den eneste vej ud af tutorialsumpen, jeg havde lagt mig i, var at fortsætte med at vade igennem det ved at følge flere tutorials. Heldigvis fandt jeg en ret god en på den samme Youtube-kanal og besluttede at bruge den som min livline.

Og sådan blev webappen, der i sidste ende skulle være en Medium klon, en musikopdagelsesapp ved hjælp af Spotify Search API.

På trods af al stresset, to uger efter beslutningen om at prøve at lære MEAN-stakken, implementerede jeg faktisk en anstændig webapp. Hvilket havde været mit mål. Sikker på, det var lidt som at snyde, men jeg regnede med, at så længe jeg kunne demonstrere det og forklare alle dele af det på et jobinterview, ville ingen være ligeglad med, om jeg havde fulgt en tutorial eller ej.

Boom. Pludselig havde jeg tre apps i min portefølje og kunne tilføje en masse nye teknologier til mit kompetencerepertoire. Endelig var det tid til at gå ind i den næste fase af min udviklerrejse: jobjagten. Og det var ikke en dag for tidligt.

Del 6. Ansøgning om job

Alt i alt ville det tage mig omkring 4 uger, 30 ansøgninger, 10 interviews og 3 tilbud at finde den perfekte pasform. Og ironisk nok ville det faktisk være det første firma, jeg ansøgte om, at jeg ville blive medlem. Jeg kunne selvfølgelig kalde det en tilfældighed, men jeg tror, ​​det er mere en effekt af en grundig screeningproces, før jeg overhovedet begynder at sende ansøgninger.

Jeg må indrømme, at jeg tror, ​​at en hel del held spillede ind i min hurtige jobjagtsucces. Men for hvad det er værd, vil jeg beskrive den proces, jeg fulgte, da jeg synes, det lærte mig et par ting om, hvilke job og virksomheder at fokusere på til det første udviklingsjob.

Den første ting, jeg gjorde, var at oprette et regneark til en liste over interessante job (jeg er oprindeligt en kedelig økonom, husker du?). Derefter brugte jeg flere dage på at søge jobbrædderne i LinkedIn, Glassdoor og Stackoverflow efter job baseret på nøgleord som web, udvikling, software, frontend, backend, Ruby, Rails, Javascript, Angular, Node og Postgres.

Ikke meget overraskende returnerede søgningerne hundredvis af job bare i Stockholm-området alene. Virksomhederne bag dem varierede fra startups til digitale bureauer, medievirksomheder, cloud-tjenesteudbydere, spiludviklere og alt imellem.

I løbet af de sidste par måneder har jeg formået at sammensætte et ret snævert sæt kriterier for, hvad jeg ville have fra min næste arbejdsgiver.

Hvis jeg kunne vælge et hvilket som helst job, jeg ønskede, lignede mine prioriteter mere eller mindre følgende:

  1. Jeg ville kode på tværs af hele stakken, hvilket betyder, at jeg ville få lige så meget database- og arkitektur ting som UX / UI ting, og hovedsageligt i JavaScript. Al hype omkring React havde sandsynligvis meget at gøre med sidstnævnte. Som jeg fortalte dig før, for alt hvad jeg vidste på dette tidspunkt, var Rails dybest set, og JavaScript var fremtiden.
  2. Min læringskurve ville være ekstremt stejl til det punkt, at jeg skulle kode dag og nat for at holde trit. Alt for at blive så god som muligt på kortest mulig tid.
  3. Mine kolleger ville være kloge, ambitiøse, sjove og uformelle og helst alle på samme tid.
  4. Virksomheden ville være en opstart med høj vækst med en meningsfuld mission og et produkt relateret til blockchain, AI og / eller bæredygtighed eller et digitalt bureau i topklasse med sådanne projekter.
  5. Jeg ville blive betalt retfærdigt.

Det handlede om det. Temmelig høje krav til en rookie, kan man tro. Men bemærk, at en høj løn ikke var en del af kriterierne (det er det heller ikke i dag med 6 måneders erhvervserfaring). Måske siger jeg det indlysende, men hvis du migrerer til en ren udviklingsrolle fra noget helt andet, synes jeg det er vigtigt at vide, at det ikke betyder noget, hvad du fik betalt før.

For eksempel vidste jeg, at min markedsværdi i finansbranchen var omkring $ 5.000 pr. Måned. Men da jeg indså, at softwareudvikling er et fundamentalt andet håndværk, ville jeg sætte mit mål omkring $ 3.700, men ville nøjes med så lave som $ 3.000 (hvilket er betydeligt lavere end den svenske gennemsnitsløn omkring $ 4.000).

Med alle ovenstående kriterier i tankerne, ville jeg begynde at gennemgå jobannoncer en efter en, tilføje dem, jeg kunne lide, til min favoritliste og opgive dem, jeg ikke gjorde. Efter et stykke tid bemærkede jeg nogle få mønstre:

For det første krævede de fleste virksomheder på papir meget mere tekniske færdigheder og erfaring end jeg kunne tilbyde. Dette kom ikke som nogen overraskelse. Fra både min egen forskning og bootcampen lærte jeg, at positionen "junior udvikler" var ved at dø.

At mange virksomheder betragtede det som for dyrt at bruge den dyrebare tid som seniorudviklere brugte på mentoring af rookies. Derfor foretrak de at ansætte seniorudviklere, som er meget efterspurgte, men ekstremt lave.

Det store paradoks her er naturligvis, at hvis ingen tager det på sig selv at pleje og undervise juniorudviklere, hvordan kan vi nogensinde lappe manglen på seniorudviklere på markedet? Ikke desto mindre, efter at have indset, at det er sådan, branchen fungerer i dag, indså jeg også, at jeg skulle søge stillinger, som jeg ikke var kvalificeret til.

For det andet så jeg, at jo varmere og større virksomheden var, jo mere sandsynligt var det at inkludere krav til en eller anden datalogi-relateret grad og professionel udviklingserfaring. Jeg regnede med det, at en anstændig portefølje og følgebrev sandsynligvis kunne give dig et interview med et firma, der har brug for en "Rails ninja" eller "React superstar" snarere end en novice som jeg var.

Men hvis jobannoncen eksplicit kræver mere end 3 års professionel JavaScript-erfaring og en kandidatgrad inden for datalogi, er mine chancer for at få et interview sandsynligvis meget små.

For det tredje nævnte næsten hver eneste jobannonce React. På trods af al hype omkring det online var jeg stadig forbløffet over sin skøre høje efterspørgsel.

Så forbløffet over, at jeg faktisk besluttede at bruge et par timer om dagen til at bygge en lille React-webapp ved hjælp af React.js på forsiden og Rails på bagsiden, så jeg også kunne tilføje det til min portefølje og genoptage.

Til dette brugte jeg faktisk mest noterne fra det ene React-foredrag i Le Wagons bootcamp, men hvis du er interesseret i at lære det, har du ikke svært ved at finde gratis guider derude, ikke mindst dem fra freeCodeCamp.

Bortset fra det faktum, at jeg kunne sætte React på mit CV, var den største fordel ved denne oplevelse at blive fortrolig med at opbygge en webapp ved hjælp af komponenter (i modsætning til controllere og visninger, som det er Rails-vejen) og arbejde med rekvisitter og tilstand .

Odds er, at du bliver nødt til at blive venner med en slags JavaScript-ramme før eller senere, og så vil disse koncepter være nyttige på begge måder, det være sig React, Angular, Vue, Ember eller andre af de gazillion JavaScript-rammer derude.

Med nye indsigter som dem ovenfor kunne jeg udvikle og forfine de kriterier, jeg allerede havde for at afgøre, om et bestemt job skulle føjes til min favoritliste eller ej. Snart nok havde jeg en liste med omkring 50 ledige stillinger, og det var tid til faktisk at begynde at sende ansøgninger. Fra en baggrund, hvor jeg havde ansøgt og interviewet hos hundreder af virksomheder, føltes dette som den nemmeste del hidtil.

Dette kan have noget med mig at gøre, at jeg er den slags person, der skriver et generisk følgebrev, som jeg sender til alle. Jeg ved hvad du tænker: hver mentor / lærer / rekrutterer, du nogensinde har talt med, har frarådet dette. Men kom nu. Det er en jobansøgning. Ikke talen til din bedste vens bryllup.

Odds er, at rekruttereren alligevel ikke bruger mere end et minut på det. Så det betyder ikke rigtig, om du nævner den pris, som virksomheden vandt, eller at du var imponeret over YoY-væksten sidste år eller din helt spekulative mening om, hvorfor deres kultur er så meget bedre end konkurrent X'er.

Det, der betyder noget, er, at du i tekst kan udtrykke sagen, hvorfor du er værd at bruge dem en time på at møde dig - på en overbevisende, datadrevet og grammatisk fejlfri måde. Hvis du vil se på min, skal du bare skrive til mig, så sender jeg det til dig! Fik en smule flatterende feedback om det, bare sige ...

Den næste ting jeg gjorde var at opdatere mit CV og LinkedIn-profil. Og her kan jeg ikke understrege nok vigtigheden af ​​søgeord. Sørg for, at navnene på alle de teknologier, du kender (eller vil foregive, at du kender) er inkluderet i begge. På denne måde er du mere tilbøjelige til at vises i søgeresultaterne (det samme her, bare spørg mig, så sender jeg mit CV).

Efter at have sendt alle ansøgningerne gik en uges tid uden at jeg hørte noget fra nogen af ​​virksomhederne. Det viste sig faktisk at være en tiltrængt hvileperiode for mig. Jeg tog mig tid til at genoprette forbindelse til mine venner og familie, som jeg slags var forsømt i de sidste par måneder, fanget af min nye besættelse.

Så begyndte jeg at få svar.

Del 7: Foretagelse af interviews

Det første svar kom fra en rigtig ung opstart. Det bestod grundlæggende af to fyre, en tidligere bankdirektør og en seniorudvikler CTO. E-mailen kom fra CTO, og han inviterede mig til mit allerførste udviklerinterview.

Da jeg var klar over, at de positive svar altid vil komme før afvisningerne, forsøgte jeg at holde et køligt hoved og ikke blive for begejstret.

Men stadig, bare det faktum, at denne fyr, en seniorudvikler med mere end 10 års erfaring, havde kigget på min LinkedIn-profil, følgebrev, CV og vigtigst af alt min portefølje og koden bag det på min Github-profil og stadig troede Jeg kan muligvis skrive god kode til dem, fik mig til at føle mig ret forbandet stolt af mig selv.

Selvom jeg ikke troede, at virksomheden faktisk opfyldte alle mine kriterier (primært på grund af det lille hold og dårlige lønudsigter), svarede jeg straks og accepterede invitationen.

På trods af al min indsats indtil dette tidspunkt havde jeg ikke brugt meget tid på at forberede mig til det tekniske interview . Men ud fra hvad jeg havde hørt og læst, skulle det være en kunst i sig selv, og i mange tilfælde noget folk ville bruge måneder på at forberede sig på.

Ofte vil bootcamp-alumner og selvlærede kodere med mere praktisk erfaring mislykkes i det tekniske interview på grund af deres manglende viden i grundlæggende datalogisk teori. Ligesom CS-grader ofte svigter på grund af deres manglende erfaring med at opbygge apps med moderne teknologier.

Men da jeg var løbet tør for både tid og penge, regnede jeg med, at dette også var noget, jeg skulle lære at gøre. Jeg kunne bare ikke udsætte interviewfasen længere. Ligesom jeg var blevet brændt mange gange, da jeg lærte at foretage den økonomiske form for interview, vidste jeg, at disse forbrændinger var afgørende for, at jeg endelig skulle finde ud af, hvordan jeg kunne vinde interviewet. Hvorfor ville det tekniske interview være anderledes?

Så jeg accepterede invitationen, og et par dage senere gik jeg ind i lobbyen på deres kontor. De ventede på mig ved receptionen.

Stedet var et losseplads. Hvis du nogensinde havde set kontoret, føltes det som om jeg lige var trådt ind på kontoret for Dunder Mifflin Paper Company. De fortalte mig, at det plejede at være et kontor for et stort revisionsfirma, omdannet til et billigt midlertidigt samarbejdsområde for den tid, der var tilbage til den planlagte renovering. Vi trådte ind i et konferencelokale og satte os ved et stort træbord.

De startede med at fortælle mig meget om sig selv og virksomheden. De havde lige udgivet en betaversion af en ny Medium-ish-app til fremtrædende livsstilsforfattere og havde samlet lidt penge fra venner og familie i deres frørunde. Men de var stadig før lanceringen, og absolut før indtægterne.

Efter cirka en time af det, der føltes meget mere som en salgspitch end et interview, forlod administrerende direktør, og jeg fik at vide, at CTO og jeg ville fortsætte til den tekniske del af interviewet. Mit hjerte sprang et slag. Fra alt det, jeg havde læst om tekniske interviews, forventede jeg at få alle mulige hjernevridere, kodende udfordringer og spørgsmål om komplekse datastrukturer kastet mod mig.

Men ingen kom. I stedet begyndte CTO at stille mig alle disse meget åbne spørgsmål.

Ligesom hvilke teknologier og rammer jeg kunne lide. Hvis jeg kunne vælge en ny teknologi til at lære næste, hvad det ville være. Hvad jeg tænkte på den nye syntaks introduceret af ES6 (2015 Javascript-opdateringen, der introducerede en masse nye seje ting som pilfunktioner, løfter og konstanter).

Vi havde en dejlig samtale, der varede sandsynligvis endnu en halv time. Men så kom den store tilbageslag, da CTO besluttede at lægge alle kortene på bordet.

På grund af deres stramme økonomiske situation fortalte han mig, at de kun kunne tilbyde mig en 6-måneders praktikopgave med symbolsk løn for nu (hvilket betyder praktisk talt ingen løn). Hvis praktikopholdet gik godt, var de imidlertid meget åbne for at tilbyde både egenkapital og anstændig løn.

”Hvis virksomheden stadig er der,” tilføjede jeg næsten.

Selvom jeg blev smigret over, at de havde givet mig et tilbud på stedet, vidste jeg med det samme, at dette hverken var det firma eller det produkt, jeg ledte efter. Ikke desto mindre afviste jeg dem ikke med det samme. Et tilbud er stadig et tilbud, tænkte jeg, og kan altid være praktisk, når man senere forhandler med andre virksomheder.

På trods af skuffelsen over både jobbet og det faktum, at det tekniske interview ikke rigtig havde lært mig noget nyt, havde jeg stadig modtaget et tilbud, hvilket gav mig et stort tillidsforhøjelse for de kommende interviews.

Det andet svar, jeg fik, var fra en lidt større opstart ved navn Teamtailor. De var en Stockholm-baseret virksomhed med en mission om at digitalisere rekrutterings- og arbejdsgivermærkeindustrien, der i øjeblikket styres af ganske ikke-tekniske rekrutteringskonsulenter og HR-ledere.

Ikke en dårlig idé. Selvom jobannoncer, der starter med ord som "rekruttering" og "HR" 9 dage ud af 10, ville have skræmt mig væk, var der noget ved dette firma, der fascinerede mig.

Fra min ret grundige undersøgelse fandt jeg ud af, at de havde eksisteret i cirka 4 år, havde omkring 30 ansatte, tilstedeværelse i 4 eller 5 lande, 600 kunder (virksomheder), en vækst i omsætningen på 100% + og brudt lige med en vis margen på toppen. Slet ikke dårligt.

For at afslutte det hele afslørede deres instagram-konto deres kontor: en brooklyn-gammel røde mursten ølfabrik midt i Södermalm, det bedste område Stockholm har at tilbyde.

MM mm.

Alt pegede mod det faktum, at de var i det søde sted i virksomhedens livscyklus. Ung nok til at kunne få dig til at føle, at du er på en rejse sammen med en uformel kultur og masser af plads til initiativ og vækst. Men stadig gammel nok til at have etableret nogle strukturer, som det kan være rart at læne sig på, når du lærer noget nyt.

Alligevel. Igen var det CTO, der skrev til mig. Efter et par meddelelser frem og tilbage besluttede vi os for et første interview på deres kontor et par dage senere. Jeg fik at vide, at både han og en anden medstifter ville mødes med mig.

Før jeg mødte nogen af ​​dem, havde jeg en rigtig god fornemmelse af det hele. Hvilket var dårligt. I det mindste i mit hoved. Fordi nu ville jeg gå ind i interviewet, sandsynligvis have lyst til dem mere, end de ville have mig, tænkte jeg. Efter at have gået op ad den gamle ølfabrik, nåede jeg endelig døren til deres kontor og trådte lige ind i en temmelig speciel scene.

Først en stor lyserød plakat lige i mit ansigt med dristige hvide bogstaver, der skriger til mig: "Teamtailor er en af ​​Europas 100 hotteste startups - Wired Magazine." Til venstre for mig lignede det en stue, hvor en flok 20-årige spillede FIFA på en enorm skærm. Foran mig et større rum, hvor bordet tættest på mig var fyldt med udviklere, der afslappet hackede væk på store skarpe skærme. Og overalt omkring mig slår soft hiphop-beats pulserende fra Sonos-højttalere.

Lige i det øjeblik forsvandt enhver dårlig fordomme over dem for at være et HR-firma. Dette sted var fantastisk. Dammit.

Du kan sige mange dårlige ting om det typiske Silicon Valley-wannabe-kontor. Men efter min mening vil selv det værste kontor af denne art stadig være tusind gange bedre end den typiske corporate modstykke. Så for mig var det himlen. Hvilket var virkelig dårligt for mit forsøg på kølighed til interviewet.

En høj, tynd fyr med en baseballkasket smilede til mig og rejste sig fra sin stol for at hilse på mig. Det var CTO. Vi trådte ind i et konferencelokale med glasvægge og grønt falsk græs, der dækkede gulvet. Den anden medstifter sluttede sig til os, og vi startede interviewet.

I modsætning til mit sidste interview begyndte de med at fortælle mig om den proces, jeg var i. Formålet med dette første møde var primært at lære mig bedre at kende. Hvis jeg fortsatte, ville det andet trin være et teknisk interview. Jeg var så lettet over at høre det. Bedragerisyndromet var ægte.

Det første spørgsmål var mere eller mindre det klassiske ”Hvorfor vil du være udvikler?” De fortalte mig, at det mere end noget andet var mit følgebrev og CV, der havde fanget deres øje. At finde forretningsorienterede udviklere var sjældent, og det var endnu sjældnere at finde udviklere med forretningsgrader og erfaring fra både forretningsudvikling og økonomi. Så hvorfor havde jeg besluttet at hoppe af min vej for at forfølge denne helt anden?

Fra interviewerfaring har jeg lært, at ærlighed næsten altid er den bedste vej at gå i disse tilfælde. Så jeg fortalte dybest set dem, hvad jeg fortalte dig i begyndelsen af ​​denne artikel, at jeg hader at sælge, elsker teknologi og ville overgå til den kreative side af tingene.

Fra dette tidspunkt fik samtalen en slags eget liv. På et tidspunkt fortalte jeg dem, at hvis jeg havde kendt de ting, jeg kender nu, ville jeg sandsynligvis have valgt at studere datalogi i stedet for forretning. Til min overraskelse blev CTO overrasket over denne bemærkning. Han lo og spurgte mig hvorfor.

Jeg tøvede. Jeg indså, at det var en af ​​de ting, jeg havde sagt, fordi jeg troede, det var, hvad de ville høre. Han slap mig af banen og fortalte mig, at han også var en selvlært udvikler. Det eneste emne, han havde taget i uni, var filmstudier. Jeg var lidt chokeret over det. Men der var mere ved det.

Faktisk havde ingen af ​​de 10 udviklere i virksomheden en reel CS-grad. Et par af dem havde taget et år eller to af et privat webudviklingsprogram, men de fleste var faktisk selvlærte.

At høre det fra denne fyr gjorde mig så glad. Han havde lige bekræftet, hvad min tidligere kollega Sandra havde fortalt mig et år tidligere - at du ikke har brug for en grad for at blive en stor udvikler. Gode ​​ting.

Samtalen fortsatte så glat, at det var først i de sidste par minutter, da de spurgte mig om min portefølje. Kun en af ​​dem havde faktisk set på det, og han sagde bogstaveligt talt, at han bare ”havde et blik”. Alt fanget af hvor godt interviewet gik, fortalte jeg dem, at jeg gerne vil demonstrere en af ​​mine apps.

Straks lysede deres ansigter op, og de rettede sig i deres stole og nikkede mig videre. Jeg var ved at indse, at jeg lige havde lavet en STOR fejl.

Den eneste app, der var næsten god nok til at vise disse fyre, var den, jeg havde lavet i løbet af måneden lige efter bootcampen. Og jeg havde ikke rørt ved den i mindst en måned. Jeg tilsluttede min MacBook til den store skærm foran os og indtastede URL'en i browseren.

Den første forlegenhed var, at det bogstaveligt talt tog 20 sekunder at indlæse hjemmesiden. Med en tør hals forsøgte jeg at forklare, at jeg brugte den gratis version af Heroku, hvilket betød, at når den server, der er tilknyttet domænet, ikke modtog nogen anmodninger i mere end en time, ville den gå i denne "dvaletilstand" hvorfra det tog lang tid at vågne op. Det sidste, jeg ønskede, var at de troede, at min app var langsom.

Da det faktisk var indlæst, tog jeg mig tid til at forklare idéen bag produktet. Det var dybest set en tjeneste til oprettelse af virtuelle linjer, der gjorde det muligt for organisationer som flyselskaber, banker og hospitaler at oprette køer online i stedet for på deres fysiske placeringer.

Så kom den anden forlegenhed. Da jeg prøvede at logge ind på min konto ved hjælp af Facebook-godkendelse, mislykkedes det. Som jeg ville indse alt for sent, var årsagen, at jeg ikke havde opdateret URL'en i mine Facebook API-indstillinger efter at have fået et nyt SSL-certifikat. Så Facebook forventede anmodninger fra et // domæne, mens mit kom fra et // domæne. Rookie-fejl.

Det lykkedes mig endelig at logge ind manuelt i stedet og dæmpet nogle af hovedfunktionerne uden problemer. Men så kom den største forlegenhed af dem alle. Jeg kunne ikke få kronjuvelen i min app til at virke: chatten. Da jeg klikkede på chatlinket, kom jeg til chat-siden, men kunne ikke se nogen af ​​mine falske brugere at chatte med.

Så gav jeg dybest set op. Som jeg virkelig ikke burde have. For bare et par timer senere ville jeg indse, at chatten fungerede helt fint. Min brugerkonto havde simpelthen ikke tilmeldt sig nogen linjer at deltage i, hvorfor jeg heller ikke kunne se nogen brugere at chatte med.

Vi sagde farvel og de fortalte mig, at de ville være i kontakt. Jeg forlod interviewet og følte mig vred og skuffet. Hvorfor havde jeg ikke forberedt mig bedre på demoen? Det hele var gået så glat indtil den sidste del.

Ikke desto mindre ville der ikke gå en time, før David skrev mig igen. Han fortalte mig, at jeg var gået videre til næste trin i processen. Jeg kunne ikke tro det, og jeg kunne ikke have været lykkeligere. Men selvfølgelig også lidt bange for at tage mit første rigtige tekniske interview.

I sidste ende ville dette andet interview imidlertid også vise sig at være noget som alle de horrorhistorier, jeg havde læst om online. Allerede i invitationens e-mail fortalte CTO mig, at jeg ville mødes med to af deres seniorudviklere, og at de simpelthen ville have mig til at vise en af ​​mine apps mere grundigt sammen med koden bag det.

Hovedformålet ville være at få fat i, hvor godt jeg kendte deres backend-ramme (Rails), og hvor hurtigt jeg kunne være i stand til at lære deres frontend-ramme Ember.js (som jeg ikke engang havde hørt om på dette tidspunkt).

Jeg vidste med det samme, at demo-appen skulle være den, jeg havde bygget ved hjælp af Rails og React.js. Det var perfekt af to grunde:

  1. det blev bygget på skinner integreret med en JavaScript-ramme (ligesom deres stak), og
  2. Jeg havde lært alle de React-ting, jeg brugte på mindre end to uger, hvilket ville give dem en god fornemmelse af, hvor hurtigt jeg kunne lære Ember.

Denne sag er et perfekt eksempel på, hvorfor det rent faktisk kan betale sig at ikke lægge alle dine æg i en kurv, når du bygger din portefølje, men faktisk prøve et par forskellige stakke.

Snart nok kom den store dag, og jeg var tilbage på deres kontor i et andet af deres falske konferencelokaler. Jeg startede med at vise appens UI-strøm.

Jeg surfede ind på webappen, og snart nok lyste arbejdstitlen "AppHunt" på skærmen med store fed lilla bogstaver. Det var lidt som Product Hunt, men mere som et markedssted strengt til apps. Så enhver bruger ville være i stand til at gennemse hjemmesiden efter apps til salg og til køb. Og hvis de oprettede en konto og loggede ind, ville de også være i stand til at søge og filtrere appelementerne, bedømme dem og skrive ting i kommentarfelterne. Det var dybest set det.

Men heldigvis for mig var det nok. De to seniorudviklere kunne tilsyneladende lide det, jeg viste dem så meget, at de gav CTO tommelfingeren. De fortalte mig senere et par ting, som de specifikt kunne lide:

  • At realtidsfunktionerne - som ændringer i kommentarerne, søgeresultaterne og klassificeringerne, der vises med det samme - viste, at jeg vidste, hvordan jeg brugte tilstand og rekvisitter, hvilket er afgørende i enhver JavaScript-ramme.
  • At jeg brugte JBuilder til at serieisere JSON-anmodningerne mellem frontend og backend.
  • At jeg brugte Elasticsearch til søgefunktionen.
  • At de kunne lide designet, og at jeg selv havde lavet mine skitser i Sketch, før jeg begyndte at kode.
  • At CSS-koden ikke var meget kontekstformet eller indlejret. I stedet fandt de meget af det genanvendeligt i hele appen, hvilket var godt. En ting, der ville have gjort dem endnu mere imponeret, sagde de til mig, ville have været, hvis jeg også havde fulgt den såkaldte BEM CSS-navngivningskonvention.

Det var først et par uger efter det andet interview, at CTO nåede ud til mig igen med et tilbud. Efter nogle diskussioner frem og tilbage besluttede vi os om en prøvetid på 6 måneder med en $ 3.300 månedsløn, der ville blive styrket til mit $ 3.700-mål, da jeg nåede et produktivt niveau.

Jeg accepterede stedet og startede mit nye job næste uge. ✌️

Parallelt med hele Teamtailor-processen interviewede jeg også for 4 andre virksomheder. Det mest bemærkelsesværdige var det svenske fintech-fænomen iZettle, som er en slags paraply med flere forskellige finansielle produkter, men hvor deres trådløse kortterminal sandsynligvis er den, de er mest kendt for.

Da denne vellykkede opstart nærmer sig en enhjørning, ville jeg lære, at deres krav til erfaring og færdighedsniveau var væsentligt højere end de mindre startups, som jeg havde interviewet indtil videre. Jeg så det både i den meget mere grundige rekrutteringsproces, de havde (5 interviews!), Og sværhedsgraden i interviewspørgsmålene.

Hovedårsagen til, at en rookie som mig endda fik et interview der i første omgang, vil jeg sige, at det i høj grad skyldes henstillingen fra en ven og navnet på den handelshøjskole, jeg er uddannet fra. Så jeg slags snydt mig ind, ville jeg sige. Men jeg var så åbenlyst ikke forberedt på dem.

Ligesom med de andre virksomheder var det første interview alt sammen fluff og bløde færdigheder. Men endnu mere “HR” denne gang. Hvorfor vil du arbejde som udvikler? Hvilke teknologier kan du lide at bruge? Hvad er dine styrker / svagheder? Og så videre. Nemme ting.

Det andet interview ville imidlertid vise sig at være en ganske traumatisk oplevelse. Det hele startede med, at jeg sad i et konferencelokale med to af deres webudviklere. Vi gentog hele "lære hinanden at kende" samtalen, og jeg blev temmelig behagelig og selvsikker. Og så fik jeg den største sucker punch i mit liv.

Ud af ingenting rakte fyren over bordet mig et stort hvidt A3-papir og en pen. Han fortalte mig, at de ville have mig til at tegne en skitse af datastrømme og processer involveret i følgende scenarie:

”En mindre virksomhedsejer har en konto hos iZettle og bruger deres kortterminal. Efter at en af ​​hans / hendes egne kunder har foretaget et køb ved hjælp af terminalen, ønsker han / hun at logge ind på webappen og / eller mobilappen for at se transaktionen. ”

Dette fangede mig virkelig på vagt, men jeg nikkede nølende og accepterede udfordringen. Så sagde fyren noget i retning af: "Vi tager bare en kop kaffe, og så kommer vi om 5 minutter tilbage og lader dig forklare dine tanker."

5 minutter! Var det en vittighed? Jeg kunne virkelig ikke fortælle det. Da de forlod, overvejede jeg seriøst, om dette var et slags trick-spørgsmål, hvor jeg skulle indse, at denne opgave bare var for stor til at udføre anstændigt på så kort tid. Men tiden løb allerede ud, og den var for stor af en risiko. Så jeg besluttede at give det et skud.

Efterhånden indser jeg, at det var et spørgsmål om systemdesign, hvilket betyder, at de ville have mig til stort set bare at kortlægge en samlet oversigt over, hvordan webappen og mobilappen fremsatte anmodninger til nogle API, der forbandt dem til serveren / serverne og databasen (hvis du vil forbedre dine færdigheder i systemdesign, vil jeg virkelig anbefale denne Youtube-kanal).

Men det gjorde jeg ikke noget af. I min tilstand af panik sprang jeg flere trin fremad og begyndte at prøve at tegne databasemodellen for brugerkontoen med en tabel, kolonner og udenlandske nøgler (jeg antog, at de brugte en relationsdatabase). Da jeg var færdig med det, havde jeg cirka 30 sekunder tilbage til at kortlægge de andre komponenter i arkitekturen. Jeg var så stresset, at jeg blev filosofisk og begyndte at stille spørgsmålstegn ved, hvad de faktiske roller for API og server var. Ikke et godt tegn.

Der gik 5 minutter, og de to udviklere vendte tilbage til en skitse, der næppe var en 5-årig værdig. Jeg havde dybest set lige tegnet tre cirkler. Én til venstre, der repræsenterer databasen, og to til højre, der repræsenterer web- og mobilapp-klienter.

Selvfølgelig svigtede jeg interviewet elendigt. Hvilket også var grunden til, at jeg ikke gik videre til en tredje. Men de svigtede mig let og fortalte mig, at de kunne lide mig, og at jeg skulle ansøge igen, når jeg havde et eller to års erfaring mere.

Hele oplevelsen skød mig ud, da jeg ikke troede, jeg havde fået en chance for at vise dem mine praktiske færdigheder. Selvom jeg slags kan se, at der er en form for værdi i at kunne illustrere systemarkitektur på et stykke papir, tror jeg virkelig, at der er tusind gange mere værdi i at kunne vise dine færdigheder med en praktisk øvelse, som en kodning udfordring eller app-demo. Men hej, der er en lektion at lære i enhver fiasko, ikke?

Alt i alt endte jeg med at deltage i 11 interviews for 6 virksomheder i løbet af mine 4 ugers jobjagt, hvoraf 3 gav mig tilbud. Så på trods af at blive brændt et par gange, var det virkelig en fantastisk oplevelse. Hvis jeg blev bedt om at navngive den eneste største belønning (bortset fra at få mit drømmetilbud), ville det være, at jeg blev fortrolig med at tale med udviklere om software . Hvis du lider af bedragerisyndromet som jeg gjorde (slå op, det er en ting), er der simpelthen ingen bedre måde at behandle det på.

En anden vigtig takeaway er, at ud af mine 11 interviews viste kun en at kræve faktisk teoretisk datalogisk viden. Ingen spørgsmål om komplekse datastrukturer, ingen lurede hjernebasere. Bare et spørgsmål om systemarkitektur. Resten var 100% centreret omkring enten praktiske eller bløde færdigheder. Så medmindre du ansøger om et prangende softwareingeniørjob hos Google eller Facebook, vil jeg bestemt anbefale at fokusere på de praktiske ting og lære de teoretiske ting senere.

Til sidst vil jeg gerne understrege det faktum, at jeg ikke kendte nogen involveret i det firma, som jeg endelig blev ansat af. Jeg ved, at der er meget indhold derude, der hævder, at et stærkt personligt netværk er den vigtigste faktor til at lande det første dev-job. Og selvom det statistisk kan være tilfældet, er koldt påføring uden henvisning bestemt ikke spild af tid.

Del 8: Hvad jeg gør i dag

I skrivende stund har jeg arbejdet hos Teamtailor i seks måneder. Og tiden har virkelig flyvet hurtigere end jeg nogensinde havde forestillet mig. Jeg har næppe engang lagt mærke til den lange, mørke og frysende vinter, der normalt er en kamp for at udholde her i Stockholm.

Jeg er en del af et team på 12 personer, hvor alle bortset fra en designer er full stack Rails og JavaScript-udviklere. Et par har 10+ års erfaring, nogle kun et par år, men kun to har egentlige akademiske tekniske grader. Resten af ​​os er mere eller mindre selvlært.

Jeg bruger mine dage på at hacke væk på vores Rails / Ember-platform og prøver hver dag at forlade appen lidt bedre, end jeg fandt den samme morgen. Selve produktet er en rekrutteringsweb-app, der lader virksomheder opbygge og administrere deres egne karrieresider, ubesværet og fuldstændigt uden at kræve nogen kodningsfærdigheder.

Til gengæld har appen bag dette karriereside to hoveddimensioner:

  1. Det giver brugerne mulighed for at håndtere arbejdsgivernes branding, der er beregnet til at tiltrække talent, med midler som jobindlæg, indhold på sociale medier, en blog, billeder, videoer og gifs.
  2. Det tilbyder et massivt sæt værktøjer til at håndtere trafikken og ansøgere - som at spore kandidater, chatte, maile og sende en sms til dem, evaluere dem med tests, opsætte automatiske udløsere til at udføre nogle handlinger, når en kandidat flyttes fra et trin til et andet, og promovering af jobannoncer på alle de store jobbrædder for at nævne nogle få.

Hvordan vi arbejder

I vores produktteam prøver vi vores bedste for at følge de agile principper for Scrum, Kanban og parprogrammering. Det betyder praktisk for os, at vi udfører vores arbejde i cyklusser, hvor vi deler implementeringen af ​​nye funktioner op i projekter, der kører i 6 uger ad gangen. Til gengæld har hvert projekt udviklere parret to og to og gjort ansvarlige for afsendelse af de nye funktioner inden for de 6 uger. Parene distribuerer deres arbejde kontinuerligt baseret på et foruddefineret Trello-bord med mindre opgaver inden for hver planlagt funktion.

Selvfølgelig bygger vi ikke bare nye ting. Vi vedligeholder også appen. Og kernen i denne vedligeholdelse har vi, hvad jeg mener er en temmelig usædvanlig rutine: "tech-on-call" pligt. Dette betyder en ugentlig roterende position, hvor hver udvikler til gengæld bruger en hel uge på at hjælpe vores brugere og supportmedarbejdere i Intercom.

Hvis du synes, det lyder som en irriterende og frustrerende opgave, var det. Indtil vi besluttede, at hver vagtteknik ville sætte alle deres andre projekter på pause, mens de var på supporttjeneste. Så pludselig, da jeg ikke længere følte, at hvert minut brugt på Intercom var et minut stjålet fra mine projekter og deadlines, begyndte jeg faktisk at nyde det.

Tænk over det - når du bare tager dig tid til at lytte, indser du, at du dybest set har en hær af frivillige kvalitetssikringstestere til din rådighed, altid klar til at give øjeblikkelig feedback om produktets faktiske UX og brugerens smertepunkter. I betragtning af dette er det tilstrækkeligt at sige, at jeg har lært lige så meget af mine tekniske uger som ethvert andet projekt eller en fejl, som jeg har arbejdet med.

Endelig tager vi to uger mellem hver 6-ugers cyklus til at gøre en fælles indsats for at squash alle de bugs, der er opstillet i vores Trello bug board. Vi bruger også disse to uger til at udvikle pladser til nye funktioner, som vi selv gerne vil se i appen. Hver udvikler får derefter chancen for at sætte disse ideer op i et delt pitchmøde, som vi har hver 8. uge, hvilket virkelig giver en, der ikke bare ønsker at løse hårde kodeproblemer, men også forretningsproblemer gennem nye seje tilføjelser til det eksisterende produkt .

Hvad jeg har gjort indtil videre

Selvom appen indeholder så mange funktioner og teknologier, der i starten var helt fremmed for mig, blev jeg smidt lige midt i handlingen allerede i min anden uge. Onboarding-processen - hvilket betyder, at jeg har en seniorudvikler, der viser mig rebene - varede kun fem dage. Efter den første uge skulle jeg i teorien være mere eller mindre autonom.

Det betød, at jeg forventede at forstå platformens arkitektur, dev-værktøjssættet, teamets workflow, vores stilguide, hvordan man yder teknisk support til brugere og kolleger og andre interne rutiner til udvikling, test, debugging, gennemgang og implementering af kode . Med andre ord en masse nye ting til nogen, der lige kom ud af en bootcamp.

Hvis du får panik lige nu, fordi du tror, ​​jeg faktisk lærte alt det om en uge, skal du slappe af. Det gjorde jeg bestemt ikke. Det var først efter et par måneder, at jeg begyndte at blive fortrolig med det meste af det. Og med tiden bemærkede de andre, og jeg ville have tillid til mere og mere ansvar. Siden da har jeg fået en del af nogle af de mest spændende og udfordrende projekter, jeg nogensinde har arbejdet med.

Den første seriøse var at opdatere den metode, vi brugte til at hente oplysninger om brugere, der tilmeldte sig vores app med bare en e-mail. Vi havde allerede integreret med en tredjeparts API til dette, at vi fremsatte anmodninger om at få data som fulde navne og URL'er til sociale medieprofiler og avatarbilleder.

Da vi imidlertid fandt, at de hentede data ofte var forkerte, havde produktteamet besluttet at skifte til en anden udbyder. Da det ville udsætte mig for flere vigtige områder og datastrømme i appen, var det det perfekte næste trin for mig.

For at implementere det bliver jeg nødt til at navigere hele vejen fra at få e-mailen fra brugerindgangen helt foran klientlaget til at forstå, hvordan dataene rejser fra Ember-frontend, gennem adaptere og serialiseringer til Rails-backend og i sidste ende bliver gemt i databasen.

Min anden egen funktion var at udvikle det, vi kalder "knap til handling", hvilket betyder, at vi giver vores brugere mulighed for at tilføje brugerdefinerede knapper til deres karrieresider i vores redigeringsværktøj.

For eksempel ville vi lade dem omdirigere til siden for en bestemt jobåbning, en bestemt afdeling eller en helt ekstern URL. Dette viste sig faktisk at være meget lettere, end jeg havde forventet. Det meste af backend-arkitekturen var allerede på plads, så alt hvad jeg havde at gøre var dybest set at oprette et par nye Ember-komponenter og føje dem til de andre muligheder i karrieresite-editoren.

Den tredje funktion, jeg arbejdede med, gjorde det muligt for vores brugere at integrere med eksterne vurderingsudbydere, hvilket betyder, at de ville være i stand til at sende kandidater til en testplatform som Hackerrank. Når de var færdige med en test, blev resultaterne automatisk sendt gennem en integration mellem vores og udbyderens API'er. Dette var stort, så jeg fungerede for det meste som en assistent til seniorudvikleren (alias Ember stormester i vores team), der var ansvarlig for projektet. Alligevel lærte det mig masser af, hvordan man korrekt opretter en API-integration og automatiserer arbejdsgange med udløsere.

Mit fjerde projekt var det største til dato, og på godt og ondt endte jeg med at gøre det mere eller mindre alene. Hele appen var oprindeligt bygget i Rails, og de fleste visninger var blevet omskrevet med JavaScript og Ember en efter en. Kun en af ​​vores hovedafsnit af appen havde stadig bare Rails-visninger. Det var den såkaldte "Medarbejder" sektion, som grundlæggende var den vigtigste destination for oprettelse, redigering og sletning af brugerkonti. Så det var lidt vigtigt, at min oversættelse til Ember var fejlfri.

Hvilket stressede mig som en skør. Da jeg havde været på holdet i cirka tre måneder på dette tidspunkt, regnede jeg med, at det var tid til at stoppe med at opføre mig som en irriterende praktikant og begynde at arbejde mere uafhængigt. Det betyder, at jeg forsøgte at genere de andre med så få spørgsmål som muligt. Det gode ved dette var, at jeg fik stor tillid til min evne til at løse virkelige softwareproblemer helt alene. Den dårlige ting var imidlertid, at det gjorde mig super langsom, og at det tog mig en god 6 uger at sende den fulde omskrivning af mere end 2.000 nye kodelinjer.

I sidste ende viste det sig endda at være hovedårsagen til, at jeg ikke fik den forhøjelse, som CTO og jeg var blevet enige om, da jeg ikke havde opfyldt min afslutning på aftalen: Jeg havde ikke nået et produktivt niveau på linje med resten af ​​holdet .

Selvom dette sugede på det tidspunkt, indser jeg nu, at hans synspunkt var helt fair, og det lærte mig en vigtig lektion. I en verden af ​​agil softwareudvikling er ensom ulv ikke en mulighed. Teamwork er en vigtig del af at finde en produktiv arbejdsgang.

Det femte projekt er det sidste til dato, og vi sendte det faktisk bare. Det var vores nye funktion at håndtere den nye europæiske lovgivning om databeskyttelse (GDPR). For os oversat til bygningsværktøjer, der gjorde det lettere for vores kunders kandidater at få slettet deres personlige data fra vores database, og også for vores kunder at bede kandidaterne om tilladelse til at gemme og fortsætte med at gemme deres data.

Lyder ret ligetil, ikke? Det var det ikke. Overhovedet.

Jeg tror, ​​at hovedårsagen var, at vi ikke kunne fokusere på en enkelt destination for appen. I stedet krævede funktionen, at vi tilføjede ting overalt. Underretninger ét sted, advarselsflag på et andet sted, søgefiltre og bulkhandlinger på et tredje og snesevis af nye e-mail-sendingshandlinger overalt.

For første gang siden jeg startede, blev jeg parret med den seniorudvikler og medstifter, der blev ombord på mig. Så jeg følte, at det var meget vigtigt for mig at vise ham, hvor meget jeg havde lært siden den første uge seks måneder tidligere. Min prøvetid var ved at slutte, og de skulle snart tage en beslutning, hvis jeg var god nok til at holde på holdet. Og med dette "enkle" projekt, regnede jeg først med at bevise, at det ville være et stykke kage.

Mærkeligt nok tror jeg imidlertid, at kompleksiteten gjorde vores par-programmeringssessioner endnu bedre. Der var så mange brugerscenarier, der skulle tages i betragtning, når vi designede hver del af arkitekturen, at vi blev tvunget til at diskutere og vride og dreje hver ny blok kode. For første gang skulle jeg ikke kun tage højde for UI / UX-dimensionen, men også omfattende juridiske overvejelser, der kunne forårsage mange problemer for vores brugere, hvis vi ikke implementerede det korrekt.

Så vi par-programmerede meget, og det var virkelig godt. Da jeg kodede, kom han med en masse god feedback, der for det meste gjorde min kode meget renere. Men i modsætning til den første indbyggede uge var jeg faktisk også i stand til at give feedback på hans kode, komme med forslag og stille spørgsmål, der virkelig også gjorde hans kode bedre.

Når du er i en tilstand af intens udvikling, som jeg har været det sidste år, synes jeg det er svært at kvantificere, hvor meget dine færdigheder er blevet forbedret på et givet tidspunkt. Så at være i stand til at give konstruktiv feedback til denne fyr med 15+ års kodning under bæltet, satte virkelig skriften på væggen for mig.

Og forresten gjorde forlængelsen af ​​min 6 måneders prøvetid ansættelseskontrakt, som jeg lige for nylig blev gjort opmærksom på. Fra nu af er jeg en fast fuldtidsansat med den løn, jeg oprindeligt anmodede om for seks måneder siden? ?

Del 9: Hvorfor blive en udvikler er det bedste, jeg nogensinde har gjort

Som du sikkert har fundet ud af nu, er jeg forelsket i kodning.

Jeg elsker at det fortsat tvinger mig til at skubbe mine intellektuelle grænser gennem kvantitativ problemløsning.

Jeg elsker, at det giver mig et udløb for kreative udtryk, når jeg designer alt fra brugergrænseflade til systemarkitektur.

Jeg elsker, at det giver mig tusind forskellige løsninger til ethvert problem i den virkelige verden.

Jeg elsker, at det ikke kun tolererer min indre perfektionist, men faktisk kræver, at perfektionist er til stede - og straffer dets fravær.

Jeg elsker, at det omgiver mig med mennesker, der sætter pris på ægthed og gennemsigtighed over small-talk og høflighed.

Jeg elsker, at det på mine indadvendte dage lader mig tage mine hovedtelefoner op, rulle ærmerne op og dybe dybt ned i en anden dimension et stykke tid.

Jeg elsker, at det altid rummer noget nyt for mig at lære, og at det vil kræve, at jeg er en livslang lærer, i modsætning til mange andre stillestående erhverv.

Men mest af alt elsker jeg, at kodning har givet mig en fornemmelse af, at fremtiden virkelig er ubegrænset.

Om et par uger fylder jeg 27 år, og jeg aner ikke, hvad fremtiden bringer for mig. I løbet af tre år er jeg muligvis stadig i samme position som nu, og skriver kode for det samme firma, alt hvad jeg ved. Jeg er muligvis en blyudvikler. Jeg er muligvis produktejer eller manager. Eller jeg er måske et helt andet sted.

Freelancing eksternt fra et solrigt paradis. Udvikling af decentrale apps på nogle forstyrrende blockchain. Design af maskinlæringsmodeller til bekæmpelse af global opvarmning. Skrivning af rumskibsalgoritmer til ekspeditioner til Mars. Eller bygge mit eget produkt.

Alle ovennævnte scenarier ville have virket helt skøre for mig, før jeg begyndte at kode.

I bedste fald gav mine tidligere finansjob mig den tynde tilfredshed at have sammensat en tyk powerpoint-præsentation fyldt med opad skrånende KPI-kurver. Og det bedst mulige fremtidsscenarie, som jeg kunne tænke på, var, at jeg landede en CFO- eller CEO-stilling i et børsnoteret selskab efter at have afsat et årti af mit liv til 100 timers arbejdsuge i en investeringsbank, private equity-firma eller ledelseskonsulent, tilbragte mine dage omkring mennesker, der bekymrede sig mere om penge og prestige end at prøve at gøre noget meningsfuldt med deres liv. Og det skræmte mig.

I dag er der intet sandsynligt fremtidsscenario, der skræmmer mig overhovedet. Og det alene giver mig sikkerhed for, at min skæve rejse de sidste tre år har haft et formål.

Selvom det er lidt trist, at jeg investerede så meget tid og energi i en karrierevej, der viste sig at være en blindgyde, ved jeg, at jeg var virkelig heldig at indse det allerede i en alder af 23 år - og at have den luksus at kunne lave et stop, se dig omkring og forfølge noget, jeg følte mere lidenskabelig for.

Så godt eller dårligt, jeg antager, at det var summen af ​​alle mine oplevelser, der førte mig til, hvor jeg er i dag. Et sted hvor det på en eller anden måde lykkedes mig at finde noget, som få mennesker nogensinde gør - et job, som jeg elsker . Og for det er jeg mere taknemmelig end ord kan sige.

Tillykke! Da du kom hele vejen igennem denne MEGET lange artikel, skal du være lige så skør som mig. Jeg havde oprindeligt to intentioner med denne tekst: at behandle mine fiaskoer og succeser de sidste tre år og at inspirere andre på stier svarende til mine. Jeg betragter den første som afsluttet. Så hvis du har spørgsmål eller feedback - bedes du kontakte os! Enten i kommentarerne nedenfor eller på [email protected]