Kuinka päästä isoon yritykseen, jos olet juniori? Kuinka palkata kunnollinen juniori, jos olet iso yritys? Leikkauksen alla kerron tarinamme aloittelijoiden palkkaamisesta etupäässä: kuinka kävimme läpi testitehtävät, valmistauduimme suorittamaan haastatteluja ja rakensimme mentorointiohjelman uusien tulokkaiden kehittämiseen ja käyttöönottoon, ja myös miksi vakiohaastattelukysymykset eivät ei toimi.
Yritän kesyttää Junioria
Hei! Nimeni on Pavel, teen etupäätyötä Wrike-tiimissä. Luomme järjestelmän projektinhallintaan ja yhteistyöhön. Olen työskennellyt verkossa vuodesta 2010, työskennellyt 3 vuotta ulkomailla, osallistunut useisiin startup-yrityksiin ja opettanut yliopistossa verkkoteknologiakurssia. Olen yrityksessä mukana teknisten kurssien ja junioreiden Wrike-mentorointiohjelman kehittämisessä sekä heidän suorassa rekrytoinnissa.
Miksi edes ajattelimme juniorien palkkaamista?
Viime aikoihin asti rekrytoimme keski- tai ylemmän tason kehittäjiä käyttöliittymään – riittävän itsenäisiä tekemään tuotetehtäviä perehdyttämisen jälkeen. Tämän vuoden alussa ymmärsimme, että haluamme muuttaa tätä käytäntöä: vuoden aikana tuotetiimiemme määrä on lähes kaksinkertaistunut, etupään kehittäjien määrä lähestyy sataa, ja lähitulevaisuudessa tämä kaikki tulee täytyy taas tuplata. Töitä on paljon, vapaita käsiä vähän, ja niitä on vielä vähemmän markkinoilla, joten päätimme kääntyä niiden kavereiden puoleen, jotka ovat vasta aloittamassa matkaansa etupäässä ja tajusimme, että olemme valmiita investoimaan heidän kehitystä.
Kuka on juniori?
Tämä on ensimmäinen kysymys, jonka esitimme itseltämme. Kriteereitä on erilaisia, mutta yksinkertaisin ja ymmärrettävin periaate on tämä:
Juniorille on selitettävä, mikä ominaisuus ja miten se tehdään. Keskille on selitettävä, mitä ominaisuutta tarvitaan, ja hän selvittää toteutuksen itse. Signor itse selittää sinulle, miksi tätä ominaisuutta ei tarvitse tehdä ollenkaan.
Tavalla tai toisella juniori on kehittäjä, joka tarvitsee neuvoja tämän tai toisen ratkaisun toteuttamiseen. Mihin päätimme rakentaa:
- Junior on henkilö, joka haluaa kehittyä ja on valmis tekemään lujasti töitä tämän eteen;
- Hän ei aina tiedä, mihin suuntaan haluaa kehittyä;
- Tarvitsee neuvoja ja hakee apua ulkopuolelta - johtajaltaan, mentoriltaan tai yhteisöltä.
Meillä oli myös useita hypoteeseja:
- Kesäkuun kantaan tulee myrsky vastausta. Sinun on suodatettava satunnaiset vastaukset ansioluettelosi lähetysvaiheessa.
- Ensisijainen suodatin ei auta. — tarvitaan lisää testitehtäviä;
- Testitehtävät pelottavat kaikki pois - niitä ei tarvita.
Ja tietysti meillä oli tavoite: 4 junioria 3 viikossa.
Tämän oivalluksen myötä aloimme kokeilla. Suunnitelma oli yksinkertainen: aloita mahdollisimman leveimmästä suppilosta ja yritä vähitellen kaventaa sitä, jotta voit käsitellä kulkua, mutta älä vähennä sitä yhteen ehdokkaaseen viikossa.
Julkaisemme avoimen työpaikan
Yrityksen puolesta: Vastauksia tulee satoja! Ajattele suodatinta.
Juniorille: Älä pelkää kyselylomaketta ennen ansioluettelosi ja koetehtävän lähettämistä – tämä on merkki siitä, että yritys on pitänyt sinusta huolta ja prosessin aseteltu hyvin.
Ensimmäisenä päivänä saimme noin 70 ansioluetteloa hakijoilta, jotka tunsivat JavaScriptin. Ja sitten uudestaan. Ja kauemmas. Fyysisesti emme voineet kutsua kaikkia toimistolle haastatteluun ja valitsimme heistä tyypit, joilla oli siisteimmät lemmikkiprojektit, live Github tai ainakin kokemusta.
Mutta tärkein johtopäätös, jonka teimme itsellemme heti ensimmäisenä päivänä, oli, että myrsky oli alkanut. Nyt on aika lisätä kyselylomake ennen ansioluettelosi lähettämistä. Hänen tavoitteenaan oli karsia pois ehdokkaat, jotka eivät olleet halukkaita ponnistelemaan mahdollisimman vähän ansioluettelon lähettämiseksi, ja ne, joilla ei ollut tietoa ja kontekstia ainakin googlettaakseen oikeat vastaukset.
Se sisälsi vakiokysymyksiä JS:stä, ulkoasusta, webistä, tietojenkäsittelytieteestä - jokainen, joka kuvittelee, mitä he kysyvät etupään haastattelussa, tuntee ne. Mitä eroa on let/var/const välillä? Kuinka voin käyttää tyylejä vain alle 600 pikseliä leveille näytöille? Emme halunneet kysyä näitä kysymyksiä teknisessä haastattelussa - käytäntö on osoittanut, että niihin voidaan vastata 2-3 haastattelun jälkeen ymmärtämättä kehitystä ollenkaan. Mutta he pystyivät aluksi näyttämään meille, ymmärtääkö ehdokas periaatteessa kontekstin.
Jokaisessa kategoriassa valmistelimme 3-5 kysymystä ja päivä toisensa jälkeen muutimme niiden joukkoa vastauslomakkeessa, kunnes poistimme kelvollisimmat ja vaikeimmat. Tämä antoi meille mahdollisuuden vähentää virtausta - 3 viikossa saimme 122 ehdokasta, jonka kanssa voisimme työskennellä edelleen. Nämä olivat IT-opiskelijoita; kaverit, jotka halusivat siirtyä etupuolelle takaosasta; 25-35-vuotiaita työntekijöitä tai insinöörejä, jotka halusivat radikaalisti vaihtaa ammattiaan ja panostivat vaihtelevasti itsekoulutukseen, kursseihin ja harjoitteluihin.
Tutustua paremmin toisiinsa
Yrityksen puolesta: Testitehtävä ei karkoita ehdokkaita, mutta auttaa lyhentämään suppiloa.
Juniorille: Älä kopioi ja liitä testitiedostoja - se on havaittavissa. Ja pidä github kunnossa!
Jos kutsuisimme kaikki tekniseen haastatteluun, joutuisimme tekemään noin 40 haastattelua viikossa vain junioreille ja vain etupäässä. Siksi päätimme testata toista hypoteesia - testitehtävästä.
Mikä oli meille tärkeää testissä:
- Rakenna hyvä skaalautuva arkkitehtuuri, mutta ilman ylisuunnittelua;
- On parempi kestää kauemmin, mutta tehdä se hyvin, kuin koota käsityö yhdessä yössä ja lähettää se kommentilla "Saan ehdottomasti valmiiksi";
- Gitin kehityshistoria on insinöörikulttuuri, iteratiivinen kehitys ja se, ettei ratkaisua ole räikeästi kopioitu.
Sovimme, että halusimme tarkastella yhtä algoritmista ongelmaa ja pientä verkkosovellusta. Algoritmiset valmisteltiin alkeistason laboratorioiden tasolla - binäärihaku, lajittelu, anagrammien tarkistus, listojen ja puiden kanssa työskentely. Lopulta päädyimme binäärihakuun ensimmäisenä kokeiluvaihtoehtona. Verkkosovelluksen piti olla tic-tac-toe millä tahansa kehyksellä (tai ilman sitä).
Lähes puolet jäljellä olevista tyypeistä suoritti testitehtävän - he lähettivät meille ratkaisut 54 ehdokasta. Uskomaton oivallus - kuinka monta tic-tac-toe-toteutusta, joka on valmis kopioitavaksi, luulet olevan Internetissä?
Kuinka monta?Itse asiassa näyttää siltä, että niitä on vain 3. Ja suurimmassa osassa päätöksiä oli juuri nämä 3 vaihtoehtoa.
Mistä ei pitänyt:
- copy-paste tai kehitys samaan opetusohjelmaan ilman omaa arkkitehtuuria;
- molemmat tehtävät ovat samassa arkistossa eri kansioissa, ei tietenkään ole toimitushistoriaa;
- likainen koodi, DRY-rikkomus, muotoilun puute;
- mallin, näkymän ja ohjaimen sekoitus yhteen luokkaan satoja koodirivejä pitkäksi;
- yksikkötestauksen ymmärtämisen puute;
- "head-on" -ratkaisu on voittoyhdistelmien 3x3 matriisin kovakoodi, jota on melko vaikea laajentaa esimerkiksi 10x10:een.
Kiinnitimme huomiota myös viereisiin arkistoihin - hienot lemmikkiprojektit olivat plussaa, ja joukko muiden yritysten testitehtäviä oli enemmän herätys: miksi ehdokas ei päässyt sinne?
Tuloksena löysimme upeita vaihtoehtoja Reactista, Angularista, Vanilla JS:stä – niitä oli 29. Ja päätimme kutsua vielä yhden ehdokkaan testaamatta hänen upeita lemmikkiprojektejaan. Hypoteesimme testitehtävien hyödyistä vahvistui.
Tekninen haastattelu
Yrityksen puolesta: Keskikokoiset/eläkeläiset eivät ole tulleet luoksesi! Tarvitsemme yksilöllisemmän lähestymistavan.
Juniorille: Muista, että tämä ei ole koe - älä yritä olla hiljaa C:n takia tai pommittaa professoria kaiken mahdollisen tietosi virralla, jotta hän hämmentyy ja antaa "erinomaisen".
Mitä haluamme ymmärtää teknisessä haastattelussa? Yksinkertainen asia - miten ehdokas ajattelee. Hänellä on luultavasti kovia taitoja, jos hän on läpäissyt valinnan ensimmäiset vaiheet - jää nähtäväksi, osaako hän käyttää niitä. Sovimme 3 tehtävästä.
Ensimmäinen koskee algoritmeja ja tietorakenteita. Selvitimme kynällä, paperilla, pseudokielellä ja piirustusten avulla, kuinka puu kopioidaan tai miten yksittäin linkitetystä listasta poistetaan elementti. Epämiellyttävä havainto oli, että kaikki eivät ymmärrä rekursiota ja sitä, miten viittaukset toimivat.
Toinen on live-koodaus. Menimme , valitsi yksinkertaisia asioita, kuten lajitteli sanajoukon viimeisen kirjaimen mukaan ja yritti 30-40 minuuttia yhdessä ehdokkaan kanssa saada kaikki testit läpäisemään. Näytti siltä, ettei tic-tac-toe:n hallituilta kavereilta pitäisi tulla yllätyksiä - mutta käytännössä kaikki eivät ymmärtäneet, että arvo pitää tallentaa muuttujaan ja funktion pitäisi palauttaa jotain returnin kautta. Vaikka toivon vilpittömästi, että se oli tärinää, ja kaverit pystyivät käsittelemään näitä tehtäviä kevyemmissä olosuhteissa.
Lopuksi kolmas koskee hieman arkkitehtuuria. Keskustelimme hakupalkin tekemisestä, debouncen toiminnasta, erilaisten widgetien hahmontamisesta hakuvinkeissä, kuinka käyttöliittymä voi olla vuorovaikutuksessa takaosan kanssa. Siellä oli paljon mielenkiintoisia ratkaisuja, mukaan lukien palvelinpuolen renderöinti ja web-socketit.
Teimme 21 haastattelua tällä mallilla. Yleisö oli täysin monipuolinen - katsotaanpa sarjakuvia:
- "Raketti". Hän ei koskaan rauhoitu, sekaantuu kaikkeen, ja haastattelun aikana hän valtaa sinut ajatusvirralla, joka ei edes liity suoraan esitettyyn kysymykseen. Jos se olisi yliopistossa, tämä olisi tuttu yritys osoittaa, no, kaikki tietosi, kun muistat vain siitä lipusta, jonka kohtasit, että viime yönä päätit olla opiskelematta sitä - et silti pääse se ulos.
- "Groot". Häneen on melko vaikea saada yhteyttä, koska hän on Groot. Haastattelun aikana joudut viettämään pitkään aikaa saadaksesi vastauksia sana sanalta. On hyvä, jos se on vain stupor - muuten se on sinulle erittäin vaikeaa päivittäisessä työssäsi.
- "Drax". Työskentelin rahtiliikenteessä ja ohjelmoinnin suhteen opin JS:n vasta Stackoverflowssa, joten en aina ymmärrä, mistä haastattelussa keskustellaan. Samalla hän on hyvä ihminen, hänellä on parhaat aikomukset ja hän haluaa tulla loistavaksi etupään kehittäjäksi.
- No, luultavasti "Tähtien Herra". Kaiken kaikkiaan hyvä ehdokas, jonka kanssa voit neuvotella ja rakentaa vuoropuhelua.
Tutkimuksemme lopussa 7 ehdokasta pääsi finaaliin vahvistaen kovia taitojaan upealla testitehtävällä ja hyvillä haastatteluvastauksilla.
Kulttuuriin sopiva
Yrityksen puolesta: Työskentelet hänen kanssaan! Onko ehdokas valmis työskentelemään erittäin lujasti kehittymisensä eteen? Sopiiko hän todella joukkueeseen?
Juniorille: Työskentelet heidän kanssaan! Onko yritys todella valmis investoimaan juniorien kasvuun, vai heittääkö se kaiken lian työn sinun päällesi alhaisella palkalla?
Jokainen juniori saa tuotetiimin lisäksi mentorin, jonka johdon on suostuttava ottamaan hänet mukaan. Mentorin tehtävänä on ohjata häntä kolmen kuukauden prosessin läpi, jossa perehdytetään ja päivitetään kovia taitoja. Siksi tulimme jokaiseen kulttuurisovitukseen mentoreina ja vastasimme kysymykseen: "Otanko vastuun ehdokkaan kehittämisestä 3 kuukaudessa suunnitelmamme mukaan?"
Tämä vaihe sujui ilman erityispiirteitä ja toi lopulta meidät 4 tarjousta, joista 3 hyväksyttiin, ja kaverit pääsivät joukkueisiin.
Elämä tarjouksen jälkeen
Yrityksen puolesta: Pidä huolta junioreistasi, tai muut tekevät!
Juniorille: AAAAAAAAAAAA!!!
Kun uusi työntekijä tulee ulos, hänet on saatava mukaan – saatava ajan tasalla prosesseista, kertoa, miten kaikki toimii yrityksessä ja tiimissä ja miten hänen tulisi toimia ylipäätään. Kun juniori tulee ulos, sinun on ymmärrettävä, kuinka häntä kehittää.
Ajatellessamme saimme listan 26 taidosta, jotka meidän mielestämme juniorilla pitäisi olla kolmen kuukauden perehdytysjakson loppuun mennessä. Tämä sisälsi kovan taidon (pinomme mukaan), tuntemuksen prosesseistamme, Scrumista, infrastruktuurista ja projektiarkkitehtuurista. Yhdistimme ne etenemissuunnitelmaksi, joka jaettiin 3 kuukaudelle.
Tässä on esimerkiksi juniorini tiekartta
Määritämme jokaiselle juniorille mentorin, joka työskentelee hänen kanssaan erikseen. Mentorista ja ehdokkaan nykytasosta riippuen tapaamisia voidaan järjestää 1-5 kertaa viikossa 1 tunnin ajan. Mentorit ovat vapaaehtoisia etupään kehittäjiä, jotka haluavat tehdä jotain muutakin kuin vain kirjoittaa koodia.
Osa mentoreiden taakasta poistetaan pinomme kursseilla - Dart, Angular. Kursseja järjestetään säännöllisesti pienille 4-6 hengen ryhmille, joissa opiskelijat opiskelevat keskeytyksettä.
Keräämme 3 kuukauden aikana säännöllisesti palautetta junioreilta, heidän mentoreistaan ja johtajiltamme ja muokkaamme prosessia yksilöllisesti. Pumpatut taidot tarkistetaan 1-2 kertaa koko jakson aikana, sama tarkistus suoritetaan lopussa - niiden perusteella laaditaan suosituksia siitä, mitä on parannettava.
Johtopäätös
Yrityksen puolesta: Kannattaako junioreihin sijoittaa? Joo!
Juniorille: Etsi yrityksiä, jotka valitsevat huolellisesti ehdokkaat ja osaavat kehittää heitä
Kolmen kuukauden aikana kävimme läpi 3 kyselylomaketta, 122 testitehtävää ja teimme 54 teknistä haastattelua. Tämä toi meille 21 hienoa junioria, jotka ovat nyt suorittaneet puolet perehdytys- ja kiihdytyssuunnitelmastaan. He suorittavat jo todellisia tuotetehtäviä projektissamme, jossa on yli 3 2 000 koodiriviä ja yli 000 tietovarastoa pelkästään käyttöliittymässä.
Huomasimme, että junioreiden suppilo voi ja sen pitääkin olla varsin monimutkainen, mutta loppujen lopuksi sen läpi kulkevat vain ne kaverit, jotka ovat todella valmiita tekemään kovasti töitä ja panostamaan kehitykseensä.
Nyt päätehtävänämme on tehdä jokaiselle juniorille kolmen kuukauden kehitystiekartat henkilökohtaisessa työskentelyssä mentorin ja yleiskurssien kanssa, kerätä mittareita, palautetta liideiltä, mentoreista ja miehiltä itseltään. Tässä vaiheessa ensimmäinen kokeilu voidaan katsoa suoritetuksi, tehdä johtopäätöksiä, parantaa prosessia ja aloittaa uudelleen uusien ehdokkaiden valinnassa.
Lähde: will.com