Rekruttering for i Yandex fortsetter. Det går i fem retninger: backend, ML, mobilutvikling, frontend og analyse. I denne bloggen, i andre blogger på Habré og utover, kan du finne mye innsikt om hvordan praksisoppholdet fungerer. Men mye i denne prosessen forblir et mysterium for de som ikke jobber i selskapet. Og ser man fra utviklingsledernes ståsted, dukker det opp enda flere spørsmål. Hvordan gjennomføre et internship riktig, hvordan maksimere gjensidig nytte med en praktikant, hvordan bli kjent med ham på tre måneder og lære ham alt han trenger for å fortsette å jobbe?
Fem av oss forberedte denne artikkelen. La oss introdusere oss selv: Ignat Kolesnichenko fra den distribuerte datateknologitjenesten, Misha Levin fra Market machine intelligence-tjenesten, Denis Malykh fra applikasjonsutviklingstjenesten, Seryozha Berezhnoy fra utviklingsavdelingen for søkegrensesnitt og Dima Cherkasov fra antisvindelutviklingsgruppen. Hver av oss representerer vårt eget praksisområde. Vi er alle ledere, vi trenger praktikanter, og vi har litt erfaring med å jobbe med dem. La oss fortelle deg noe fra denne opplevelsen.
Intervju før internship
Flere tekniske intervjuer venter på kandidater. Suksess på et intervju avhenger mindre av myke ferdigheter (evnen til å kommunisere effektivt) og mer av harde ferdigheter (ferdigheter i matematikk og programmering). Ledere vurderer imidlertid begge deler.
Ignat:
Selv om en person er veldig kul, men absolutt ukommunikativ, vil han ikke kunne bruke alle ferdighetene sine. Dette tar vi selvsagt hensyn til, men dette er ingen grunn til å ikke ta noen på praksisplass. Om tre måneder kan alt endre seg, og dessuten kan førsteinntrykket ditt vise seg å være feil. Og hvis alt er riktig, må du forklare personen, se etter andre kommandoer. For praktikanter er kommunikasjonsevner definitivt ikke en nøkkelfaktor. Likevel er faglige ferdigheter mye viktigere.
Denis:
Jeg liker folk som forteller historier – på en god måte. En person som kan fortelle hvordan han og teamet hans heroisk taklet en eller annen fakap, er interessant. Jeg begynner å stille oppfølgingsspørsmål når en historie som denne kommer opp. Men dette skjer sjelden hvis du bare spør «for å fortelle om noe interessant i prosjektene dine».
En kandidat sa en gang en fantastisk setning, som jeg til og med skrev ned: «Ungikk å løse kjedelige problemer med hell.»
Siden det er lite tid til kommunikasjon, prøver intervjueren å få nyttig informasjon om kandidaten hvert minutt av møtet. Det er flott hvis praktikanten på forhånd fant ut hvilke detaljer om erfaringen hans (ikke fra CV-en) han kunne dele. Dette bør være en kort historie strengt tatt.
Denis:
Jeg legger merke til hvis en person sier at han har prøvd mange språk og tilnærminger. Folk med et bredere syn kommer opp med mer elegante løsninger i kampmodus. Men dette er et tvetydig pluss. Du kan få taket på det, men egentlig ikke lære noe.
Tiden for historiene beskrevet av Denis gjenstår vanligvis bare ved det endelige intervjuet. Inntil da er det nødvendig å demonstrere den grunnleggende og praktiske kunnskapen som vil danne grunnlaget for fremtidig arbeid. Og selvfølgelig må du skrive koden på en tavle eller på et stykke papir.
Misha:
Vi tester kunnskap om sannsynlighetsteori og matematisk statistikk. Vi ser på om personen har erfaring med å jobbe med metrikk, med maskinlæringsalgoritmer, med å sette sine parametere, med omskolering osv. Vi forventer at personen kan skrive kode tilstrekkelig til å være analytiker.
Denis:
De som kommer på intervju kan stort sett språk: i Jekaterinburg har vi en god skole med grunnleggende språk, gode institutter. Men for å være ærlig, er en praksiskandidat med gode hardferdigheter et sjeldent tilfelle, i hvert fall i vårt epsilon-nabolag. For eksempel Swift. Det innebærer veldig komplekst arbeid med strenger, og det er få mennesker som kan jobbe med dem utenpå hodet. Øyet fanger umiddelbart oppmerksomheten din. Under intervjuer gir jeg ofte en oppgave som er knyttet til strengbehandling. Og i hele denne tiden var det bare én person som klarte å skrive en slik Swift-kode med en gang, på et stykke papir. Etter det gikk jeg rundt og fortalte alle at noen endelig klarte å løse dette problemet i Swift på et stykke papir.
Testing av algoritmer under et intervju
Dette er et eget tema fordi kandidatene fortsatt har et spørsmål – hvorfor vurderer vi alltid kunnskap om algoritmer og datastrukturer? Selv fremtidige mobilutviklere og frontend-utviklere gjennomgår slike tester.
Misha:
Under intervjuet kommer vi garantert til å gi en slags algoritmisk problemstilling. Kandidaten må finne ut hvordan den skal implementeres i Python, helst uten feil. Du må forstå hvordan du sjekker programmet og korrigerer det selv.
Erfaring med algoritmer er nyttig av tre grunner. For det første vil det åpenbart være nødvendig i algoritmiske oppgaver – som ikke skjer ofte, men som skjer. For det andre vil utvikleren kunne løse problemer knyttet til algoritmer mer effektivt, selv om de ikke trenger å fordype seg i selve algoritmene (og det er allerede ganske mange av dem). For det tredje, hvis du ikke ble undervist i algoritmer på universitetet, men du fortsatt vet hvordan du skal jobbe med dem, så karakteriserer dette deg som en nysgjerrig person og vil øke din autoritet i intervjuobjektets øyne.
Denis:
En stor del av mobilutvikling er JSON-shuffling. Men en gang hver sjette måned er det tilfeller når algoritmer er nødvendig. Jeg tegner for tiden vakre kart for Yandex.Weather. Og i løpet av en uke måtte jeg implementere utjevningsalgoritmen, Sutherland-Hodgman-algoritmen og Martinez-algoritmen. Hvis en person ikke visste hva et hashmap eller en prioritert kø var, ville han ha sittet fast med det i lang tid, og det ville være uklart om han ville ha klart det eller ikke uten hjelp utenfra.
Algoritmer er grunnlaget for utvikling. Dette er det som hjelper en utvikler til å være en utvikler. Det spiller ingen rolle hva du gjør. De trengs også i enkle prosjekter, der hovedarbeidet består i å "oversette JSON". Selv om du ikke skriver selve algoritmene, men du implisitt bruker noen datastrukturer, er det bedre å forstå dem. Ellers vil du ende opp med programmer som er trege eller feil.
Det er programmerere som kom i utvikling akademisk: de gikk inn på universitetet, studerte i fem år og fikk en spesialitet. De kjenner algoritmene fordi de ble undervist. Og så karakteriserer ikke kunnskapen om algoritmer i seg selv en persons horisont på noen måte; denne horisonten må testes på en annen måte.
Og det er selvlærte mennesker, som jeg teller selv. Ja, formelt sett har jeg IT-utdanning, diplom i programvareingeniør. Men selvlærte mennesker lærte å programmere «til tross for det». De hadde ikke et universitetsprogram. Vanligvis er de ikke kjent med algoritmer - fordi de aldri har møtt behovet for å studere dem. Og når en slik person forstår algoritmer, betyr det at han brukte tid og forsto dem. Etter eksamen fra universitetet innså jeg at jeg hadde blinde flekker når det gjelder grunnleggende algoritmer - faktum er at spesialiteten min ble brukt. Jeg gikk og studerte nettkurs fra Princeton University, den velkjente Robert Sedgwick. Jeg skjønte det og gjorde alle leksene mine. Og når en person forteller en lignende historie under et intervju, blir jeg umiddelbart interessert, jeg har et ønske om å jobbe med ham eller i det minste fortsette samtalen.
Ignat:
Når du intervjuer en praktikant, forventer du på noen måter enda mer enn av en erfaren utvikler. Vi snakker om muligheten til å løse algoritmiske problemer, skriv raskt i det minste noe riktig kode. Praksiskandidaten er fortsatt ved universitetet. For bare et år siden ble han fortalt alt om algoritmer i detalj. Det forventes at han kan reprodusere dem. Hvis en person er tilstrekkelig og lyttet til forelesningene nøye, vil han rett og slett vite alt, få det fra cachen.
Hvilke oppgaver løser praktikanten?
Vanligvis kan praksisprogrammet skisseres og diskuteres under de avsluttende intervjuene. Bare helt i begynnelsen av arbeidet kan en praktikant bli tildelt opplæringsoppgaver, hvis resultater ikke vil bli brukt i produksjonen. Dessuten er sannsynligheten liten for å få slike oppgaver. Oftest blir kampprosjekter gitt fra etterslepet, det vil si de som er anerkjent som verdige oppmerksomhet, men ikke en prioritet og "atskillelige" - slik at andre komponenter ikke er avhengige av implementeringen. Ledere prøver å fordele dem slik at traineen blir kjent med ulike deler av tjenesten og jobber i samme miljø med andre teammedlemmer.
Ignat:
Dette er svært nyttige oppgaver. De vil kanskje ikke øke klyngeutnyttelsen med 10 %, eller spare selskapet for en million dollar, men de vil gjøre hundrevis av mennesker glade. For eksempel har vi for tiden en praktikant som jobber med vår klient for å drive drift på våre klynger. Før du starter, må operasjonen laste inn noen data til klyngen. Dette tar vanligvis 20–40 sekunder, og før det skjedde stille: du lanserte det i konsollen og satt der og så på en svart skjerm. Praktikanten kom og laget funksjonen på to uker: nå kan du se hvordan filene lastes opp og hva som skjer. Oppgaven er på den ene siden ikke vanskelig å beskrive, men på den andre siden er det noe å grave i, hvilke biblioteker man skal se på. Det beste er at du gjorde det, det gikk en uke, det viste seg å være på klynger, folk bruker det allerede. Når du skriver et innlegg på det interne nettverket sier de takk.
Misha:
Traineer forbereder modeller, samler inn data for dem, kommer opp med beregninger og gjennomfører eksperimenter. Etter hvert begynner vi rett og slett å gi ham mer frihet og ansvar – vi sjekker om han takler det. Hvis ja, flytter han til neste nivå. Vi antar ikke at når en praktikant kommer inn, vet de hvordan de skal gjøre alt. Lederen hjelper ham med å finne ut av det, gir ham en lenke til en intern ressurs eller nettkurs.
Hvis en praktikant viser at han er på sitt beste, kan han få noe av prioritet, viktig for avdelingen eller andre tjenester.
Dima:
Praktikanten vår gjør nå hardcore modifikasjoner av antisvindel. Dette er et system som bekjemper et bredt spekter av misbruk og svindel på Yandex-tjenester. Først tenkte vi å gi ting som ikke var veldig kompliserte og lite viktige for produksjonen. Vi prøver å tenke gjennom praktikantens oppgaver på forhånd, men så så vi at personen var «tennt» og løste problemer raskt og godt. Som et resultat begynte vi å betro ham å lansere anti-svindel for nye tjenester.
I tillegg er det en liten sjanse for å få en oppgave som kolleger ikke tidligere har henvendt seg på grunn av omfanget.
Dima:
Det er ett gammelt system, og det er et nytt, som ennå ikke er fullført. Det er nødvendig å flytte fra den ene til den andre. I fremtiden er dette et viktig prosjekt, men med høy usikkerhet: du må kommunisere mye, lese uforståelig arvekode. På det avsluttende intervjuet fortalte vi ærlig til praktikanten at oppgaven var vanskelig. Han svarte at han var klar, kom til teamet vårt, og alt ordnet seg for ham. Det viste seg at han har egenskapene til ikke bare en utvikler, men også en leder. Han var klar til å gå rundt, finne ut, pinge.
Veiledning av en praktikant
En praktikant trenger en mentor for å fordype seg i prosesser. Dette er en person som er klar over ikke bare sine egne oppgaver, men også oppgavene til praktikanten. Det etableres regelmessig kommunikasjon med mentoren; du kan alltid henvende deg til ham for råd. Mentoren kan enten være gruppeleder (hvis det er en liten gruppe) eller en av kollegene, faste teammedlemmer.
Ignat:
Jeg prøver å komme opp minst annenhver dag og spørre hvordan det går med praktikanten. Hvis jeg ser at jeg sitter fast, prøver jeg å hjelpe ham, spør ham hva problemet er, og graver det ut med ham. Det er klart at dette tar fra meg energien og gjør arbeidet til en praktikant ikke så integrert effektivt – jeg kaster også bort tiden min. Men dette gjør at han ikke kan henge seg fast i noe og få resultater. Og det er fortsatt raskere enn om jeg gjorde det selv. Selv trenger jeg ca 5 timer på oppgaven. Praktikanten vil gjøre det om 5 dager. Og ja, jeg skal bruke 2 timer i løpet av disse 5 dagene til å chatte med praktikanten og hjelpe. Men jeg skal spare minst 3 timer, og praktikanten vil være fornøyd med at han fikk råd og hjelp. Generelt trenger du bare å kommunisere tett, se hva personen gjør, og ikke miste kontakten.
Seryozha:
Praktikanten er hele tiden i kontakt med sin mentor og kommuniserer med ham flere ganger om dagen. Mentoren gjennomgår koden, gjør parprogrammering med praktikanten og hjelper til når det oppstår problemområder. Det er på denne måten, ved å kombinere hjelp av en mentor og reelle kampoppgaver, at vi trener opp front-end utviklere.
Dima:
For å forhindre at en praktikant blir forlatt, diskuterer vi hvem som skal veilede ham allerede før ansettelse. Dette er også en stor oppgradering for mentoren selv: forberedelse til rollen som teamleder, testing av evnen til å huske både sin egen oppgave og oppgaven til traineen. Det er jevnlige møter, som jeg noen ganger går til selv, for å holde meg orientert. Men det er mentoren som kommuniserer med praktikanten ganske regelmessig. Han bruker mye tid i starten, men det lønner seg.
Men å ha en mentor betyr ikke at alle problemer som oppstår løses gjennom ham.
Misha:
Det er vanlig for oss at mennesker som står overfor et problem spør naboer og kolleger om råd og raskt finner hjelp. Jo raskere en person vokser, jo oftere trenger han å gå til kollegene sine for å lære noe. Det er til og med nyttig å bare lære om andres oppgaver, slik at du kan finne på nye. Når en praktikant er i stand til å komme til enighet, forstå hva som er viktig for den andre siden, og komme til resultater i et team, vil han vokse mye raskere enn en som lederen må gjøre alt dette for.
Seryozha:
Det finnes dokumentasjon, men det meste av informasjonen går tapt i lufta. Hvis du absorberer det tidlig i karrieren, er det en ekstra fordel, og vi kan fokusere personen på det de trenger å lære.
Den ideelle praktikanten er en som trener i flere måneder, blir juniorutvikler, så bare utvikler, så teamleder osv. Dette krever en arketype på en student som ikke er flau over å spørre om noe ikke er klart for ham, men er også i stand til å arbeide selvstendig. Hvis han ble fortalt at han kunne lese om det et sted, ville han gå, lese det og faktisk komme tilbake med ny kunnskap. Han kan gjøre feil, men han bør ikke gjøre feil mer enn én gang, maksimalt to ganger, på samme sted. Den ideelle praktikanten bør utvikle seg, absorbere alt som en svamp, lære og vokse. Den som sitter og prøver å finne ut av alt på egen hånd, bruker lang tid på å rote rundt og ikke stiller noen spørsmål, blir neppe vant.
Slutt på praksis
Før jobbstart signerer vi en åremålskontrakt med hver trainee. Selvfølgelig er praksisplassen betalt, formalisert i samsvar med den russiske føderasjonens arbeidskode, og praktikanten har de samme fordelene som enhver annen Yandex-ansatt. Etter tre måneder avsluttes programmet – vi overfører da mange av praktikantene til personalet (på en tidsubestemt kontrakt).
På den ene siden er det viktig for lederen at utbygger oppfyller sitt internminimum. Det er her traineen ledes, fra og med intervjuet. Dette er imidlertid bare begynnelsen på historien. For oss er en praktikant alltid en potensiell kandidat for ansatte. Minimumsprogrammet for en leder er å identifisere helt i begynnelsen en person som etter tre måneder ikke skammer seg over å anbefale til andre avdelinger. Det maksimale programmet er å holde ham i samme team, og ansette ham som en medarbeider. Samtidig tar vi hensyn til at en andre- eller tredjeårsstudent – selv om han er blitt praktikant – vil trenge å fortsette studiene ved et universitet med studieårets begynnelse.
Seryozha:
Først av alt, traineer for oss er menneskelig ressurspotensial. Vi prøver å vokse folk i Yandex slik at de er ideelt egnet til våre oppgaver. Vi gir dem alt, fra en kultur for kommunikasjon og interaksjon i team til encyklopedisk kunnskap om alle våre systemer.
Ignat:
Når vi tar en praktikant, prøver vi ham umiddelbart for å bli med i teamet vårt. Og som regel er den eneste hindringen mangelen på en ledig stilling. Vi prøver å ansette nok unge gutter som praktikanter. Hvis en person har fem års utviklingserfaring, kommer han til Yandex og er praktikant på nivået, så, dessverre, for oss betyr dette at selv om han er en flott fyr, siden han får jobb i Yandex med fem års erfaring, vil han ikke være i stand til å vokse til en seniorutvikler. Det er vanligvis et spørsmål om hastighet: langsom vekst i fortiden vil bety sakte vekst her. Ja, noen ganger kommer forståelsen av at en person ikke er opp til oppgaven først etter tre måneder. Men dette er ganske sjeldent. I over halvparten av tilfellene er vi klare til å ansette personer i staben. I mitt minne har det aldri vært en situasjon der en person har fullført en praksisplass, men ikke klarte å bestå et intervju for en fulltidsstilling.
Misha:
Vi tilbyr alle suksessrike praktikanter å forbli i selskapet. Etter et praksisopphold tar vi vanligvis på oss mer enn halvparten på heltid. Sommerpraksis er vanskeligere fordi det ofte kommer tredjeårsstudenter til oss og det er vanskelig for dem å kombinere arbeid og studier.
Dima:
La oss si at praktikanten gjør en god jobb og har mange utsikter til å vokse til en god utvikler – selv om han ikke har nok erfaring akkurat nå. Og anta at det ikke er noen ledig stilling for en tidsubestemt kontrakt. Da er alt enkelt: Jeg må gå til lederen min og fortelle ham - dette er en veldig kul person, vi må for all del beholde ham, la oss tilby ham noe, la oss finne et sted å plassere ham.
Historier om praktikanter
Denis:
Jenta som fikk praksisplass hos oss i 2017 var fra Perm. Dette er 400 kilometer fra Jekaterinburg i vest. Og hver uke kom hun til oss fra Perm med tog til School of Mobile Development. Hun kom på dagtid, studerte om kvelden og dro tilbake sent på kvelden. Da vi satte pris på en slik iver, inviterte vi henne til å jobbe, og det ga resultater.
Ignat:
For flere år siden deltok vi i et internutvekslingsprogram. Det var interessant å jobbe med utenlandske gutter. Men traineene derfra er ikke sterkere enn for eksempel fra ShAD eller fra Det datavitenskapelige fakultet. Det ser ut til at EPFL er blant de 20 beste universitetene i Europa. I det øyeblikket, som en fortsatt lite erfaren intervjuer, hadde jeg denne forventningen: utrolig, vi intervjuer folk fra EPFL, de kommer til å bli superkule. Men folk som har fått grunnutdanning om koding her – også ved sentrale regionale universiteter – viser seg å være ganske på nivå.
Eller en annen historie. Nå har jeg en fyr på staben min, han er veldig ung, rundt 20 år gammel. Jobber i St. Petersburg, kom for en praksisplass. Han er veldig kul. Du, som vanlig, gir en person problemer, han løser dem, og en måned senere kommer han og sier: Jeg løste dem, jeg ser, og det ser ut til at arkitekturen din er dårlig bygget. La oss gjøre det om. Koden vil bli enklere og tydeligere. Jeg frarådet ham selvfølgelig: mengden arbeid er stor, det er ingen fortjeneste for brukerne, men ideen høres helt rimelig ut. Personen fant ut en kompleks flertrådsprosess og foreslo forbedringer - kanskje utidige, refaktorering for refaktoriseringens skyld. Men så snart du vil komplisere denne koden, kan du fortsatt gjøre denne refaktoreringen. Det gikk faktisk flere måneder og vi tok fatt på denne oppgaven. Jeg ansatte ham gjerne. Vi er ikke alle genier. Du kan komme, finne ut av noe og peke på problemene våre. Dette settes pris på.
Misha:
Vi har slike ideelle praktikanter. Til tross for mangel på erfaring ser de oppgaven ikke bare på et teknisk, men også på et globalt nivå. De tilbyr grunnleggende forbedringer. De har en forståelse av hvordan man kan oversette problemer fra den virkelige verden til den tekniske verden uten å miste betydningen. De lurer på hva det endelige målet er, om det er verdt å grave i detaljer nå eller om de helt kan endre tilnærmingen til oppgaven eller til og med formuleringen av problemet. Dette betyr at de har potensial til å være flere nivåer høyere. For å gå denne veien trenger de bare å oppgradere noen ferdigheter og interne verktøy. I tillegg lanserer flere vellykkede prosjekter.
Kilde: www.habr.com