TL;DR er et innlegg for spørsmål/svar om Data Science og hvordan man kan gå inn i yrket og utvikle seg i det. I artikkelen vil jeg analysere de grunnleggende prinsippene og FAQ og er klar til å svare på dine spesifikke spørsmål - skriv i kommentarene (eller i en privat melding), jeg vil prøve å svare på alt innen noen få dager.
Med bruken av notatserien "Satanist Date" kom mange meldinger og kommentarer med spørsmål om hvordan du skal begynne og hvor du skal grave, og i dag vil vi analysere hovedferdighetene og spørsmålene som dukket opp etter publikasjonene.
Alt som står her hevder ikke å være den ultimate sannheten og er forfatterens subjektive mening. Vi skal se på de viktigste tingene som virker viktigst i prosessen.
Hvorfor er dette nødvendig?
For at målet skal være bedre oppnåelig, slik at det i det minste ser noe spesifikt ut - du ønsker å bli DS eller forskningsforsker hos Facebook/Apple/Amazon/Netflix/Google - se på kravene, språkene og nødvendige ferdigheter spesifikt for hvilken stilling. Hva er ansettelsesprosessen? Hvordan går en typisk dag i en slik rolle? Hvordan ser gjennomsnittsprofilen til en person som jobber der ut?
Ofte er helhetsbildet at en person egentlig ikke forstår hva han vil, og det er ikke helt klart hvordan man forbereder seg på dette uklare bildet - så det er verdt å ha i det minste en grov plan for hva akkurat du ønsker.
Konkretiser gjeldende målvisning
Selv om det endrer seg underveis, og det generelt er normalt å endre planer i løpet av stykket, er det verdt å ha et mål og fokusere på det, med jevne mellomrom evaluere og tenke nytt.
Blir det eller er det fortsatt aktuelt?
Når du vokser inn i en posisjon.
Tenk deg at du før stillingen din trenger å ta en doktorgrad, jobbe 2-3 år i bransjen og generelt klippe håret mens du mediterer i et kloster – vil ikke situasjonen med Data Science være den samme som den en gang var med økonomer og advokater? Vil alt endre seg til det ugjenkjennelige på området du ønsker å forfølge?
Er det ikke en god sjanse for at alle skynder seg dit nå, og vi vil se et bilde der det er et bredt lag med mennesker som prøver å komme inn i yrket - og det blir rett og slett en mager startposisjon.
Det kan være verdt å vurdere dagens trender når du velger en vei, ikke bare den nåværende tilstanden på arbeidsmarkedet, men også din ide om hvordan den endrer seg og hvor den er.
Forfatteren planla for eksempel ikke å bli satanist, men i løpet av doktorgraden jobbet han med tredjepartsprosjekter som hadde sterke ferdigheter til felles med DS, og på slutten av forskerskolen byttet han naturlig nok til miljøet, da han så en god posisjon.
Hvis det i løpet av stykket viser seg at det vil være nødvendig å flytte et annet sted - fordi det nå er mest bevegelse og all den mest interessante handlingen skjer, så vil vi flytte dit naturlig.
Nedbryting av ferdigheter
Dette er betingede kategorier av ferdigheter som synes jeg er nøkkelen for fullt og effektivt arbeid i DS. Jeg vil fremheve engelsk separat - lær hva du enn gjør i CS. Neste er nøkkelkategoriene.
Programmering/skripting
Hvilke språk er du sikker på å bli kjent med? Python? Java? Shell scripting? Lua? SQL? C++?
Hva akkurat du trenger for å kunne og hvorfor med tanke på programmering – utvalget av stillinger her varierer veldig.
For eksempel må jeg ofte implementere kompleks logikk, spørringer, modeller, analyser og generelt utvikle tolkede systemer, men det stilles nesten aldri krav til kodehastighet, bortsett fra de mest generelle og rimelige.
Derfor er ferdighetssettet mitt veldig forskjellig fra de som skriver Tensorflow-biblioteket og tenker på å optimalisere koden for effektiv bruk av l1-cachen og lignende ting, så se på akkurat hva du trenger og vurder den riktige veien til læring.
For eksempel, for python, gjør folk allerede opp språklæring.
Det er sikkert allerede erfarne råd og gode kilder for dine behov - du må bestemme deg for en liste og begynne å jobbe med den.
Forstå forretningsprosesser
Du kan ikke gå noe sted uten det: du må forstå hvorfor du er nødvendig i denne prosessen, hva du gjør og hvorfor. Ofte er det dette som kan spare deg for mye tid, maksimere nytten og ikke kaste bort tid og ressurser på tull.
Vanligvis stiller jeg meg selv følgende spørsmål:
- Hva gjør jeg egentlig i selskapet?
- Hvorfor?
- Hvem skal bruke det og hvordan?
- Hvilke alternativer har jeg?
- Hva er grensene for parameterne?
Her er litt mer detaljer om parametrene: du kan ofte endre arbeidsscenarioet i stor grad hvis du vet at noe kan ofres: for eksempel tolkbarhet eller omvendt, et par prosent vil ikke spille noen rolle her og vi har en veldig rask løsning, og klienten trenger det, fordi han betaler for tiden rørledningen går i AWS.
matematikk
Her tenker og forstår du alt selv - uten kunnskap om grunnleggende matematikk er du ikke noe annet enn aper med en granat (beklager Random Forest) - så du må i det minste forstå de grunnleggende tingene. Hvis jeg skulle lage en veldig minimal liste, ville den inneholde:
- Lineær algebra - et stort antall ressurser er enkle å Google, se etter det som passer deg best;
- Matematisk analyse - (minst i de to første semestrene);
- Sannsynlighetsteori er overalt i maskinlæring;
- Kombinatorikk – det er faktisk komplementært til teorien;
- Grafteori - minst BASIC;
- Algoritmer - i det minste for de to første semestrene (se Cormens anbefalinger i boken hans);
- Mathlogic - i det minste grunnleggende.
Praktisk dataanalyse og visualisering
Noe av det viktigste er å ikke være redd for å skitne hendene med data og gjennomføre en omfattende analyse av datasettet, prosjektet og lage en rask datavisualisering.
Utforskende dataanalyse skal rett og slett bli noe naturlig, som alle andre datatransformasjoner og muligheten til å lage en enkel pipeline fra unix-noder (se tidligere artikler) eller skrive en lesbar og forståelig notatbok.
Jeg vil gjerne nevne visualisering: det er bedre å se én gang enn å høre hundre ganger.
Å vise en graf til en leder er hundre ganger enklere og klarere enn et sett med tall, så matplotlib, seaborn og ggplot2 er vennene dine.
Myke ferdigheter
Like viktig er det å kunne formidle dine ideer, samt resultater og bekymringer (osv.) til andre – sørg for at du tydelig kan si oppgaven både teknisk og forretningsmessig.
Du kan forklare kollegaer, ledere, overordnede, kunder og alle andre som trenger det hva som skjer, hvilke data du bruker og hvilke resultater du fikk.
Dine diagrammer og dokumentasjon bør leses uten deg. Det vil si at du ikke trenger å gå til deg for å forstå hva som står der.
Du kan lage en oversiktlig presentasjon for å få frem poenget og/eller dokumentere prosjektet/arbeidet ditt.
Du kan formidle ditt standpunkt på en begrunnet og følelsesløs måte, si «ja/nei» eller stille spørsmål/støtte en avgjørelse.
trening
Det er mange forskjellige steder hvor du kan lære alt dette. Jeg vil gi en kort liste - jeg prøvde alt fra det, og for å være ærlig har hvert element sine fordeler og ulemper. Prøv det ut og avgjør hva som passer deg, men jeg anbefaler på det sterkeste å prøve flere alternativer og ikke bli sittende fast på ett.
- Online kurs: coursera, udacity, Edx, etc;
- Nye skoler: online og offline - SkillFactory, ShAD, MADE;
- Klassiske skoler: universitets masterprogrammer og avanserte opplæringskurs;
- Prosjekter - du kan ganske enkelt velge oppgaver som interesserer deg og kutte dem, laste dem opp til github;
- Praksisplasser - det er vanskelig å foreslå noe her; du må se etter hva som er tilgjengelig og finne passende alternativer.
Er det nødvendig?
Avslutningsvis vil jeg sannsynligvis legge til tre personlige prinsipper som jeg prøver å følge selv.
- Bør være interessant;
- Bringe indre nytelse (= i det minste ikke forårsake lidelse);
- "Å være din."
Hvorfor dem? Det er vanskelig å forestille seg å gjøre noe hver dag og ikke nyte det eller ikke være interessert. Se for deg at du er en lege og hater å kommunisere med mennesker - dette kan selvfølgelig fungere på en eller annen måte, men du vil hele tiden være ukomfortabel med strømmen av pasienter som vil spørre deg om noe. Dette fungerer ikke i lengden.
Hvorfor nevnte jeg spesifikt intern nytelse? Det virker på meg som om dette er nødvendig for videre utvikling og i prinsippet læringsprosessen. Jeg liker det veldig godt når jeg klarer å fullføre en kompleks funksjon og bygge en modell eller beregne en viktig parameter. Jeg liker det når koden min er estetisk vakker og velskrevet. Derfor er det å lære noe nytt interessant og krever ikke direkte noen vesentlig motivasjon.
"Å være din" er den samme følelsen av at dette er omtrent det du ønsket å gjøre. Jeg har en liten historie. Siden barndommen har jeg vært interessert i rockemusikk (og metal - LAKS!), og som så mange andre ønsket jeg å lære å spille og det er alt. Det viste seg at jeg ikke hadde hørsel og ingen stemme - dette plaget meg ikke i det hele tatt (og jeg må si at dette ikke plager mange utøvere rett på scenen), og da jeg fortsatt gikk på skolen fikk jeg en gitar... og det ble klart at jeg egentlig ikke liker å sitte i timevis og spille på det. Det gikk hardt, det virket alltid for meg som om det kom ut en slags tull - jeg hadde ingen glede av det i det hele tatt og følte meg bare elendig, dum og fullstendig ute av stand. Jeg bokstavelig talt tvang meg selv til å sette meg ned for timer og generelt var det ikke god mat for hesten.
Samtidig kunne jeg sitte ganske rolig i timevis og utvikle noe leketøy, bruke et manus til å animere noe på flash (eller noe annet), og jeg var vilt motivert til å fullføre elementer i spillet eller håndtere mekanikken til bevegelse og/eller koble til tredjepartsbiblioteker, plugins og alt annet.
Og på et tidspunkt skjønte jeg at det å spille gitar ikke er min greie, og at jeg virkelig liker å lytte, ikke spille. Og øynene mine gnistret da jeg skrev spill og kode (hørte på all slags metall i det øyeblikket) og det var det jeg likte da, og det var det jeg burde ha gjort.
Har du andre spørsmål?
Selvfølgelig kunne vi ikke gå gjennom alle emnene og spørsmålene, så skriv kommentarer og send meg en PM - jeg er alltid glad for å ha spørsmål.
Kilde: www.habr.com